5 Aug
2009
5 Aug
'09
11:45 a.m.
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 "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"
- 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")
The mockups are located at:
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
5 Aug
5 Aug
3:51 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Guillaume Lerouge wrote:
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
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.
- 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.
5:07 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi,
On Wed, Aug 5, 2009 at 3:51 PM, Anca Paula Luca <ancapaula.luca(a)xwiki.com>wrote;wrote:
Me too. Hitting enter should behave in the same fashion as double-clicking
-> trigger "Next" (unless the user is on the last screen).
Also, for the case when the wysiwyg dialog is not a wizard (table, importer
Guillaume Lerouge wrote:
I still think that keeping the tab's label as dialog box title is easier
since it doesn't require an additional rule (how should both things be
combined?). Clicking on something under the "Link" button opens a dialog box
called "Link" -> simple, easy, effective.
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.
- 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. 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?
I'm still in favor of 1/ for consistency reasons. I think that if the
wording is done correctly, the redundancy can be kept to a minimum.
In general, we would love some feedback about the UI / UX of the wysiwyg
dialogs, things that should be polished for a final
version.
Indeed, please feel free to join the discussion and shed some light on our
ideas :-)
Guillaume
Thanks,
Anca
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
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
7 Aug
7 Aug
10:15 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
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.
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.
WDYT?
Thanks,
Anca
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. - 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
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
10 Aug
10 Aug
10:57 a.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi,
On Fri, Aug 7, 2009 at 10:15 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com>wrote;wrote:
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.
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
> - 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
11:43 a.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
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
7 Aug
7 Aug
2:07 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
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.
Also, we have started a set of guidelines for the inner part of the dialogs at
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix
which contains the current implementation or implementation plan.
Also we should make sure this is consistent with the overall xwiki conventions.
Please add any suggestions you might have.
Thanks,
Anca
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 "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"
- 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")
The mockups are located at:
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
17 Aug
17 Aug
5:01 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Hi devs,
I'd like to have your opinion on punctual approaches for the consistent design
of the wysiwyg dialogs. Please vote and comment on the issues discussed at:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix .
We specifically need to make decisions on the following topics:
1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A
2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+0.2 for E, +0.4 for F, +0.4 for H
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for B
WDYT?
Thanks a lot,
Anca
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 "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"
- 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")
The mockups are located at:
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
5:05 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Anca Paula Luca wrote:
Hi devs,
I'd like to have your opinion on punctual approaches for the consistent design
of the wysiwyg dialogs. Please vote and comment on the issues discussed at:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix .
We specifically need to make decisions on the following topics:
1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A
2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+0.2 for E, +0.4 for F, +0.4 for H
I forgot to number the current implementation, this becomes:
+0.2 for F, +0.4 for G, +0.4 for H
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for B
WDYT?
Thanks a lot,
Anca
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 "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"
- 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")
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
5:11 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Hi Devs,
On Mon, Aug 17, 2009 at 5:05 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com>wrote;wrote:
+1 for D as it's the one that stands out the more visually. If others think
it pops up too much I'm also +1 for G
+1 for B
We're looking for your feedback ! (Thibaut, Caty time for you to chip in ;-)
Thanks,
Guillaume
Anca Paula Luca wrote:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix.
> We specifically need to make decisions on the following topics:
> 1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
> +1 for A
+1 for A with a left-aligned title
Hi devs,
I'd like to have your opinion on punctual approaches for the consistent
design
of the wysiwyg dialogs. Please vote and comment
on the issues discussed
at:
2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+0.2 for E, +0.4 for F, +0.4 for H
I forgot to number the current implementation, this becomes:
+0.2 for F, +0.4 for G, +0.4 for H
WDYT?
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Thanks a lot,
Anca
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 "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"
> - 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")
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 
5:27 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
On Aug 17, 2009, at 5:01 PM, Anca Paula Luca wrote:
Hi devs,
I'd like to have your opinion on punctual approaches for the
consistent design
of the wysiwyg dialogs. Please vote and comment on the issues
discussed at:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix
.
We specifically need to make decisions on the following topics:
1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A
+1 for A (left aligned) but then I couldn't understand what B is about
(lots of text to read...).
2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+0.2 for E, +0.4 for F, +0.4 for H
+1 for H (ie "Required" text) but with the orange color on the field
name + "Required part.
I like "Required" since it makes it obvious and doesn't require a
legend (Using "*" would require a legend).
+1 for C2 (ie all errors reported) but with error text above field
(and not below as in C2).
For tree: +1 for D
Thanks
-Vincent
+1 for B
WDYT?
Thanks a lot,
Anca
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 "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"
> - 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")
>
> The mockups are located at:
> http://incubator.myxwiki.org/xwiki/bin/view/Mockups/
> GenericMacroDialog
>
> WDYT?
>
> Guillaume
5:53 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Vincent Massol wrote:
All errors will be reported anyway, the C2 is only for demonstration purposes,
to see how it looks (we wanted to check if how would the error below look like
in the context of multiple errors).
so that's another vote for B.
On Aug 17, 2009, at 5:01 PM, Anca Paula Luca wrote:
B is about Guillaume's initial proposal in this thread (dialog title + step
title + step description for each wizard step).
Hi devs,
I'd like to have your opinion on punctual approaches for the
consistent design
of the wysiwyg dialogs. Please vote and comment on the issues
discussed at:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix
.
We specifically need to make decisions on the following topics:
1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A
+1 for A (left aligned) but then I couldn't understand what B is about
(lots of text to read...). 2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+0.2 for E, +0.4 for F, +0.4 for H
+1 for H (ie "Required" text) but with the orange color on the field
name + "Required part.
I like "Required" since it makes it obvious and doesn't require a
legend (Using "*" would require a legend).
+1 for C2 (ie all errors reported) but with error text above field
(and not below as in C2).
For tree: +1 for D
I agree that D looks a lot better for the tree, but style-wise it's inconsistent
with the other errors in wizard forms. The trees / lists are still forms, part
of the same wizard and I think they should all look the same.
Thanks for your votes,
Anca
Thanks
-Vincent
+1 for B
WDYT?
Thanks a lot,
Anca
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 "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"
> - 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")
>
> 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 
5:38 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Anca Paula Luca wrote:
Hi devs,
I'd like to have your opinion on punctual approaches for the consistent design
of the wysiwyg dialogs. Please vote and comment on the issues discussed at:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix .
We specifically need to make decisions on the following topics:
1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A
+1 for current implementation (only green color)
+0.5 for G (required)
I don't like the rest.
+0.2 for E, +0.4 for F, +0.4 for H
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for current implementation (just red-colored message)
Marius
+1 for B
WDYT?
Thanks a lot,
Anca
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 "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"
- 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")
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 
6:02 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Anca Paula Luca wrote:
Hi devs,
I'd like to have your opinion on punctual approaches for the consistent design
of the wysiwyg dialogs. Please vote and comment on the issues discussed at:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix .
We specifically need to make decisions on the following topics:
1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A
2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+0.2 for E, +0.4 for F, +0.4 for H
+1 for H. Color alone is not good (color blindness?). Plus, there's no
standard color for "mandatory", a color does not mean anything without
an explanation, so colors are not intuitive for everyone (green usually
means that it's OK, while red/orange-red means that there is an error).
An asterisk alone doesn't bring much value, either, without an explanation.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
19 Aug
19 Aug
11:56 a.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A with a left-aligned title (keep the consistency with the left
alignerd forms)
*2. *
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 F, G, H with modifications:
F - * need somewhere to be stated that * means Required
- the location of the star changes the position with the length of the
label
G - from a visual scanning point of view, it's better that they are at the
beginning of the line and the stars are not changing their position
- but the star should be outside the alignment of the text
- also somewhere needs o be stated the meaning of the star
H - is the most straight forward
- Required should have another color than the explanatory text ("Type the
address...") so it pops out
I agree with Sergiu that green is not the best color for required fields.
Also it has low contrast with black and white.
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 C1 because is a separation between the explanatory text and the error
text. Putting it below makes sense for me to have this separation. The red
color is ok.
I don't like the green of the labels for the mandatory fields. Too many
colors and means nothing for me that the fields are green.
12:10 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Hi,
A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <valicac(a)gmail.com>wrote;wrote:
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A with a left-aligned title (keep the consistency with the left
alignerd forms)
Pretty much everyone agreed on left-aligned title.
*2. *
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 F, G, H with modifications:
F - * need somewhere to be stated that * means Required
- the location of the star changes the position with the length of the
label
G - from a visual scanning point of view, it's better that they are at the
beginning of the line and the stars are not changing their position
- but the star should be outside the alignment of the text
- also somewhere needs o be stated the meaning of the star
H - is the most straight forward
- Required should have another color than the explanatory text ("Type the
address...") so it pops out
I agree with Sergiu that green is not the best color for required fields.
Also it has low contrast with black and white.
Proposal H got the most vote. I agree with Caty on the fact that make it
colored would pop out more. As long as it's a dark enough color I think it
won't hinder accessibility.
Thus I'm suggesting we use H but with "required" printed in the orange
color
used in proposal G.
WDYT?
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 C1 because is a separation between the explanatory text and the error
text. Putting it below makes sense for me to have this separation. The red
color is ok.
I don't like the green of the labels for the mandatory fields. Too many
colors and means nothing for me that the fields are green.
B got 3 votes, A one, C one. B & C are quite similar (text above or below
the error). Having text at the top is better in the tree configuration and
it doesn't make that much of a difference for regular fields.
Thus I suggest we go for B.
We're short on time here, please cast your -1 quickly if you disagree with
this.
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
1:15 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Hi,
A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica
<valicac(a)gmail.com>wrote;wrote:
+1 for A and left align.
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A with a left-aligned title (keep the consistency with the left
alignerd forms)
Pretty much everyone agreed on left-aligned title.
*2. *
All the colors that are used in the proposals are too strong, orange is
too much for a mandatory field. The primary focus should be on the field
title, and the secondary one on the required mark. Either we keep H, or we
use B and add a legend for the asterix. This is the most comune way of
marking mandatory fields, and most of the users are used to it. If they
don't notice the asterix, they will be notified.
There would be another solution, to add a light yellow background color to
the mandatory fields, and of course, add a legend for that color.
+1 for H as it is
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 F, G, H with modifications:
F - * need somewhere to be stated that * means Required
- the location of the star changes the position with the length of the
label
G - from a visual scanning point of view, it's better that they are at
the
beginning of the line and the stars are not changing their position
- but the star should be outside the alignment of the text
- also somewhere needs o be stated the meaning of the star
H - is the most straight forward
- Required should have another color than the explanatory text ("Type
the
address...") so it pops out
I agree with Sergiu that green is not the best color for required
fields.
Also it has low contrast with black and white.
Proposal H got the most vote. I agree with Caty on the fact that make it
colored would pop out more. As long as it's a dark enough color I think it
won't hinder accessibility.
Thus I'm suggesting we use H but with "required" printed in the orange
color
used in proposal G.
WDYT?
3.
There is a big difference between B and C.
+1 for C, because the field title and the help section should not be mixed
with the error message. The user should easily distinguish between
different kind of informations from inside the interface.
Raluca.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 C1 because is a separation between the explanatory text and the error
text. Putting it below makes sense for me to have this separation. The
red
color is ok.
I don't like the green of the labels for the mandatory fields. Too many
colors and means nothing for me that the fields are green.
B got 3 votes, A one, C one. B & C are quite similar (text above or below
the error). Having text at the top is better in the tree configuration and
it doesn't make that much of a difference for regular fields.
Thus I suggest we go for B.
We're short on time here, please cast your -1 quickly if you disagree with
this.
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
4:10 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Guillaume Lerouge wrote:
dark enough color is not compatible with that orange flavour :) . I can do a
prototype but I think it will be a lot too much (since it's more than just a
sign, it's a full word orange).
how about H as is? (compatible with the link you gave me to
http://www.cxpartners.co.uk/thoughts/web_forms_design_guidelines_an_eyetrac…
guideline 5 where normal colors are used).
Hi,
A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <valicac(a)gmail.com>wrote;wrote:
I used the same color & style for "required" as for the explanatory text
because
it's the same type of information, explanations for the field. The position next
to the field label is supposed to distinguish it from the rest of the explanation.
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A with a left-aligned title (keep the consistency with the left
alignerd forms)
Pretty much everyone agreed on left-aligned title.
*2. *
>
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
> +1 F, G, H with modifications:
> F - * need somewhere to be stated that * means Required
> - the location of the star changes the position with the length of the
> label
>
> G - from a visual scanning point of view, it's better that they are at the
> beginning of the line and the stars are not changing their position
> - but the star should be outside the alignment of the text
> - also somewhere needs o be stated the meaning of the star
>
> H - is the most straight forward
> - Required should have another color than the explanatory text ("Type the
> address...") so it pops out
I agree with Sergiu that green is not the best color for required fields.
Also it has low contrast with black and white.
Proposal H got the most vote. I agree with Caty on the fact that make it
colored would pop out more. As long as it's a dark enough color I think it
won't hinder accessibility.
Thus I'm suggesting we use H but with "required" printed in the orange
color
used in proposal G.
WDYT?
3.
Since Marius' vote for A was based on the fact that too much red is scary (and I
agree users fear errors), but a red-bordered field is useful to better associate
the error with the field, I'd go for a lighter red (compatible with the grey
labels). I'll do a prototype asap. WDYT?
Thanks,
Anca
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 C1 because is a separation between the explanatory text and the error
text. Putting it below makes sense for me to have this separation. The red
color is ok.
I don't like the green of the labels for the mandatory fields. Too many
colors and means nothing for me that the fields are green.
B got 3 votes, A one, C one. B & C are quite similar (text above or below
the error). Having text at the top is better in the tree configuration and
it doesn't make that much of a difference for regular fields.
Thus I suggest we go for B.
We're short on time here, please cast your -1 quickly if you disagree with
this.
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:11 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
I added prototype I to illustrate this. The orange used is the "wiki standard
colors" orange (which could, of course be grayed a bit to match the other labels).
Hi,
A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <valicac(a)gmail.com>wrote;wrote:
I used the same color & style for "required" as for the explanatory text
because
it's the same type of information, explanations for the field. The position next
to the field label is supposed to distinguish it from the rest of the explanation.
>> I agree with Sergiu that green is not the best color for required fields.
>> Also it has low contrast with black and white.
>>
> Proposal H got the most vote. I agree with Caty on the fact that make it
> colored would pop out more. As long as it's a dark enough color I think it
> won't hinder accessibility.
>
> Thus I'm suggesting we use H but with "required" printed in the orange
color
> used in proposal G. * 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A with a left-aligned title (keep the consistency with the left
alignerd forms)
Pretty much everyone agreed on left-aligned title.
*2. *
>
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
> +1 F, G, H with modifications:
> F - * need somewhere to be stated that * means Required
> - the location of the star changes the position with the length of the
> label
>
> G - from a visual scanning point of view, it's better that they are at the
> beginning of the line and the stars are not changing their position
> - but the star should be outside the alignment of the text
> - also somewhere needs o be stated the meaning of the star
>
> H - is the most straight forward
> - Required should have another color than the explanatory text ("Type the
> address...") so it pops out
dark enough color is not compatible with that orange flavour :) . I can do a
prototype but I think it will be a lot too much (since it's more than just a
sign, it's a full word orange).
how about H as is? (compatible with the link you gave me to
http://www.cxpartners.co.uk/thoughts/web_forms_design_guidelines_an_eyetrac…
guideline 5 where normal colors are used).
That would be prototype E.
WDYT?
3.
Since Marius' vote for A was based on the fact that too much red is scary (and I
agree users fear errors), but a red-bordered field is useful to better associate
the error with the field, I'd go for a lighter red (compatible with the grey
labels). I'll do a prototype asap. WDYT?
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 C1 because is a separation between the explanatory text and the error
text. Putting it below makes sense for me to have this separation. The red
color is ok.
I don't like the green of the labels for the mandatory fields. Too many
colors and means nothing for me that the fields are green.
B got 3 votes, A one, C one. B & C are quite similar (text above or below
the error). Having text at the top is better in the tree configuration and
it doesn't make that much of a difference for regular fields.
Thus I suggest we go for B.
Thanks,
Anca
We're short on time here, please cast your -1
quickly if you disagree with
this.
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:17 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Hi,
On Wed, Aug 19, 2009 at 5:11 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com>wrote;wrote:
(and
I
I like it.
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Anca Paula Luca wrote:
because
I like I and the fact that it pops out a bit more (which is the point of the
required sign, make it obvious that those 2 fields have to be filled). I'll
be ok with H if nobody else likes it though.
Guillaume Lerouge wrote:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
Hi,
A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <valicac(a)gmail.com
wrote:
>
>> * 1.*
>>
>> >> +1 for A with a left-aligned title (keep
the consistency with the left
>> alignerd forms)
>
> Pretty much everyone agreed on left-aligned title.
>
> *2. *
>>
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
>> +1 F, G, H with modifications:
>> F - * need somewhere to be stated that * means Required
>> - the location of the star changes the position with the length of
the
>> label
>>
>> G - from a visual scanning point of view, it's better that they are at
the
>> beginning of the line and the stars are
not changing their position
>> - but the star should be outside the alignment of the text
>> - also somewhere needs o be stated the meaning of the star
>>
>> H - is the most straight forward
>> - Required should have another color than the explanatory text ("Type
the
>
address...") so it pops out
I used the same color & style for "required" as for the explanatory text
it's the same type of information,
explanations for the field. The
position next
to the field label is supposed to distinguish it
from the rest of the
explanation.
>> I agree with Sergiu that green is not the best color for required
fields.
>> Also it has low contrast with black and
white.
>>
> Proposal H got the most vote. I agree with Caty on the fact that make it
> colored would pop out more. As long as it's a dark enough color I think
it
> won't hinder accessibility.
>
> Thus I'm suggesting we use H but with "required" printed in the orange
color
> used in proposal G.
I added prototype I to illustrate this. The orange used is the "wiki
standard
colors" orange (which could, of course be grayed a bit to match the other
labels).
dark enough color is not compatible with that orange flavour :) . I can
do a
prototype but I think it will be a lot too much
(since it's more than
just a
sign, it's a full word orange).
how about H as is? (compatible with the link you gave me to
http://www.cxpartners.co.uk/thoughts/web_forms_design_guidelines_an_eyetrac…
guideline 5 where normal colors are used).
> WDYT?
> 3.
>>
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
>> +1 C1 because is a separation between the
explanatory text and the
error
>> text. Putting it below makes sense for me
to have this separation. The
red
>> color is ok.
>>
>> I don't like the green of the labels for the mandatory fields. Too many
>> colors and means nothing for me that the fields are green.
>
> B got 3 votes, A one, C one. B & C are quite similar (text above or
below
> the error). Having text at the top is better
in the tree configuration
and
it
doesn't make that much of a difference for regular fields.
Thus I suggest we go for B.
Since Marius' vote for A was based on the fact that too much red is scary agree users fear errors), but a red-bordered
field is useful to better
associate
the error with the field, I'd go for a
lighter red (compatible with the
grey
labels). I'll do a prototype asap. WDYT?
That would be prototype E.
Thanks,
Anca
> We're short on time here, please cast your -1 quickly if you disagree
with
this.
Thanks,
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs _______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5:50 p.m.
New subject: [xwiki-devs] [vote] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
Guillaume Lerouge wrote:
Hi,
On Wed, Aug 19, 2009 at 5:11 PM, Anca Paula Luca
<ancapaula.luca(a)xwiki.com>wrote;wrote:
-1.
The goal is to make it _visible_ that a field is required, not to make
sure that the first thing the user sees is that some fields are
required. By making the (required) text too visible, the user will be
confused. First 5 seconds after I open a dialog:
"Wow, something red, this is important. Did I do something wrong? Huh?
This is a required field. This one too. This one too. Which fields are
required? Target URL, link text, and tooltip. Now, what was I trying to
do? What am I linking too?"
This is wrong. We're getting the user's attention for something not that
critical. If the user fails to fill in a field, it's not the end of the
world. The wizard will notify this later, and the user will be able to
fill it in.
Ideal first two seconds:
"Hm, now I have to enter the link. This is the link URL. Link text? Oh,
this one is required, better fill it in. etc."
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
Anca Paula Luca wrote:
because
I like I and the fact that it pops out a bit more (which is the point of the
required sign, make it obvious that those 2 fields have to be filled). I'll
be ok with H if nobody else likes it though. Guillaume Lerouge wrote:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
Hi,
A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <valicac(a)gmail.com
wrote:
>> * 1.*
>>
>> >> +1 for A with a left-aligned title (keep
the consistency with the left
>> alignerd forms)
> Pretty much everyone agreed on left-aligned title.
>
> *2. *
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
>> +1 F, G, H with modifications:
>> F - * need somewhere to be stated that * means Required
>> - the location of the star changes the position with the length of
the
>> label
>>
>> G - from a visual scanning point of view, it's better that they are at
the
>> beginning of the line and the stars are
not changing their position
>> - but the star should be outside the alignment of the text
>> - also somewhere needs o be stated the meaning of the star
>>
>> H - is the most straight forward
>> - Required should have another color than the explanatory text ("Type
the
>
address...") so it pops out
I used the same color & style for
"required" as for the explanatory text it's the same type of information,
explanations for the field. The
position next
to the field label is supposed to distinguish it
from the rest of the
explanation.
>> I agree with Sergiu that green is not the
best color for required
fields.
>> Also it has low contrast with black and
white.
>>
> Proposal H got the most vote. I agree with Caty on the fact that make it
> colored would pop out more. As long as it's a dark enough color I think
it
> won't hinder accessibility.
>
> Thus I'm suggesting we use H but with "required" printed in the orange
color
> used in proposal G.
I added prototype
I to illustrate this. The orange used is the "wiki
standard
colors" orange (which could, of course be grayed a bit to match the other
labels).
dark enough color is not compatible with that
orange flavour :) . I can
do a
prototype but I think it will be a lot too much
(since it's more than
just a
sign, it's a full word orange).
how about H as is? (compatible with the link you gave me to
http://www.cxpartners.co.uk/thoughts/web_forms_design_guidelines_an_eyetrac…
> guideline 5 where normal colors are used).
>
>> WDYT?
24 Aug
24 Aug
5:36 p.m.
New subject: [xwiki-devs] [vote] [results] Default look of dialog boxes in the WYSIWYG editor (was [PROPOSAL])
As a result of the discussions here and the fact that we need to converge, I'm
implementing the following:
Anca Paula Luca wrote:
Hi devs,
I'd like to have your opinion on punctual approaches for the consistent design
of the wysiwyg dialogs. Please vote and comment on the issues discussed at:
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix .
We specifically need to make decisions on the following topics:
1.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+1 for A
A
2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendi…
+0.2 for E, +0.4 for F, +0.4 for H
H
E
WDYT?
Thanks a lot,
Anca
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 "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"
- 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")
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
4:47 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
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
Actually, Marius suggested that we keep the "invalid" buttons hidden (but
without changing the positions of the displayed buttons), for the following reasons:
1/ the interface should be as light as possible, we shouldn't crowd the
interface with buttons that the user can never push
2/ disabled buttons can be a little confusing, the user wouldn't know if there
is something he needs to do to enable those buttons.
To help, imagine the following interaction model (which we envisage but it's not
a priority right now): in a wizard step, if the step form is invalid, the "Next"
button is disabled (for example if the user has to make a selection, the "Next"
button will only become enabled after the selection has been made). Now, given
that the "Finish" button would be present on _all_ steps but disabled, I think
it can become a little confusing for the user, who wouldn't know if there is
something he needs to select, fill in, etc to enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but invalid buttons
are invisible).
wdyt?
Thanks,
Anca
- 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 "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"
- 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")
The mockups are located at:
http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
5:05 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Anca Luca wrote:
Guillaume Lerouge wrote:
Big +1!
Thanks Anca,
Marius
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
Actually, Marius suggested that we keep the "invalid" buttons hidden (but
without changing the positions of the displayed buttons), for the following reasons:
1/ the interface should be as light as possible, we shouldn't crowd the
interface with buttons that the user can never push
2/ disabled buttons can be a little confusing, the user wouldn't know if there
is something he needs to do to enable those buttons.
To help, imagine the following interaction model (which we envisage but it's not
a priority right now): in a wizard step, if the step form is invalid, the
"Next"
button is disabled (for example if the user has to make a selection, the "Next"
button will only become enabled after the selection has been made). Now, given
that the "Finish" button would be present on _all_ steps but disabled, I think
it can become a little confusing for the user, who wouldn't know if there is
something he needs to select, fill in, etc to enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but invalid buttons
are invisible).
wdyt?
Thanks,
Anca
- 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 "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"
- 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")
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
5:50 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi,
On Mon, Aug 24, 2009 at 5:05 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Anca Luca wrote:
following
reasons:
I'm ok with that. It's gonna look a bit weird when there's only the final
action & the "previous" button available, but the benefits (specifically
being able to dynamically enable a button once a given action has been
performed) outweigh this issue.
+1
Guillaume
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
Actually, Marius suggested that we keep the "invalid" buttons hidden (but
without changing the positions of the displayed buttons), for the 1/ the interface should be as light as possible,
we shouldn't crowd the
interface with buttons that the user can never push
2/ disabled buttons can be a little confusing, the user wouldn't know if
there
is something he needs to do to enable those
buttons.
To help, imagine the following interaction model (which we envisage but
it's
not
a priority right now): in a wizard step, if the
step form is invalid, the
"Next"
button is disabled (for example if the user has
to make a selection, the
"Next"
button will only become enabled after the
selection has been made). Now,
given
that the "Finish" button would be
present on _all_ steps but disabled, I
think
it can become a little confusing for the user,
who wouldn't know if there
is
something he needs to select, fill in, etc to
enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but invalid
buttons
are invisible).
wdyt?
Big +1! Thanks Anca,
Marius
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Thanks,
Anca
> - 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 "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"
> - 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")
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 
6:54 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
On Aug 24, 2009, at 4:47 PM, Anca Luca wrote:
To help, imagine the following interaction model
(which we envisage
but it's not
a priority right now): in a wizard step, if the step form is
invalid, the "Next"
button is disabled (for example if the user has to make a selection,
the "Next"
button will only become enabled after the selection has been made).
Now, given
that the "Finish" button would be present on _all_ steps but
disabled, I think
it can become a little confusing for the user, who wouldn't know if
there is
something he needs to select, fill in, etc to enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but
invalid buttons
are invisible).
I am not an UI expert but as an Eclipse user this semantics would
confuse me.
When I create a project in Eclipse, for Example, I have the "Finish
button" present on all the wizard forms but disabled (not that Eclipse
is the reference for UIs though :))
It becomes enabled only when I can "finish" the creation process early
or when I am at the end of the wizard and everything validates.
If you hide disabled buttons you end up with with situations where you
have three kinds of "configurations"
1) Enabled buttons
2) Disabled buttons but not hidden (the next button in a wizard when
the form is not complete)
3) Disabled and hidden buttons (like the finish button in you previous
example)
I don't think you want to make the "next" button appear and disappear
as the user edits the form, doesn't you? I think this would be weird
imho.
-Fabio
7:04 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi Fabio,
On Mon, Aug 24, 2009 at 6:54 PM, Fabio Mancinelli <
fabio.mancinelli(a)xwiki.com> wrote:
On Aug 24, 2009, at 4:47 PM, Anca Luca wrote:
That was also my initial opinion. What would actually happen is that the
"Next" button would disappear when at the last step of the form ;-)
The drawback with that approach is that the user doesn't know whether doing
an action (selecting a link for instance) will "un-disable" a button or not
-> some buttons will get enabled (say, "next") while others won't
("finish").
In practice there's indeed a "blinking" risk, we might be aiming at the
best
while the good would be enough (yes, that's a rough translation of a French
saying).
Guillaume
To help, imagine the following interaction model
(which we envisage
but it's not
a priority right now): in a wizard step, if the step form is
invalid, the "Next"
button is disabled (for example if the user has to make a selection,
the "Next"
button will only become enabled after the selection has been made).
Now, given
that the "Finish" button would be present on _all_ steps but
disabled, I think
it can become a little confusing for the user, who wouldn't know if
there is
something he needs to select, fill in, etc to enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but
invalid buttons
are invisible).
I am not an UI expert but as an Eclipse user this semantics would
confuse me.
When I create a project in Eclipse, for Example, I have the "Finish
button" present on all the wizard forms but disabled (not that Eclipse
is the reference for UIs though :))
It becomes enabled only when I can "finish" the creation process early
or when I am at the end of the wizard and everything validates.
If you hide disabled buttons you end up with with situations where you
have three kinds of "configurations"
1) Enabled buttons
2) Disabled buttons but not hidden (the next button in a wizard when
the form is not complete)
3) Disabled and hidden buttons (like the finish button in you previous
example)
I don't think you want to make the "next" button appear and disappear
as the user edits the form, doesn't you? I think this would be weird
imho.
-Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
7:13 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
On Aug 24, 2009, at 7:04 PM, Guillaume Lerouge wrote:
That was also my initial opinion. What would actually happen is that
the
"Next" button would disappear when at the last step of the form ;-)
The drawback with that approach is that the user doesn't know
whether doing
an action (selecting a link for instance) will "un-disable" a button
or not
-> some buttons will get enabled (say, "next") while others won't
("finish").
In practice there's indeed a "blinking" risk, we might be aiming at
the best
while the good would be enough (yes, that's a rough translation of a
French
saying).
I misunderstood. I though that buttons were disappearing and appearing
in the _same_ form.
What you are proposing, if I am not wrong again, is that each form has
a different set of buttons that depends on the
actual actions that are possible at that point (though some of them
could be temporarily disabled).
Ok. I don't have a strong opinion but I think it could be ok.
Sorry for the noise :)
-Fabio
7:22 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
We should make a standard and follow it on other aspects too.
The same discussion is for the pagination: do you show the prev link? yes
you do, and it's disabled. But the user know that a Prev action can be done
and he knows it's possition.
The same aspect is for menus too - if I don't have Edit rights - should I
see the edit link?
These remarks are very correct:
Actually, Marius suggested that we keep the
"invalid" buttons hidden (but
without changing the positions of the displayed buttons), for the following
reasons:
1/ the interface should be as light as possible, we shouldn't crowd the
interface with buttons that the user can never push
2/ disabled buttons can be a little confusing, the user wouldn't know if
there
is something he needs to do to enable those buttons.
But if you have the icons/links/buttons disabled:
A. the users knows the possible actions are there and doesn't need to still
look for them in the interface;
B. when the finishing / editing step will occur and will be possible, the
user will know where to look for it, because he seen it before.
C. the buttons don't disappear and appear like crazy. This is good also for
the designer - he can align the controls and the other sibling elements
don't blink from left to right.
7:37 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi,
On Mon, Aug 24, 2009 at 7:22 PM, Ecaterina Valica <valicac(a)gmail.com> wrote:
We should make a standard and follow it on other
aspects too.
The same discussion is for the pagination: do you show the prev link? yes
you do, and it's disabled. But the user know that a Prev action can be done
and he knows it's possition.
The same aspect is for menus too - if I don't have Edit rights - should I
see the edit link?
These remarks are very correct:
I'm really afraid of C) -> buttons appearing and disappearing for no
specific reason (from the user point of view). A button that was there is no
longer there -> how comes?
Plus the standard practice in all wizards we've looked at with Caty was to
have all buttons displayed all the time... I guess if hiding buttons from
one part of the form to the next was a good practice we would have found a
UX blog talking about it by now (we didn't).
So I'm afraid we're going against a standard and re-inventing new stuff just
for the sake of it, with no proven value at the end of the line. People are
not (yet) accustomed to form buttons magically appearing and I don't want
our project managers to be the ones who will have to explain our users that
"yes, our developers liked hide-and-seek buttons best so that's what we
implemented" ;-)
Guillaume
Actually, Marius suggested that we keep the
"invalid" buttons hidden (but
without changing the positions of the displayed buttons), for the
following
reasons:
1/ the interface should be as light as possible, we shouldn't crowd the
interface with buttons that the user can never push
2/ disabled buttons can be a little confusing, the user wouldn't know if
there
is something he needs to do to enable those buttons.
But if you have the icons/links/buttons disabled:
A. the users knows the possible actions are there and doesn't need to still
look for them in the interface;
B. when the finishing / editing step will occur and will be possible, the
user will know where to look for it, because he seen it before.
C. the buttons don't disappear and appear like crazy. This is good also for
the designer - he can align the controls and the other sibling elements
don't blink from left to right.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
7:54 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Guillaume Lerouge wrote:
Hi,
On Mon, Aug 24, 2009 at 7:22 PM, Ecaterina Valica <valicac(a)gmail.com> wrote:
I think I've seen some minimal wizards, with only the usable buttons in.
We should make a standard and follow it on other
aspects too.
The same discussion is for the pagination: do you show the prev link? yes
you do, and it's disabled. But the user know that a Prev action can be done
and he knows it's possition.
The same aspect is for menus too - if I don't have Edit rights - should I
see the edit link?
These remarks are very correct:
I'm really afraid of C) -> buttons appearing and disappearing for no
specific reason (from the user point of view). A button that was there is no
longer there -> how comes?
Plus the standard practice in all wizards we've looked at with Caty was to
have all buttons displayed all the time... I guess if hiding buttons from
one part of the form to the next was a good practice we would have found a
UX blog talking about it by now (we didn't). Actually, Marius suggested that we keep the
"invalid" buttons hidden (but
without changing the positions of the displayed buttons), for the
following
reasons:
1/ the interface should be as light as possible, we shouldn't crowd the
interface with buttons that the user can never push
2/ disabled buttons can be a little confusing, the user wouldn't know if
there
is something he needs to do to enable those buttons.
But if you have the icons/links/buttons disabled:
A. the users knows the possible actions are there and doesn't need to still
look for them in the interface;
B. when the finishing / editing step will occur and will be possible, the
user will know where to look for it, because he seen it before.
C. the buttons don't disappear and appear like crazy. This is good also for
the designer - he can align the controls and the other sibling elements
don't blink from left to right.
So I'm afraid we're going against a standard and re-inventing new stuff just
for the sake of it, with no proven value at the end of the line. People are
not (yet) accustomed to form buttons magically appearing and I don't want
our project managers to be the ones who will have to explain our users that
"yes, our developers liked hide-and-seek buttons best so that's what we
implemented" ;-)
It's not magically or chaotically, it's matching what the user can do: you have
only a button therefore the only thing you can click and could ever click is
that button, I think it makes it simple.
Now the *only* good reason I find for showing disabled buttons is to actually
make it obvious for the user that it's a process in multiple steps (it's a
wizard, everybody knows Previous and Next means wizard), not make him believe
that clicking the only visible button in the first form will get the job done
and then have the surprise of another step appearing and so on. Make it clear
from the very beginning what is he doing there (you have multiple steps to take,
at one point you'll be able to "Insert X", you do have a previous button and
will be able to return at this step if you mess up something).
Thanks,
Anca
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
25 Aug
25 Aug
12:01 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
I vote +1 for all buttons visible, but disabled if not active.
Thanks,
Caty
3:07 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Ecaterina Valica wrote:
I vote +1 for all buttons visible, but disabled if not
active.
-0, I just hope I won't have to say this:
"No, you can't finish at this step.. the finish button is there just to
assure you that this wizard will end at some point. This way you'll know
where to click when that moment comes."
Marius
Thanks,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:27 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi,
On Tue, Aug 25, 2009 at 3:07 PM, Marius Dumitru Florea <
mariusdumitru.florea(a)xwiki.com> wrote:
Ecaterina Valica wrote:
That's exactly what most wizards do:
- http://www.raymond.cc/images/create-backup-wizard.png
-
http://www.mdt-project.net/help_mdt_PE/help/pl.com.astec.mdt.help/html/what…
-
http://www.ibm.com/developerworks/opensource/library/os-eclipse-custwiz/fig…
- http://www.netbeans.org/images/articles/facelets/new-file-wizard.png
- http://www.ibm.com/developerworks/library/j-ajdt/ajdocWizard.GIF
Displaying disabled buttons matches the user model / user expectation for
wizard. Since this kind of interface is frequent, specially for Windows
users, you're much less likely to have to explain why a disabled button is
displayed than to have to explain why some buttons appear and disappear.
Guillaume
I vote +1 for all buttons visible, but disabled
if not active.
-0, I just hope I won't have to say this:
"No, you can't finish at this step.. the finish button is there just to
assure you that this wizard will end at some point. This way you'll know
where to click when that moment comes."
Marius
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Thanks,
Caty
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
3:35 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
if you make sufficient contrast for the enabled/disabled buttons it will be
ok. Users are not that dump, and plus the disabled actions are used allover
in the modern OSes.
I vote +1 for all buttons visible, but disabled if not
active.
-0, I just hope I won't have to say this:
"No, you can't finish at this step.. the finish button is there just to
assure you that this wizard will end at some point. This way you'll know
where to click when that moment comes."
Marius
12:54 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi,
On Mon, Aug 24, 2009 at 7:54 PM, Anca Luca <ancapaula.luca(a)xwiki.com> wrote:
Guillaume Lerouge wrote:
no
Exactly. We show a wizard (= multiple steps process), let's provide users
with the UI they're expecting from a wizard (all buttons displayed at all
times).
Guillaume
Hi,
On Mon, Aug 24, 2009 at 7:22 PM, Ecaterina Valica <valicac(a)gmail.com>
wrote:
> We should make a standard and follow it on other aspects too.
>
> The same discussion is for the pagination: do you show the prev link?
yes
> you do, and it's disabled. But the user
know that a Prev action can be
done
> and he knows it's possition.
>
> The same aspect is for menus too - if I don't have Edit rights - should
I
> see the edit link?
>
> These remarks are very correct:
>
>> Actually, Marius suggested that we keep the "invalid" buttons hidden
(but
>> without changing the positions of the
displayed buttons), for the
> following
>> reasons:
>> 1/ the interface should be as light as possible, we shouldn't crowd the
>> interface with buttons that the user can never push
>> 2/ disabled buttons can be a little confusing, the user wouldn't know
if
>> there
>> is something he needs to do to enable those buttons.
>
> But if you have the icons/links/buttons disabled:
> A. the users knows the possible actions are there and doesn't need to
still
> look for them in the interface;
> B. when the finishing / editing step will occur and will be possible,
the
> user will know where to look for it, because
he seen it before.
> C. the buttons don't disappear and appear like crazy. This is good also
for
the
designer - he can align the controls and the other sibling elements
don't blink from left to right.
I'm really afraid of C) -> buttons appearing and disappearing for no
specific reason (from the user point of view). A button that was there is longer there -> how comes?
Plus the standard practice in all wizards we've looked at with Caty was
to
have all buttons displayed all the time... I
guess if hiding buttons from
one part of the form to the next was a good practice we would have found
a
UX blog talking about it by now (we didn't).
I think I've seen some minimal wizards, with only the usable buttons in.
So I'm afraid we're going against a standard and re-inventing new stuff
just
for the sake of it, with no proven value at the
end of the line. People
are
not (yet) accustomed to form buttons magically
appearing and I don't want
our project managers to be the ones who will have to explain our users
that
"yes, our developers liked hide-and-seek
buttons best so that's what we
implemented" ;-)
It's not magically or chaotically, it's matching what the user can do: you
have
only a button therefore the only thing you can click and could ever click
is
that button, I think it makes it simple.
Now the *only* good reason I find for showing disabled buttons is to
actually
make it obvious for the user that it's a process in multiple steps (it's a
wizard, everybody knows Previous and Next means wizard), not make him
believe
that clicking the only visible button in the first form will get the job
done
and then have the surprise of another step appearing and so on. Make it
clear
from the very beginning what is he doing there (you have multiple steps to
take,
at one point you'll be able to "Insert X", you do have a previous button
and
will be able to return at this step if you mess up something).
Thanks,
Anca
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
24 Aug
24 Aug
7:46 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Ecaterina Valica wrote:
We should make a standard and follow it on other
aspects too.
The same discussion is for the pagination: do you show the prev link? yes
you do, and it's disabled. But the user know that a Prev action can be done
and he knows it's possition.
The same aspect is for menus too - if I don't have Edit rights - should I
see the edit link?
It's not quite the same: "if you were logged in / had the edit rights, you could
edit". Here we propose to hide the things that _are not possible at all_ at that
moment, no matter what you do.
These remarks are very correct:
While I understand and agree with A & B and the fact that we need a rule, I
disagree with C: from the designing pov we can make them stay in their places
(that was the idea actually, they _don't move around_ when siblings are hidden).
And the appearing and disappearing would be corresponding with whether can be
used or not (I'd say that could help).
Thanks,
Anca
Actually, Marius suggested that we keep the
"invalid" buttons hidden (but
without changing the positions of the displayed buttons), for the following
reasons:
1/ the interface should be as light as possible, we shouldn't crowd the
interface with buttons that the user can never push
2/ disabled buttons can be a little confusing, the user wouldn't know if
there
is something he needs to do to enable those buttons.
But if you have the icons/links/buttons disabled:
A. the users knows the possible actions are there and doesn't need to still
look for them in the interface;
B. when the finishing / editing step will occur and will be possible, the
user will know where to look for it, because he seen it before.
C. the buttons don't disappear and appear like crazy. This is good also for
the designer - he can align the controls and the other sibling elements
don't blink from left to right. _______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:32 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Guillaume Lerouge wrote:
Hi Fabio,
On Mon, Aug 24, 2009 at 6:54 PM, Fabio Mancinelli <
fabio.mancinelli(a)xwiki.com> wrote:
As I told you in our voice conversation, we can have a Next button in the last
form of the wizard, which would do the very same thing as a finish (except that
it would be confusing maybe for the user who wouldn't understand what's the
difference between the two, would click a next and have the wizard closed and
would think that he did smth wrong).
On Aug 24, 2009, at 4:47 PM, Anca Luca wrote:
That was also my initial opinion. What would actually happen is that the
"Next" button would disappear when at the last step of the form ;-) To help, imagine the following interaction model
(which we envisage
but it's not
a priority right now): in a wizard step, if the step form is
invalid, the "Next"
button is disabled (for example if the user has to make a selection,
the "Next"
button will only become enabled after the selection has been made).
Now, given
that the "Finish" button would be present on _all_ steps but
disabled, I think
it can become a little confusing for the user, who wouldn't know if
there is
something he needs to select, fill in, etc to enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but
invalid buttons
are invisible).
I am not an UI expert but as an Eclipse user this semantics would
confuse me.
When I create a project in Eclipse, for Example, I have the "Finish
button" present on all the wizard forms but disabled (not that Eclipse
is the reference for UIs though :))
It becomes enabled only when I can "finish" the creation process early
or when I am at the end of the wizard and everything validates.
If you hide disabled buttons you end up with with situations where you
have three kinds of "configurations"
1) Enabled buttons
2) Disabled buttons but not hidden (the next button in a wizard when
the form is not complete)
3) Disabled and hidden buttons (like the finish button in you previous
example)
I don't think you want to make the "next" button appear and disappear
as the user edits the form, doesn't you? I think this would be weird
imho.
The drawback with that approach is that the user doesn't know whether doing
an action (selecting a link for instance) will "un-disable" a button or not
-> some buttons will get enabled (say, "next") while others won't
("finish").
Another drawback I see, although it might not be that bad because we're talking
only about 3 buttons here, is that the user constantly sees things he cannot use
(ah look a button "what does this button dooo?" ah cannot use it why?). Why
would the "blinking" be a problem? buttons would only change configuration from
one step to another. You click a button, you get a new form loaded, with new
options to go further. Is this an issue? (I'm no expert, I'm just saying).
Thanks,
Anca
In practice there's indeed a "blinking" risk, we might be aiming at the
best
while the good would be enough (yes, that's a rough translation of a French
saying).
P.S.: and yes, we might be over-engineering the 3 buttons...
Guillaume
-Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:39 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Hi,
On Mon, Aug 24, 2009 at 7:32 PM, Anca Luca <ancapaula.luca(a)xwiki.com> wrote:
You don't get a "new form", it's still part of the same wizard
experience.
Imagine if Eclipse's buttons got hidden or shown at each step of every
wizard, you would find that very disturbing.
--
Guillaume Lerouge
Product Manager - XWiki
Skype: wikibc
Twitter: glerouge
http://guillaumelerouge.com/
Guillaume Lerouge wrote:
This means 2 buttons that do the same thing but are not located in the same
place not named the same. I can see confusion in our users' eyes already ;-)
Hi Fabio,
On Mon, Aug 24, 2009 at 6:54 PM, Fabio Mancinelli <
fabio.mancinelli(a)xwiki.com> wrote:
As I told you in our voice conversation, we can have a Next button in the
last
form of the wizard, which would do the very same thing as a finish (except
that
it would be confusing maybe for the user who wouldn't understand what's the
difference between the two, would click a next and have the wizard closed
and
would think that he did smth wrong). On Aug 24, 2009, at 4:47 PM, Anca Luca wrote:
That was also my initial opinion. What would actually happen is that the
"Next" button would disappear when at the last step of the form ;-) To help, imagine the following interaction model
(which we envisage
but it's not
a priority right now): in a wizard step, if the step form is
invalid, the "Next"
button is disabled (for example if the user has to make a selection,
the "Next"
button will only become enabled after the selection has been made).
Now, given
that the "Finish" button would be present on _all_ steps but
disabled, I think
it can become a little confusing for the user, who wouldn't know if
there is
something he needs to select, fill in, etc to enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but
invalid buttons
are invisible).
I am not an UI expert but as an Eclipse user this semantics would
confuse me.
When I create a project in Eclipse, for Example, I have the "Finish
button" present on all the wizard forms but disabled (not that Eclipse
is the reference for UIs though :))
It becomes enabled only when I can "finish" the creation process early
or when I am at the end of the wizard and everything validates.
If you hide disabled buttons you end up with with situations where you
have three kinds of "configurations"
1) Enabled buttons
2) Disabled buttons but not hidden (the next button in a wizard when
the form is not complete)
3) Disabled and hidden buttons (like the finish button in you previous
example)
I don't think you want to make the "next" button appear and disappear
as the user edits the form, doesn't you? I think this would be weird
imho. The drawback
with that approach is that the user doesn't know whether
doing
an action (selecting a link for instance) will
"un-disable" a button or
not
-> some buttons will get enabled (say,
"next") while others won't
("finish").
Another drawback I see, although it might not be that bad because we're
talking
only about 3 buttons here, is that the user constantly sees things he
cannot use
(ah look a button "what does this button dooo?" ah cannot use it why?). Why
would the "blinking" be a problem? buttons would only change configuration
from
one step to another. You click a button, you get a new form loaded, with
new
options to go further. Is this an issue? (I'm no expert, I'm just saying).
Thanks,
Anca
We definitely are :-) Let's go for the basics !! That's what people are used
to, it matches the user model... Why would we not want to match the user
model?
Guillaume
In practice there's indeed a "blinking" risk, we might be aiming at the
best
while the good would be enough (yes, that's a
rough translation of a
French
saying).
P.S.: and yes, we might be over-engineering the 3 buttons...
Guillaume
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
-Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:17 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Fabio Mancinelli wrote:
On Aug 24, 2009, at 4:47 PM, Anca Luca wrote:
yes, and each one would correspond to one context / meaning:
1/ can be clicked
2/ can be clicked provided that you validly fill in the form
3/ no matter what happens with this form, this action cannot be taken (so why
show it?)
To help, imagine the following interaction model
(which we envisage
but it's not
a priority right now): in a wizard step, if the step form is
invalid, the "Next"
button is disabled (for example if the user has to make a selection,
the "Next"
button will only become enabled after the selection has been made).
Now, given
that the "Finish" button would be present on _all_ steps but
disabled, I think
it can become a little confusing for the user, who wouldn't know if
there is
something he needs to select, fill in, etc to enable it.
I'd go for minimal UI (i.e. all buttons on the footer strip, but
invalid buttons
are invisible).
I am not an UI expert but as an Eclipse user this semantics would
confuse me.
When I create a project in Eclipse, for Example, I have the "Finish
button" present on all the wizard forms but disabled (not that Eclipse
is the reference for UIs though :))
It becomes enabled only when I can "finish" the creation process early
or when I am at the end of the wizard and everything validates.
If you hide disabled buttons you end up with with situations where you
have three kinds of "configurations"
1) Enabled buttons
2) Disabled buttons but not hidden (the next button in a wizard when
the form is not complete)
3) Disabled and hidden buttons (like the finish button in you previous
example)
I don't think you want to make the "next" button appear and disappear
as the user edits the form, doesn't you? I think this would be weird
imho.
very weird, I agree, but
No button will appear and disappear as the user edits the form, they would be
enabled and disabled (as the user edits the form), just the way eclipse does --
but that's planned for later, not in the current proposal.
Hidden buttons would be the actions that cannot be taken from the current step,
for example, if one cannot finish directly from the current step no matter what
he'd do, the "Finish" button would not be there. The arguments for this
choice
are the ones listed above.
Now, eclipse also has the "real time" errors, which are very convenient and make
the user rarely (if not never) reach the buttons with an invalid form.
Thanks,
Anca
-Fabio
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7:24 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
To help, imagine the following interaction model
(which we envisage but
it's not
a priority right now): in a wizard step, if the step form is invalid, the
"Next"
button is disabled (for example if the user has to make a selection, the
"Next"
button will only become enabled after the selection has been made). Now,
given
that the "Finish" button would be present on _all_ steps but disabled, I
think
it can become a little confusing for the user, who wouldn't know if there
is
something he needs to select, fill in, etc to enable it.
How about changing the name of the "Next" action at the end in
"Finish"
Prev Next
into
Prev Finish ?
7:38 p.m.
New subject: [xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
Ecaterina Valica wrote:
I don't think it could work, since there are steps where Next and Finish are
both possible. In those steps you'd have a different placement of Finish, to the
left, while in the last step, Finish would be to the right of Previous. Also,
the placement of the Previous button could vary because of the different sizes
of the Next button and the Finish button (or whichever its configured label is).
Thanks,
Anca
To help,
imagine the following interaction model (which we envisage but
it's not
a priority right now): in a wizard step, if the step form is invalid, the
"Next"
button is disabled (for example if the user has to make a selection, the
"Next"
button will only become enabled after the selection has been made). Now,
given
that the "Finish" button would be present on _all_ steps but disabled, I
think
it can become a little confusing for the user, who wouldn't know if there
is
something he needs to select, fill in, etc to enable it.
How about changing the name of the "Next" action at the end in
"Finish"
Prev Next
into
Prev Finish ? _______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
5554
days inactive
5574
days old
41 comments
9 participants
participants (9)
-
Anca Luca -
Anca Paula Luca
-
Ecaterina Valica -
Fabio Mancinelli -
Guillaume Lerouge -
Marius Dumitru Florea -
Raluca Stavro -
Sergiu Dumitriu -
Vincent Massol