Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-dev] RE: [ui-best-practices-working-group] WTP Facets Framework UI Walkthrough Notes

Thanks, Eugene. I am changing this thread from wtp-pmc to wtp-dev as it should be more broadly visible. Could you forward it to ui-best-practices-working-group? I am not subscribed.


See my comments inline.


- Konstantin



-----Original Message-----
From: Eugene Kuleshov [mailto:eu@xxxxxxxx]
Sent: Friday, May 30, 2008 9:32 AM
To: User Interface Architecture Working Group
Cc: Konstantin Komissarchik; WTP PMC communications (including coordination, announcements, and Group discussions)
Subject: Re: [ui-best-practices-working-group] WTP Facets Framework UI Walkthrough Notes


Raev, Kaloyan wrote:


  I have few additional comments. Please see below:

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


  I haven't heard from UI Expert group about this, but I think this page

is overusing groups for single elements. If there is just one element in

the group you should be using just plain label and not a group. Then UI

would look less crowded.


[kosta] If there is a particular way you think this should look, could you open an enhancement request with a mockup or a detailed description? I find that it is difficult to balance UI where there is a mixing of controls that are inside groups with those that are not inside groups, but perhaps some of the groups can be consolidated (or something like that).


  Also, ordering of fields is somewhat odd. It seems like the primary

control there is the EJB facet version (btw, should it be called "EJB

specification version" or something like that?), and then if this EJB

should be added to EAR or not. Then, perhaps, "Target runtime". And then

configuration (is it EJB faced configuration or configuration for the

target runtime? also unclear from the UI).


[kosta] There was an involved discussion regarding this. The current ordering is based on the idea that most users are constrained by their choice of the runtime environment. That is, most users don’t get to write the app first and then shop around for compatible runtimes. Thus the current flow.


[kosta] EAR selection currently can affect runtime, spec and configuration fields. This is a hold-over from pre-3.0 days when that behavior was less problematic and some would argue desirable. The EAR selection behavior was supposed to change along with other changes, but that didn’t happen for 3.0. Maybe Chuck or Jason can reply with a bug reference.


[kosta] Regarding the label for the EJB module version combo, I argued to use the word spec there (same in other WTP wizards), but lost that argument.


> When looking at the Project Facets dialog

> ( and the Project

> Facets property page

> ( there are lot of

> recommendations suggested.


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

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



  It been suggested to investigate if lock/unlock can be replaced with

"show all" or "show only valid/available facets"


[kosta] This doesn’t work. The information about locked facets is key in figuring out the list of available facets.


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

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



  You can also try to show error decoration on conflicting invalid

entries and then show more detailed error on the details tab.


[kosta] I have considered adding decorations on facets to provide secondary feedback to tie in with validation, but this doesn’t really address the consistency comment from the working group.


> * Configurations drop-down

>   - The Save button should have ellipsis :-)

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


  Boris pointed out that it is confusing to have Save and Delete buttons

next to "Configurations" drop down (should it be called "Templates"?)

and compared this UI with project prefs / Java Code Style / Formatter,

which uses "Edit.../Remove" approach (though personally I think it is

not the same as facet UI)

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


  Bob also suggested to have entry like "Save as new..." in the

"Configurations" dropdown.

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



  Mik and Boris pointed out that it is hard to figure out why certain

selections are removed (e.g. removing versions of war facet only when

particular tomcat runtime is selected). It been said that in this case

it is better to allow user select an invalid combination and show him a

error that selected combination is conflicting or invalid.


[kosta] In practice this hasn't been a problem for users. Users easily grasp the concept that available facets are constrained by runtimes that are selected. The natural "what’s supported by my platform" relationship. Showing everything is not realistic as it would create information overload. Once you put a couple of products on top of WTP, you might easily have several dozen of facets available most of which aren’t applicable in a particular context. Users would be lost without filtering.


  From myself I also would like to add that it is somewhat confusing to

have two somewhat parallel concepts - facets and runtimes. They can be

selected independently, but then they also related to each other. Why

runtimes aren't facets?


[kosta] With enough generalization everything is an Object. :) Again, in practice users seem to have no problem telling the difference between the concept of runtimes (something your app will run on) and facets (features that you choose to use in your app). Not sure what would be gained (at least from user’s perspective) by trying to conflate the two.






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