Discuss subscribe/bookmark implementation

[kav2k]

Finally got to test the implementation.

I agree that TOR gives a sensible message to non-premium users regarding the bookmark feature.
However, on the TOR side: if trying to subscribe to a page with no feed, the failed validation message is confusing and not user-friendly. This flow needs to be revised.

Instead of opening TOR interface for that, we could potentially invoke the TOP API, namely quickadd, and parse the response. If it's a success, open the feed page. If it failed, we can show an error message in the invoking page. There could also be an option not to open the TOR interface on success of adding subscription.

Also, we could consider looking for feeds ourselves before submitting. Both that and showing our UI on the page are possible, if we add activeTab permission - it won't trip the permission warning and will work after a context menu was evoked. Here's an example of how to look for feeds: http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/extensions/subscribe_page_action/feed_finder.js?revision=HEAD

Speaking of which. There's a big problem with the subscribe flow. A page can have more than one feed associated with it. From the top of my head, this: http://www.zapcomic.com/2014/07/712-welcome-to-earth/ has links to the overall comic feed and to the comment feed for a particular issue. TOR does not allow to select which feed you're subscribing to. We could fix it in the extension, using the detection script above.

[knyar]

I am not particularly fond of any feed detection logic, I believe people who use RSS are usually literate enough to enter a specific RSS url into the "Add a subscription" form. So while glitches in the auto-detection logic do not concern me, I am obviously not against making that logic better, and think that your suggestions are very sensible.

I believe we had subscription flow improvements in The Old Reader roadmap a couple of years ago, and those improvements were mostly around allowing users to choose the feed they want among multiple feeds referenced by a particular page. I have no idea when/if current project owners will be working on that.

I've been using code from #33 for several days now, and I am inclined to publish a new build of the extension in the next couple of days. If anyone wishes to improve the subscription flow, I am fine with that, but I think what we have now is good enough.

[kav2k]

I'm not against publishing - I also tested this code and I mostly like it.

Consider feed detection as a possible enhancement. Maybe calling it a "big" problem is an overstatement.

It's sad that you are no longer involved with the project.

[jfiorato]

We recently (in June) implemented some great subscription enhancements that help a ton for finding feeds. If we can't find a feed, we recommend feeds similar to what you asked for.

http://theoldreader.com/feeds/subscribe?url=https%3A%2F%2Fwww.google.com
or
http://theoldreader.com/feeds/subscribe?url=google

Like I'm sure you are very aware of, RSS feeds are just flat out difficult to find sometimes. Auto-discovery is spottily implemented, and RSS links are usually buried somewhere terribly hard to locate, requiring people to view source and then search for 'rss' or 'atom'. That sucks for everyone, privy to HTML/web development or not.

We still haven't addressed the site with multiple feeds for sites like @kav2k's example, and I think would make sense to on the TOR end of things, eventually. Just not sure how big of a priority it is at the moment.

[MikkCZ]

Is there any decision, what to improve in the extension from the point of UI or backend code? I may work on this, after #47/#58 is resolved.

[MikkCZ]

The PR above has been merged. What can be done here now?

Using background API calls for subscription before the page is actually opened or not seems a bit tricky to me, as you need a good communication to the user in case of a failure or when it takes long time (slow connection). Btw. that's something I haven't done properly in #47 myself.

What I think we can address are the pages with multiple feeds now. Getting the feed programatically from the page source code shouldn't be hard (if it's in the and we use a content script for that). Than we can display it similar way as the Firefox subscribe button does for feeds (simple entries in the context menu). Or cannot this happen on the service side, when the addon opens the subscribe link with the page URL, instead of feed URL?

[kav2k]

For the record, feed detection logic used by Google's own extension can be seen at https://github.com/justinkelly/chrome-rss (see feed_finder.js and sniff_common.js)

[MikkCZ]

Here seems to be an easier way to do it.