Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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-----
From: Raev, Kaloyan [mailto:kaloyan.raev@xxxxxxx]
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




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:


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.

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

( and the Project

Facets property page

( 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


  - 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.


* 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.




Kaloyan Raev

Eclipse WTP Committer


Senior Developer


SAP Labs Bulgaria

T +359/2/9157-416



P Save a tree - please do not print this email unless you really need



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.

Back to the top