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-----
From: Raev, Kaloyan [mailto:[EMAIL PROTECTED]
Sent: Friday, May 30, 2008 2:16 AM
To: Konstantin Komissarchik; User Interface Architecture Working Group;
WTP PMC communications (including coordination, announcements,and Group
discussions)
Subject: WTP Facets Framework UI Walkthrough Notes
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
<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
<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
<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:[EMAIL PROTECTED]
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._______________________________________________
wtp-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/wtp-dev
