Planning

Based on feedback received from BOFs held at the last two conferences, significant pesterng of users of other feed readers, analysis of other feed related tools and analysis of current trends in the use and production of feeds the next couple versions of the news tool will focus on two general areas:

Adding an easily implementable interface for Sakai tools to be able to produce rss feeds with varied levels of access restrictions.

There are many times when a user would want to track changes over time in a tool based on their view/role, examples of tools that I've personally wished I could are: discussion, message center, resources, Samigo (for published assessments), callendar and more. Feeds can be used in many ways and allow for many interesting uses of data many of which I'm sure haven't even been thought up yet.

A couple tools are already producing their own feeds, which is great, but it would be very nice to have a central standard service for doing so. This will prevent other tools from resolving the same problem over and over, will ensure consistent format/type/quality of feeds coming out of Sakai and it will possibly allow the news tool reader to let users easily discover internal feeds using a browse feeds type of interface (see next section).

Many times a user may wish to control access and content of feeds based on roles. This interface must allow for fine grained control over who can see what based on the existing access restrictions of the tool. Due to these access restrictions and the fact that many institutions use Sakai in an SSO setting, many of these role specific feeds may be only really useful internally.

The biggest design hurdle that I don't see an obvious answer for at this point is in how to get the implementations of the interface from the tools and into the news tool. My first thought is to get an optional entry in the Sakai tool definition added and have that entry spring loaded into the FeedService some how, but that will require more investigation and disucssion. 

Bring the news tool up to date

feed readers and aggregators have come a long way in the past few years and we have not yet evolved with these changes.

  • Add proper handling of enclosures and extensions to feed specs (such as the iTunes extensions to rss). At the very least we should provide a link to the enclosure, optionally we could include a small flash media player widget for certain types of media.
  • Better handling of caching of feeds, caching an entire feed for 10 minutes no matter what is a fairly out dated way of doing this. Many readers check the feed without downloading the entire feed more often and only download the entire thing when the feed has changed (Rome has a plugin that may do most of this for us).
  • On demand loading of what the user actually needs (see Google's new feed reader http://www.google.com/reader/view/ for a very nice example of this). If a feed has 100's of items the user should be able to get to them if they want, but we should not show them to the user if they do not want. The tool should show the user the first page or two of entries, then if they scroll all the way to the end use ajax to grab the next block of results and repeat until either the feed runs out or the user stops reading and scrolling.
  • Add the optional ability to add multiple feeds to one news tool. The biggest hurdle with this one is finding a clean UI for displaying all the feeds. Most good readers use the left bar for this, but we have less realestate to work with then most readers because that is where the Sakai tool bar lives.
  • Track read status of entrys. From the user standpoint many feel that this is a nice feature, some users don't really use it in other readers however and implementing this could result in substantial database bloat for what some consider unimportant data. A slightly less acurate but possibly good enough to make every one happy aproach is to just track the date of the last view for each user on each feed, which would result in MUCH MUCH fewer DB entries. This will need more discussion, please share your thoughts.
  • Add support for tagging. This once again falls into the debate of db bloat. But the rewards are greater in this case, it would be a very nice feature to be able to tag entries and thus be able to point your class directly to all news items with a certain tag to start a discussion or just to focus what your class is to pay attention to from a feed.
  • Direct linking. If aggregation and/or tagging are implemented the user should be able to direclty link to a particular feed, tag or feed entry. This will be especially useful when using news items to start discussions.
  • Add support for reading restricted feeds. Some feeds require some sort of authentication, most methods of doing so are far from secure and hacks in my opinion, but we should be able to read them.
  • Provide a way for users to 'Browse' for feeds. The list of feeds available for browsing would include locally produced feeds and possibly other popular public feeds from with in the current Sakai installation.
    *Many of these items are unconnected to the other items and will be seen and treated as small bite sized tasks being done in small iterations.

Input

We're very interested in you input on any of these items or any items that you feel should be on the list.

Be part of it

If you would like to get involved with improving the news tool please let us know. Thus far we've had a lot of people very interested in seeing these changes happen, but very few that actualy have time to help out (which is a state I can totally understand as it's how I am on MANY other projects going on in Sakai right now).