In his Publishing 2.0 post, Doc Searls makes a comment on how RSS is enabling people to get their "Web services without the complicating container we call a browser". I was thinking that this makes sense in that we access the web through a number of different interaction modes, of which browsing is only one (though the web browser supports more than just browsing mode interaction).

Different types of interfaces (e.g., a piece of paper or a book codex or a TV screen) have advantages over the web browser for certain types of interaction modes (e.g., doodling, reading at length, and passive video viewing, respectively). So, what types of interaction does the RSS-type web serve?

I think there are a lot of interaction options with RSS-type data precisely because the data is more database-like, i.e., in a format more tied to data storage semantics and less tied to user interaction (presentation) semantics.

RSS-type data generally is designed to be presented in the context of web browser functionality (e.g., rendering entries with HTML markup, URLs that become HTML links, etc.), but it doesn't represent the larger context of "page" layout-type information (navigation, visual cues, etc.) that the computer web browser is designed to account for.

So, one of many things that seems interesting to note, in contrasting RSS-type interactions with full web page interactions, is that web pages generally push a lot of information to us that is important for browsing, i.e., being able to associate the current page with related information (most prominently other pages on the same site).

If one isn't doing this kind of browsing, for example, if one is reading the "meat" of a web page, all of the browsing-related information—at least in that moment, is outside the scope of one's present interaction.

If you know that you are going to read a particular web page or section of a web page, and are not going to be browsing around the site, RSS-type interactions are nice because all of the layout information is stripped away (or, is not added in the first place) to produce the RSS-type feed (e.g., why I utilize RSS-type feeds to read websites on a tiny mobile phone).

So, in one dimension, RSS-type feeds pull only a chunk of a page that is the one needed for the user interaction of reading or skimming, though not for browsing. When the user interaction is only about reading the chunk, it's nice to have an interface that is only, or mostly, about displaying the chunk.

Also, as I have written about before, RSS-type feeds represent time, and, in this context, affect a kind-of timeliness in RSS-type interactions. When one is just reading a section of a web page, one way to look at the layout and navigation information not presently being used is that its appearance is untimely—one doesn't need it yet, but it has already arrived.

So, this is another dimension where RSS-type feeds pull information—in this case, pulling it at the right time. Perhaps one of the attractions of RSS-type feeds is that they further refine the "just in time" delivery of web information.

Email and instant messaging, which seem to more effectively push information in front of us, are perhaps the ultimate form of "just in time" delivery. But, they are pushy in that one doesn't have much control over what comes into one's email / IM client: they are also untimely to the degree that messages are interruptions.

RSS-type feeds, I think, are more like pull email than like web push. Instead of messages being sent to you, you say whom you want to receive messages from. And, in some sense, you also get control over when (in time) you get the messages: show me something new only when there is something new.

The other aspect of RSS-type feeds that are like email is that RSS reading is essentially out-of-band with the web, at least in the two way sense. What you read in your RSS-type feed reader can link to the web, but the web can't link to it (I've posted about this). That said, I think there is a lot of potential in applications of a browsable web of RSS-type information.