625229 - Make side panes easier to discover on first-run

Status: VERIFIED FIXED

(Firefox for Android Graveyard :: General, enhancement, P1)

Description

[Thomas Arend [:tarend]]

Situation:
Users don't discover side panes easily, so they can't figure out how to navigate, access tabs, an change settings

Comment 1

[Thomas Arend [:tarend]]

And idea we discussed was to show the side panes on first-run and then zoom in / hide the size panes. Alternative: show a good visual hint on firstrun or start page (something like  tabs <---  ---> settings)

Madhava: please feel free to add color and detail. Thanks!

Comment 2

[Mark Finkle (:mfinkle) (use needinfo?)]

I remeber one idea we had was to use a simple animation on the firstrun page. First, show the sidebars, then animate them moving offscreen. Finally, the normal firstrun content would be shown.

Comment 3

[Tony Chung [:tchung]]

why is this severity P1? its an enhancement request

Comment 4

[Thomas Arend [:tarend]]

See http://bit.ly/bugprio  
Priority = how many people are affected (P1 = everyone uses side panes)
Severity = impact of the issue or feature (here: enhancement)

Comment 5

[Tony Chung [:tchung]]

(In reply to comment #4)
> See http://bit.ly/bugprio  
> Priority = how many people are affected (P1 = everyone uses side panes)
> Severity = impact of the issue or feature (here: enhancement)

ah, thanks thomas.  As long as we have an understanding on what this means to those working on bugs, and a clear way to expose this to set expectations.

Comment 6

[Madhava Enros [:madhava]]

Design work proceeding on the feature page: https://wiki.mozilla.org/Fennec/Features/disc

Comment 7

[Wesley Johnston (:wesj)]

Attachment: WIP patch

This works, but might need a little tweaking. I'll try to get a video recorded sometime this weekend.

Comment 8

[Wesley Johnston (:wesj)]

Attachment: Video

Here is a video of how this looks.

Comment 9

[Mark Finkle (:mfinkle) (use needinfo?)]

From a technically viewpoint, it doesn't look to bad. The sliding looks fluid. From a UX viewpoint, it also looks good. We can discuss whether both sidebars should slide out together or we alternate, as in the video. Either way, it's a great start.

Now, we need to run the same on Android and see how fluid it is.

Comment 10

[Wesley Johnston (:wesj)]

Just to convince finkle the performance isn't worthless, horrible webcam video ahoy:

http://www.youtube.com/watch?v=CyYG_RxESqI

Comment 11

[Mark Finkle (:mfinkle) (use needinfo?)]

(In reply to comment #10)
> Just to convince finkle the performance isn't worthless, horrible webcam video
> ahoy:
> 
> http://www.youtube.com/watch?v=CyYG_RxESqI

finkle is satisfied! looks pretty good, thanks

Comment 12

[Wesley Johnston (:wesj)]

Attachment: Patch

This does the sidebar demo for us using CSS3 Animations. It will run every time about:firstrun is loaded (which for most people is only on firstrun). I'm not sure if we care enough to hide that behind an additional firstrun pref?

There are a few gotchas that I'm not sure how important they are to us. If you pan the sidebars open during or before the video, things will look bit funky. In addition, I'm not disabling clicking on the sidebars during the demo either.

Comment 13

[Wesley Johnston (:wesj)]

Attachment: Patch

Slightly smarter. This disables commands via a broadcaster, and disables the demo if the user starts panning.

Comment 14

[Madhava Enros [:madhava]]

Be good to understand the overall first-run flow, including this and the language picker.

Comment 15

[Aaron Train [:aaronmt]]

Is there also a plan (perhaps encompassing of the enhanced discoverability as a whole?) to additionally dictate the approach towards using swipe events to access the panes (perhaps an arrow with a dialog or what have you)?

Comment 16

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 529833 [details] [diff] [review]
Patch

># HG changeset patch
># Parent 6caf1fca1192ce44e38fef447d5c600f6cd0e17e
>
>diff --git a/mobile/chrome/content/browser-ui.js b/mobile/chrome/content/browser-ui.js
>--- a/mobile/chrome/content/browser-ui.js
>+++ b/mobile/chrome/content/browser-ui.js
>@@ -1097,18 +1097,20 @@ var BrowserUI = {
>       default:
>         isSupported = false;
>         break;
>     }
>     return isSupported;
>   },
> 
>   isCommandEnabled : function(cmd) {
>+    let broadcaster = document.getElementById("bcast_demoMode");

I don't like "demoMode" -> "bcast_uidiscovery"

>-    if (elem && (elem.getAttribute("disabled") == "true"))
>+    if ((broadcaster && (broadcaster.getAttribute("mode") == "demo")) ||
>+        (elem && (elem.getAttribute("disabled") == "true")))

"demo" -> "discovery"

You could have each <command> observe the broadcaster, but I guess we don't really need to be that specific yet.

Break these into 2 "if" statments. I think it woul be more clear. Add a comment above the broadcaster "if" statement so we know why it's here

>-      <vbox class="panel-dark">
>+      <vbox id="tabs-sidebar" class="sidebar" observes="bcast_demoMode">

is this actually required? OK - I see this is used in the CSS

>-              <box id="toolbar-moveable-container">
>+              <box id="toolbar-moveable-container" observes="bcast_demoMode">

same? OK - don't you need the class="sidebar" for this to be used in the CSS?

>-      <vbox class="panel-dark">
>+      <vbox id="controls-sidebar" class="sidebar" observes="bcast_demoMode">

same? OK - I see this is used in the CSS

>diff --git a/mobile/chrome/content/firstrun/firstrun.xhtml b/mobile/chrome/content/firstrun/firstrun.xhtml

>-    <div id="content">
>+    <div id="content" hidden="true">

not sure it needs to be hidden during the discovery phase, but we'll get more feedback

>         function init() {
>           setupLinks();
>+          demoUI();

demoUI -> startDiscovery

>+        function endDemo() {

stopDiscovery

>+        function showContent() {
>+          let doc = getChromeWin().document;
>+          let winElt = doc.documentElement;
>         }

what exactly is happening here?

>diff --git a/mobile/themes/core/browser.css b/mobile/themes/core/browser.css

>+#toolbar-moveable-container,
> #toolbar-moveable-container[top="0"] {

this seems redundant. you should only need one of these lines

>+/* Sidebar peeking */
>+.sidebar[mode="demo"] {
>+  -moz-animation-delay: 1s;
>+  -moz-animation-duration: 5s;
>+  -moz-animation-name: demosidebars;

mode="demo" -> mode="discovery"
demosidebars -> uidiscovery

r- cause I want to see the next patch before checkin, but this looks good

Comment 17

[Wesley Johnston (:wesj)]

Attachment: Updated to nits

> Don't you need the class="sidebar" for this to be used in the CSS?
Whoops. We need to lock the urlbar during the demo so that the sidebars are "attached to it. Typo on my part.

> what exactly is happening here?
Cruft :( Pulled it out now.

Comment 18

[Mark Finkle (:mfinkle) (use needinfo?)]

Comment on attachment 530344 [details] [diff] [review]
Updated to nits

We might want to add a pref to only show the discovery on the real firstrun and not everytime the page loads. We'll deal with that in a followup.

Comment 19

[Wesley Johnston (:wesj)]

http://hg.mozilla.org/mozilla-central/rev/8ea8e50b631c

Comment 20

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Doesn't seem to work after uninstalling and reinstalling the app.

Comment 21

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

Mozilla/5.0 (Android; Linux armv71; rv6.0a1) Gecko/20110506 Firefox/6.0a1 Fennec/6.0a1
Device: Thunderbolt
OS: Android 2.2

Comment 22

[Matt Brubeck (:mbrubeck)]

(In reply to comment #21)
> Mozilla/5.0 (Android; Linux armv71; rv6.0a1) Gecko/20110506 Firefox/6.0a1
> Fennec/6.0a1

This change just landed today, so it is not in the 20110506 nightly build.

Comment 23

[Naoki Hirata :nhirata (please use needinfo instead of cc)]

oh oops.  Matt's right.  Going to test tomorrow.

Comment 24

[Aaron Train [:aaronmt]]

Verified Fixed

Device: Nexus One

Mozilla/5.0 (Android; Linux armv7l; rv6.0a1) Gecko/20110508 Firefox/6.0a1 Fennec/6.0a1

Question, is there any expectation that these CSS transforms (albeit very basic usage here) will cause any performance hit on older devices?

Comment 25

[Wesley Johnston (:wesj)]

There has been some concern. Getting some broad(er) device testing was part of reason to check this in now.

Comment 26

[Aaron Train [:aaronmt]]

in-litmus+ https://litmus.mozilla.org/show_test.cgi?&id=18184