Closed Bug 769316 Opened 12 years ago Closed 10 years ago

Reader Mode: Provide add-on hooks to allow third-party service integration

Categories

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

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: lucasr, Unassigned)

References

Details

Suggested feature from Kevin in my blog: "As it seems you’re still in the early stages of developing the reader, also please do keep an open mind about third-party integration, with an eye towards allowing add-ons to provide the integration if nothing else. For example: Mobile Safari’s existing “Reader” feature has lots of handy and unexpected uses, like emailing a cleaned-up article to a friend—with all the copyright angst that entails—or “clipping” a recipe to Evernote via email. But I don’t care about iCloud and I don’t want to have to use Safari on the desktop just to have access to my reading list. So ultimately I resort to using the Instapaper bookmarklet and ignore the built-in UI for the most part. Replace “Mobile Safari” with “Firefox” and “iCloud” with “Firefox Sync”… see the point I’m trying to make? Contrast with iOS apps by indie developers like Reeder and Tweetbot: they allow you to hook up the read-it-later button(s) in their UIs to several popular third-party services. If other read-it-later services have public API’s and friendly developers (Instapaper: yep, and yep) why reimplement offline reading lists, tags, folders, search, and archive features inside Firefox if you don’t have to? That just seems like NIH behavior to me, especially given that Instapaper, Readability, Pocket, et al. already enjoy widespread adoption among mobile users on all platforms. If a hypothetical mobile device user knows she can replace the stock Android browser with Firefox, it would stand to reason she’s knows about and probably already uses one of these services as well. Also consider a user of desktop Firefox who does her offline reading on the subway with an iOS device." Might be something to pursue in the future?
Component: General → Reader Mode
Priority: -- → P4
I've been thinking about this for a while. Have some ideas to pursue, whether that ends up being through explicit hooks or well-codified intents and some UI affordances… who knows?
Assignee: nobody → rnewman
Priority: P4 → --
Generally I see the way forward as: * Within Firefox, on both platforms, aim for "Read it Now". Reader Mode is a great way to make content more readable, but the interface for managing a set of stuff to read later isn't a core competency. * Rip out Reading List on both desktop (if it's done) and mobile, and on Android find a good way to make it easy to instead dump content into the user's preferred app. * Make it easy for users to discover and opt-in to services that provide reading lists as a core competency. I would *love* to see things like a doorhanger saying "want to read this later? Go install one of these add-ons! We love Pocket [top developer]". Summary of what I see as opportunities for improvement (sorry if this seems blunt!), which are why I see that way forward: On desktop, the Pocket add-on does *everything* one might want, with the exception of providing a Safari-like reader mode. We have no value to add here in terms of managing a reading list. On Android: * There's no way to read a page later if Reader Mode doesn't think it's a long-form article. Instead I choose Share > Add to Pocket, or I have to use bookmarks. Pocket gets heavy usage for videos; I use it for all kinds of things, from forum posts to product pages to videos. About 75% of the things I Pocket don't get flagged as readable by Reader Mode, so we're not supporting what users want to do. * If I know in advance that I want to read an article later, I have to click it, wait for it to load, wait for Reader Mode to decide that it's long-form, click the Reader button, then click the "Book+" icon. I don't want to read it _now_, I want to read it _later_, but I have to load it and format it first. That doesn't make sense to me. We should be able to put any link or any loaded page into a reading list in two taps. * I already use another RIL service. Why do I now have a separate list of things to read? That separate list doesn't sync, doesn't have previews, etc., so I don't use it. That means I use Reader Mode to fix some website's broken color scheme, not as a reading list. * There's no way to discover my Reading List until I add a page to it. Until I find a long-form article, I have no idea that Firefox has a Reader Mode. (I just spent five minutes pottering around in Nightly trying to find it, then Googled to figure out how to get it to show up -- aah! I have to find a long article!)
Note that a lot of the Android stuff can be addressed by improving how we interact with the system Share intent. I imagine that a lot of users share to: * Email/FB/Twitter/WhatsApp * Some reading list app. If we could pin those intents in a rich share menu, we'd have tap-and-hold-then-tap to read later on a link, or Menu > {my reading list intent} to read the current page later. We can stick the reading list intent in the Reader Mode view in place of Book+.
AFAIK, the UX team is working on some big features around the "read later" use case. Ian, could you give us some background info about this project?
Flags: needinfo?(ibarlow)
Assignee: rnewman → nobody
Flags: needinfo?(ibarlow)
This bug is old, and I think we already do a lot of the things mentioned in here. As far as add-on APIs are concerned, add-ons can now use ReaderMode.jsm directly to parse content if they want.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.