Hi,
On Fri, Aug 7, 2009 at 10:15 PM, Anca Paula Luca
<[email protected]>wrote:
> Anca Paula Luca wrote:
> > 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
> should be
> > 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
> the
> > 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.
>
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
> 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
>
> >
> >> - 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
> fields.
> > 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
> >
> >> The mockups are located at:
> >> http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
> >>
> >> WDYT?
> >>
> >> Guillaume
> >>
> > _______________________________________________
> > devs mailing list
> > [email protected]
> > http://lists.xwiki.org/mailman/listinfo/devs
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/devs
