oslc-core message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Re: [oslc-core] Usability of delegated UIs
- From: Steve K Speicher <sspeiche@us.ibm.com>
- To: "Lonnie VanZandt" <lvanzandt@sodius.com>
- Date: Tue, 25 Nov 2014 13:48:55 -0500
Lonnie,
This is good feedback. I think
you conclude on an important item though, the application should make it
easy. Typically these dialogs are exposed for a given purpose, therefore
they should be designed to help satisfy this purpose which might be some
preset filters like: test cases without links to reqs, etc. This
wouldn't require any new specification, which has its benefits. Perhaps
just a publication of best practices on knowing how best to expose purposeful
dialogs and guidance on what to put in it. For example, I've seen
selection dialogs offer the ability to create new resources as well. Which
makes good sense in many cases, if you can't find a good one to select,
then create one.
Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net
From:
"Lonnie VanZandt"
<lvanzandt@sodius.com>
To:
Steve K Speicher/Raleigh/IBM@IBMUS
Cc:
"Ian Green1"
<ian.green@uk.ibm.com>, "OASIS OSLC Core TC Discussion List"
<oslc-core@lists.oasis-open.org>
Date:
11/25/2014 09:40 AM
Subject:
Re: [oslc-core]
Usability of delegated UIs
At Sodius, while working on the delegated dialogs for
the OSLC RLIA Windchill integration, we did discuss usability capabilities
like these. For example, we considered—but ran short of time to pursue—offering
the user the choice to run one of several preconfigured Queries in the
Delegated Selection Dialog. In the current product, the user can only enter
search terms for the dcterms:title and dcterms:shortTitle parameters. As
another example of delegated dialog usability, we chose to use Angular
and Bootstrap for the UI elements. While we hardly exploit it yet, this
provides a foundation from which we could allow our dialogs to be “mobile-first”,
tablet-friendly, and responsive to changes in screen size and resolution.
With a bit of labor on the implementation of our UI widgets in the dialogs,
we could offer the user the choice of custom columns (practical filtering
of the resources’ attributes) and column sorting.
Clearly, once you start interacting with a user and designing
attractive and ergonomic interfaces, the field of opportunities becomes
large (and currently largely unplowed).
Before concluding, returning to Ian’s example, the Selection
Dialog—if it supported user-selected filtering—could offer what he seeks
through the application of the additional filter of rejecting each candidate
testcase that is in the requirement’s related testcases set.
—
Lonnie VanZandt
303-900-3048
Sent from Dropbox's Mailbox on
Mac
On Tue, Nov 25, 2014 at 7:07 AM, Steve K Speicher <sspeiche@us.ibm.com>
wrote:
I have not heard of any work like this
or anyone providing this use case, though I can see how it would be helpful.
We've only dealt with "prefilling" creation dialogs, not sure
it would follow a certain model by which providers exposed "dialog
factories" and you could post a set of resources to exclude and the
provider could return a URL that would possible satisfy it. Another
option possibly would be for the dialogs (frames) to just communicate over
existing postMessage(). Just thinking out loud.
Thanks,
Steve Speicher
IBM Rational Software
OSLC - Lifecycle integration inspired by the web -> http://open-services.net
From: Ian
Green1 <ian.green@uk.ibm.com>
To: "OASIS
OSLC Core TC Discussion List" <oslc-core@lists.oasis-open.org>
Date: 11/25/2014
08:17 AM
Subject: [oslc-core]
Usability of delegated UIs
Sent by: <oslc-core@lists.oasis-open.org>
One of the apparent limitations of the delegated UI protocol is that the
resource views offered to the user cannot be adjusted according to the
user's scenario.
For example, the user wants to make a link between a requirement and a
test case, and so must pick a test case. The RM application then
makes a link to the selected test case. In this scenario it would improve
usability if the QM provider would not offer for selection test cases which
are already linked from the requirement. This is a bit contrived but I
hope it illustrates the issue.
Is anyone aware of previous work or exploration in this area? I am
aware of the work being done in the CM TC where configuration context may
be used to inform the picker behaviour (for example, filtering resources
to those in the specified context).
best wishes,
-ian
ian.green@uk.ibm.com (Ian Green1/UK/IBM@IBMGB)
IBM Rational
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]