The Raindrop Design Philosophy is Simple
It starts simple, the challenge is keeping it simple. And like any philosophy these are questions, not answers; answers would be too easy. 
Simplicity
How do we avoid complexity without over simplifying? Where we are about to abbreviate, could we perhaps express in another manner?
For example we’ve started Raindrop with two different types of messaging, Twitter and Email, because we’ve found that people need to use more than just email to communicate with each other. However Twitter and Email are two very different types of messages so how do we display the right amount of information to user?
Do we combine both types into a single message format, and if so how do we indicate a tweet or a mail?
Sender | Date ?Recipients? ?Subject? ?Message?
Or do we break these messages up into two different formats, each with specific visual cues?
e.g. Example Email
Sender | Date ?Recipients? ?Subject? ?Message?
Example Twitter
Sender | Date ?Recipients? Message
And those are just single messages, not even conversations yet. So what is the simplest (most efficient) way to represent conversations in Email and Twitter? We’re still looking for the right answers.
The following video shows the simple design of Raindrops built in keyboard navigation.
If these questions interest you then I’d invite you to join us at our Flickr Raindrop Design Group where we’ve opened up these design discussions.
A designer knows that he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away - Antoine de St-Expurey
Everything should be made as simple as possible, but not simpler. - Albert Einstein
Content Driven Design
How do we iterate designs from as many different areas of design like typography, interaction, visual, and more while keeping user content as our main focus?
In the following video we look at how interaction design and information architecture have already influenced how we’re looking at messages in Raindrop. So far we’re analyzing the content of messages to determine what kind messages they are and apply the right categories to them so we can take advantage of that information in the user interface.
As you’ll see in the next section, Designing in the Open, we’ve also iterated on a grid view that relies heavily on typographical influences for creating a solid layout structure.
Form follows function-that has been misunderstood. Form and function should be one, joined in a spiritual union. - Frank Lloyd Wright
Designing in the Open
We are looking to solve a complex problem and we need help. How do we engage the right people to help solve the problems we have? What are the right problems we should solve first? How do we frame the user intentions such that we solve the problems in a satisfying way?
We’ve created the Raindrop Design Flickr Group to help facilitate open design discussions around conversations on the web. Our goal with this group is to have a place for ourselves and others to post new mockups and designs and receive quality feedback from other designers working in this space.
Here are some examples of designs already posted to the Flickr group, please join the group if you’re interested in discussing these and future designs.
Iteration 1 (list view)
Keyboard Access - Iteration 1
Iteration 2 (grid view)
Join the group if you’re interested in these design discussions. We also have separate developer discussions happening on the mailing list if you are looking for discussion of API or code development.
Connecting with our Users
How do we integrate our community of users and developers for feedback and discussion as the product evolves?
Currently we’re trying to use Get Satisfaction integrated directly into the application itself. This provides at least one place for our users to discuss issues and suggestions they come across while using raindrop.
The following video shows how we’ve started to integrate Get Satisfaction directly into the application design, giving our users a place to find help and ask questions. This direct integration also means that our designers and developers have a place to find feedback and connect with application users.
But user feedback only goes so far to help understand how our implemented designs are working. Another aspect of feedback we are exploring is the use of anonymous statistical data gathered from our users (with their permission).
For our initial phases we’re looking at gathering simple metrics which could be used to optimize our existing designs. We don’t want to collect any personal information — only gross numbers that give us valuable insight into how the application is used.
Example data that would be tremendously useful:
- How many folders do users have?
- How many new folders do users create on a daily basis?
- How many tags do users have?
- How many tags are users creating on a daily basis?
Future iterations of this kind of feedback could use the Test Pilot project from Mozilla Labs. Currently Test Pilot is running a study to understand how it could optimize the opening and closing of tabs for users. This kind of integrated user testing is extremely helpful for Firefox to understand its users and how certain interactions effect them. Raindrop would surely benefit from this kind of distributed usability testing framework.
However beautiful the strategy, you should occasionally look at the results. - Winston Churchill
Evolutionary
What is the right balance to have between a platform built for tinkering and innovation with a production ready product that holds peoples private data? Firefox has successfully led the way in this direction for quite some time. How do we create a similar direction?
How do we build an API that allows designers to easily build new applications or extend currently applications in ways we have yet to imagine?
Currently we’ve build an integrated extension system that gives instant feedback to changes made in the inflow interface. For more on this see James’ video on Raindrop Software Components.
It’s evolution, baby - Pearl Jam
-Bryan Clark
Will Raindrop allow me to group the contents of my address book so that when I receive email from those addresses it automatically goes into folders according to that group? I may have emails from friends / family that I am in the cc list for, but these are just as important as emails from friends / family that I am the only recipient for, so would like to be able to make sure these have high priority. I have organizations in my address book that whose emails I am definitely on the cc list for and would like to be able to give these a lower priority than the personal emails, but a higher one than viagra ads whose senders aren’t in my address book
One challenge with prioritizing the messages by checking if the sender is in the address book. For me the first contact from customer comes from the person who’s not yet in my address book and certainly that can be more important for me than a shopping list from my wife where I’m in to field…
@Andy: Part of the design of the Personal vs. Bulk mail is allowing you, the user, to control what Raindrop thinks is personal or bulk. And this then gets into @Henkka’s question.
@Henkka: Yes, so we’ve tried some initial designs on this early on but don’t have something clear enough just yet. When you receive an email from a new person you should have the choice of saying “This is a person I care about”, “This isn’t a person”, or even “This is spam”. We’ve also been working on tagging people so you can tag a person “Customer” and then Raindrop will group all messages (new and old) with that tag.
Thanks for the comments! We should be posting some new designs soon.
Hi,
I’d like to offer a user point of view for your design, if that’s okay. While I’ve designed web interfaces, for sites and applications, I want to focus on a problem that I have that Raindrop appears poised to solve.
I recently moved back to a Mac after 14 years on Wintel and 6 years before that on a Mac. The biggest problem for me is finding a Mac equivalent to Outlook plus Xobni. Which has got me thinking about the real problems I’m trying to address with email.
First, sorry if this is a long comment. Second, when I say email in my comments, I also mean Twitter, Facebook, and other data Raindrop will handle.
I want to focus on a layer of your design that resides above the list and detail designs you have posted.
If I were king for a day, when I open my email I’d see four lists or groupings:
1. a list of people (with data about new emails)
2. a list of people I’ve not corresponded with in some time period (say > two weeks or > a month)
3. a list of new people not currently in my address book (with ability to assign them to my address book, project, client, or tag, as well as assign them to an existing person, for example, a tweet from someone in my address book)
4. I also might see a list of new emails for newsgroups, broadcasts, announcements, as one area, organized by source as a list, not one box per source
From this initial view, I could then drill down into my emails based on person, project, client, or tag.
Today, of course, I have to adapt to the email software, not the other way round. Even the list view and detail view designs you have would force me into that mold, if I understand them correctly (I may not). Instead of having my emails sorted by groupings meaningful to me (e.g. people, projects, clients, other tags), I have to scroll vertically to scan each email. It would be much easier to have the email software sort my emails by groupings I define and let me scan those groupings and then dive into lists of emails and then into specific emails.
In this design approach, as the user, I would define what emails and people belonged to what projects, clients, or other tags. I also might get to specify key words and phrases (e.g. product names) that would get an email sorted into a specific groupings. I could assign a person, for example, to multiple projects, clients, or tags.
To Henkka’s point, it also might be useful to assign numeric weights to people, projects, and other tags so they show up higher in this initial view. And to be able to change these weights on this view, by clicking something and having the view adjust dynamically. That would make this view not only easier to scan and interact with but also a work space with the most important people, projects, or other tags up top.
Also, it would be important to me to flag emails at least the least and to turn them into tasks (or to dos) at best. Then sort by tasks. Indeed, flags might be a view, in this initial design layer, equal to sorting by people, projects, or other tags.
Grouping emails by broadcast versus announcements, to: versus cc:, personal versus bulk, that is useful but it lets data drive the design. Instead, with email at least, people should define this top initial layer, whether it is to organize email by people or projects or tags, and switch between those “views”.
For me, at least, it would be neat to see software designed around people not data. Especially email which comes from people even though it’s about work or other activities.
Look forward to seeing how this project evolves. Hopefully some of my comments will be useful. If it was useful, I’d be happy to play with actual wireframe/designs.
An individual person may have multiple online personas/addresses/handles etc. I think it’s important that there’s a facility to associate these disparate entities with one actual “Person”.
Essentially I think this means just being able to create a tag of “Joe Smith” and to tag one example each of his emails/tweets/facebook updates as “Joe Smith” so Raindrop will understand “Joe Smith” to be the author of messages via any of those inbound channels from then on.
Just a thought.
I’d like to see filtering structures based on my purpose coming to the client:
If I can “tag” my use case then I can choose between say “continue existing conversations”, “check the archive”, “continue with a project”. Tagging usecases as well as/rather than emails themselves is a small distinction that sometimes collapses, it’s very different when searching for a specific email, but sometimes choosing a specific form of content will have structural implications for how I view it, such as wanting threaded chains of replies vs seeing as many names as possible.
So can use case tagging be implemented from a set of email tags? Possibly; the clue to my idea is in the “viewing implications of content”. If tags can have formatting rules assigned to them, then (as a first prototype) there could be a dominant tag, that sets global formatting (with accomodations to different protocols obviously), with other tags simply continuing their standard function as filters.
So you could sellect “conversations” “freinds”, or “unread” “conversations”, with the first tag being in a big box, and dragging “unread” and “conversations” so they swap will change the formatting.
The swapping of freinds and conversations is probably the most interesting, as “freinds” veiwing implication could be a picture, and their latest tweet/facebook status, forming a drop down menu if you click on their picture. If conversations was there the list and status would only include what is judged to be replys to what you said. The alternative formatting would be a set of generated conversation threads in the order of last post, filtered to include only those declared as freinds.
You can immediately start to imagine how the secondary tags could start subformatting that, but I thing it’s better to just get the content->presentation thing going:
To start with you creating different formatting as different pseudo-tags (with the formatting choices acting as tags to all content until specifically applied), but add the possibility for people to apply those properties to their own tags, via prototype inheritence (drag to the big spot when in another view, say yes to dialog box to copy view format) and then alteration via a view-properties menu.
This allows seperate family trees of view options and so few side effects, but still allowing people to be power users and personalise their devices to a significant extent.
I can even envisage an interesting way to include search within that paradigm: If the search tag is dominant, the view is a tag-filtered search with the appropriate search bar, if it’s not, then the search you just did acts as a filter itself, as “search 1″.