Closed Bug 784331 Opened 12 years ago Closed 11 years ago

Indicate if a page is In / Out of reader mode, allow Toggle In / Out

Categories

(Firefox for Android Graveyard :: Reader View, defect, P4)

ARM
Android
defect

Tracking

(firefox15 unaffected, firefox16 affected, firefox17 affected)

RESOLVED FIXED
Firefox 22
Tracking Status
firefox15 --- unaffected
firefox16 --- affected
firefox17 --- affected

People

(Reporter: pretzer, Assigned: capella)

Details

(Whiteboard: [mentor=lucasr][lang=java])

Attachments

(2 files, 7 obsolete files)

Attached image Mockup of the first possibility (obsolete) —
Currently there is no indication if a page is in reader mode or not, except the page-styling (one has to know and recognize the reader mode styling for that though).
It might make sense to add some kind of indication to let the user know if the page is in reader mode or not.
One possibility would be to add a reader mode indicator to the tab on the tabs list (see the mockup for that).
Another possibility that came to my mind was to let the reader mode icon stay visible in the awesomebar after the mode has been activated and change it's appearance (e.g. turn it to orange) to indicate it's 'active' state. Leaving the icon visible while in reader mode would have the extra benefit of adding the possibility of a toggle functionality that also lets the user 'leave' reader mode again via the icon (currently only the Back button does that).
Priority: -- → P4
Attached patch Patch (v1) (obsolete) — Splinter Review
I thought I'd put this up before getting too much further into it.

The second option mentioned in the comments / bug request works out to be fairly easy to do. (Tapping the orange "reader enabled" icon does nothing @ this point.)

I noticed the P4 priority ... is this something we'd like to pursue?
Assignee: nobody → markcapella
Status: NEW → ASSIGNED
Attachment #704297 - Flags: feedback?(lucasr.at.mozilla)
Attached image Screenshots (obsolete) —
(In reply to Mark Capella [:capella] from comment #2)
> Created attachment 704298 [details]
> Screenshots

Ian, what do you think?
Comment on attachment 704297 [details] [diff] [review]
Patch (v1)

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

Looks good but I guess we'll have to figure out the interaction with the new reader mode indicator. Maybe tapping on it would toggle back to the original page?
Attachment #704297 - Flags: feedback?(lucasr.at.mozilla) → feedback+
Attached patch Patch (v2) (obsolete) — Splinter Review
status: Toggling on / off is also fairly easily achieved with this addition to the patch.

I'm considering switching the |enteringreadermode| functions to be something more like |switchingreadermode| for UI cleanliness ... I also have to look further at Tab.handleLocationChange() implications ... new code to me / still tinkering ...

I need to figure out the readermode expert / mentor I can chat with ...
Attachment #704297 - Attachment is obsolete: true
Flags: needinfo?(ibarlow)
(In reply to Mark Capella [:capella] from comment #5)
> Created attachment 704830 [details] [diff] [review]
> Patch (v2)
> 
> status: Toggling on / off is also fairly easily achieved with this addition
> to the patch.

Nice :-)

> I need to figure out the readermode expert / mentor I can chat with ...

That would be me. Let me know if you have questions.
Whiteboard: [mentor=lucasr][lang=java]
(In reply to Lucas Rocha (:lucasr) from comment #3)
> (In reply to Mark Capella [:capella] from comment #2)
> > Created attachment 704298 [details]
> > Screenshots
> 
> Ian, what do you think?

In terms of interaction, this makes sense. But I'd like to revisit how we style the icon for this mode. I can take a look at this.
Flags: needinfo?(ibarlow)
Thanks lucasr !

While ibarlow reviews the icon style, I'll be looking at my last question ... whether we need to change enteringReadMode functions to switchingReaderMode ...

My personal testing so far hasn't shown any show stoppers without making that change. It seems to be primarily to provide a non-changing title and favicon during forward transitions. I may go ahead and make the change for forward and (now) backwards transitions and test for a bit.

Let me know if any "gotchas" come to mind ?
Comment on attachment 704830 [details] [diff] [review]
Patch (v2)

Hmm ... guess I never flagged this one either
Attachment #704830 - Flags: feedback?(ibarlow)
Ian, ping?
Nag ping....
Summary: No indication if a page is in reader mode → Indicate if a page is In / Out of reader mode, allow Toggle In / Out
Attached patch Patch (v3) (obsolete) — Splinter Review
Drats ... bit-rotted / re-based ...
Attachment #704830 - Attachment is obsolete: true
Attachment #704830 - Flags: feedback?(ibarlow)
Attachment #714970 - Flags: feedback?(ibarlow)
Here are the enter / exit versions of the reader icons. http://cl.ly/0Q3I3r1V3A2S

Let's drop these in and we should be done. 

Icon mockup, for reference: http://cl.ly/image/2y3U0J1W2z3y
Attached patch Patch (v4) (obsolete) — Splinter Review
Cool ... followup posts to contain screenshot, test apk
Attachment #653736 - Attachment is obsolete: true
Attachment #704298 - Attachment is obsolete: true
Attachment #714970 - Attachment is obsolete: true
Attachment #714970 - Flags: feedback?(ibarlow)
Attachment #716058 - Flags: review?(lucasr.at.mozilla)
Looks good to me!
Comment on attachment 716058 [details] [diff] [review]
Patch (v4)

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

Looks good but needs the suggested refactoring before getting a r+.

::: mobile/android/base/Tab.java
@@ +386,5 @@
>          GeckoEvent e = GeckoEvent.createBroadcastEvent("Reader:Add", String.valueOf(getId()));
>          GeckoAppShell.sendEventToGecko(e);
>      }
>  
>      public void readerMode() {

I'd prefer a more explicit approach. Something like a method enterReaderMode() and leaveReaderMode(). Then do the isAboutReader check in the click listener instead of hiding it here.

@@ +390,5 @@
>      public void readerMode() {
> +
> +        String tabURL = getURL();
> +        if (ReaderModeUtils.isAboutReader(tabURL)) {
> +            String fromAboutReaderURL = ReaderModeUtils.getUrlFromAboutReader(tabURL);

Wondering: this will always add a session history entry instead of going "back" to original page. I think the ideal behavior is:

1. If you're in page and enter reader mode (via the reader icon), tapping on reader icon will take you 'back' to original page instead of adding a new history entry.
2. If tap on a reading list item (which enters reader mode directly), tapping on the reader icon will go to original page (as you're doing here).

Ian, what do you think?
Attachment #716058 - Flags: review?(lucasr.at.mozilla) → review-
> Wondering: this will always add a session history entry instead of going
> "back" to original page. I think the ideal behavior is:
> 
> 1. If you're in page and enter reader mode (via the reader icon), tapping on
> reader icon will take you 'back' to original page instead of adding a new
> history entry.
> 2. If tap on a reading list item (which enters reader mode directly),
> tapping on the reader icon will go to original page (as you're doing here).
> 
> Ian, what do you think?

Agree 100%. You're entering / exiting a mode here, which shouldn't be adding to your trail of page history.
Attached patch Patch (v5) (obsolete) — Splinter Review
Ah well, I guess I was working harder than I needed to. I can just call the Tab.doBack() method from BrowserToolbar.java for the exit function ... seems to work and would be simpler than modifying Tab.java or adding a new method ...
Attachment #716058 - Attachment is obsolete: true
Attachment #716759 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 716759 [details] [diff] [review]
Patch (v5)

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

Looks good otherwise.

::: mobile/android/base/BrowserToolbar.java
@@ +881,5 @@
>  
>          // Handle the viewing mode page actions
>          setSiteSecurityVisibility(mShowSiteSecurity && !isLoading);
> +
> +        // Handle the readerMode image and visibility

It's probably worth explaining the intended behavior in more detail here. Maybe something like: "We show the reader mode button if 1) you can enter reader mode for current page or 2) if you're already in reader mode, in which case we show the reader mode "close" (reader_active) icon.
Attachment #716759 - Flags: review?(lucasr.at.mozilla) → review+
Attached patch Patch (v6)Splinter Review
I'm asking for another review, as I've modified the patch to correct a situation I caught while testing.

There were a couple ways to observe the new reader_active (or click-to-close) icon when no actual history was available to navigate "back" through. Pressing the icon did nothing, which was confusing.

One example, tap tabs counter upper-right on screen, tap tab "+" button, select bookmarks tab, tap item "Reading List", tap previously added item, observe new misleading reader_active icon.

I'm sorry I missed this. I imagine it would have shown up as another bug request fairly quickly.
Attachment #716759 - Attachment is obsolete: true
Attachment #717936 - Flags: review?(lucasr.at.mozilla)
Comment on attachment 717936 [details] [diff] [review]
Patch (v6)

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

Nice.
Attachment #717936 - Flags: review?(lucasr.at.mozilla) → review+
https://hg.mozilla.org/mozilla-central/rev/d90114adfbad
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 22
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: