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