| [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----- 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. >
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. > 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 >
(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. > > * 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. regards, Eugene 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. |