942915 - Decide on placement for "Metro Mode" button in Australis

Status: RESOLVED FIXED

(Firefox :: Toolbars and Customization, defect, P2)

Description

[Marina Samuel [:emtwo]]

This is a follow up from bug 934032. We'd like to include the 'Metro Mode' button to switch to Metro as one of the default 'Customize and Control' buttons for users with Windows 8. Brian (:bbondy) mentioned that it would make sense to exchange the full screen button with the metro one.

Comment 1

[Brian R. Bondy [:bbondy]]

I think it'd make sense to still have the full screen button in the customization panel, but I think we could replace it on the main UI on >= Win8.

Comment 2

[:Gijs (he/him)]

I suspect this is something that you'd want to check with Madhava.

Comment 3

[Brian R. Bondy [:bbondy]]

+Madhava

Comment 4

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

I think putting this in place of the fullscreen button makes sense to me (and moving the fullscreen button to the palette). Windows 8 pushes users towards Metro for their immersive experience, which is what Fullscreen Browsing is supposed to accomplish.

Comment 5

[Mike Conley (:mconley) (:⚙️)]

(In reply to Jared Wein [:jaws] from comment #4)
> I think putting this in place of the fullscreen button makes sense to me
> (and moving the fullscreen button to the palette). Windows 8 pushes users
> towards Metro for their immersive experience, which is what Fullscreen
> Browsing is supposed to accomplish.

That makes sense to me too.

Comment 6

[Dão Gottwald [:dao]]

Metro gives the whole screen to applications (such as Firefox), whereas our fullscreen mode does that for content (i.e. it makes Firefox reduce its UI close to zero). Does our Metro mode accomplish the latter as well as fullscreen mode? If not, these seem like different use cases really.

Also, is switching to Metro mode as seamless as going fullscreen?

Comment 7

[Brian R. Bondy [:bbondy]]

(In reply to Dão Gottwald [:dao] from comment #6)
> Metro gives the whole screen to applications (such as Firefox), whereas our
> fullscreen mode does that for content (i.e. it makes Firefox reduce its UI
> close to zero). Does our Metro mode accomplish the latter as well as
> fullscreen mode? If not, these seem like different use cases really.

There are different and valid use cases for both; however, most of the use cases are common.
If you're asking what the UI looks like on Metro, there is no chrome at all unless you swipe it in.
And even then, once you tap content it disappears.

> Also, is switching to Metro mode as seamless as going fullscreen?

No, it closes the browser and re-opens (although with session store) in the new environment.

I do think it'll be a bit confusion (and redundant) to have both full screen and metro though.
When users want an immersive full screen experience in Windows 8, I think they'll think of the metro application more than they'll think of just get rid of the extra window chrome at the top.

But my suggestion was to jut take the default place of full screen, and leave the icon customizable for full screen.  I'd rather replace the full screen button than something like the addon button.

Comment 8

[Dão Gottwald [:dao]]

(In reply to Brian R. Bondy [:bbondy] from comment #7)
> > Also, is switching to Metro mode as seamless as going fullscreen?
> 
> No, it closes the browser and re-opens (although with session store) in the
> new environment.

So the transition takes longer, likely feels more jarring and we might lose data along the way since session store isn't perfect, especially when audio/video or plugins are involved. That does seem like a significant regression.

> I do think it'll be a bit confusion (and redundant) to have both full screen
> and metro though.
> When users want an immersive full screen experience in Windows 8, I think
> they'll think of the metro application more than they'll think of just get
> rid of the extra window chrome at the top.

Since it's more disruptive to the whole application and session, have you considered adding the Metro mode switch to the jump list instead?

> But my suggestion was to jut take the default place of full screen, and
> leave the icon customizable for full screen.  I'd rather replace the full
> screen button than something like the addon button.

Why are you assuming that we'd need to remove something else if we didn't remove fullscreen?

Comment 9

[Brian R. Bondy [:bbondy]]

(In reply to Dão Gottwald [:dao] from comment #8)
> So the transition takes longer, likely feels more jarring and we might lose
> data along the way since session store isn't perfect, especially when
> audio/video or plugins are involved. That does seem like a significant
> regression.

Yes but you get a significant amount of extra functionality and a touch optimized experience, which is not capable in full screen mode. This is more a question of what will people do more, I'd bet they'd want to go to metro more than they'd want to use full screen, but perhaps we can do some A/B testing via telemetry probes with different default placeholders.  It's also a question about what does Mozilla want to promote more, having the Metro button will lead to more people making us the default which is an obvious win in terms of market share.

> Since it's more disruptive to the whole application and session, have you
> considered adding the Metro mode switch to the jump list instead?

Sure, but it's best to leave this decision to UX to decide.

> > But my suggestion was to jut take the default place of full screen, and
> > leave the icon customizable for full screen.  I'd rather replace the full
> > screen button than something like the addon button.
> 
> Why are you assuming that we'd need to remove something else if we didn't
> remove fullscreen?

I don't know if we're trying to limit the number of default icons or not. If not then sure we can add another one. But you may have extra confusion about full screen vs Metro. Or maybe people will understand the distinction fine, in which case that's fine with me.

I'm not the best person to make these calls, deferring to the experts (UX).

Comment 10

[Dão Gottwald [:dao]]

(In reply to Brian R. Bondy [:bbondy] from comment #9)
> (In reply to Dão Gottwald [:dao] from comment #8)
> > So the transition takes longer, likely feels more jarring and we might lose
> > data along the way since session store isn't perfect, especially when
> > audio/video or plugins are involved. That does seem like a significant
> > regression.
> 
> Yes but you get a significant amount of extra functionality and a touch
> optimized experience, which is not capable in full screen mode.

Yes, but... different use cases. When I (primarily a Windows 7 user, mind you) go fullscreen, it's because I want to focus on some particular content and not be distracted by other stuff. This doesn't mean I'd prefer switching to a different input method at the same time. So your advertised benefits won't necessarily help me. I suspect the same will be true for people going fullscreen in order to do a presentation.

Comment 11

[Brian R. Bondy [:bbondy]]

Adding another button to the grid by default sounds like the easiest short term solution to make everyone happy, but we'll wait on UX to weigh in.

Comment 12

[Madhava Enros [:madhava]]

Hi all -

While I'm usually in the "if we're going going to add a tool, is there one we can remove?" camp, I think that it's not clear enough that a "switch to metro" button really a 1:1 replacement for Full Screen. As others have mentioned above, I think there are use-cases and user-expectations that are different enough between the two that we would get some confusion and frustration. That said, to be honest - I think we just don't know enough yet.

I also understand why you'd want to have one there, for discoverability of the Metro UI and the (possibly) more Firefox-set-to-default world it might drive.

Can we add the switch-to-metro button (rather than replacing Fullscreen) and then watch with telemetry to see how many people actually use either or both? If we really see a drop off in using fullscreen and people using the switch button we'd have a better basis to make that swap.

Comment 13

[Brian R. Bondy [:bbondy]]

Yep that sounds good to me, Marina can you make that change for this bug, and post a followup about adding a telemetry probe? The telemetry probe should be posted separate since it isn't as high priority.

Comment 14

[Marco Mucci [:MarcoM]]

Hi Madhava, thanks very much for the quick turnaround and solution.

Comment 15

[Marina Samuel [:emtwo]]

Attachment: Part 1: v1: Add 'Metro Mode' as a default button

Comment 16

[Brian R. Bondy [:bbondy]]

Comment on attachment 8340001 [details] [diff] [review]
Part 1: v1: Add 'Metro Mode' as a default button

Review of attachment 8340001 [details] [diff] [review]:
-----------------------------------------------------------------

Do any tests need to be updated for this as well? Perhaps even if they currently pass adding a test to make sure this shows up on win8?

Comment 17

[Brian R. Bondy [:bbondy]]

... and not on other win OS and other OS.

Comment 18

[Marina Samuel [:emtwo]]

Attachment: Part 2: v1: Update Tests

Tests pass locally, waiting on try: https://tbpl.mozilla.org/?tree=Try&rev=b0a96393e987

Comment 19

[:Gijs (he/him)]

(In reply to Marina Samuel [:emtwo] from comment #18)
> Created attachment 8340002 [details] [diff] [review]
> Part 2: v1: Update Tests

Driveby nits:

Could you please use Services.sysinfo instead of the direct Cc access, also for the code in CustomizableUI?

># HG changeset patch
>diff --git a/browser/components/customizableui/test/head.js b/browser/components/customizableui/test/head.js
>+function isInWin8() {

You've put this (and the other function you've added) inbetween two related functions. I know the file isn't particularly well-organized, but could you not make it worse? :-)

Comment 20

[Marina Samuel [:emtwo]]

Attachment: Part 2: v2: Update Tests

Address nits

Comment 21

[Marina Samuel [:emtwo]]

Attachment: Part 2: v3: Update Tests

Some tests were failing on non-windows. Updated to fix those & tested locally both on a windows & mac machine.

Comment 22

[Marina Samuel [:emtwo]]

https://tbpl.mozilla.org/?tree=Try&rev=7b937ecc419d

Comment 23

[Brian R. Bondy [:bbondy]]

Comment on attachment 8340545 [details] [diff] [review]
Part 2: v3: Update Tests

Review of attachment 8340545 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/customizableui/test/browser_890140_orphaned_placeholders.js
@@ +47,5 @@
> +      if (!isInWin8()) {
> +        placementsAfterAppend = placementsAfterAppend.concat(["sync-button"]);
> +        btn = document.getElementById("sync-button");
> +        simulateItemDrag(btn, panel);
> +      }

I don't fully understand why we don't want this and the developer button one below in win8. Can you explain?

Comment 24

[Marina Samuel [:emtwo]]

In windows 8 now we have a 10th default button added, the Metro Mode button which means by default there are 2 visible placeholders when in customize mode. This test checks that when a row has 2 buttons, there is 1 visible placeholder. So in non-windows 8, 2 buttons need to be added (developer AND sync) to get 1 placeholder but in windows 8, only 1 button needs to be added (developer).

I could add a comment if it doesn't seem clear.

Comment 25

[Brian R. Bondy [:bbondy]]

Comment on attachment 8340545 [details] [diff] [review]
Part 2: v3: Update Tests

Review of attachment 8340545 [details] [diff] [review]:
-----------------------------------------------------------------

I see, thanks for the explanation.

Comment 26

[Brian R. Bondy [:bbondy]]

I think the existing surrounding comments are clear enough btw, I should have just read them before asking about the change :)

Comment 27

[:Gijs (he/him)]

NB: when landing, please ensure all csets have 'Australis' in the commit msg, so we can back them out on holly.

Comment 28

[Marina Samuel [:emtwo]]

https://hg.mozilla.org/integration/fx-team/rev/8601e55efa52
https://hg.mozilla.org/integration/fx-team/rev/f2a84fb7a14e

Comment 29

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/8601e55efa52
https://hg.mozilla.org/mozilla-central/rev/f2a84fb7a14e

Comment 30

[Jim Jeffery not reading bug-mail 1/2/11]

I just installed the latest hourly m-c win32 build that contains this patch.

When I go into the 'customize area', I still see a Metro Icon on the palette.  Have I mis-read this patch, that it 'should' not be on systems running win7 ?

Comment 31

[:Gijs (he/him)]

(In reply to Jim Jeffery not reading bug-mail 1/2/11 from comment #30)
> I just installed the latest hourly m-c win32 build that contains this patch.
> 
> When I go into the 'customize area', I still see a Metro Icon on the
> palette.  Have I mis-read this patch, that it 'should' not be on systems
> running win7 ?

This is tracked in bug 944740.

Comment 32

[Brian R. Bondy [:bbondy]]

When testing this bug, please do normal testing + also test to make sure upgrading from an older Nightly before Australis to this build shows the button by default.
Another test case that should be including is a fresh install of a new profile should show it by default.

Comment 33

[Tim Nguyen :ntim]

Please take a look at bug 956583