03. Third Iteration
↪ screenshot: The third iteration (click images to view on flickr)
The Major Changes
The third iteration that we have come up with is a hybrid of the first and second iterations. While we liked the keyboard navigation and easy of readability of the first, we felt that it lacked in terms of widget organization and effective use of screen real estate. The second iteration was an experimental attempt at solving some of these issues using a scalable grid to fill the page. While this was a better use of screen real estate, the general consensus was that the order in which the messages were read was not intuitive enough, and simply difficult to navigate. Building upon the same grid as the second iteration, the third iteration uses the first two columns to present your direct messages, group messages, and @replies. This makes up your main inflow, and is where your primary information will be located. To the right of this are your widgets which are presented in a grid formation, which will fill the page with a number of columns based on the width of your browser. The minimum width at which this page can be viewed is 960px, which accomodates the inflow and a single column of widgets.
This layout allows for the effective use of screen real estate, coupled with the simple and intuitive keyboard navigation of the first iteration. Instead of having only the inflow column swipe out to the full conversation, the entire page will now animate.
This iteration also incorporates the concept of the inflow summary. In the mockup above the inflow summary tells you exactly what new information has arrived since your last visit, and allows you to access it quickly and easily. For example you could download all your new attachments from multiple messages all at once through your inflow summary, or quickly access and scroll through all your new links. The exact location and layout of the inflow summary have not been determined, see the below screen shot for a minimized version of the inflow summary inside the grid area.
↪ screenshot: Minified inflow summary
Creating the Right Grid
The latest designs of the scalable grid assign a fixed height and position to each of the widgets. We decided upon a fixed height after having iterated through a number of options which proved unsuccessful. The goal was to keep a simple grid of elements that scales well from a few items in a small screen to a large number in a wide screen.
Here are some interactive demos (written in HTML/JavaScript) of the variations we’ve tried for this grid layout. Be sure to try resizing your browser so you can see how the variations effect the grid layout with multiple columns and with only a single column.
- Floating grid boxes to the top as new items arrive
- Dynamically changing the size of boxes as new items arrive
- Changing the size of new boxes to a fixed height as new items arrive
And our final iteration, Highlighting changes in each box with a fixed height and position in the grid. An issue with this design (and some of the other designs) is that new items indications could take place “below the fold” and we will be trying to address this issue in future designs.
Andy,
This is a solid improvement over the visual presentation in iteration 2, as it addresses a key component in information review: content value changes based on source. With that in mind, a single extended column to the left makes perfect sense. Excellent thinking on your part.
A big concern for me with Raindrop is that now that I CAN view multiple sources of online communications in one window, it likely should have a layout that is not overwhelming (sure, that’s ironic since it’s an aggregator, but approachability is every bit as important as usability). It needs a little air. Frankly, I liked the balloon approach from iteration 1 as it seemed less overwhelming was very approachable. Users have to WANT to use software like this to shift from their current workflows, however antiquated.
If a navigational hierarchy is necessary (as in iteration 1), is it possible to implement some form of AJAX to minimize its screen real estate? Edward Tufte offered a wonderful video on the ‘Net wherein he described one of the true advantages of the iPhone as an interface that eliminates itself from the equation, allowing screen space to be used for content.
Again, great thinking on your part.
I also agree with Craig. This is a great step but ultimately one that can be overwhelming to the user. Information overload is a huge concern and the more you can make the interface polymorphic, the more users can adapt it to their needs.
Granted, building for various use-cases means more work, but with messaging you have to give people a way to consume/share that matches their mental model and not another system that diverges from what they are comfortable.
One thought for the right side is to simply make them collapsable lists that have a numeric indicator when new content is added. This would allow the user to toggle open the list and choose when they want to see the new content. The one downside is that you end up creating more anxiety buy having all those unread counts…
I’m definitely beginning to agree with the both of you re:information overload. I think one solution, the obvious one, is simply having one stream of widgets rather than a grid.
http://animalyouth.com/files/rd_2column.jpg - A quick mock up of this: I feel this addresses the needing some air.
Thinking about it more this makes more sense for “view specific widgets” - such as a widget which would only be present on a twitter page - so that it doesn’t get lost 3 columns over from the main twitter timeline. This way view specific widgets could also use the same arrow as shown in the minified summary widget.
However with that said we’re still quite early in the design process and we feel that it’s better to try new things and make mistakes now, and in the process possibly come up with new ideas. As it is so quick to iterate (it only took a day or two to create the second iteration) I would still like to push this iteration out and see what comes of it, learn from it, and move on to whatever comes next.
This being the first time I’ve worked on an open design process like this, feels like I’m airing out my dirty laundry for everyone to see, heh.
EDIT: Just also a note about unread counts - The idea here is that the counts on widgets would work in the same way as facebook notifications. Clicking on it would pull up a list of new activity, and at the same time remove the count from your widget. The inflow count would work in the same way as your inbox does now.
A few tweaks to this direction make up iteration 3.1, as posted on the flickr group:
http://www.flickr.com/photos/43332657@N06/4050853425/in/pool-raindropdesign/
This is really looking good, it’s almost exactly what i had in mind when i looked at the second iteration.
Look forward to seeing more ideas from you!
Joshua’s idea concerning collapsable lists sounds exceptionally efficient and approachable to me. This sounds similar to Google Reader - an expansive amount of content users can quickly skim to determine varying value.
Andy: the newest iteration is looking very approachable. Curious about your color decisions, though. Would Raindrop allow users to determine color of the various widgets?
Andy: another thought - is there value in larger photo/movie icons to the right of the content? When a piece of content with an attachment arrives at a user’s inbox, the user generally describes the attachment briefly. I suspect you could save space by using simple, identifiable iconography rather than a thumbnail image.
A similar, though not exact, example of this is Twitter. The vast majority of users wield Twitter as a social bookmarking service: a link with a brief summary/opinion.
Hey Craig,
1. In the end we are imagining that Raindrop would be fully skin-able. For more minor things such as simply changing background colors there might be a add-on or something in the settings to change this quickly. As for now I’m sticking to pastels that are typical to colored bond paper. This isn’t necessarily finalized or anything, but for right now it’s an easy to way to communicate and separate the ideas in the mockups.
2. I think the value in having a larger preview rather than a single iconographic symbol is that it gives you a better preview of what you’re about to open. For example I might only be interested in 1/3 attached images, so it would be nice to open that one specifically right away. Also since the inflow would only provide a brief snippet of the conversation, it’s wholly possible that what is displayed will not describe the attachment yet.
Twitter is a bit different than email in that you will definitely have a full description of the link because of character limit, in which case a small icon might be suitable. Although, the preview might still be nice if you want the youtube description of a video or something.
Ideally, if there were many links in an email, I would like the preview pane to be able to scroll through all the different ones, as is shown with the next/prev buttons in the mockup.