I just started diving into Sola's work from bug 998036 for jiggling the reader mode hint, but Mark rightly suggested that we should take a step back and nail down the UX specs before going too far. Ian, you seemed excited about the jiggling reader mode icon in bug 998036. Can you elaborate on where you think we should go with this? Some questions to help figure out how to design this framework: * If we do want this for reader mode, what should the paired popup look like? * What conditions will prompt the hint? E.g., the first time the reader icon is shown? Is this a one-off hint, or can it be triggered multiple times? * Will there be other places in our UI where we will want this jiggle effect?

Hey Brian, take a look at this attached mockup, hopefully this answers most of your questions. Basically we want to use a combination of wiggling/shaking the reader icon and popping up a tooltip. (In reply to Brian Nicholson (:bnicholson) from comment #0) > Ian, you seemed excited about the jiggling reader mode icon in bug 998036. > Can you elaborate on where you think we should go with this? > > Some questions to help figure out how to design this framework: > * If we do want this for reader mode, what should the paired popup look like? > * What conditions will prompt the hint? E.g., the first time the reader icon > is shown? So as to space out the frequency with which a user might see tips, I suggest waiting until the second or third time a user hits an article that can be parsed by Reader Mode. Also, this should not be shown if a user finds Reader Mode on their own beforehand. > Is this a one-off hint, or can it be triggered multiple times? One off > * Will there be other places in our UI where we will want this jiggle effect? Not sure. Maybe? It seems like it might be a useful visual cue to have in our toolbox, if used in moderation.

Also cc-ing Anthony, he can also give some guidance with regard to visual design and animation polish, once we have the basic interactions working properly.

Anthony, this bug needs design for Fx33.

(In reply to Ian Barlow (:ibarlow) from comment #1) > So as to space out the frequency with which a user might see tips, I suggest > waiting until the second or third time a user hits an article that can be > parsed by Reader Mode. Also, this should not be shown if a user finds Reader > Mode on their own beforehand. Unfortunately, there's no good way for us to know whether they've entered reader mode before since we haven't been collecting that data. Here are our options: 1) Set the target count to a lower number (e.g., 3), and if the user didn't manually hit the reader mode icon the first two times it appeared, the hint will show up the third time. Since most people probably don't visit reader mode 1 out of every 3 page visits, nearly everyone will see the hint, including those that have used reader mode before. 2) Set the target count to a much higher number (or set no target at all initially). This gives us a full release cycle to collect the data to determine whether users have entered reader mode, and we could then lower the target count in the following Fx release after we've more accurately gauged reader mode usage. If we add a telemetry "reader icon shown" counter to the data collection period, it could also help to tweak the ideal target count depending on how often users actually see the icon. #2 might be ideal if we can uplift the data collection logic to Aurora so that the actual hint still gets shipped in Fx33. Thoughts?

Implements HintPopup. Getting the "PRO TIP" text to be bold was a bit tricky -- I ended up adding a CDATA tag to preserve the HTML chars in the string, then using Html.fromHtml() to apply the bold effect.

Shows a HintPopup and jiggles the reader mode icon when the reader mode icon is shown. It looks like Sola's jiggle effect was pulled directly from https://plus.google.com/+CyrilMottier/posts/FABaJhRMCuy, so only requesting feedback until we're sure the code is compatible with our license.

Adds a counter for the reader mode icon. Only marking for feedback again until we've verified what we want to do for comment 4.

Ian/Anthony/anyone else: Here's a build with patches 1 & 2 applied (I omitted the 3rd patch so it's easy to trigger the popup). Any changes you'd recommend? http://people.mozilla.org/~bnicholson/fennec_builds/reader-hint.apk Also, as mentioned in comment 6, the code for the "jiggle" effect we're currently using is unlicensed. If we want our own jiggle effect, please describe it or post a video; otherwise, we'll have to contact the author to make sure we can use his code.

Splitting this patch to be a bit more manageable -- jiggle effect will be separate.

bnicholson suggested landing counting in earlier Firefoxes. Thumbs up for this. Something to think about, probably not for this bug, but for others: you might want to have some kind of date-related weighting on usage (e.g., bucketing), or some kind of count expiry. There are contextual approaches that a straightforward counter doesn't solve, such as "hey, I see you haven't used this in a while/ever".

Attaching a static mockup here. I'm trying to be as noninvasive with this tip as possible here considering the loading animation and interaction that happens, when the page is done loading, and how the user will quickly scroll as/when it's done loading (this one is harder). That being said, the idea here is rather simple. This alert would fade in and out of the URL bar after the page is loaded if it can be viewed in Reader mode. We may run into some issues because we tuck the URL/toolbar when the user scrolls so we might have to bounce it back into frame. I'm going to have to play with that a bit more but here is the overall idea. I believe I've seen something similar done in other browsers. In case you guys were wondering, the "Reader mode" icon should be click-able here at all points of the animation.

Put together a .MOV to help illustrate the animations I'm talking about. I didn't add the loading bar though for the sake of this mock up but when the loading is done, the 'x' turns to the "Reader mode" icon as it does currently. I'm open to it flashing more than once or what not but again, this will definitely require some fine tuning as the interactions/animations are key here.

Anthony - I like that you are thinking about being noninvasive. I think we might need some iterations to get the animations/transitions in the URLBar feeling "right". We played with the combinational effects of different animations/transitions in the URLBar before, with lock icon transitions for example. It's also a bit of poor timing that Brain just put up patches to implement the mockup in attachment 8427788 [details]. Is UX willing to move ahead with Ian's mockup as a first pass?

(In reply to Mark Finkle (:mfinkle) from comment #14) > It's also a bit of poor timing that Brain just put up patches to implement > the mockup in attachment 8427788 [details]. Is UX willing to move ahead with > Ian's mockup as a first pass? Like as an approach we would ship? I would say no. Sorry to waste some of Brian's time... but Anthony's thinking around a more subtle approach for offering tips is a thing I would like us to lead with, not something that we would send out later as a follow-up.

Couple of questions/comments for the new mockup: * Is the trigger for this hint still the same (i.e., show the hint once after the reader icon has been shown N times)? Since it's more subtle, we could use this hint more liberally -- maybe show it every time the reader mode icon appears until the user enters reader mode? * One tricky aspect of this is that reader mode is really just another page action, so it's possible that there will be other icons in the URL bar (and the reader icon could be to the left or right of these icons, or hidden in the overflow menu). We might need to do some hiding/shifting around of page action icons to make the effect work. Another more general question: Chenxia pointed out that the reader icon shows up in situations we don't want it. For instance, searching "hello" on Google displays the icon, and clicking it takes the user to a not-so-useful reformatted page of the search results. If we push users to try reader mode but their first experience is one of these false positive pages, they'll probably miss the real value of the feature. Should we try improving our reader mode algorithm before promoting it more? Note that fixing this, sadly, will not be trivial. Also, I'm catching up on some rAc work and I'll be leaving for vacation tomorrow night, so I won't be able to get to this for awhile. Unassigning myself for now in case someone else wants to take this.

(In reply to Brian Nicholson (:bnicholson) from comment #16) > Couple of questions/comments for the new mockup: > > * Is the trigger for this hint still the same (i.e., show the hint once > after the reader icon has been shown N times)? Since it's more subtle, we > could use this hint more liberally -- maybe show it every time the reader > mode icon appears until the user enters reader mode? I would like to give "every time" a try to see if it's too much. But there's a lot of nuances involved in this since we can't tell when the user scrolls (and hides the toolbar), how loading will affect their experience, etc.. > * One tricky aspect of this is that reader mode is really just another page > action, so it's possible that there will be other icons in the URL bar (and > the reader icon could be to the left or right of these icons, or hidden in > the overflow menu). We might need to do some hiding/shifting around of page > action icons to make the effect work. I would agree, but it's a little bit finicky so I really think we have to prototype this to play with it. NI'ing you guys to see how we want to proceed.

(In reply to Anthony Lam (:antlam) from comment #17) > I would like to give "every time" a try to see if it's too much. OK, so by "every time" you mean always show this effect when the icon appears, regardless of whether the user has ever entered reader mode in the past? Just trying to figure out if we still need to move forward with the "has reader mode ever been entered" pref proposed in bug 1028406.

(In reply to Brian Nicholson (:bnicholson) from comment #18) > (In reply to Anthony Lam (:antlam) from comment #17) > > I would like to give "every time" a try to see if it's too much. > > OK, so by "every time" you mean always show this effect when the icon > appears, regardless of whether the user has ever entered reader mode in the > past? Just trying to figure out if we still need to move forward with the > "has reader mode ever been entered" pref proposed in bug 1028406. My vote is to not give any hint if I have already used Reader. I am willing to give "every time" a try, but I know we ended up hating URLBar animations in the past. They are not as smooth as we hope.

Let's just try it and see. It's easy enough to throttle back if we decide showing it every time is too much, but I think Anthony's design is such a nice little detail that it might warrant more repeated use than we originally planned for in this bug.

Brina - Make sure we can back it out or disable it. Reader mode appears way more than we imagine.

(In reply to Anthony Lam (:antlam) from comment #17) > (In reply to Brian Nicholson (:bnicholson) from comment #16) > > Couple of questions/comments for the new mockup: > > I would like to give "every time" a try to see if it's too much. But there's > a lot of nuances involved in this since we can't tell when the user scrolls > (and hides the toolbar), how loading will affect their experience, etc.. I think we can start off showing the hint every time, until the reader actually enters reader mode - but in any case, that's something that's easy to adjust. I'm ambivalent about whether or not to land a pref that tracks whether a user has entered reader mode before this bug (so that we can avoid showing the hint if they've used reader mode before) - the tip seem unobtrusive enough. > > > * One tricky aspect of this is that reader mode is really just another page > > action, so it's possible that there will be other icons in the URL bar (and > > the reader icon could be to the left or right of these icons, or hidden in > > the overflow menu). We might need to do some hiding/shifting around of page > > action icons to make the effect work. > > I would agree, but it's a little bit finicky so I really think we have to > prototype this to play with it. I think prototying is a good idea; do you have any clarification on what to do if there are multiple page actions in the urlbar? As a first pass, I'd we could just have the reader mode icon always be the first icon so we don't have to deal with overflow, and then just fade all the other page action icons (like Android app, or RSS feed for home feeds), but we can change that once we have a prototype.

Wanted to point out this bug 1031559 in here too.. So how should we proceed with this?

(In reply to Anthony Lam (:antlam) from comment #23) > Wanted to point out this bug 1031559 in here too.. Just keep in mind that bug 1031559 only covers one flow. Loading a new page from inside Fennec will still need a different flow. Likely the flow covered in this bug. > So how should we proceed with this? We could still think about how the current mockup in this bug would handle: 1. The animated Lock icon coming in from the left end of the URL bar 2. Any other pageactions displayed for the page 3. Having the "refresh" icon in the URLbar or in the Toolbar, and how the refresh button would display (i.e. would it animate as well) when coming from the awesomescreen. The URLBar could have a lot of things going on.

(In reply to Mark Finkle (:mfinkle) from comment #24) > Just keep in mind that bug 1031559 only covers one flow. Loading a new page > from inside Fennec will still need a different flow. Likely the flow covered > in this bug. Yep, definitely. > We could still think about how the current mockup in this bug would handle: > 1. The animated Lock icon coming in from the left end of the URL bar > 2. Any other pageactions displayed for the page > 3. Having the "refresh" icon in the URLbar or in the Toolbar, and how the > refresh button would display (i.e. would it animate as well) when coming > from the awesomescreen. > > The URLBar could have a lot of things going on. I think that's fair :) Building it out would really help so we could play with it and see as well.

Friendly ping on status here?

I don't think anyone has had the time to work on this bug, so there's no work on it so far and this should not track 33. I (or someone else) can pick this up for the next cycle though.

I wanted to call out that we will need to drop down the browser chrome once the page finishes loading to expose this tip since most people tend to scroll before the page is completely finished loading (and as is loading).

Friendly ping on the status here ;)

liuche, what's the status here? At this point, I don't think this will be making Fx34.

Clearing tracking to ? again.

filter on [mass-p5]

Thinking about this a bit more, if most people are indeed scrolling before the page is done loading completely... is it worth asking if we can tell weather a page can be turned into "Reading mode" earlier on in the process? (i.e. before the page loads 100%, at say... 80%?)

Anthony, how does the mock for this look, is it up to date? Gemma's feedback that people seemed to find reading list to be a huge differentiator makes me want to bring this to life again. Maybe an intern project...? :)

The video mock here is a good place to start. I believe that a lot of people start scrolling before we're actually able to tell that the page is "Reader View-able" so I'd love to get a build to test this out. We will likely have to bring the toolback back down with this current approach but I think it could work.

I think it's time we revisit this. What's something simple we can do here? I think it would be great to ship this in 48 with the migrated reading list.

I think the attached designs are still the desired outcome here. With the in-product helper UIs in bug 1246238 and possibly bug 1247689, anything more would be boarder lining "too intrusive" territory. Can we try to implement the attached designs here?

(In reply to Anthony Lam (:antlam) from comment #38) > I think the attached designs are still the desired outcome here. With the > in-product helper UIs in bug 1246238 and possibly bug 1247689, anything more > would be boarder lining "too intrusive" territory. > > Can we try to implement the attached designs here? Why do we think this design is a good contextual hint? I am concerned that the design is too nuanced and not enough of a hint. Why not try the "too intrusive" hint? What are our expectations/goals for the hint? The current designs seem like a nice animation and we could consider adding it as a permanent feature, but does it really constitute a contextual hint? Should we A/B test: 1. Current design 2. Using the proposed animation 3. Using an intrusive popup As I said, switching to the animation is not a bad thing, but is it really the best hint?

I agree that we should test different approaches and let the data speak for itself. Instead of debating the merits of different designs, let's gather data to see how they actually change user behavior. If a subtle design doesn't change how much people use the feature, then we know it didn't work. That being said, I'm fine with being "too intrusive" for a piece of UI that only appears once. The whole point of a hint is to teach something to the user, we want them to pay attention to it. ahunt, would you be interested in picking this up after your other reading list work settles down?

(In reply to Mark Finkle (:mfinkle) from comment #39) > Should we A/B test: > 1. Current design > 2. Using the proposed animation > 3. Using an intrusive popup > > As I said, switching to the animation is not a bad thing, but is it really > the best hint? Yep, I agree. Let's try some options here and test them! Designing for re-usability will be a big part of this too because we want to do more work around these hints/tips but also because we want the solution here to be scalable. Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1177612#c26, I think this can be an alternative design that's more obvious. I've attached a screenshot of 2 more options. One animates in and then out, while the other will just animate in and require user interaction to dismiss.

NI-ing Barbara to get her on the list, maybe create an Aha card?

Added Aha https://mozilla.aha.io/features/FENN-481 for discussion in our next funnel

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.