Subscribe to
NSLog(); Header Image

The Email / RSS Paradigm

"Gee, PulpFiction sure looks a lot like Mail!" Obviously, this was a goal of ours in the creation of PulpFiction. The downside to using Mail's familiar UI is that sometimes people say "PulpFiction treats your feeds like email."

Y'see, that's not exactly true. PulpFiction has an interface like Mail - a drawer with folders and accounts, a table with columns of data, and bottom view with "message" content. It's got a search field and a progress window. It's got similar menus, buttons, and keyboard shortcuts. The Mail model (and let's be clear here: "Mail" is an app, "email" is a technology) offers a few other features which we realized we could leverage in a syndicated content aggregator:

  1. Each article is an independent entity.
  2. Articles stick around until you say otherwise: they're under your control the instant they "arrive" on your computer.
  3. Folder hierarchies can be created to organize the articles at a fine level.
  4. Easy searching of titles, articles, authors, etc.
  5. Ability to apply filters to "incoming" articles.

PulpFiction moves away from Mail's UI where it makes sense: you can't "reply" to anything in PulpFiction, though we have an "Email Article" button. PulpFiction includes a powerful subscriptions manager, for which Mail has no need. Many of the differences stem from the fact that email is a two-way medium while syndicated content remains largely one-way.

Mail's UI and PulpFiction's UI are similar because they present data of a similar granularity, not because they're treating that data "the same." The UI is merely a "vehicle" for data delivery and data presentation.

Previous attempts at solving the "how do I present all this data" dilemma in the syndicated content world have resulted in a variety of "delivery vehicles." Most have treated the feed as the package to be delivered. The package contained a bunch of stuff, but the delivery vehicles only cared about the package as a whole. In this model, the feed (the package) is delivered to the user. PulpFiction treats the feed as the shipper, not the package, and delivers individual articles to the user.

The "Mail UI" doesn't work for aggregators that, effectively, define a feed as the delivery item. If your email client did this, the sender could decide how many and which of their emails you could see at any one time. The "Mail UI" and the way in which it presents data works for PulpFiction because an article is the "delivered" content. Just as you may have other emails from the same sender lying about, you can organize your articles independent of the feed from which they came.

Our goal was not to "make RSS like email," but to take the granularity of syndicated content up a notch: from "feed-centric" cargo to "article-centric" cargo. This change necessitated a delivery vehicle different than those being used by most aggregators. Mail's model fits beautifully and delivered appropriately granular cargo. It's a fine line, that much is true. But it's in the definition of the line through which true functionality comes.

We didn't shoehorn syndicated content into an email model, and we "don't treat RSS like email." We looked at how we wanted to deal with the data and found a user interface with which people were already comfortable and which presented data at the proper granularity. It's easy to tell someone "it works kinda like your email app" and people latch on quickly, which is critical to the success of syndicated content.

So, "PulpFiction treats your feeds like email" is close to the truth, but it doesn't really tell the whole story. PulpFiction delivers the content users want through an interface suited to delivering the proper cargo.

7 Responses to "The Email / RSS Paradigm"

  1. links for 2004-12-14

    FlickrBlog: A Day in the Life A day of photography - December 21. Maybe I’ll participate this time round. (categories: dayinthelife flickr photography) The 25 most difficult questions… …you’ll be asked on a job interview. Not t...

  2. I'm using newsfire now, the only thing that's keeping me from switching is that $25 is hard to justify blowing right now for a RSS reader - and I love what I've used in PF. What I like about it is that the interface is as simple or as powerful as I want to make it. I don't have that option with NewsFire - a common criticism that I have with applications like Safari in the Mac world. UI is nice, but the whole reason I bought into this OS is because it's out of my way when I want it to be and I can twiddle bits when I want to. And I came from the unix desktop camp, so I guess that might indicate where my priorities lie.

    Anyways, what scares me are the efforts of browsers and email clients to integrate RSS support - ironically these clients are doing the same thing they set out to defeat, the "netscape-itis" that brought them forth, integrating a bunch of barely associated parts to the point where two ends do not relate at all - this is not third normal form, it's an application.. Half-assed features do nothing to persuade me to use them, they might open my eyes but if I'm stuck on it I will find a special tool that has more flexibility - like PF.

    Anyways, in this long post-death-march exhaustion rant, the fact that PF allows me to make it as simple or powerful as I want is the killer - I can use the drawers or just look at the main panel, for instance, or define my own CSS if I like a simpler display. It's the same reason I switched to using PathFinder, and use Emacs to write code. All have relatively simple, easy to use default interfaces and allow you to go much farther if you need to.

    In other words, you could have made it look like damn near anything and 10 minutes of use would have still convinced me - as the flexibility (as you describe with your "package" comments) allows me to fit it to my needs, not yours. Maybe that's not what you were hoping to hear, but take it as a complement nonetheless - backend design, IMO, is much more significant in the long run.

  3. Uh, just to be clear, I wasn't complaining about the price - my financial situation right now (yay Xmas) is keeping me from purchasing it, not anything else.

  4. I, too, think the treatment of feeds as being made up individual articles really makes sense. That is, after all, the point of the feed. It's also why I don't like going to the sites in the first place - I used to have a list a dozen long of "daily visit" sites, but now that's down to 5: a Christian devotional, my company's stock ticker, Apple, my LiveJournal friends page, and's NeXT forums. All else comes in via RSS feeds. Sure I don't need there, but I like it. 😉

    I have a few usability comments on PulpFiction (yours for the asking - email me), and I'm still evaluating whether I want that or an RSS-to-email gateway, but PF is definitely top shelf and I'll likely buy it before too long, especially now that I'm seeing the benefits of RSS.

  5. Hey, it's no longer "my" software, but I still had quite a hand in shaping the application, and so I'm proud of the "VIII" that PulpFiction got in the Ars review. Of course, no review would be complete if there...

  6. [...] I still believe my thoughts in this article apply, though I haven't had a chance to re-read that article yet today… FootnotesI hate that [...]

  7. [...] I have relatively interesting (in my opinion) articles like "The Email/RSS Paradigm" with only six comments, two of which are TrackBacks from my own [...]