02. Second Iteration
View on Vimeo.
This is a post detailing the second Raindrop iteration in the design process. It talks about a more experimental layout based on what we found limiting about the first layout.
The result of the first iteration led me to explore a somewhat different direction than what we had been doing previously. I knew that the inflow still had to present the same information - message type, date sent, the sender, the subject and the message and corresponding replies. However as opposed to sticking to a two column grid, I wanted the inflow to present the most amount of information possible at once, using the maximum amount of available screen real estate. The result of this was reverting back to the fundamentals of graphic design and implementing a strict grid system to organize the messages.
↪ screenshot: The grid system. (click images to enlarge)
The number of columns in the grid is dependant on the width of the browser. Three columns accommodates the average browser width, sitting at 960 pixels wide. The typography now adheres to a 14px baseline grid, and screen real estate is used much more economically. The sidebar is also now compressed into a top menu again emphasizing the importance of screen real estate.
↪ screenshot: New direct and group messages displayed first, followed by 3 grouping widgets, and lastly your old read messages indicated by a lower opacity.
Message order reads from left to right:
1 2 3 4 5
6 7 8 9 etc
As opposed to piling the notification, broadcast, and mailing list widgets to the bottom of the inflow, they now mark the end of unread messages, and the beginning of old messages. The space between read and unread messages will house these widgets. These widgets adhere to the grid like any other message but are now clearly defined by differentiating background colours. Unread messages will always appear at the beginning of the inflow, followed by your widgets, and then followed by old messages. This is the default message order, and can be re-arranged in your inflow settings. This grid layout accommodates the addition of many more add ons and extensions in the future. It also creates a space which add-on developers can easily adhere to.
↪ screenshot: Drop down Quick Compose and a drop down menu.
The quick compose is now out of sight but not out of reach when you first enter the inflow. Simply click on the compose button to bring down the Quick Compose. Also, drop down menus are bolder and more legible as indicated by a bold yellow overlay.
What’s next?
This second iteration is one tangent created out of what I felt could be improved upon the first. These are simply two iterations. Maybe the grid view is too experimental for day to day messaging use. Maybe this is a much better direction than a standardized two column view. It is wholly possible that neither of these directions are the right one, or that the right direction could be a merge of both. The project is now out to the public for feedback, to create something collaborative and for everybody.
Summary:
Pros: Much more effective use of screen real estate (scalable, compressed menu), designed to a strict grid - including a typographic baseline grid, clear order of direct messages, widgets, then old messages. Also has a cleaner aesthetic, and lots of room for added widgets.
Cons: Keyboard navigation is less intuitive, no transition from inflow to full message, empty space below each message caused by fixed height of each row.
-Andy Chung
Hey guys, really, really love the ideas behind this and am very excited to see where this goes. I personally dont think the 2nd iteration is very consumable for the average person. Most people read messages top to bottom (an obvious result of email) and with the whole keyboard-centric mentality the first design makes much more sense.
Overall, I can’t wait to see what you guys do next.
As an overview this is the preferred way for me. But then i’d like to browser categories in the top to bottom way. Or something similar.
after testing Wave for a few days, i was surprised by how much of a learning curve their was. Thus far, it just doesn’t feel intuitive to me.
however, after watching the video on Raindrop (the one on the home page i believe) I was blown away. I think this is exactly what I’ve been looking for.
Well done guys. Well done indeed
This seems like an exciting project.
While I know both iterations have their benefits, I think the presentation of iteration #2 is more of an all-up, which could be good for those that are managing multiple info-streams. The downside is that it could be info-overload for the untrained eye. In that case, iteration #1 might be more familiar.
Perhaps you could explore the widget concept somewhat? I’m curious if the information (e.g., for notifications and broadcasts) could be presented in a different way? If so, perhaps those categories could float as tabs on the edge of the browser (bottom or side) and show just a little snippet that would expand on hover or?
Maybe this would allow for a single-column approach (with site nav at the top) that maps to the standard top-down, left-right reading style. In addition, you could then enable the iteration #1 approach to viewing the full content of the message using left and right keystrokes.
Just a thought.
Hey Robert,
Good points on the first two iterations. Your ideas for a new iteration are definitely very inline with where we’re thinking of going with the next phase - We’re thinking of having a one column inflow of your direct/group/@replies (implementing the keyboard nav style of the first iteration), with broadcast/notification/mailing list widgets laid out in a grid view on the right. Will post some mockups of this soon hopefully.
This would use your arrow keys for message navigation, however keyboard nav for the widgets would be up in the air.
VERY interesting and very useful. I have no doubts as to its success. Maybe popups of information when a new message comes in, a mouseover would allow for a popup of that message and its parents, only if there were a conversation going.
I am excited by this!
>Message order reads from left to right:
>1 2 3 4 5
>6 7 8 9 etc
Maybe I’m missing something, but don’t see why the chronology is in rows rather than columns. It’s well established that vertical motions are easier for humans than horizontal motions. It is also the case that changing the width of the display would not reflow the most recent messages. Changing the height would of course, though typically browsers and phones are higher than wide, so 1-2 fewer messages would reflow than when changing width with the content in rows. But anyway, the display can be paginated by height, and in fact having discrete page jumps is a useful reduction in complexity from smooth scrolling, fixing addresses of messages (e.g. “2nd page lower-left”) for quick navigation. Newspapers suck for many reasons, but their presentation of text isn’t one of them.