1142265 - [UX] investigate always showing the reader view button in the URL bar

Status: RESOLVED FIXED

(Toolkit :: Reader Mode, defect)

Description

[Bryan Clark (DevTools PM) [:clarkbw]]

Currently the reader view button appears in the URL bar for pages which it has detected should be 'reader view compatible' but for pages which aren't determined to be compatible it doesn't appear.

This bug is asking UX to investigate the possibility that (on Desktop) we always show the reader view button.  By making this change we would avoid a number of issues we've run into with the current system but also create a few new issues we would need to deal with.

Issues this change could alleviate: 
* where the button appears on a page which isn't compatible with reader mode
 * the button appearing on a page indicates to people that it should work, when it might not
* where reader view must parse the page in some way to know that it is compatible
 * this check is costly in terms of performance, we could avoid this need to parse all pages
* timing when the button to appear as a page is loaded
 * some pages cause the button to not appear for a while, this would make the button always available

Issues this creates that we need to investigate:
* What happens when a person chooses reader view on a page that just isn't compatible, like google calendar.
... I'm probably missing other items

Comment 1

[:Margaret Leibovic]

Thanks for filing this! Indeed, we are suffering a lot of performance issues from trying to determine whether or not to show the button, and if we come up with a less costly alternative way of determining that, we will probably be even more inaccurate about whether to show the button (we used to do this originally on Android).

In looking into the performance regressions for desktop, I learned that we're actually missing good performance tests for Android, so finding an alternate UX on Android would likely lead to perf improvements (although with no way to measure them :/).

Comment 2

[Markus Jaritz [:markus] (UX)]

If we show the reader view button all the time, 
- we can somehow highlight it, once we know if a page is viewable in reader view.

If user clicks the button, but the page is not fully compatible,
- we can ask to rate their experience.

If user clicks the button, but the page is not compatible,
- we can ask what part of the page they would like to view in reader view to learn how to improve.


Always having the button will shift the experience from one that only shows you stuff that works, to one that needs your feedback to improve and will fail quite often. Therefore it might be a more participatory approach that might be suited for users that are up for that, but not for people that just expect stuff to work.

Michael, what's your talk on that?

Comment 3

[:Margaret Leibovic]

(In reply to Markus Jaritz [:maritz] from comment #2)
> If we show the reader view button all the time, 
> - we can somehow highlight it, once we know if a page is viewable in reader
> view.

We won't be able to do this without suffering the same performance costs we're currently suffering, since we don't actually know if a page is viewable in reader view until we try parsing it. However, we can improve this situation by trying to make Readability.js less aggressive about stripping content, so that hopefully it would always return *something*.

> Always having the button will shift the experience from one that only shows
> you stuff that works, to one that needs your feedback to improve and will
> fail quite often. Therefore it might be a more participatory approach that
> might be suited for users that are up for that, but not for people that just
> expect stuff to work.

Currently, even when we show the button, the content isn't necessarily great. Right now we only don't show it if we have absolutely nothing to show, so if we switch to an "always show the button" situation without doing anything else, right now we would just fall back to reloading the same page (that's what the error handler in our about:reader logic does).

Comment 4

[Bryan Clark (DevTools PM) [:clarkbw]]

(In reply to Markus Jaritz [:maritz] from comment #2)

Besides what you have below here about increased participation.  How do you think we could handle the reader view with a page that doesn't work?

Here's the steps that would happen with this new experience:
# On a page that isn't compatible the user clicks the reader view button (the button is always shown)
# On click Firefox then parses the page and determines it isn't compatible
# ??? Profit ??? - now Firefox needs to show something

Some options I can think of:
* Return the user to the original page, show a notification explaining that it doesn't work
* Show the Reader View with an alert inside it ( something like http://cl.ly/image/0Y2N2i153U1f )
 * Possibly leaving the page as original
 * Or possibly try other minimal parse strategies like parsing out only the iframes and embeds 

> Always having the button will shift the experience from one that only shows
> you stuff that works, to one that needs your feedback to improve and will
> fail quite often. Therefore it might be a more participatory approach that
> might be suited for users that are up for that, but not for people that just
> expect stuff to work.

I'm adding Will and Gregg to see if heartbeat could be used for this kind of feedback.  I'd guess we would want to know the page a person was on and perhaps what they thought was wrong with it.

Comment 5

[Markus Jaritz [:markus] (UX)]

As Bryan suggests if the user clicks, but we then fail parsing, we have 3 options:
- do nothing
- tell the user that we failed (in nicer words)
- try to come up with solutions not to fail (new parsing strategies)

The first 2 seem rather negative to me concerning user perception of the feature:
We don't want to have a button that sometimes does not work. Users would not trust such a feature, and therefore not use it. And if the feature fails sometimes, a notifications saying that something went wrong might be an option, but only if this happens very rarely. If it occurs regularly the user might again not trust the feature, and thus not use it. (If we phrase the notification more towards: "help us improve the feature" as suggested earlier, that might improve perception for people willing to contribute, but probably not for the average user.)

The 3rd seams to be technically challenging as we would need to provide "something useful" for every page and as I do not understand how the parsing works, can not comment on.

It seams to me that this might be weighing user satisfaction with the feature against development effort and it is hard to tell where to draw the line. 

Or rethink the feature around what is possible:
As we do not know how much to remove from each page,how about we re-frame the feature and instead of a button, give the user a slider to set the level of reduction themselves for every page… (and learn from that over time?) Could we use AdBlock-Lists to learn what we need to remove?
This might however require redesign of the Reader View as it then would not be a separate view, but rather a filter or sieve.

Comment 6

[Justin Dolske [:Dolske]]

(In reply to Markus Jaritz [:maritz] from comment #5)

> Or rethink the feature around what is possible:
> As we do not know how much to remove from each page,how about we re-frame
> the feature and instead of a button, give the user a slider to set the level
> of reduction themselves for every page… (and learn from that over time?)

I do like the idea -- we want to do something similar with current password manager work... We give the user UI to correct what the browser does (e.g. saving or filling a login incorrectly), and use that as a real-world signal that we have an issue on some site.

But we don't have the time to implement this for 38 (or react to it, even if we did). :(

So we're optimizing for the least-worst UX we can get in the time available.

Comment 7

[Michael Maslaney [:mmaslaney] ([e-mail])]

I agree with Markus, that the first two options seem rather negative, regarding user sentiment. Unfortunately, time is not on our side at the moment, and because of that, I would suggest option number two. I think we can frame the language to focus more on "helping us build the feature", rather than us failing.

Tone Examples:

• "This page cannot be converted to Reader View at this time [ Report ]

• "Reader View determined that this page could not be converted" [ Report ] 

• "Unable to convert. We are currently in the process of making more of the web convertible for Reader View" [ Report the error ]

Moreover, let's use this error as a chance to recommend sites that work well with Reader View, like nytimes.com

• [ Reader View Recommended ]

We could also, re-frame the perception of the error to be closely aligned with the page, not the Reader View, itself.

• "The current page will only render at [x] percent, and thus is not deemed compatible with Reader View" [ Request this page to be added to Reader View ] 

Thinking long term, I believe we should evaluate our parsing strategy. Explaining to users that our new feature is still "under development" will only hold so much empathy.

Comment 8

[Will Kahn-Greene [:willkg] ET needinfo? me]

Sorry this took me a while to get to reading through.

Regarding comment #4, Heartbeat is designed to measure user sentiment across Firefox desktop channels over time across our user populace. It's not a good feedback mechanism.

However, Input hosts a feedback form here:

https://input.mozilla.org/feedback/

We could add a new product and then users could use that form. We can't change the language of that form, though.

If you want to change the language or do anything differently, you could write an in-product form that posts to the Input feedback API. Firefox OS, Firefox for Android and Hello all do that. Input feedback API details here:

http://fjord.readthedocs.org/en/latest/api.html#posting-product-feedback-post-api-v1-feedback

If that sounds like the direction you want to go, it's worth talking to Matt Grimes of the User Advocacy team and he'll work with you to set it all up.

Comment 9

[Markus Jaritz [:markus] (UX)]

Attachment: 150317_RV_Feedback.jpg

To see what it is that we are talking about, I drafted 3 options, depending on our confidence that a given site will be useful in reader view.

However, I think that need a big percentage of pages where the reader view actually works for it to have good feedback. I would guess min. over 50% of pages that we can expect users want to READ should work fine. I tested with blogs I read, and it looked ok. But I have no idea if this matches an average user.

Comment 10

[Bryan Clark (DevTools PM) [:clarkbw]]

I'm calling this fixed as we have several ways to options to take further.  As it stands right now our algorithm for detecting if a page "is readable" has improved quite a bit so we've decided to go forward with that instead of showing the button all the time.

It would be good to file some separate bugs for the ideas that came from this investigation and are appropriate to use. 

I filed bug 1150980 for looking further into the feedback / input method.