I purchased a Motorola mpx200 about a month ago. This is one of the two mobile phones running the Microsoft Smartphone 2002 OS available in the United States today. It's absolutely fantastic; I think it is, without a doubt, the best cell phone I have ever owned (and I've owned quite a few: a Samsung flip-phone with Sprint PCS back in 1998, a Nokia 5190, a Nokia 8290, a Danger Hiptop (B&W), and a Ericsson T28 Worldphone). The only thing that I feel like my Smartphone lacks (and this was a problem with the Hiptop as well) is a really good RSS aggregator. So, there are a few ways to go about making an application that will run on a Smartphone.
The first two ways are, sadly, not going to work out for me right now. I don't have the time or desire to get good enough at using the C++-based Smartphone API to write a really usable aggregator, and Smartphone 2002 doesn't support the .Net CF (although Smartphone 2003 does). The third way is far more workable.
First off, a mobile web application can be written with ASP.Net (no new API to learn!). Secondly, there are already at least two full-featured RSS engines written with the .Net framework available today. Third, targeting the web means that any mobile phone or PDA supported by the Microsoft Mobile Internet Toolkit will be able to use this web application perfectly (this means that the app would work with everything from Smartphones to Hiptops, to Treos, to Pocket PCs, etc.). Of course, you lose out on some richer sets of functionality by working with the web, but oh well. There's only so much that can be done here.
So, let me toss some ideas out there for what something like this might look like (with any luck, I will have some spare time to start piecing this together sometime soon).
It doesn't make a lot of sense to try and add new feed URLs through a mobile phone. It's tedious and error-prone. It would make a lot more sense if the web app could suck down an OPML file to determine a user's feed subscriptions.
It should be very easy to figure out what has and has not been read. At the same time, you really don't want to overwhelm your users with a huge amount of text on the screen at once. There's an interesting balancing act to strike there, and I'm not quite sure what it would look like yet.
It would be really cool if a user knew how much data they would be required to suck down before they click on a “detailed information”-type link. This could be as simple as Foo (4k). I'd really rather not run over my monthly data allowance, and I'm sure a lot of other people feel the same way.
I'll throw out some more ideas as I have them, and I'll look for some free time later this week to code up a prototype. This is definitely one of those projects where I have a huge amount of desire for something like this to exist, so I'd love to jump on it if at all possible. What does everyone out there think about this?