Over the course of working on Snowl, I’ve established a set of principles to guide its development. They’re aspirational, but they have many practical ramifications. And while the current implementation doesn’t embody them yet by a long shot, I expect it conform more and more closely to them over time.
The principles are:
- feeds are a transport format, not a feature;
- people and conversations are first-class objects;
- one app can satisfy a broad range of users;
- searching is better than pre-categorization;
- browser features are useful for messaging;
- a messaging app is a platform.
feeds are a transport format, not a feature
Feeds are currently presented in many application interfaces (including Firefox’s) as a user-facing feature of the web. But feeds are data formats defining generic mechanisms for syndicating content. They’re designed to be machine-readable, not human-consumable, and interfaces that expose them directly are often too technical, like the way websites publish both RSS and Atom feeds and Firefox asks users to pick between them (as aptly
described by Atul Varma).
Treating feeds as a transport format means that rather than exposing them directly, Snowl should use them internally to give users a way to do the things they want to do, like find out when a website changes or keep up with what their friends are doing on the web.
So when a website provides RSS and Atom feeds of the same content, Snowl should pick a format instead of asking the user to do so. And when a website provides comment feeds, Snowl shouldn’t expose those feeds to users, it should just show the conversations embodied in them to the users following that site.
The same is true for feeds provided by social network APIs. For example, the
Last.fm API exposes the listening habits of its users’ friends as individual feeds, but Snowl shouldn’t make users manage individual feed subscriptions when they’re really just interested in what their friends are listening to. Instead, it should present those individual feeds as
Last.fm friend updates, separating them by friend–not feed–where appropriate.
people and conversations are first-class objects
There’s no unique identifier for people on the internet. We each have an ever growing number of email addresses, usernames, and nicks on various websites, social networks, and messaging services. But we think of each person’s various identifiers as representing the same being, and so should Snowl, so its users never have to figure out how they received a message (email, blog post, tweet, etc.) when looking for one from a particular person.
Also, context is crucial in conversations, and it’s rarely obvious which message contains a particular portion of an extended conversation, so Snowl should let users interact with conversations rather than just their constituent messages, searching and browsing them as easily as they search and browse individual messages, and displaying messages in context.
one app can satisfy a broad range of users
Most users don’t want to configure their experience, they just want things to work. And Snowl shouldn’t force them to make unnecessary decisions. In fact, Snowl should need no preferences, because it always knows exactly what its users want.
Realistically, that’s not possible, but the closer we can get, the better (while not trying to be too smart in ways that frustrate users). For example, a number of feed readers let users specify how often to update each feed. But this is information that it’s possible to derive based on how often a feed is updated. There’s no reason for Snowl to expose this question to users who shouldn’t need to answer it.
Some users, however, do want to configure their experience. Others have unusual needs. And some have great ideas about how to create better experiences.
Firefox has shown that it’s possible to build an application that satisfies all these users, and Snowl should follow in its pawsteps, using hidden preferences, subtle affordances, extensibility APIs, and other techniques to make it possible for those users to customize and modify Snowl to their hearts’ content, while keeping the interface simple for everyone else.
searching is better than pre-categorization
Traditional messaging interfaces use pre-categorization to help you find messages. But the evolution of web search engines has shown that it’s faster and simpler in many cases to simply search for what you want. Snowl should make it trivial to find any message quickly by searching for its content or metadata.
browser features are useful for messaging
Web browsers have developed a variety of features over the last dozenish years to make it easier for users to browse, find, save, and recall the web pages they visit. Snowl should take advantage of all these innovations to make accessing messages better, utilizing features like tabs for opening multiple messages, bookmarks to flag them for later reference, tagging for categorization, and the awesomebar for searching them.
a messaging app is a platform
Snowl was never intended to be just a feed and tweet reader. Feeds and Twitter are just two popular services with open APIs whose disparate kinds of messaging were good testbeds for early architectural and user experience decisions. Communication over the internet is evolving rapidly, and messaging apps have to evolve alongside it.
The best way to do that is to make Snowl a platform that others can extend to new messaging services and user experiences.
So Snowl comprises a datastore of subscriptions, messages, and people; a set of APIs for retrieving, storing, and sending messages; and a variety of interfaces for accessing them. And it should employ a flexible schema (like CouchDB‘s) to make it trivial to extend its data model; expose an API that makes it easy to add support for new messaging services; and provide useful primitives for building innovative new ways of looking at messages.
