10 Aug
2009
10 Aug
'09
11:43 a.m.
Guillaume Lerouge wrote:
Hi,
On Fri, Aug 7, 2009 at 10:15 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com>wrote;wrote:
Although widely used on the web, the "?" solution still requires the user to
think about hovering it (which is almost the same as the tooltip solution --
although much more intuitive in this case). And it's also relatively technically
demanding at this point (potentially not safe for the 2.0 frame).
Also, this will have to be aligned with a general view on form helps, for
consistent look & feel across the wiki.
FTM, I think it could be solved exclusively through wording (good wording ==
shorter texts), and limiting the help labels to the necessary ones.
Thanks,
Anca
Anca Paula Luca wrote:
should be
the
Given the potential space issue, I'm ok for 3) too. I'll update the wiki
page to suggest another wording for top level titles so that dialog titles
and wizard step titles work nicely together.
Overall, it feels like too many descriptions there by default, too much
Guillaume Lerouge wrote:
> Hi Devs,
> Anca asked me to finalize the overall look of dialog boxes in the
WYSIWYG so
> that she can work on it and polish it for the
2.0 release. Right now the
> issue is that we're using a different look for the link, image & macro
> dialog boxes which poses a consistency problem.
>
> I've been working with Cati on a proposal for the look of the overall
box
-
> not for the inner part of the box. Proposals
for the standardization of
the
> inner part of the box will come later. The
dialog box uses a wizard-like
> look and follows the vertical form principles proposed by Cati in a
previous
> email (thus the primary action button at the
bottom left, to follow the
> user's eye flow). Its "hidden" features are:
>
> - Buttons can be in an enabled or disabled mode depending of what the
> current step is
> - All buttons are displayed all the time so that they don't move from
one
> screen to the next
> - Buttons' labels are configurable
> - There is no "Cancel" button, the cross at the top right of the
dialog
> box plays that role
> - The title in the top bar doesn't change and its name is the same as
the
> associated toolbar button (clicking on
"Link" opens a dialog box
called
"Link")
The user never clicks on just "Link", it is always a
submenu item that it
chooses ("Wiki page", "Attached file", etc). I assume the dialog
title a combination of the two, since only the name of
the submenu item is far
from
suggestive.
wdyt?
> - The "Wizard Step Title" reflects what's happening at the current
step:
> "Page Selection" , "Code
Macro" , "Image Selection"
> - The description tells the user what to do at the current step:
"Select
the
page to link to" , "Select the image to insert" , "Fill in macro
parameters"
After discussion we came to the conclusion that the
description will tell user what will be the result of the current step,
and not instructions
about how
to do it. All instructions will go next to the
field in the form of the
wizard step.
Also this description can be skipped if the title
is good enough, to
avoid
redundancy.
At this point, I am afraid
that these two will take up too much space,
while
being slightly redundant. Since a description can be quite long, it could
span
on 2 lines of text. + 1 line the title = 3 lines in the dialog header.
Right now
the header is only one line of text. An experiment showed it to take over
twice
the space if a description is included and this space would be taken from
the
content of the dialog. With even more help labels (for fields, for example)
this
can turn into a space issue. For example, in the case of a link target
document
selection we would have a title + description in the header, then the tabs
strip
then another help label about how the selection should be made in the
selected
tab and only after that the actual list of pages to select from.
Now, we have two choices for the header:
1/ we make it variable height and resizes with its content.
advantages: leaves more space when it's not there, flexible with the size
of
text to encapsulate
disadvantages: variable size is disturbing. Even so, the proposal was to
have
descriptions for steps everywhere so not much space would be saved. Also,
it
could be technically hard to implement the variable size correctly cross
browser
& platform and flexible with i18n.
2/ fixed height, to comprise 2-3 lines of description text, ensuring that
all
labels would fit. If description is missing, the title would be vertically
centered.
advantages: fixed size consistent across multiple steps & dialogs,
potentially
easy to implement
disadvantages: could take too much space for nothing, all descriptions
would
need to fit the available space.
3/ Drop the description in the header, as the current implementation is.
advantages: more space
disadvantages: one explanation less (do we really need it except for the
macro
parameters dialog?)
I would go for 3) with appropriate wording on dialog titles, fields help
labels,
and wizard step titles.
text,
which could cause problems to in most of the cases, when users already know
how
to use the wysiwyg and the text would just take up space for nothing.
Well, this issue isn't easy to address. We could hide explanations under a
"?" sign located next to each field and display it on hover, but that
requires extra work.
Guillaume
WDYT?
Thanks,
Anca
fields.
> - Double-clicking on an item (an image, a
page name) acts in the same
> fashion as selecting it and clicking the "Next" button. If the
"Next"
button
> is disabled at the current step,
double-clicking works as the primary
action
("Insert" , "Create")
Also, webforms usually are submitted when
enter is hit in one of their We also do this currently in our dialog forms. In
the case when "Finish"
and
"Next" are both enabled, which one
should be the one executed by enter?
I'd go
for "Next" for consistency.
Also, for the case when the wysiwyg dialog is not a wizard (table,
importer
dialogs for the moment), we have two options for
the wizard step title:
1/ keep the Wizard Step and Descriptions in place, to contain detailed
description of the action to be executed, for consistency reasons. While
the
dialog title will be the same as the toolbar
button / menu clicked, the
Wizard
Step title will contain a more detailed
description of the action and the
description will probably be missing most of the times since it's
redundant.
2/ we remove the top bar completely, as it
currently is the case for the
table &
importer dialogs, to avoid crowding the dialogs
with redundant
information (the
title of the dialog should be enough information,
as it's only one action
and
that is the actual name of the action -- as
opposed to wizard steps where
differentiation of various subactions is needed).
Guillaume's suggestion was for strong consistency, therefore 1/. I think
that,
while it could turn out useful, it can be
confusing to have multiple
titles for
a dialog when they refer to the same action.
wdyt?
In general, we would love some feedback about the UI / UX of the wysiwyg
dialogs, things that should be polished for a final version.
Thanks,
Anca
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
The mockups are located at:
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs