680499 - Back/Done buttons in new start-up Add-On UI respond poorly to muscle memory on Windows

Status: RESOLVED WONTFIX

(Toolkit :: Add-ons Manager, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

Attachment: Screenshot

If making a change to an addon, for example disabling an addon, the next screen describes what is going to happen. At the bottom right of the screen, there are two buttons: [Back] [Done].

The buttons are positioned closely together, and common Windows users are used to seeing buttons like that meaning [OK] [Cancel]. Because of this, my muscle memory had me hit the [Back] button when I wanted to hit the [Done] button.

Comment 1

[:Gavin Sharp [email: [e-mail]]]

Looks to me like this dialog should use a <wizard>, rather than rolling it's own wizard-like logic... that should also take care of making the button order platform-appropriate.

Comment 2

[Alex Faaborg [:faaborg] (Firefox UX)]

>Looks to me like this dialog should use a <wizard>

that's fine in terms of getting the button order right (and not making this mistake in future multi-step processes), but we would want to update the visual design of the wizard to follow:

-one large title (as opposed to the three titles we currently have in our wizard)
-white back
-recessed area at the bottom for buttons

we are also using this style with setting up a Sync account (and again I think it might just be custom instead of using <wizard>

Comment 3

[Dão Gottwald [:dao]]

> >Looks to me like this dialog should use a <wizard>
>
> that's fine in terms of getting the button order right (and not making this
> mistake in future multi-step processes), but we would want to update the
> visual design of the wizard to follow:
> 
> -one large title (as opposed to the three titles we currently have in our
> wizard)
> -white back
> -recessed area at the bottom for buttons

Has a bug been filed on this?

These improvements don't seem like blocking issues and could be worked on independently and in parallel. In the meantime we should just use <wizard>, as getting the looks right but the interaction wrong (bug 680873 is another data point) isn't a good tradeoff.

Comment 4

[Alex Faaborg [:faaborg] (Firefox UX)]

while this is a bug (we can adjust the button order and set a default button), switching this code over to beign a wizard and also modifying the wizard appearance might be overkill since we were planning this flow to mainly a one time thing for users.

Comment 5

[LegNeato]

---------------------------------[ Triage Comment ]---------------------------------

Tracking this Firefox 8 as we should get a call from UX/Product if this is required for the feature to ship.

CCing Asa and Boriss as they are both on point according to the feature page @ https://wiki.mozilla.org/Extension_Manager:Projects:Third_Party_Add-on_Warnings

Comment 6

[Asa Dotzler [:asa]]

Happy to see us fix this in a later release for any of the late-ugrading users, but I don't think I'd pull the feature over this and we're basically done with the 8 cycle so I wouldn't chase a fix either.

Comment 7

[LegNeato]

[triage comment]

No longer tracking due to comment 6.

Comment 8

[Alex Limi (:limi) — Firefox UX Team]

Agreed that this is not optimal, but it shipped, and is a one-time UI, so I don't think we should worry about it.

If we use it again in the future, we should consider upgrading the <wizard> to look native on Windows, and use that.