[xwiki-devs] [PROPOSAL] Default look of dialog boxes in the WYSIWYG editor
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/
Guillaume Lerouge wrote:
Hi Devs, Anca asked me to finalize the overall look of dialog boxes in the WYSIWYG so that she can work on it and polish it for the 2.0 release. Right now the issue is that we're using a different look for the link, image & macro dialog boxes which poses a consistency problem.
I've been working with Cati on a proposal for the look of the overall box - not for the inner part of the box. Proposals for the standardization of the inner part of the box will come later. The dialog box uses a wizard-like look and follows the vertical form principles proposed by Cati in a previous email (thus the primary action button at the bottom left, to follow the user's eye flow). Its "hidden" features are:
- Buttons can be in an enabled or disabled mode depending of what the current step is - All buttons are displayed all the time so that they don't move from one screen to the next - Buttons' labels are configurable - There is no "Cancel" button, the cross at the top right of the dialog box plays that role - The title in the top bar doesn't change and its name is the same as the associated toolbar button (clicking on "Link" opens a dialog box called "Link")
The user never clicks on just "Link", it is always a submenu item that it chooses ("Wiki page", "Attached file", etc). I assume the dialog title should be a combination of the two, since only the name of the submenu item is far from suggestive. wdyt?
- The "Wizard Step Title" reflects what's happening at the current step: "Page Selection" , "Code Macro" , "Image Selection" - The description tells the user what to do at the current step: "Select the page to link to" , "Select the image to insert" , "Fill in macro parameters"
After discussion we came to the conclusion that the description will tell the user what will be the result of the current step, and not instructions about how to do it. All instructions will go next to the field in the form of the wizard step. Also this description can be skipped if the title is good enough, to avoid redundancy.
- 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
Hi, On Wed, Aug 5, 2009 at 3:51 PM, Anca Paula Luca <[email protected]>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
Guillaume Lerouge wrote: -
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?
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.
- 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.
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
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
The mockups are located at: http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
Hi Devs, Anca asked me to finalize the overall look of dialog boxes in the WYSIWYG so that she can work on it and polish it for the 2.0 release. Right now the issue is that we're using a different look for the link, image & macro dialog boxes which poses a consistency problem.
I've been working with Cati on a proposal for the look of the overall box - not for the inner part of the box. Proposals for the standardization of the inner part of the box will come later. The dialog box uses a wizard-like look and follows the vertical form principles proposed by Cati in a previous email (thus the primary action button at the bottom left, to follow the user's eye flow). Its "hidden" features are:
- Buttons can be in an enabled or disabled mode depending of what the current step is - All buttons are displayed all the time so that they don't move from one screen to the next - Buttons' labels are configurable - There is no "Cancel" button, the cross at the top right of the dialog box plays that role - The title in the top bar doesn't change and its name is the same as the associated toolbar button (clicking on "Link" opens a dialog box called "Link")
The user never clicks on just "Link", it is always a submenu item that it chooses ("Wiki page", "Attached file", etc). I assume the dialog title should be a combination of the two, since only the name of the submenu item is far from suggestive.
wdyt?
- The "Wizard Step Title" reflects what's happening at the current step: "Page Selection" , "Code Macro" , "Image Selection" - The description tells the user what to do at the current step: "Select the page to link to" , "Select the image to insert" , "Fill in macro parameters"
After discussion we came to the conclusion that the description will tell the user what will be the result of the current step, and not instructions about how to do it. All instructions will go next to the field in the form of the wizard step.
Also this description can be skipped if the title is good enough, to avoid redundancy.
At this point, I am afraid that these two will take up too much space, while being slightly redundant. Since a description can be quite long, it could span on 2 lines of text. + 1 line the title = 3 lines in the dialog header. Right now the header is only one line of text. An experiment showed it to take over twice the space if a description is included and this space would be taken from the content of the dialog. With even more help labels (for fields, for example) this can turn into a space issue. For example, in the case of a link target document selection we would have a title + description in the header, then the tabs strip then another help label about how the selection should be made in the selected tab and only after that the actual list of pages to select from. Now, we have two choices for the header: 1/ we make it variable height and resizes with its content. advantages: leaves more space when it's not there, flexible with the size of text to encapsulate disadvantages: variable size is disturbing. Even so, the proposal was to have descriptions for steps everywhere so not much space would be saved. Also, it could be technically hard to implement the variable size correctly cross browser & platform and flexible with i18n. 2/ fixed height, to comprise 2-3 lines of description text, ensuring that all labels would fit. If description is missing, the title would be vertically centered. advantages: fixed size consistent across multiple steps & dialogs, potentially easy to implement disadvantages: could take too much space for nothing, all descriptions would need to fit the available space. 3/ Drop the description in the header, as the current implementation is. advantages: more space disadvantages: one explanation less (do we really need it except for the macro parameters dialog?) I would go for 3) with appropriate wording on dialog titles, fields help labels, and wizard step titles. 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
- Double-clicking on an item (an image, a page name) acts in the same fashion as selecting it and clicking the "Next" button. If the "Next" button is disabled at the current step, double-clicking works as the primary action ("Insert" , "Create")
Also, webforms usually are submitted when enter is hit in one of their fields. We also do this currently in our dialog forms. In the case when "Finish" and "Next" are both enabled, which one should be the one executed by enter? I'd go for "Next" for consistency.
Also, for the case when the wysiwyg dialog is not a wizard (table, importer dialogs for the moment), we have two options for the wizard step title:
1/ keep the Wizard Step and Descriptions in place, to contain detailed description of the action to be executed, for consistency reasons. While the dialog title will be the same as the toolbar button / menu clicked, the Wizard Step title will contain a more detailed description of the action and the description will probably be missing most of the times since it's redundant.
2/ we remove the top bar completely, as it currently is the case for the table & importer dialogs, to avoid crowding the dialogs with redundant information (the title of the dialog should be enough information, as it's only one action and that is the actual name of the action -- as opposed to wizard steps where differentiation of various subactions is needed).
Guillaume's suggestion was for strong consistency, therefore 1/. I think that, while it could turn out useful, it can be confusing to have multiple titles for a dialog when they refer to the same action.
wdyt?
In general, we would love some feedback about the UI / UX of the wysiwyg dialogs, things that should be polished for a final version.
Thanks, Anca
The mockups are located at: http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Fri, Aug 7, 2009 at 10:15 PM, Anca Paula Luca <[email protected]>wrote:
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
Hi Devs, Anca asked me to finalize the overall look of dialog boxes in the WYSIWYG so that she can work on it and polish it for the 2.0 release. Right now the issue is that we're using a different look for the link, image & macro dialog boxes which poses a consistency problem.
I've been working with Cati on a proposal for the look of the overall box - not for the inner part of the box. Proposals for the standardization of the inner part of the box will come later. The dialog box uses a wizard-like look and follows the vertical form principles proposed by Cati in a previous email (thus the primary action button at the bottom left, to follow the user's eye flow). Its "hidden" features are:
- Buttons can be in an enabled or disabled mode depending of what the current step is - All buttons are displayed all the time so that they don't move from one screen to the next - Buttons' labels are configurable - There is no "Cancel" button, the cross at the top right of the dialog box plays that role - The title in the top bar doesn't change and its name is the same as the associated toolbar button (clicking on "Link" opens a dialog box called "Link")
The user never clicks on just "Link", it is always a submenu item that it chooses ("Wiki page", "Attached file", etc). I assume the dialog title should be a combination of the two, since only the name of the submenu item is far from suggestive.
wdyt?
- The "Wizard Step Title" reflects what's happening at the current step: "Page Selection" , "Code Macro" , "Image Selection" - The description tells the user what to do at the current step: "Select the page to link to" , "Select the image to insert" , "Fill in macro parameters"
After discussion we came to the conclusion that the description will tell the user what will be the result of the current step, and not instructions about how to do it. All instructions will go next to the field in the form of the wizard step.
Also this description can be skipped if the title is good enough, to avoid redundancy.
At this point, I am afraid that these two will take up too much space, while being slightly redundant. Since a description can be quite long, it could span on 2 lines of text. + 1 line the title = 3 lines in the dialog header. Right now the header is only one line of text. An experiment showed it to take over twice the space if a description is included and this space would be taken from the content of the dialog. With even more help labels (for fields, for example) this can turn into a space issue. For example, in the case of a link target document selection we would have a title + description in the header, then the tabs strip then another help label about how the selection should be made in the selected tab and only after that the actual list of pages to select from.
Now, we have two choices for the header: 1/ we make it variable height and resizes with its content. advantages: leaves more space when it's not there, flexible with the size of text to encapsulate disadvantages: variable size is disturbing. Even so, the proposal was to have descriptions for steps everywhere so not much space would be saved. Also, it could be technically hard to implement the variable size correctly cross browser & platform and flexible with i18n.
2/ fixed height, to comprise 2-3 lines of description text, ensuring that all labels would fit. If description is missing, the title would be vertically centered. advantages: fixed size consistent across multiple steps & dialogs, potentially easy to implement disadvantages: could take too much space for nothing, all descriptions would need to fit the available space.
3/ Drop the description in the header, as the current implementation is. advantages: more space disadvantages: one explanation less (do we really need it except for the macro parameters dialog?)
I would go for 3) with appropriate wording on dialog titles, fields help labels, and wizard step titles.
Given the potential space issue, I'm ok for 3) too. I'll update the wiki page to suggest another wording for top level titles so that dialog titles and wizard step titles work nicely together. Overall, it feels like too many descriptions there by default, too much
text, which could cause problems to in most of the cases, when users already know how to use the wysiwyg and the text would just take up space for nothing.
Well, this issue isn't easy to address. We could hide explanations under a "?" sign located next to each field and display it on hover, but that requires extra work. Guillaume WDYT?
Thanks, Anca
- Double-clicking on an item (an image, a page name) acts in the same fashion as selecting it and clicking the "Next" button. If the "Next"
button
is disabled at the current step, double-clicking works as the primary action ("Insert" , "Create")
Also, webforms usually are submitted when enter is hit in one of their fields. We also do this currently in our dialog forms. In the case when "Finish" and "Next" are both enabled, which one should be the one executed by enter? I'd go for "Next" for consistency.
Also, for the case when the wysiwyg dialog is not a wizard (table, importer dialogs for the moment), we have two options for the wizard step title:
1/ keep the Wizard Step and Descriptions in place, to contain detailed description of the action to be executed, for consistency reasons. While the dialog title will be the same as the toolbar button / menu clicked, the Wizard Step title will contain a more detailed description of the action and the description will probably be missing most of the times since it's redundant.
2/ we remove the top bar completely, as it currently is the case for the table & importer dialogs, to avoid crowding the dialogs with redundant information (the title of the dialog should be enough information, as it's only one action and that is the actual name of the action -- as opposed to wizard steps where differentiation of various subactions is needed).
Guillaume's suggestion was for strong consistency, therefore 1/. I think that, while it could turn out useful, it can be confusing to have multiple titles for a dialog when they refer to the same action.
wdyt?
In general, we would love some feedback about the UI / UX of the wysiwyg dialogs, things that should be polished for a final version.
Thanks, Anca
The mockups are located at: http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Guillaume Lerouge wrote:
Hi,
On Fri, Aug 7, 2009 at 10:15 PM, Anca Paula Luca <[email protected]>wrote:
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
Hi Devs, Anca asked me to finalize the overall look of dialog boxes in the WYSIWYG so that she can work on it and polish it for the 2.0 release. Right now the issue is that we're using a different look for the link, image & macro dialog boxes which poses a consistency problem.
I've been working with Cati on a proposal for the look of the overall box - not for the inner part of the box. Proposals for the standardization of the inner part of the box will come later. The dialog box uses a wizard-like look and follows the vertical form principles proposed by Cati in a previous email (thus the primary action button at the bottom left, to follow the user's eye flow). Its "hidden" features are:
- Buttons can be in an enabled or disabled mode depending of what the current step is - All buttons are displayed all the time so that they don't move from one screen to the next - Buttons' labels are configurable - There is no "Cancel" button, the cross at the top right of the dialog box plays that role - The title in the top bar doesn't change and its name is the same as the associated toolbar button (clicking on "Link" opens a dialog box called "Link") The user never clicks on just "Link", it is always a submenu item that it chooses ("Wiki page", "Attached file", etc). I assume the dialog title should be a combination of the two, since only the name of the submenu item is far from suggestive.
wdyt?
- The "Wizard Step Title" reflects what's happening at the current step: "Page Selection" , "Code Macro" , "Image Selection" - The description tells the user what to do at the current step: "Select the page to link to" , "Select the image to insert" , "Fill in macro parameters" After discussion we came to the conclusion that the description will tell the user what will be the result of the current step, and not instructions about how to do it. All instructions will go next to the field in the form of the wizard step. Also this description can be skipped if the title is good enough, to avoid redundancy. At this point, I am afraid that these two will take up too much space, while being slightly redundant. Since a description can be quite long, it could span on 2 lines of text. + 1 line the title = 3 lines in the dialog header. Right now the header is only one line of text. An experiment showed it to take over twice the space if a description is included and this space would be taken from the content of the dialog. With even more help labels (for fields, for example) this can turn into a space issue. For example, in the case of a link target document selection we would have a title + description in the header, then the tabs strip then another help label about how the selection should be made in the selected tab and only after that the actual list of pages to select from.
Now, we have two choices for the header: 1/ we make it variable height and resizes with its content. advantages: leaves more space when it's not there, flexible with the size of text to encapsulate disadvantages: variable size is disturbing. Even so, the proposal was to have descriptions for steps everywhere so not much space would be saved. Also, it could be technically hard to implement the variable size correctly cross browser & platform and flexible with i18n.
2/ fixed height, to comprise 2-3 lines of description text, ensuring that all labels would fit. If description is missing, the title would be vertically centered. advantages: fixed size consistent across multiple steps & dialogs, potentially easy to implement disadvantages: could take too much space for nothing, all descriptions would need to fit the available space.
3/ Drop the description in the header, as the current implementation is. advantages: more space disadvantages: one explanation less (do we really need it except for the macro parameters dialog?)
I would go for 3) with appropriate wording on dialog titles, fields help labels, and wizard step titles.
Given the potential space issue, I'm ok for 3) too. I'll update the wiki page to suggest another wording for top level titles so that dialog titles and wizard step titles work nicely together.
Overall, it feels like too many descriptions there by default, too much
text, which could cause problems to in most of the cases, when users already know how to use the wysiwyg and the text would just take up space for nothing.
Well, this issue isn't easy to address. We could hide explanations under a "?" sign located next to each field and display it on hover, but that requires extra work.
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
Guillaume
WDYT?
Thanks, Anca
- Double-clicking on an item (an image, a page name) acts in the same fashion as selecting it and clicking the "Next" button. If the "Next" button is disabled at the current step, double-clicking works as the primary action ("Insert" , "Create") Also, webforms usually are submitted when enter is hit in one of their fields. We also do this currently in our dialog forms. In the case when "Finish" and "Next" are both enabled, which one should be the one executed by enter? I'd go for "Next" for consistency.
Also, for the case when the wysiwyg dialog is not a wizard (table, importer dialogs for the moment), we have two options for the wizard step title:
1/ keep the Wizard Step and Descriptions in place, to contain detailed description of the action to be executed, for consistency reasons. While the dialog title will be the same as the toolbar button / menu clicked, the Wizard Step title will contain a more detailed description of the action and the description will probably be missing most of the times since it's redundant. 2/ we remove the top bar completely, as it currently is the case for the table & importer dialogs, to avoid crowding the dialogs with redundant information (the title of the dialog should be enough information, as it's only one action and that is the actual name of the action -- as opposed to wizard steps where differentiation of various subactions is needed).
Guillaume's suggestion was for strong consistency, therefore 1/. I think that, while it could turn out useful, it can be confusing to have multiple titles for a dialog when they refer to the same action.
wdyt?
In general, we would love some feedback about the UI / UX of the wysiwyg dialogs, things that should be polished for a final version.
Thanks, Anca
The mockups are located at: http://incubator.myxwiki.org/xwiki/bin/view/Mockups/GenericMacroDialog
WDYT?
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Guillaume Lerouge 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
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/NewWysiwygEditorInterfaceAppendix... +1 for A 2. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +0.2 for E, +0.4 for F, +0.4 for H 3. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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
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/NewWysiwygEditorInterfaceAppendix...
+1 for A
2. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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/NewWysiwygEditorInterfaceAppendix...
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi Devs, On Mon, Aug 17, 2009 at 5:05 PM, Anca Paula Luca <[email protected]>wrote:
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/NewWysiwygEditorInterfaceAppendix...
+1 for A
+1 for A with a left-aligned title
2.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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
+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
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+1 for B
+1 for B We're looking for your feedback ! (Thibaut, Caty time for you to chip in ;-) Thanks, Guillaume
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
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/NewWysiwygEditorInterfaceAppendix...
+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/NewWysiwygEditorInterfaceAppendix...
+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).
3. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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
Vincent Massol wrote:
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/NewWysiwygEditorInterfaceAppendix...
+1 for A
+1 for A (left aligned) but then I couldn't understand what B is about (lots of text to read...).
B is about Guillaume's initial proposal in this thread (dialog title + step title + step description for each wizard step).
2. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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).
3. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+1 for C2 (ie all errors reported) but with error text above field (and not below as in C2).
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.
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/NewWysiwygEditorInterfaceAppendix...
+1 for A
+1 for A
2. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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/NewWysiwygEditorInterfaceAppendix...
+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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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/NewWysiwygEditorInterfaceAppendix...
+1 for A
2. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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.
3. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+1 for B
-- Sergiu Dumitriu http://purl.org/net/sergiu/
* 1.* http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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/NewWysiwygEditorInterfaceAppendix... +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/NewWysiwygEditorInterfaceAppendix... +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.
Hi, A bit of summarizing on what we've got so far: On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <[email protected]>wrote:
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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/NewWysiwygEditorInterfaceAppendix... +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/NewWysiwygEditorInterfaceAppendix... +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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Hi, A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <[email protected]>wrote:
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +1 for A with a left-aligned title (keep the consistency with the left alignerd forms)
Pretty much everyone agreed on left-aligned title.
+1 for A and left align.
*2. *
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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?
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
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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
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.
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Guillaume Lerouge wrote:
Hi, A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <[email protected]>wrote:
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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/NewWysiwygEditorInterfaceAppendix... +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 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.
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_eyetrack... guideline 5 where normal colors are used).
WDYT?
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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 (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
We're short on time here, please cast your -1 quickly if you disagree with this.
Thanks,
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
Hi, A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <[email protected]>wrote:
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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/NewWysiwygEditorInterfaceAppendix... +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 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.
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_eyetrack... guideline 5 where normal colors are used).
WDYT?
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix... +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 (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?
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Wed, Aug 19, 2009 at 5:11 PM, Anca Paula Luca <[email protected]>wrote:
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
Hi, A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <[email protected] wrote:
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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/NewWysiwygEditorInterfaceAppendix...
+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 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.
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_eyetrack...
guideline 5 where normal colors are used).
WDYT?
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.
3.
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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 (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?
That would be prototype E.
I like it. Guillaume
Thanks, Anca
We're short on time here, please cast your -1 quickly if you disagree
with
this.
Thanks,
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Guillaume Lerouge wrote:
Hi,
On Wed, Aug 19, 2009 at 5:11 PM, Anca Paula Luca <[email protected]>wrote:
Anca Paula Luca wrote:
Guillaume Lerouge wrote:
Hi, A bit of summarizing on what we've got so far:
On Wed, Aug 19, 2009 at 11:56 AM, Ecaterina Valica <[email protected] wrote:
* 1.*
http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+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/NewWysiwygEditorInterfaceAppendix...
+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 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. 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_eyetrack...
guideline 5 where normal colors are used).
WDYT?
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.
-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/
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/NewWysiwygEditorInterfaceAppendix...
+1 for A
A
2. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+0.2 for E, +0.4 for F, +0.4 for H
H
3. http://dev.xwiki.org/xwiki/bin/view/Design/NewWysiwygEditorInterfaceAppendix...
+1 for B
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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
Anca Luca wrote:
Guillaume Lerouge wrote:
Hi Devs, Anca asked me to finalize the overall look of dialog boxes in the WYSIWYG so that she can work on it and polish it for the 2.0 release. Right now the issue is that we're using a different look for the link, image & macro dialog boxes which poses a consistency problem.
I've been working with Cati on a proposal for the look of the overall box - not for the inner part of the box. Proposals for the standardization of the inner part of the box will come later. The dialog box uses a wizard-like look and follows the vertical form principles proposed by Cati in a previous email (thus the primary action button at the bottom left, to follow the user's eye flow). Its "hidden" features are:
- Buttons can be in an enabled or disabled mode depending of what the current step is - All buttons are displayed all the time so that they don't move from one screen to the next
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?
Big +1! Thanks Anca, Marius
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Mon, Aug 24, 2009 at 5:05 PM, Marius Dumitru Florea < [email protected]> wrote:
Anca Luca wrote:
Guillaume Lerouge wrote:
Hi Devs, Anca asked me to finalize the overall look of dialog boxes in the
WYSIWYG so
that she can work on it and polish it for the 2.0 release. Right now the issue is that we're using a different look for the link, image & macro dialog boxes which poses a consistency problem.
I've been working with Cati on a proposal for the look of the overall box - not for the inner part of the box. Proposals for the standardization of the inner part of the box will come later. The dialog box uses a wizard-like look and follows the vertical form principles proposed by Cati in a previous email (thus the primary action button at the bottom left, to follow the user's eye flow). Its "hidden" features are:
- Buttons can be in an enabled or disabled mode depending of what the current step is - All buttons are displayed all the time so that they don't move from one screen to the next
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?
Big +1!
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
Thanks Anca, Marius
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
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
Hi Fabio, On Mon, Aug 24, 2009 at 6:54 PM, Fabio Mancinelli < [email protected]> wrote:
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.
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
-Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
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
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.
Hi, On Mon, Aug 24, 2009 at 7:22 PM, Ecaterina Valica <[email protected]> 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 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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Guillaume Lerouge wrote:
Hi, On Mon, Aug 24, 2009 at 7:22 PM, Ecaterina Valica <[email protected]> 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 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).
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
I vote +1 for all buttons visible, but disabled if not active. Thanks, Caty
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Tue, Aug 25, 2009 at 3:07 PM, Marius Dumitru Florea < [email protected]> wrote:
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."
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/whats... - http://www.ibm.com/developerworks/opensource/library/os-eclipse-custwiz/figu... - 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
Marius
Thanks, Caty _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
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
Hi, On Mon, Aug 24, 2009 at 7:54 PM, Anca Luca <[email protected]> wrote:
Guillaume Lerouge wrote:
Hi, On Mon, Aug 24, 2009 at 7:22 PM, Ecaterina Valica <[email protected]> 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 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).
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).
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
Thanks, Anca
Guillaume
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
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:
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.
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Guillaume Lerouge wrote:
Hi Fabio,
On Mon, Aug 24, 2009 at 6:54 PM, Fabio Mancinelli < [email protected]> wrote:
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.
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 ;-)
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).
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, On Mon, Aug 24, 2009 at 7:32 PM, Anca Luca <[email protected]> wrote:
Guillaume Lerouge wrote:
Hi Fabio,
On Mon, Aug 24, 2009 at 6:54 PM, Fabio Mancinelli < [email protected]> wrote:
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.
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 ;-)
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).
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 ;-)
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).
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.
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...
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
Guillaume
-Fabio _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Guillaume Lerouge Product Manager - XWiki Skype: wikibc Twitter: glerouge http://guillaumelerouge.com/
Fabio Mancinelli wrote:
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)
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?)
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 [email protected] http://lists.xwiki.org/mailman/listinfo/devs
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 ?
Ecaterina Valica 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.
How about changing the name of the "Next" action at the end in "Finish" Prev Next into Prev Finish ?
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
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (9)
-
Anca Luca -
Anca Paula Luca
-
Ecaterina Valica -
Fabio Mancinelli -
Guillaume Lerouge -
Marius Dumitru Florea -
Raluca Stavro -
Sergiu Dumitriu -
Vincent Massol