Can Live Bookmarks Evolve Into a Full Feed Reader?

[sabret00the]

With the advent of App Tabs and the decision to open the AOM and DLM
in tabs, you have to think about some of the other functionality,
namely the Feed Reading capabilities of Firefox. Right now, it does
the job in it's most basic of abilities and you have to think that
this ability can be extended.

I don't have too much to add as I believe that Google have gone the
correct route in terms of design. Google Reader does everything that
you'd want from a feed reader. A summary instead of just titles and
categorised to boot. That's everything that I'd want from a feed
reader and believe it should be a part of the browser.

There is a place for the existing system, after all, some people are
happy to have the bare minimum, however some people don't Feeds can
cause a lag on the browser and so adding extra functionality could
actually promote the feature getting it's own exe or run it within the
plugin container. This could simply be made a preference.

Also, with such a feature you open up Firefox to more innovation. Not
only would this provide a good foothold for the share aspects of the
Social Agent mentioned as part of the Online Identity Labs project,
but it could allow many other extensions and innovations to hook in.
Off the top of my head I'm able to think of adding Share buttons to
content on the fly.

This would also tie in fantastically with Firefox Sync/Firefox Home.
As [the users that would migrate to this from services like Google
Reader) would still be able to access their feeds on the fly and avoid
missing out on the up to the minute goings on in the world.

Thanks for listening.

x-posted to the Labs mailing list.

[Mike Hanson]

Hi -

I've been thinking about this a lot lately too -- and I totally agree that the connections to the Online Identity stuff are relevant.

I think it has a lot of potential and a couple tricky bits.  I've been noodling a little bit with a prototype and have some thoughts from that...

The browser that we currently have has a couple mismatches to the feed-reader role.  We would need to add:

* A subscription list - much like the Bookmark system, but richer and more sophisticated

* A local database of entries

* A background system to pull updates

* Intelligence about how to prioritize the update pull - this would require some cleverness.  Don't check frequently for feeds that haven't updated in a year, that sort of thing.

* An API to allow addons or (potentially) web content to render the feed stream.  I think there is no reason to limit ourselves to a single rendering -- this should be fully and dynamically extensible.  (I would argue that Google Reader does everything that some people want in a feed reader.  Other people love Feedly, Pulse, Fever, NetNewsWire... the list goes on)

So, really, most of the work is on the backend.  It is often underappreciated how sophisticated the Google Reader backend is -- it deals with a large number of really hard problems, including slow, unreachable, and completely malformed feeds.

Recent work by Google on PubSubHubbub suggests a way to avoid frequent polling (for feeds that support it) -- it would be sweet if a desktop newsreader was smart enough to use it.

The existing microsummary system, which is not broadly used, provides some architectural starting points.  It currently checks for new summaries once a week and has a timer task that fires every 15 seconds to see whether a new pull is required.  That can be adapted.

It is important to be clear about why a desktop newsreader would be different, or better, than a cloud-based solution (like Google Reader), especially given the fact that custom front-ends to Google Reader (like Feedly) are possible.  The main reason that I've been thinking of lately is that there are feeds that can't be viewed in Google Reader, because they are private to a two-party communication, but perhaps there are others.  What do you think?

Best,

Mike

--

Michael Hanson, Mozilla Labs (@michaelrhanson)

--
You received this message because you are subscribed to the Google Groups "mozilla-labs" group.
To post to this group, send email to mozill...@googlegroups.com.
To unsubscribe from this group, send email to mozilla-labs...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mozilla-labs?hl=en.

[sabret00the]

What I was thinking is that like the current system works in getting
the data in a timely manner, you then process it ultimately displaying
it through a portal and marking items read in the DB in order to hide/
fade them. If this is done on top of a system that could ultimately be
as simple as a list of URL's with a last pulled time for each item.
Then you're not overtly loading the browser or doing too much
processing.

In this regards, we're lucky to have a community that will ultimately
build on the system and add complexity. I think it's essential to lay
the foundation and then build on top of it until a point where you can
rebuild completely and make educated choices based on the experiences
of the previous system. For example, pulling the feeds with a
secondary process rather than with firefox.exe in order to prevent
bogging the browser down (especially if you have notifications
enabled).

I feel that if a feed hasn't been updated in a more than a year, you'd
handle that easily enough. You'd simply match it's ID against an array
and have it skipped 9/10 times.

I agree that it gets complicated at the time that you'd want to allow
people to hook into the system and perhaps that's the time when local
storage of the data is needed. Perhaps then, the best option would be
to upload the rendered page to the cloud. Then perhaps depending on
the type of requests there are for API's, then at that point, you'd
break the page down into smaller chunks so as that an add-on can
access whatever it needs.

As you point out, the possibilities opened with Pubsubhubbub are
exciting and having real time feeds would be amazing, but in terms of
adoption, I imagine it'll be a while before that really kicks off. Are
places like WordPress and Blogspot shipping with this enabled by
default? If so, it may cut adoption time significantly. So in that
case, you could then have the feed tab listen for updates and add
them. At this point, it becomes impossible to do this all with memory
and you'd have to do it with local storage. However, it's easy to stop
your feed checker from checking those sites as it'd simply populate
another array to check against and see that it wouldn't have to check
feed XXX.

In regards to desktop newsreaders, it's harder to argue for them
against cloud based ones in this day and age where by everyone is
trying to move everything to the cloud. But people do like to be in
control of their data and interests. Take a look at Tweetdeck. There
are alternatives available within the cloud but people want something
tangible. And ultimately at a quick glance, there are over 4000 weekly
downloads from Firefox users in order to enhance Google Reader. Feedly
is on it's way to a million downloads. There is no question here, in
my opinion that people want more than what Firefox gives them and
would welcome the enhancement to Firefox.

You're onto something in consideration of private feeds. I'm not sure
of the implementation, but I can definitely think of ways in which you
can interact with secure feeds in the browser in manners that you
can't, at least not at the same level in a cloud based solution.
Especially if for example, a feed is encrypted.

You've clearly given it some thought and have managed to come quite
far with it. Initially some of your ideas sounded silly but as I went
through the post and thought about how things would work, I can see
exactly where you're coming from and applaud the forethought. I'm
going to further mull on the idea of API's, as I imagine some users
will want their feeds on things like iGoogle. So you're right, it does
require greater thought from the perspective of extensibility.
However, I do think that although not a solution, Firefox Home/Weave/
Sync will provide an amazing amount of external usage.