Notices

Maybe this is a stupid question but, why the dependency to a browser? I see the advantages but it also adds complexity.

With a feed reader the most important is to read the feeds.

1. Gimme the headline and link to source.
2. Perhaps some excerpt too.
3. Probably the picture(s) as well.
4. Download the downloadable media as long as there is wlan available.
5. Full content? Well, yes although I can perhaps wait or just download via data connection if it's really urgent.
6. Real HTML formatting while offline? Well, If I really want the real page I can visit it with the real browser.

I understand the direction things are going for the Maemo 5 device. But I hope that the 'being online' tagline does not manifest itself into every nook and cranny of the services that the Maemo 5 device provides.

The offline experience is a big usage case for me at least. It will also weigh in heavily for any purchase I make in the tablet arena in the future. Not everyone is lucky enough to have ultra-cheap data rates via 3G. In Canada, the duopoly that is our telecom market (Bell Canada and Rogers) make data plans very expensive.

OK back on topic now - Aren't we talking about a customized iGoogle or something like that? I would add calendar appointments, to do lists, new mail notifications, and forum posts that meet certain criteria (e.g. keywords, author, threads I started) into the mix as well. If you are thinking out of the box, then I would want to know everything that could possibly affect me to be displayed in one location. Currently, I have to look at my RSS reader, gPodder, mnotify, calendar, to do, the forums, etc to get a snapshot of the things that interest me or that I have to act upon. There must be some way to efficiently present all this information to a user?!

On a sidenote, on S60 there is a nice program which allows one to prioritize connections when multiple are available and decide to disconnect either one if one with higher priority is available. This is useful for corporate networks, but also when roaming and able to access WiFi hotspots. I have not tried this with something like Devicescape yet though.

Maybe you want the feader to decide what you (probably) like, or allow the user to create such filters. If the user has multiple feeds the need for this increases. Its a power user feature so to speak.

The dependancy on the browser woud exist because Web 2.0/AJAX is the current hype, but also the most used platform. Such platforms integrate well and add tons of services. Which device doesn't have a browser? That is what Yahoo/Live/Google/Ovi is all about. (Although the possibility to jump off the platform doesn't seem to be important to users yet. I'd say, if you have guts and believe in your platform, you allow the user this easily because you know they won't leave anyway. It is a bit like believing in quality of your open source code.) That first. Second, you can easily make this in PHP without some kind of new protocol. You just allow the user to manage their RSS feeds with advanced filtering. I would say allow them to provide feedback or suggestions for filters as well.

One could allow the user to grab the output on browser or RSS. But then this isn't synced either. Once you're leaving the browser paradigm (geeks...) it isn't a good abstraction layer.

I know this issue from other protocols as well. SIP, for example. You can phone from any account with which you logged in, but the last one who logged in will receive the phone call. In the console IRC client Irssi one can run a module called Irssi-proxy. A user can connect with any IRC client (from any platform) to this proxy, and once connected, the user can read/write to the connection with the server from both ways. I like this model. However, it still doesn't actually by definition provide offline synchronisation because often these models lack proper history support.

Works like this: Server <-> Daemon <-> Clients. The server or content provider is what we have now, they speak a protocol and standard (e.g. RSS over HTTP). The daemon understands these protocols and abstracts it, does some things with it e.g. blacklist, whitelist, greylist (tagging/marking) filtering/prioritising. Think of it as a firewall. It also knows what is read and not read and allows to map (this is part of the filtering; could be more advanced). Then the clients connect and are always synced. End result? Something like IMAP. The provider (e.g. IMAP service provider) can run this daemon, even as part of the protocol or service, but also customer/user can run their own. Corporate users or users who care about privacy might prefer the latter. If you take something like voicemail, which is inherently expensive and inefficient while synchronisation isn't important, you might not want to give the customer this power for financial reasons but that is a different story.

OK - thinking about this further. What about a "OMWeather-style" tabbed display? You can have tabs for news, mail, podcasts, forums, calendar, todo,etc. I'll also throw IM's, VoIP Voicemails into the mix. Something like this would make viewing your life a heck of a lot easier, at least for me.

I have some ideas for presenting feeds from numerous sources.
the graffiti wall works nicely for some things, but theres more required.

I'm with Gary, guys... I don't care about filtering and what not, just let me browse and read smoothly, simply, and stylishly

(Applets? Status Bar/Panels?)

That is what the NIT (or a smartphone) is for and about for some users hence importance of WWAN like HS*PA. Problem is now the UI. Difficult really. On S60 it is easy to switch back and forth, and even make home screen informative. That is w/o touch (soon with, learn from them as they learn from you). While one can learn from iPhone as well they do not have multi tasking there. And, multi tasking on S60 is cumbersome because user doesn't see what is running (no taskbar).

How to take note of new events? Provide different options (including vibrate IMO). Ambient light is powerful too though.

When are they important enough to alert the user and when not What do you want to allow the user to always take note of? And how do you want to present it to the user? The latter is very important. You don't want 200 different style of interfaces, you don't want 200 different ways of using touch screen, you don't want 200 toolkits, you want to give the user some kind of consistency so they don't have to relearn and are familiar with an unexplored program.

Now the other 2 questions. Maybe you'd want to sort this information on a calendar, and go back one day, and see the IMs, todo, podcasts, etc. of that particular day. Maybe you want the user to specify what mode he is in applying filters because the user is working, travelling, at home with partner, at a party, etc. Different situations, different needs, different priorities. Harry is at a party, but is on call for his work. Harry puts off any new information he receives; its on hold. Except his work phone number and colleagues (these are tagged as group). If those phone he is notified with high importance. Sandy is waiting for the bus. The bus is late. Sandy is bored. She sets the profile to bored and watches the news and reads the weather, but not the international news because this would take her too much time. John is drinking a coffee at Starbucks. He wants to finish some eBay transactions, but not see his IM messages on his NIT. He's also like to check the stock market because he got earlier an alert which is always on, notifying him about important changes of one of his important stocks. And so on. This way of interacting is very advanced and complex, but also very intuitive. It takes away the noise the user doesn't want at particular moments. As long as the interface is intuitive to the user while the power user (important customer base of NIT) is not neglected. So it goes further than merely RSS.

Mmm two thoughts:

1. I still want to differentiate between things I can miss (feeds + podcasts + microblogs) from things I better don't miss (email + appointments + ToDo)

2. Presentation in one place doesn't mean that the tool to handle those sources of information should be the same. There are apps and services specializing in email, calendar and tasks. I think it's already complex enough to try to handle the incoming feeds + podcasts + microblogs in one app.

But there is plenty of good ideas in this thread already. Now... who wants to pick this up and work on something?

I think there does indeed need to be an "uber-feed reader"--one that can process RSS feeds for text, audio, and video (or combinations thereof). One of my current problems with Canola is that its concept of "podcast" is limited to only audio feeds; I have to switch to Video Center to download a video podcast. (Gpodder seems to try to accommodate both, but the current version still appears horribly slow, and the UI is an assault on the senses).

Having said all that, I think it is a mistake to incorporate Twitter, Jaiku, etc. into such an app. The founders of Identi.ca (and others) are on record as saying treating microblogging sites as blogs was a mistake; people appear to want to use such sites as a new variant of IM. The success of apps like Twirl and users' persistent desire to link Jaiku and Twitter with their IM apps seem to confirm this. While an uberfeed reader should be able to consume microblogging feeds just like any other RSS or Atom feed, not providing a facility to treat microblogs as IM streams would overlook how heavy users of such services (the tech-savvy target market for Maemo devices) actually prefer to work with them.

My thinking is that the browser should already be stout enough to view (parse) XML so that it would just need a new chrome in order to differentiate the RSS "app" from normal browsing.

Developing new chrome takes the idea of separating content/presentation/function a bit further.
- Content being the XML
- Presentation layer being the specific browser chrome
- Function being those actions the chrome does which you numbered above

If you will, taking the "internet" of the Internet Tablet and making the browser stand as a development platform. And then the IT would have that as something to extend even more the community involvement.

I'm not so much in favor of RSS being a separate app because RSS really isn't different from web browsing - speaking funcitonally. The difference is the speed at which one gets information, and then its presentation. All of the actual tech that goes into an RSS reader is already built into a browser, its just a matter of chaning the UI so that its respected as such (IMO).