| [wtp-dev] RE: WTP Facets Framework UI Walkthrough Notes |
|
Thanks everyone for taking
the time to review this UI and to provide the feedback. Unfortunately, I only
found out about this meeting a couple of hours before it was supposed to happen,
so I was not able to attend. See my comments inline... - Konstantin PS: For broader visibility, I
changed wtp-pmc list on this e-mail thread to wtp-dev. -----Original Message----- Hello, Here are the notes I have taken during the WTP Facets
Framework UI walkthrough that we did on Wednesday. There are some screenshot uploaded on the wiki that can
be used for a quick reference while reading the notes: http://wiki.eclipse.org/UI_Walkthrough_Facets I am sending these notes to Konstantin, who develops the
Facets Framework, WTP PMC list and UI Working Group list. Konstantin, I assume you will have questions. You can
discuss them in the UI Working Group list. We may make another
walkthrough on facets in a few weeks if needed. Notes follow... The first wizard page of the Project Creation wizards
looks OK and complies with the Eclipse UI guildelines. http://wiki.eclipse.org/Image:Screenshot_facets_1.png The idea for choosing the version of the primary facet on
the first wizard page is accepted well. When looking at the Project Facets dialog (http://wiki.eclipse.org/Image:Screenshot_facets_2.png)
and the Project Facets property page (http://wiki.eclipse.org/Image:Screenshot_facets_3.png)
there are lot of recommendations suggested. * the checkbox in front of each facet - the current situation is that if the facet
cannot be uninstalled, the checkbox cannot be unchecked. Instead a tooltip pops
up explaining why it cannot be unchecked. This tooltip is quite a
strange idea and does not comply with the Eclipse UI guidelines [kosta] This is a third
iteration at this UI element and one that has been best-received by users.
We’ve tried simply not allowing the operation (users are confused by lack
of visual feedback). We’ve tried a msg box popup (users don’t like
because it’s too jarring). - checkboxes that should not be unchecked should
be grayed [kosta] There is no such
thing as a disabled checkbox in a checkbox tree. "Gray" checkboxes
are used for showing partially-selected parent nodes and are not even gray on
some platforms (such as WinXP with default theme). - even better all checkboxes should be allowed to
be unchecked, but if the user unchecks a facet that cannot be uninstall, then
an validation error should appear. [kosta] I personally think that
if an operation is not allowed, good UI should prevent that operation.
Unfortunately, the checkbox tree control simply does not handle this scenario,
so we had to think outside of the box. It would not be an improvement to show a
validation message in this situation if the only corrective action is to
reverse what the user just did. Much better to not allow the user to do it in
the first place. * locking/unlocking - locking of facets is very weird and it seems
that nobody (except Konstantin) knows what exactly it does. It seems like it
filters facets depending on their constraints. [kosta] The concept of locked
facets has existed in the framework from the start, but Lock/Unlock UI was only
made available in 3.0 as part of providing the generic Faceted Project Wizard
feature. This feature was introduced at the request of power users who wanted
to be able to create any faceted project (as allowed by facet constraints).
Vast majority of users will never use this feature as they interact with the
framework via specialized project creation wizards (such as Dynamic Web Project
or EJB) that pre-configure the locked facets in a manner that’s
consistent with those project types. - if it is about filtering of facets, it would be
much clearer for the user if there is a global checkbox for showing/hiding the
appropriate facets for the current use case. [kosta] It is about filtering
facets. By combining information about locked facets with declared facet
constraints, we are able to present to the user only the facets that are
applicable in that context. I don’t understand the specific suggestion
mention here, so I will not comment on that. * validation - the idea of showing validation errors is very
much liked - validation error entries should not be
selectable. Currently, they are and it this implies that the user can do something
with this error (like quick fix), but actually he has no options for
actions. [kosta] This is left open to
enable future support for things like quick fixes and context sensitive help.
This is also important for accessibility. - validation errors should not appear in the
special widget below the facets list view, but in the dialog box title, or the
property page title. This is according to the Eclipse UI guidelines. [kosta] This comment comes up
often. Unfortunately, the banner support for messages is not capable of dealing
with requirements of this UI. The guidelines say that you are supposed to pick
one error at a time to present to the user. Once the user fixes that problem,
you are supposed to present the next one. That works ok when problems are not
inter-related. In this case, most of the problems that are displayed are facet
constraint validation issues. By their nature they are very inter-related. Without
seeing the whole picture (all validation problems), it would be very difficult
for the user to figure out the appropriate corrective action. Think of it as
trying to fix 100 compile errors in java in a tool that presents you with one
random compiler error at a time until you fixed them all. It’s not quite
that bad, but in downstream products where you have dozens of facets to deal
with, it is not uncommon to have half a dozen validation messages to present to
the user. [kosta] It is also worth noting
that the same UI panel appears in a banner dialog as well as inside of a
project properties page. Any problems display solution needs to be able to work
in both cases. * Configurations drop-down - The Save button should have ellipsis :-) [kosta] Good catch. I opened https://bugs.eclipse.org/bugs/show_bug.cgi?id=234885 - It would be better that the Save/Delete buttons
are replaced with Edit/Remove/New/Import buttons like in the Java > Code
Style > Formatter preferences page. - Save/Delete seems to be rarely used, even never
by the ordinary users. So, it is better to remove them at all. - Creating and Deleting of facet configurations
should be moved in a Preferences page. A link ("Configure") to this
preferences page could replace the Save/Delete buttons. [kosta] The suggestion to put
management of configurations into preferences has come up before. There is an
enhancement request to track that possibility. Some UI mockups are available on
a wiki linked from one of the comments. https://bugs.eclipse.org/bugs/show_bug.cgi?id=191715 * Runtime view - again validation errors are better than filtering.
The user should see all available runtimes, otherwise it may be
frustrating why a certain runtime is not available. When selecting invalid
runtime, a validation error should appear. [kosta] Yes, filtering of
runtimes and lack of feedback regarding why a runtime is not available has been
reported as a problem by users in the past. Some work was done to try to
improve the situation, but I agree that the current state is still not optimal.
I have opened an enhancement request to track taking another pass at this
issue. More details there. https://bugs.eclipse.org/bugs/show_bug.cgi?id=234892 Greetings, Kaloyan Raev Eclipse WTP Committer <http://www.eclipse.org/webtools/people/person.php?name=raev>
Senior Developer NW C JS TOOLS JEE (BG) SAP Labs Bulgaria T +359/2/9157-416 mailto:kaloyan.raev@xxxxxxx www.sap.com P Save a tree - please do not print this email unless you
really need to! Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it. |