The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.".
As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session.
The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel.
Matt Flaschen
Honestly I don't think cancel should be destructive. I think "discard changes" should. But currently we don't change the button text after the user has made changes. Someone want to log that bug, should be simple since there are other actions that listen for changes to the text box to trigger a "are you sure you want to navigate away from this page" if changes have been made.
Sent while mobile
On Mar 5, 2014, at 12:20 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.".
As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session.
The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel.
Matt Flaschen
_______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
I strongly support to that suggestion as it improves the design!
2014-03-05 16:23 GMT+08:00 Jared Zimmerman jzimmerman@wikimedia.org:
Honestly I don't think cancel should be destructive. I think "discard changes" should. But currently we don't change the button text after the user has made changes. Someone want to log that bug, should be simple since there are other actions that listen for changes to the text box to trigger a "are you sure you want to navigate away from this page" if changes have been made.
Sent while mobile
On Mar 5, 2014, at 12:20 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.".
As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session.
The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel.
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On Wed, Mar 5, 2014 at 8:20 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.".
As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session.
The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel.
In addition to that... the author is asking if Save page should be mw-ui-constructive (green). That's correct right? mw-ui-primary is actually deprecated in the new version, and save is not a multi-step action so it's not mw-ui-progressive (blue).
Jared?
Do we really want to change the button from something else *to* destructive once text has been entered? What do we do about users whose browsers don't support JavaScript?
We need to be careful with setting too strict of rules in situations like this. I find the color of the button is important for many users to distinguish the difference between actions at first glance. In the case of Flow, where we have Cancel (or Discard -- the wording of which actually makes more sense), Preview, and Reply/Add topic, I don't want to have two buttons side-by-side of the exact same color that perform drastically different actions (Preview and Cancel).
--Shahyar
On Wed, Mar 5, 2014 at 8:51 AM, Steven Walling swalling@wikimedia.orgwrote:
On Wed, Mar 5, 2014 at 8:20 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.".
As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session.
The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel.
In addition to that... the author is asking if Save page should be mw-ui-constructive (green). That's correct right? mw-ui-primary is actually deprecated in the new version, and save is not a multi-step action so it's not mw-ui-progressive (blue).
Jared?
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
For non-JS I'll say what I always say. We should have a graceful controlled degradation for these users. In this can they will see no change. eg. the button will always say cancel , and not change based on their actions.
Sent while mobile
On Mar 5, 2014, at 7:22 AM, Shahyar Ghobadpour sghobadpour@wikimedia.org wrote:
Do we really want to change the button from something else to destructive once text has been entered? What do we do about users whose browsers don't support JavaScript?
We need to be careful with setting too strict of rules in situations like this. I find the color of the button is important for many users to distinguish the difference between actions at first glance. In the case of Flow, where we have Cancel (or Discard -- the wording of which actually makes more sense), Preview, and Reply/Add topic, I don't want to have two buttons side-by-side of the exact same color that perform drastically different actions (Preview and Cancel).
--Shahyar
On Wed, Mar 5, 2014 at 8:51 AM, Steven Walling swalling@wikimedia.org wrote:
On Wed, Mar 5, 2014 at 8:20 AM, Matthew Flaschen mflaschen@wikimedia.org wrote: The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.".
As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session.
The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel.
In addition to that... the author is asking if Save page should be mw-ui-constructive (green). That's correct right? mw-ui-primary is actually deprecated in the new version, and save is not a multi-step action so it's not mw-ui-progressive (blue).
Jared?
-- Steven Walling, Product Manager https://wikimediafoundation.org/
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
_______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 03/05/2014 12:33 PM, Jared Zimmerman wrote:
That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
I think the idea of starting quiet neutral, and changing to quiet destructive when they have (unsaved) changes, makes sense. I agree it shouldn't be too attention-grabbing, since quiet buttons are not visible until hover/focus.
I'm not sure about changing the text. That might be too attention-grabbing.
For non-JS I'll say what I always say. We should have a graceful controlled degradation for these users. In this can they will see no change. eg. the button will always say cancel , and not change based on their actions.
Yes, I think this is fine.
For the core edit page, I filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=62304 . There is also a Flow one S filed at https://bugzilla.wikimedia.org/show_bug.cgi?id=62290
Matt Flaschen
I'm not sure about changing the text. That might be too attention-grabbing.
If changing the text makes the action more contextual, it tends to work well. We applied and tested with users similar approaches [1]. some examples are the Draft namespace prototypes (where "publish draft" turns into "save" once there are changes) and the translate extension (where possible outdated translations have "Confirm translation" as the initial action and it turns into "Save" when the user modifies the translation).
A possible distraction can be produced if the change in text length has a big impact, but you can play with min-width to compensate that (giving some extra room to the button which is expected to grow). In this case, since we are talking about silent buttons, that is even less of a problem (compared to colourful primary action buttons).
[1] Testing sessions for draft namespaces available at https://www.mediawiki.org/wiki/Draft_namespace/Usability_testing/Results
On Thu, Mar 6, 2014 at 6:22 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 03/05/2014 12:33 PM, Jared Zimmerman wrote:
That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
I think the idea of starting quiet neutral, and changing to quiet destructive when they have (unsaved) changes, makes sense. I agree it shouldn't be too attention-grabbing, since quiet buttons are not visible until hover/focus.
I'm not sure about changing the text. That might be too attention-grabbing.
For non-JS I'll say what I always say. We should have a graceful
controlled degradation for these users. In this can they will see no change. eg. the button will always say cancel , and not change based on their actions.
Yes, I think this is fine.
For the core edit page, I filed as https://bugzilla.wikimedia. org/show_bug.cgi?id=62304 . There is also a Flow one S filed at https://bugzilla.wikimedia.org/show_bug.cgi?id=62290
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Pau has a good point if we keep the strings a single word when possible (language) the distraction should be minimized. Especially since we should try to do a quick but subtle fade between the two black text strings shouldn't be that distracting.
Sent while mobile
On Mar 6, 2014, at 12:50 AM, Pau Giner pginer@wikimedia.org wrote:
I'm not sure about changing the text. That might be too attention-grabbing.
If changing the text makes the action more contextual, it tends to work well. We applied and tested with users similar approaches [1]. some examples are the Draft namespace prototypes (where "publish draft" turns into "save" once there are changes) and the translate extension (where possible outdated translations have "Confirm translation" as the initial action and it turns into "Save" when the user modifies the translation).
A possible distraction can be produced if the change in text length has a big impact, but you can play with min-width to compensate that (giving some extra room to the button which is expected to grow). In this case, since we are talking about silent buttons, that is even less of a problem (compared to colourful primary action buttons).
[1] Testing sessions for draft namespaces available at https://www.mediawiki.org/wiki/Draft_namespace/Usability_testing/Results
On Thu, Mar 6, 2014 at 6:22 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 03/05/2014 12:33 PM, Jared Zimmerman wrote: That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
I think the idea of starting quiet neutral, and changing to quiet destructive when they have (unsaved) changes, makes sense. I agree it shouldn't be too attention-grabbing, since quiet buttons are not visible until hover/focus.
I'm not sure about changing the text. That might be too attention-grabbing.
For non-JS I'll say what I always say. We should have a graceful controlled degradation for these users. In this can they will see no change. eg. the button will always say cancel , and not change based on their actions.
Yes, I think this is fine.
For the core edit page, I filed as https://bugzilla.wikimedia.org/show_bug.cgi?id=62304 . There is also a Flow one S filed at https://bugzilla.wikimedia.org/show_bug.cgi?id=62290
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
For English, maybe. There's no guarantee that changing from Cancel to Discard in other languages will be one word, or even close in length.
--Shahyar
On Fri, Mar 7, 2014 at 3:21 AM, Jared Zimmerman jzimmerman@wikimedia.orgwrote:
Pau has a good point if we keep the strings a single word when possible (language) the distraction should be minimized. Especially since we should try to do a quick but subtle fade between the two black text strings shouldn't be that distracting.
Sent while mobile
On Mar 6, 2014, at 12:50 AM, Pau Giner pginer@wikimedia.org wrote:
I'm not sure about changing the text. That might be too
attention-grabbing.
If changing the text makes the action more contextual, it tends to work well. We applied and tested with users similar approaches [1]. some examples are the Draft namespace prototypes (where "publish draft" turns into "save" once there are changes) and the translate extension (where possible outdated translations have "Confirm translation" as the initial action and it turns into "Save" when the user modifies the translation).
A possible distraction can be produced if the change in text length has a big impact, but you can play with min-width to compensate that (giving some extra room to the button which is expected to grow). In this case, since we are talking about silent buttons, that is even less of a problem (compared to colourful primary action buttons).
[1] Testing sessions for draft namespaces available at https://www.mediawiki.org/wiki/Draft_namespace/Usability_testing/Results
On Thu, Mar 6, 2014 at 6:22 AM, Matthew Flaschen mflaschen@wikimedia.orgwrote:
On 03/05/2014 12:33 PM, Jared Zimmerman wrote:
That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
I think the idea of starting quiet neutral, and changing to quiet destructive when they have (unsaved) changes, makes sense. I agree it shouldn't be too attention-grabbing, since quiet buttons are not visible until hover/focus.
I'm not sure about changing the text. That might be too attention-grabbing.
For non-JS I'll say what I always say. We should have a graceful
controlled degradation for these users. In this can they will see no change. eg. the button will always say cancel , and not change based on their actions.
Yes, I think this is fine.
For the core edit page, I filed as https://bugzilla.wikimedia. org/show_bug.cgi?id=62304 . There is also a Flow one S filed at https://bugzilla.wikimedia.org/show_bug.cgi?id=62290
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Pau Giner Interaction Designer Wikimedia Foundation _______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
correct, thats what I was alluding to, however in the translation notes we should include the goal of striving for short strings here.
*Jared Zimmerman * \ Director of User Experience \ Wikimedia Foundation
M : +1 415 609 4043 | : @JaredZimmermanhttps://twitter.com/JaredZimmerman
On Fri, Mar 7, 2014 at 11:50 AM, Shahyar Ghobadpour < sghobadpour@wikimedia.org> wrote:
For English, maybe. There's no guarantee that changing from Cancel to Discard in other languages will be one word, or even close in length.
--Shahyar
On Fri, Mar 7, 2014 at 3:21 AM, Jared Zimmerman jzimmerman@wikimedia.orgwrote:
Pau has a good point if we keep the strings a single word when possible (language) the distraction should be minimized. Especially since we should try to do a quick but subtle fade between the two black text strings shouldn't be that distracting.
Sent while mobile
On Mar 6, 2014, at 12:50 AM, Pau Giner pginer@wikimedia.org wrote:
I'm not sure about changing the text. That might be too
attention-grabbing.
If changing the text makes the action more contextual, it tends to work well. We applied and tested with users similar approaches [1]. some examples are the Draft namespace prototypes (where "publish draft" turns into "save" once there are changes) and the translate extension (where possible outdated translations have "Confirm translation" as the initial action and it turns into "Save" when the user modifies the translation).
A possible distraction can be produced if the change in text length has a big impact, but you can play with min-width to compensate that (giving some extra room to the button which is expected to grow). In this case, since we are talking about silent buttons, that is even less of a problem (compared to colourful primary action buttons).
[1] Testing sessions for draft namespaces available at https://www.mediawiki.org/wiki/Draft_namespace/Usability_testing/Results
On Thu, Mar 6, 2014 at 6:22 AM, Matthew Flaschen <mflaschen@wikimedia.org
wrote:
On 03/05/2014 12:33 PM, Jared Zimmerman wrote:
That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
I think the idea of starting quiet neutral, and changing to quiet destructive when they have (unsaved) changes, makes sense. I agree it shouldn't be too attention-grabbing, since quiet buttons are not visible until hover/focus.
I'm not sure about changing the text. That might be too attention-grabbing.
For non-JS I'll say what I always say. We should have a graceful
controlled degradation for these users. In this can they will see no change. eg. the button will always say cancel , and not change based on their actions.
Yes, I think this is fine.
For the core edit page, I filed as https://bugzilla.wikimedia. org/show_bug.cgi?id=62304 . There is also a Flow one S filed at https://bugzilla.wikimedia.org/show_bug.cgi?id=62290
Matt Flaschen
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
-- Pau Giner Interaction Designer Wikimedia Foundation _______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
On 03/05/2014 12:33 PM, Jared Zimmerman wrote:
That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
Just to clarify, you're saying it should be quiet neutral (mw-ui-button mw-ui-quiet) to start, then (for JS users) if they make a change, it becomes quiet destructive and the text changes to 'Discard'?
In Deepali's initial edit page patch, it probably won't implement the JS change (that can come later), but I want to make sure we're okay with being quiet neutral to start.
This is the last remaining issue for that patch (https://gerrit.wikimedia.org/r/#/c/116725/). It's still destructive to start, which contradicts the style guide.
Matt Flaschen
Yes. That's correct Matt
Sent while mobile
On Mar 7, 2014, at 12:04 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
On 03/05/2014 12:33 PM, Jared Zimmerman wrote: That's partly (but not strongly) why I think both should be quiet destructive. But since both would be quiet, either quiet neutral (cancel) or quiet destructive (discard) the user won't actually see a color change or appearance when they enter text.
Just to clarify, you're saying it should be quiet neutral (mw-ui-button mw-ui-quiet) to start, then (for JS users) if they make a change, it becomes quiet destructive and the text changes to 'Discard'?
In Deepali's initial edit page patch, it probably won't implement the JS change (that can come later), but I want to make sure we're okay with being quiet neutral to start.
This is the last remaining issue for that patch (https://gerrit.wikimedia.org/r/#/c/116725/). It's still destructive to start, which contradicts the style guide.
Matt Flaschen
_______________________________________________ Design mailing list Design@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/design
Yes, should be constructive not primary.
Sent while mobile
On Mar 5, 2014, at 5:51 AM, Steven Walling swalling@wikimedia.org wrote:
On Wed, Mar 5, 2014 at 8:20 AM, Matthew Flaschen mflaschen@wikimedia.org wrote:
The current proposed change to use mw-ui-button for save/preview/show changes/cancel (on the edit screen) uses mw-ui-destructive (with quiet) for the cancel button. This directly contradicts the style guide, which says, "This should not be used for cancel buttons.".
As noted at https://gerrit.wikimedia.org/r/#/c/116725/ , my understanding of destructive is that you are deleting something that was already publicly visible, or at least has an impact beyond your own personal session.
The cancel button doesn't seem to fit that. Cancel is a common concept, and semantically clear, so perhaps we should simply add mw-ui-cancel.
In addition to that... the author is asking if Save page should be mw-ui-constructive (green). That's correct right? mw-ui-primary is actually deprecated in the new version, and save is not a multi-step action so it's not mw-ui-progressive (blue).
Jared?