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
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.
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.
Hello,
Snowl is really interesting!
A short remark though: while searching is definitively useful no question, searching for information with google on the web is radically different from using personal (some call it familiar) information that you are already aware of. In such context chronological or topic based pre-organisation are also quite efficient.
Cheers
Aurélien
Based on your previous post “Snowl Futures” and on this one “Snowl Principles” I would like to make a few comments:
1) What should be Snowl’s function?
I believe that the long term vision should be “Snowl as a messaging platform”. This implies that it should have “pull” functionalities (which it has now as a message reader) but also “push” ones. I recall that this is not new since it was stated on the first roadmap the possibility of developing “an interface for writing and sending messages to enable true two-way conversations”. I think that is also your vision too from what you said in “a messaging app is a platform”
2) What should be Snowl’s core features be?
a) Persons, Organizations, Groups and Conversations as first-class objects
I agree with everything that you stated in the principle “Persons and Conversations as first-class objects”, however I think there should be 2 more first-class objects: organisations and groups.
Organisations – Sometimes we “talk” or want to know what a given organisation is doing and there is no person on the other side. Example: I track down the activities of several companies and for that I subscribe to their news feed. There is no person involved just me and an organisation
Groups – This is something similar to the friend list functionality in FriendFeed. Example: I want to see all messages by Mozilla Labs or subscribe to its news feed. Mozilla Labs is neither a person (although its feed aggregates their members messages) nor an organisation (it is just a department inside Mozilla Corp). Also If there is no group feed, then I should be able to aggregate the feeds of Persons in a Group while preserving the Persons feeds.
Also another important feature to implement relates to the way Snowl should view the different objects.
Persons and Organisations are easy to define and because of that they should be detected automatically by the app. No manual input to create or fill details, that information should be retrieved from other services.
Groups and Conversations demand some degree of manual input. While Groups should be exclusively manual to allow the biggest range of possibilities, Conversations should use a mixed approach, i.e. the app needs to automatically detect that X and Y messages belong to that conversation but also allow adding to or deleting a message from a conversation.
b) An easy way to view messages made by myself
This is a killer, specially since I stop counting how many times I missed a conversation in which I made a comment and forgot to track it to see updates. Probably this could be solved if you could add yourself as a Person object to the app.
c) A way to enable Snowl to easily retrieve a feed from sites (full site or section) that aren’t feed enabled
Some companies that I track don’t use feeds on their sites. I’ve tried Dapper and a little bit of Yahoo Pipes but these are not very user friendly ways to do it.
d) Integrate audio and video in Snowl
Most of the messages and conversations which occur in the Internet are text based or have audio and video embedded in text. However with the dissemination of audio and video ways of communicating shouldn’t them be supported?
3) What should be Snowl’s position in the Mozilla Ecosystem?
Here I’m trying to identify synergies between Snowl and other Mozilla applications and technologies.
a) Thunderbird
If Snowl is a messaging platform shouldn’t it be more tightly coupled with Mozilla Messaging? Also since it shares the same core objectives that Thunderbird but takes a much more broad view on what messaging is (not mainly email) shouldn’t the new generation Thunderbird be built on top of Snowl?
Contacts manager – Since it already stores our personal and professional relationships leveraging the info presented in the contacts manager could be a great way of quickly find Persons, Organizations and Conversations (if not Groups)
I’ve choose Thunderbird because of the overlapping nature of the two, however
a good exercise should be to list all apps and technologies of Mozilla and analyze them, and their modules/components (as I did in Thunderbird’s contact manager example), to see the potential synergies.
Thanks for allowing us to participate in this conversation and I anxiously expect the next brainstorming post
Hello,
I noticed you switched from JS dates to Julian dates. Could you, please, explain it to me? Just curious…
Anonymous: SQLite’s native date format is Julian dates, so Snowl converts to Julian dates when it stores dates in Snowl’s SQLite database (which makes it easier to do date calculations in SQL queries) and then converts them back to JS dates when retrieving dates from the database and storing them in memory (which makes it easier to use them in JS code).
Understood, thanks a lot!