In case you missed it, Michael Affronti, Microsoft's Program Manager for Outlook, announced on his MSDN blog that Outlook 12 will have RSS aggregation built in. He later followed up with another post describing the proposed interface for managing feeds.
Given the popularity of Microsoft Outlook this is big news for fans of RSS and syndication. As Robert Scoble points out, this will bring the benefits of RSS and syndication to millions of people already familiar with Outlook.
But the question I pose here is: Does Outlook's interface provide the best metaphor for managing intranet-based RSS feeds?
Many RSS aggregators are built with a mail-like interface. The aggregator I have been using for the past two years is Bloglines. Its interface is somewhat mail-like with feeds being managed in folders in the left pane and the contents of the feeds showing in the right pane. However, one of the best feature, in my opinion, is being able to select a folder full of feeds and letting Bloglines show all of the unread items in all of the feeds in that folder. I view this as a personal "clipsheet" for the common topic of the feeds in the folder.
For example, I have a folder called "Photography" that holds all of the feeds I monitor regarding photography. Clicking on the "Photography" folder gives me a clipsheet summary of new blog postings and articles regarding photography. Michael hints at being able to do this with Outlook 12.
Longer term, however, I question whether Outlook's interface (or a Bloglines-like interface, for that matter) is the best way to aggregate intranet feeds since they will contain very different kinds of information from what is predominately found in most feeds today. All enterprise RSS product interfaces I have seen to date are built based on the same scenarios as the consumer use of RSS feeds. That is, we want to quickly scan a number of websites and blogs looking for new items that interest us.
But, as intranet applications start producing RSS feeds I think the tables may turn on the "traditional" aggregators and we will see opportunities for new kinds of innovative aggregation. This is because intranet feeds will contain information much more targeted to the individual than what is found on the internet today. Sure, many (initially, most) RSS feeds consumed on intranets are and will be from media websites and blogs.
However, instead of articles and opinions that are made available for anyone to read, intranet feeds will contain timely contextual business information that the intranet user needs to execute a business process or make a decision. This information will be tailored to the individual based on their identity (just like any intranet application screen). An RSS feed from a company's product management system should only return data the requesting user can access (or is relevant to their role) just like it does today with existing application interfaces.
For example, instead of sending an email (or requiring the intranet user to login to the application) to notify a user that a new part has been released, an RSS feed will be populated with information indicating this change. An aggregator should place this notification item into a contextually relevant part of the interface so the intranet user will be able to see that the event took place.
In most large companies, few jobs are handled by a single application; intranet users are moving from one application to another to follow a business process. Therefore, an effective intranet aggregator will have to manage information coming from the applications required to accomplish a job or task. The feed item will have an advantage over the simple email message because the aggregator will know which application the information is coming from since it is polling the feed itself (rather than just catching email messages coming at it).
In my opinion identity-driven RSS feeds will be a primary feature that distinguishes intranet versus internet use of aggregators. Can an aggregator with a mail-like interface (like Outlook) be the manager of these items? Certainly Outlook's rules for managing mail and RSS items will provide the ability to route feed items somewhere but will this be enough for the intranet user?
In addition, as the barriers to retrieving information across disparate systems are dropped (after all, aggregators will now proactively retrieve information rather than require navigating an application interface) the productivity of the knowledge worker will increase, perhaps quite dramatically. As a result, the scope of an individual's responsibility will also expand, meaning more application feed items will be coming to the intranet user.
Now, I can envision some general scenarios for RSS feeds that would naturally fit into Outlook. For example, a new task is assigned in an ERP system and then it shows up in the intranet user's RSS feed. Perhaps this task will automatically be placed on the user's calendar or task list.
However, it seems to me that identity-driven RSS feeds will enable an opportunity to provide a functional view of an intranet user's job. The interface to consume these feeds should somehow be functionally relevant as well, not just an extension of an inbox, calendar, or to-do list.
Identity-driven RSS feed items should not simply be thrown in with the mish-mash of messages coming in via email. There has to be something better to take advantage of this increase in relevant, targeted information flow. Otherwise, this increase in information flow (as relevant as it may be) will be seen as another culprit in information overload rather than an enabler for improving visibility across an individual's workload, as it should.
I am picking on Outlook, but I could probably make the same comments about many (perhaps all) present-generation RSS aggregators. Current aggregators are certainly more than sufficient for dealing with a small number of intranet applications providing a limited number of feeds. But, as application support of RSS increases it may not be long for the intranet user to start crying out from information overload.
Today, a limiting factor in business process execution is the clumsy nature of retrieving information via an application interface. In the future, this barrier will be nearly removed and the limiting factor will be the intranet user's ability to process this information. So I continue to look for innovative feed aggregation to help the intranet user, already overwhelmed with email today, to effectively manage multiple executing business process work streams.
5 Top Federal Initiatives For 2015As InformationWeek Government readers were busy firming up their fiscal year 2015 budgets, we asked them to rate more than 30 IT initiatives in terms of importance and current leadership focus. No surprise, among more than 30 options, security is No. 1. After that, things get less predictable.