User Centered Design @ MozCamp Beta in Bangalore, India

I just returned from Bangalore, India for Mozilla's MozCamp. Mozilla has an amazing global community and MozCamps are where we come together to learn from one another, and leave prepared and motivated to spread our mission and skills with our local communities. The main focus of this MozCamp was to train our core contributors ("train the trainer") and ultimately prepare them for the upcoming FirefoxOS launch in India.

MozCamp attendees in Bangalore, India. [photo credit: Biraj Karmakar]

The workshop

I collaborated with Bill Selman (Lead User Researcher @ Mozilla) to design a 3 hour workshop that would teach the fundamentals of User Centered Design and give the participants a chance to touch on each step in our research and design process. We covered interviewing users, research analysis, identifying audience and success metrics, sketching ideas, and collaborative design. The process resulted in the teams having a single concept that they feel confident in prototyping further after leaving the session. The theme of the workshop was to "Create an app that helps your community learn about or contribute to Mozilla."  We had 25 attendees (across 2 separate sessions) that designed 10 concepts that I'd love to see in the hands of our community.

* PDF: This was a very hands-on workshop, but feel free to view the slides we used to guide us through each step and keep us on task.

The level of enthusiasm and quality of work that came out of the workshop exceeded my expectations. I learned so much from the community and can't wait to keep working with them, even though we've all gone back to our homes. Mozillians are pros at remote collaboration, but being in person for a few hours and co-designing allowed us to get a head-start on some ideas we've all had floating around our heads and also meet new Mozillian's to collaborate with!

App concepts that help communities contribute or learn about Mozilla

* PDF: View the recap slides to see an overview of the workshop steps and all concepts presented at the end of each workshop session.

 

Project kick-offs and feedback with the Mozilla community

This session had greater value than just teaching the fundamentals of our research and design process. We're also hard at work updating our contribution experience at Mozilla, so this was a great opportunity for Mozilla to hear about what is important to local communities and what tools would help support their needs. Keep an eye out for how the feedback from this workshop and the entire MozCamp has a direct impact on the solutions we implement to improve how you can contribute to Mozilla. I'm also excited to see community-built apps come to life from the workshop concepts. I'd like to kick off more projects at MozCamps and give Mozillians more opportunities to have an impact on what we are working on.

Thank you, India!

It's hard to communicate through a blog post the gratitude I have towards our community of Mozillians and the positive feeling that I have after visiting Bangalore. I left India with many new friends and look forward to coming back soon! Regardless of distance, we can still collaborate, be friends, be makers, and empower each other to make the web a better place!

 

Resources & Links

Thanks to everyone who came to the workshop! A few of you left early to catch a flight, so if you aren’t on this list, please let me know. If you have blogged about the event or your concepts, please share.
@jaipradeesh, @yati_itay, @sushanthiray, @bitgeekypankaj, @manishearth, @darkowlzz, @larissashapiro, @sawrubh, @diwanship, @bird_of_d_dawn, @arunmartin, @spacetime29, @psubhashish, @imasrikar, @abhishek_potnis, @pmjcreations, @ekuttan, @akshayaurora, @grssam, @roysrijib, @_tripad, @saurabhshah, @akshtkedia

 

A new update experience for Australis: our process and design principles

Try it out now in Firefox Beta for desktop!

We’re excited to release a new onboarding experience for users updating to the new Firefox (Australis). We're not just introducing a new design in Firefox 29, but a new way for the web and browser chrome to interact with each other in our onboarding experience.  This will allow us to show, not just tell the users what is new in Firefox and educate them about the browser. With this new interaction we avoid relying on passive viewing of a web page and create a memorable experience that is immersed in the browser. To learn more, see the following blog posts that describe our design principles and process. Also, try it out for yourself now in Beta before it reaches our general release channel and feel free to send me any feedback.


Video of update experience and new tour UI for Firefox Beta users upgrading to the new Australis browser.


5 questions to ask during your design process

Learn how our initial assumptions about educating users became a project dedicated to creating an Update experience for Firefox 29 in 5 questions to ask during your design process.

Introducing the Update Experience for Australis

Learn about the key design principles that stemmed from our research and testing in Introducing the Update Experience for Australis.

Onboarding Tour UI

Cross-team collaboration at Mozilla has been key to creating this experience.  The collaboration spans across teams such as release engineering, web development, marketing, visual design, UX, user advocacy & support, metrics, and others. In just over a year, this project grew from a side project for just a few of us to an in-product experience for our users. Thanks to everyone involved for their hard work and stay tuned as we continue to iterate and improve in preparation for the Firefox 29 general release.

Command & Query: a better filter and search for developers on MDN

The Mozilla Developer Network is in the process of a complete redesign. Findability and readability are 2 important focuses. Visually, we can support this with a cleaner, responsive, more flexible docs template and new styles across the site. Technically, we can support this with our implementation of elastic search and rethinking how we are tagging and providing access to our content.

Implementing elastic search was a big improvement, but what else can we do to support both the discovery of our content and the behaviors of our developer audience? Below, is a UI proposal that I am working on with Jannis Leidel and David Walsh that I call "Command & Query". Also explained are 2 additional levels of implementation. Presenting lower effort implementation options allows us to choose what variation we can implement now (our MVP) given our other priorities, launch blockers, or desire to test certain aspects of this concept, and build on after launch to reach the full design goal. 

 

Command & Query - full concept

The Command & Query concept allows all users the ability to hand-select multiple filters from a drop-down menu while allowing experienced users to type in short-hand commands for specific filters. The search field UI can handle displaying and removing multiple filters that the user has chosen.

Simple UI for entering search term and manually selecting filter type.

Thanks to David (@DavidBruant) and Jesús (@tx2z) for your javascript and front-end magic over our MDN Paris hack weekend. We've made a lot of progress! See demo video below. 

Work in progress. Code prototype sans final styles.

Possible styling for command & query UI

 

Examples of command and filter UIs:

Duck Duck Go allows for a single filter entered by key command or selecting from drop down menu.

GitHub's search UI

Chosen, Harvest's jquery plugin. Also see David Walsh’s blog post about Chosen
http://davidwalsh.name/demo/jquery-chosen.php

The mockup below demonstrates how search query shares the search field with multiple filters and supports 3 levels of user interaction. 1) For users entering a simple search, they can enter their query and search as normal. 2) For users wanting to view and choose from all filters offered, they can manually select from the drop-down menu. 3) For users that are familiar with filter commands, they can type the short-hand command behind '#', directly into the field (hitting enter commits it). '#' indicates that a word is a filter. Words without a # are simply a search term.

 

Advanced user adds filters by typing command in combination with search term.


Iterative Steps 

a. Query, no command - a simple, all visual UI for all user types

In this variation, we still have a visual way for all users to apply filters, but key commands would not yet exist. A query/search term is the only item allowed in the search field in this example. A drop-down menu exists to allow users to select multiple filters. The filters chosen are not reflected in the search field, but are indicated in the drop-down menu itself, therefore greatly simplifying the search field UI for implementation. 

The next steps for this iterative implementation is to add the ability to enter commands via the search field and drop-down menu and represent chosen filters in the search field.. 

b. Command by text - text input filtering only for advanced users

In this variation there is no visual UI for adding or viewing filters. All user types will not benefit in using filters at launch as this would only be a functional prototype to be sure filters are working as expected when paired with a search term. Functionally, the filter commands (a word preceded by #) will be able to be typed into the search field and will be reflected in the search results page, but only for users who know about the filters and what their corresponding commands are. I consider this a functional prototype for filtering itself, but not one that supports all of our users and allows them to benefit from filtering. Our filter commands would not allow for spaces in this example since we are using spaces to separate commands from each other and search terms.

 The next step for this iterative implementation is a visual layer (drop down and "Chosen" style filter display) to support use of filters by all user types.

 

The Command & Query UI offers a more powerful search for all MDN users, while supporting a command method for advanced users to quickly add filtering to a search query. I look forward to seeing how a UI like this can perform with MDN content and the addition of our new styles and templates. If we do not have time before launch to test, get feedback from the community, and implement the full solution, we also have the option to start with the smaller steps shown above.  

The new MDN is being designed iteratively, while users opt into a beta of the site and try out changes as they are released. They respond by filing bugs and giving us feedback via IRC (#mdn) and and mailing lists. MDN does not exist without our community and contributors, and while we are heads-down trying to work as quickly as we can to get the initial foundation of the new MDN built, it is important to balance this with sharing our ideas and getting feedback from the community. Your feedback and discussion is always welcome!

 

A few UX changes. A single page. Millions of new downloads.

We recently designed, tested, and released a new version of our our primary download page for Firefox for Desktop. In our tests, we improved the download conversion rate of the top 3 non-Firefox browsers by over 12%! This alone results in millions of additional downloads annually.

Focusing on the entire funnel leading up to a product download and not just the product itself, is as important as the efforts taken to improve retention of a product. This is one of the approaches that the Websites team at Mozilla is taking to improve and support our products.

What is the /new page on Mozilla.org?

This is where the majority of our desktop browser downloads are initiated. For instance, if the user searches for "Firefox", "Mozilla Firefox", or "download Firefox" from a desktop browser, the /new URL is the top search result.

What did we change?

Though a relatively simple page, we were able to make number of changes across visual design, interaction, technical improvements and overall user experience that had substantial results. How did we do this?
1. reduced the number of steps to download
2. simplified number of actions displayed on page and reduced distractions to funnel user directly to download (ie: no link to Fx for Android or other products displayed)
3. focus on our product - the last page design did not display visuals that focused on the product, but focused more on Mozilla community.
4. significantly faster page load time
5. updated style to our responsive Mozilla style guide
6. inline page interaction that responds immediately to the user's request for download, resulting in no page refresh for confirmation and installation instructions.

Old experience - includes page refresh:

New experience - inline interaction, no page refresh:

* To experience the inline page interaction yourself, visit the Firefox for Desktop download page.

Design decisions & Testing

We could infer that the outcome of changes such as updating this page to a consistent style as our other Mozilla.org pages and improving page load time would have a positive result. However, some of the other changes were more subjective and required testing and validation before releasing to 100% of our users.

Based on common interaction patterns, what we know about how users respond to pages that "feel" responsive to their actions, as well as minimizing distraction, we were able to make many initial design decisions.  To validate the more subjective changes, such as button placement, button style, and animations, we ran A/B tests using Google Analytics Content Experiments.

An important part of testing is not just validating our work, but exposing interesting facts about our users and issues that may need further attention. For instance, we learned that large percentage of users downloading Firefox already have Firefox. This could mean that the user is not aware that we run silent updates, that they are not aware that their version of Firefox is already up to date, that they wanted a fresh copy of the browser, or a number of other possibilities. This is just one of the interesting things we learned that we are looking into for further improvements.

Given the success of these tests, we were very confident in releasing the new experience to all of our users. Our initial improvements to the /new page and download funnel are just the beginning. We will also continue to test improvement possibilities, such as the style of the download button, to learn more about our users and improve the performance of the download funnel.

A few stats:

Across the top 3 browsers, we saw a 14% download conversion improvement.

Across all browsers and operating systems, we saw an average of a 4% improvement.

Considerable improvements to page load time:

  • Time to be able to interact: 46% decrease
  • Time to load page content: 71% decrease
  • Time to execute JavaScript: 35% decrease

[ To see more stats, and learn about our A/B testing process, stay tuned for a post from Chris More. ]

Next Steps:

Testing download button designs / styles, translate page for non-english languages, add logic and conditional messaging for all platforms, improve other touch points within the onboarding funnel by using a similar process of testing and validating with real users.

Mozilla + Design Gym Workshop #3

Our 3rd and final Design Gym / Mozilla Developer Network workshop was held at AlleyNYC. For each workshop we've invited expert guests to participate and add new ideas along the way. For this workshop we were joined by 2 Mozillians (besides myself) from the MDN team. 

Ideate & Present

This workshop is a final chance to work through old & new ideas. It is also time to get away from post-it notes, rough ideas, and defining our audience and problem. We are now past that point and need to start picking concrete ideas and visualizing them. It is as difficult to keep a coder away from coding as it is to keep a designer away from starting to design early in the process. However, by holding off on tangible solutions in the beginning and focusing more on implementation and visuals in the 3rd workshop, our final solutions are more thought through and useful to the problem at hand. 

It is quite a large endeavor to try to solve for everything needed in a site redesign at the end of 3 workshops, so I asked the teams to focus on the 5 familiar topics we discussed in our last workshop. They can then take 2 of their best ideas to visualize and bring to a state that is presentable at the end of the night. 

Solutions

I'd like to post 20 ideas here, since there were so many that could potentially be useful to the MDN community, but I'll stick to a few for the sake of keeping this a readable post.

Symbiotic relationship and benefits to our community: Experts and beginners can do more than instruct and be instructed on MDN. Expert exposure and contribution on all levels to MDN gives us more than credibility and community. It offers us the ability to get our members exposure, speaking gigs for the experts can result in free conference passes for our community, exposure and a closer community can result in funding connections and job opportunities, etc. By reaching out and finding the needs of our community, we can use our exposure and credibility to support these needs in tangible (and appreciative!) ways. 

Friendliness and context: There is so much we can do with MDN by just connecting the dots of our current content and using more personal and useful messaging. This can be done without adding more content. For instance, welcoming the user in a more friendly and functional way: "Welcome, Luke! There are 2,100 other designers here!" This message highlights activity and also makes being a designer (and possibly new coder) at MDN  not feel quite so intimidating. It gives the user a sense of context of where they are in the community. 

Alive and human: "Make it feel active and human" was a quote that came out of this workshop. MDN currently feels like only a directory for developers. You don't get a sense of activity and the types of users present or the discussions happening in the back-channels, code demos being postes, etc. All of this content and activity already exists. Why doesn't the homepage reflect how alive our community is? We should highlight these activities on the homepage and throughout.

There is more to teaching code than diving into code itself. Many methods of learning require a lot of work and actual coding to learn the how and why of things. The following examples will be helpful tools to teach beginning users about scope, how code effects your outcome, and how all pieces of the puzzle fit together. 

Visualize how it's built: Show a bird's-eye-view diagram of all the pieces that go into creating a particular example. Show the user all parts of the process (Git, text editor, database, content creators, etc). Show this in context of large and small familiar examples. How do Amazon and Pinterest work? How does a simple Tumblr blog work? 

Backwards engineer: I've found that one great way to learn about how a machine works (especially any electronics) is to take a part away and see what happens. If we can show the user a finished website and allow them to take away the CSS, take out the dynamic pieces, etc one at a time with a simple toggle, we can teach by backwards engineering and show them the direct effect of each part of the whole. The user is learning about the code before diving into a code editor.

Extras: Profile driven experience, more action-oriented homepage, add lower-investiment (passive consumption) items, focus on the users and their activities across MDN, "novices only know what they want in the end".

Thank You!

Besides being a fun and extremely valuable set of workshops, I met a wonderful group of enthusiastic and smart people. They were willing to meet up in NYC in the evenings, somehow still full of energy, after a long day at work or school to learn about design process and our Mozilla challenge.  I definitely recommend working with the Design Gym and their group of "solvers" . Looking forward to working with them again!

Mozilla + Design Gym Workshop #2

Our 2nd Design Gym / Mozilla Developer Network collaborative workshop was held at Parsons last week. Besides our regular group of participants, we invited students from the MFA Design and Technology program to join us. Their insight (and enthusiasm!) was really invaluable to the evening. 

Understand

Now that we've had a chance to get to know our audience and get introduced to the problem at hand (see workshop #1 post), workshop #2 continues to further deconstruct and understand. We do this by focusing more on specific topics and hypotheses and applying them to a number of design models. (i.e.: 2x2 Matrix, Empathy Map, Journey Map, etc - see images for examples)

Topics

The topics I asked the teams to focus on are as follows:

  • Trust
  • Communication
  • Continuity
  • Functionality
  • Notoriety

What we learned and assumptions to start designing for

Experts and beginners have a symbiotic relationship

Beginners tend to need more structure and experts, less structure

Some learners don't realize that they can teach and have worth in the community

There are competing and corresponding elements in the same environment:

- Structured vs. Unstructured

- Beginner vs. Experienced

- Solo vs. Community

- Contributor vs. Reader

- Linear vs. Non-linear

3 ways of presenting content:

1. pre-packaged & syllabus 

2. with expectation and context ("when you are learning, you need to know where your north star is")

3. choose your own adventure

Continuity and connections between our content will lead to better collaboration among the community as well as a better understanding of all that MDN has to offer. 

Questions to explore further

How do we allow intimidated users to feel welcome in the community?

Experts are more likely to play and take risks - how can we draw the same behavior from others?

Why should an experienced coder help a beginner?

Why should I return to MDN?

Mozilla + Design Gym Workshop #1

moz_DG.png

Workshop

Mozilla has teamed up with The Design Gym to hold a 3-part workshop here in NYC. What I think is interesting about The Design Gym process is that it's sort of a hybrid of a design workshop and community discussion since the audience present has some relation to the problem we are trying to solve. We had a great 1st workshop and I'm looking forward to getting farther through the process. 

Workshop #1: Kick-off & Examine 

Workshop #2: Understand 

Workshop #3: Ideate 

Problem Overview

We're using the following problem as the subject of the workshop: We are working on a redesign of the Mozilla Developer Network. We have an excess of valuable content, code demos, code challenges, a large and dedicated community, and a common goal of supporting the open web. We also can offer content and participation on a global scale, in many languages. At MDN you can be at the beginner level and learn from the community or contribute your skills to Mozilla. The key issue is that this content is currently presented and organized without the community in mind and the way they would use MDN as a resource. Developers & Designers are the MDN community, and the experience should reflect how they would use it.

Goal of Workshop #1

  • Introduce the Design Gym teams to MDN's challenge / brief
  • Gather a wide array of data from relevant users

Experts & Participants

We held our first workshop at TechStars where we welcomed TechStars members to join us. Among them were technical and creative founders, as well as former Google developers. We had a great mix of beginners, self-taught experts, and designers who would love to improve their coding skills.

Thanks to MovelineMarquee, and TechStars

Excerpts from: quotes and ideas

"Part of learning how to code is just learning how to learn. "

"Efficiency and good use of time is key. I trust Stack Overflow with this."

"I need to trust the community I am going to and spending time at."

"I make a conscious decision between just looking all the time for a coding answer and trying to remember." (He decides when to use Google vs. trying to keep it all in his brain for recall)

" I would get to MDN and leave if I came to the homepage.There is no on-boarding. I need to be helped immediately or told how I can contribute."

"Can we be the Dribbble for code?" (similar to a GitHub profile, but with the demos you've posted and list of what you've contributed to)

"Collaboration is so easy for the advanced user. It's very difficult for the novice user."

Excerpts from: take-aways

  • There is tension between providing knowledge for knowledge sake (i.e.: a glossary of terms) and knowledge for specific problems. (i.e.: "how to solve X") 

  • We need a method of measuring our trustworthiness. (see: Stack Overflow)

  • We saw a mix of those who want to start with fundamentals and definitions and build from there and those who want to start with a specific problem to solve. In this group of participants, the former is method of choice from those that are developers as their key roll and the latter came from the visual learners in the room.

  • Participants wished there was a syllabus or a timeline from novice to advanced when learning something new, so that there was some context of a typical learning progression. 

  • There was a discussion about how as a developer you need to "game the system" in order to find the answer to your coding issues. You have to figure out how to navigate through search results, wikis, and forums to answer your questions. It's hard to harness that and is part of the learning curve for beginners (part of "learning how to learn").

  • There was a general theme of wanting to be self-sufficient, but enjoying collaboration and learning from each other - this doesn't necessarily have to happen with an in-person community. 

  • There should be constant cues to be involved and collaborate throughout MDN. (i.e.: When you are watching the Demos, there is no call to action to create your own or edit a wiki)

  • More guidance needed from homepage for the different types of users coming to the site, from methods of learning to methods of contributing and collaborating.

Questions coming out of Workshop #1

  • What is the most common task at MDN right now?

  • How do the code challenges bring developers back? (email, promotion on MDN, promotion elsewhere)

  • How did current MDN members first learn about MDN? 

Wander Sign In / Up Flow Challenge

While in NYC, I’m taking the chance to work with a couple of startups in the Techstars program.  One of these companies is Wander.

 

Wander won’t be launched for a few more weeks, but until then, you can check out the Wander blog and start participating in Wander Weeks while anticipating the beta launch.

tumblr_m3t9mrsjrB1qay3ql.png

When initially approaching the sign in and sign up flows I thought it would be similar to sign up flows I’ve approached before. However, there was a key element to their pre-beta sign-up that made a unique solution necessary.

For the past few months, you could sign up to be notified when Wander launches, but also reserve your Wander name. In this process only a username and email were captured, but no password. This is great for lowering the conversion barrier and having a friendly way to capture user emails, but produces another use case to account for when launching.

The effect of this key anomaly is that at the time Wander Weeks is released (and any time thereafter) we could have 3 types of users:

tumblr_m3roc4wqfH1qay3ql.png
tumblr_m3rockyKxy1qay3ql.png

We needed a way for all 3 user types (when I say “user types” here I am only referring where they are in authentication and not personas) to enter Wander, and handle the odd case of the user who has entered their email, but not yet provided a password. The one variable that all users need to or have already entered is their email. So, the solution is to first have the user enter their email. This essentially acts as a key to tell us which door to open next. Once we determine if the email is known or unknown to us, we then know how much information we already have from the user, and therefore know which fields to populate next. (enter password you have already defined, or enter a new password for the first time). Another benefit to this flow is that we do not have to bring the user out of the experience and to their email to confirm, resulting in a lower drop-off rate. For the few to none cases where users attempt to enter another user’s email before they have defined a password (see 50% user type), we allow the user to reset their password and confirm any changed passwords via email or contact us directly to monitor what happened.

Stay tuned for the full Wander release. It’s an exceptional team and I’ve had a lot of fun working with them.

Mozilla: Push Notifications Survey Results

 I sent out a quick survey to get a general idea of how people both use and feel about notifications. This includes methods from mobile push notifications to Growl style desktop notifications, notifications triggered by content, and perhaps system notifications as well.  Knowing separately how developers implement and end users consume notifications is also important, but we can consider how to gather user-type specific patterns in another survey, personal interviews, or by observing use.


42 people responded to the survey and a majority also left additional thoughts at the end of the form. I was pleasantly surprised at the effort put into the additional thoughts as it allowed this general form to give us even more information than intended.

Here are some points you might find useful, but click through the images to see for yourself:  

  • Receiving a notification for interactions with personal accounts or the user’s own content was most favorable. 78.6% of survey takers like notification for replies, comments, or shares from sites like Twitter, Facebook, Tumblr and 57.1% for Twitter follows or Facebook friend requests. Calendar events were also noted several times in the “other” field. (see image)
  • Most users want to be notified immediately when content becomes available. (see image) However, some noted that while they would like immediate notification for direct and personal communication, for non-personal or non-time sensitive notifications they would prefer it to be occasional.
  • 50% of people want notifications on both mobile and desktop. A combined 40% noted a preference for either desktop or mobile. This is an incentive to focus on improvements for multi-device/platform notifications.

The many thoughts provided in the open field at the end of the survey were especially helpful. I could post 20+ but here are a few from recipients, content creators, and developers:
“As little battery drain as possible on mobile devices. “

“When pushing notifications to multiple devices, it bugs me when clearing the notification on one doesn’t cross all devices.”

“This would be really useful for development-related things where I want to be notified while I’m around doing development because it helps the team keep in sync. Currently we use IRC for this, but IRC clients aren’t very useful on mobile devices and it might be nice to keep in sync without having to be on IRC where I’m pesterable.”

“Like most people I am addicted to them so its a love hate relationship. Would be nice to be able to very easily turn them off if I wanted to escape for a while”

“They should be contextual to time/location. Or, in other words, adherent to which ‘mode’ I’m in: working, relaxing, hanging with friends, etc.”

“I love them because, they keep me on track of my activity being it personal or professional.”

“As an author of several web services, it would be nice to have a better format than email for sending such things.”


In general, it seems as though notifications discussions trigger a very personal response. Not surprising, transparent intentions from content sources, ability to manage output, and the need to be in control, is the overall tone of the feedback. Users love notifications when appropriate, helpful, and not intrusive of personal time and space.

Thanks so much to those who took the time to complete the survey and write an additional response about their personal uses and ideas to make being notified a better experience. We really appreciate it!

The survey is still up. Take it yourself, here.

Firefox Notifications is a project I have been working on with @jeffbalough at Mozilla.

Firefox notification add-on update

While I don’t consider myself a visual designer, I felt that mocking up something more visual than wireframes would help to get feedback from a wider audience. For our prototype we will stick to a very minimal visual design.

 The first mock-up is quite minimal and text-focused.

 


The second mock-up both uses the dominant color in the favicon/source icon to better visually differentiate the source content. It also shows how we could use content from sources like LastFM and Linked in and potentially use the visual assets offered for different post types. You can see a music event recommendation, message from a LastFM friend, or notice from a LinkedIn group.

 

 As I mentioned, the colors used in the second version are taken from the dominant color of the favicon (or if we have a default icon for common social sites). Chrome does this in their home tab. Etsy and Dribbble also use this method for searching by color. Example:  http://lokeshdhakar.com/

We have also set a few requirements to keep the prototype simple as we test with a few content source types. As we gauge the volume of content displayed and expectations for viewing this content, we may need to revisit these rules once again.

 Our take on the prototype is that this is timely content. This is not a service like Delicious or Evernote where you keep links that you want to revisit. If we offer an archive, this becomes a different kind of tool than intended. For now, we have set the following to keep the “what you see and when” logic simple:

1. Items shown are from within the past 24 hours.

2. Maximum height of panel extends to height of browser. (not demonstrated in visual design) After which, a scroll bar is displayed. Edgecase: If the user has (i.e.) 50 items to be shown from 10 sources, we should consider a rule to show x items from each source with a “x more” indicator to expand all. It is important that the user can see as many sources as possible and the most recent items from these sources. The user shouldn’t have to scroll excessively to see hidden sources in the bottom of the panel.

2. Delete item from view when it is ‘read’. ‘Read’ is defined by the user clicking on link/button within item.

3. User explicitly deletes single item from view by clicking the ‘X’ icon. (“Are you sure?” verification not needed for single item)

4. User explicitly deletes all items from a source by clicking the ‘X’ icon. (“Are you sure? This will delete all items from this source” verification needed)

5. If an item has not been seen since panel was last expanded, it can have a 5% opacity background of the dominant hue. (as shown in attached screenshot of more colorful mock-up)