With over 140 RSS feeds now in my blogroll, it takes me around 2 hours a day to consume all of the info that is published…and most of that is just skimming to pick out the information I want to heavily digest vs. the info that doesn’t matter so much.

RSS allows us to consume more information faster than ever possible before. I even believe that RSS will increase the rate to which we evolve as a race. The downside of this is information overload. With all of this information at our fingertips, how can we possibly filter the important from the not-so-important? Marshall Kirkpatrick (former writer for Tech Crunch) gives us some insights to how he manages thousands of feeds with ease (I’ve added a couple tips of my own as well)…

Use a start page

Marshall suggests using a startpage that can be glanced at every couple of hours that gives you a high level of what’s new with items you’ve marked as a high priority. The new google reader provides a nice start page that I sometimes use. Alternatives include Original Signal and Page Flakes.

Preview New Feeds

I think its a good idea to preview new feeds that you subscribe to. This helps keep them separate from other feeds you’ve deemed as important and reliable information. You can do this by creating a “new feeds” folder or just put them at the root level of your feed reader. Once you’ve deemed your new feed as one you want to hang on to and read regularly, you can them move into the appropriate folder or tag.

Organize your feeds

This one is pretty much common sense…but common sense is not always common practice. I am constantly re-structuring and optimizing how all of my feeds are organized. At one point i had an “internet” folder, but now its necessary for that to be broken out into 4 or 5 folders. Marshall advises that with thousands of feeds, it helps to separate your feeds by priority so that you can quickly access the more important information.

High priority sources

I’ll just quote this one (note the last sentence in bold :)…

“The single most helpful tool for me in my efforts to blog about news events first has been an RSS to IM/SMS notification tool. I use Zaptxt to subscribe to very high priority feeds. It sends me an IM and SMS whenever a high-profile company blog is updated and in a number of other circumstances. There are quite a few services that offer this functionality now and it’s invaluable. A big part of taking a prominent position in the blogosphere is writing first on a topic. That’s a large part of what got me the job at TechCrunch and it’s something that an increasing number of people are clearly trying to do.

In sectors where people are already using tools like the above, I expect further developments to emerge that differentiate writers’ handling of the huge amount of information available. New tools and new practices. It’s a very exciting time to be someone who works with information.”

Do you have any tips to share? Let me know!

Like all forms of usability testing results, eye tracking gives us good clues into user behavior, but it certainly shouldn’t be taken literally. Testing results are merely insights into problems and their solutions…and I prefer to treat them that way. Heck I’ve observed many testees that do the opposite of what they say…which is really just part of human nature when it comes to using things vs. explaining how you use them.

One of the recent and big studies to come out this year was the Poynter Institute’s “EyeTrack III” 2004 Eye Tracking Study. This is the third eye track study conducted by Poynter since 1991.

Here’s what Poynter has found from their eye tracking studies relating to website content usability, page layout, navigation and design: (along with some great comments from Frank Spillers below each finding that are good examples of how one can interpret the data):

1. Users spend a good deal of time initially looking at the top left of the page and upper portion of the page before moving down and right-ward.
Comment: Another thing to think about is how this user behavior mirrors search engine traffic (i.e. Google Bot visiting your site). Search engines read starting at the top left, and then downward in a left to right column fashion.

2. Normal initial eye movement around the page focuses on the upper left portion of the screen.
Comment: Not surprising when you consider that users are patterned by all the other software and websites that they use which have a standard menu start point (e.g. File, Edit, View…). Note: For Japanese or Arabic it would be the mirror reverse.
3. Ads perform better in the left hand column over the right column of a page.
Comment: The right column is treated by users as an “after-thought” area and should be designed with that in mind.

4. Smaller type encourages focused viewing behavior.
Comment: This is especially true in older or elderly users. For the rest of your users, stick with 9-12 point Sans Serif (Arial, Helvetica, Verdana) with an average of 10-11. FYI: Only developers appreciate miniature fonts!

5. Larger type promotes lighter scanning.
Comment: Most reading behavior consists of skimming and scanning. If you want to slow your users down- use smaller fonts in the body of your content. Use larger fonts to help them cover more territory.

6. Dominant headlines most often draw the eye first upon entering the page- especially upper left of the page.
Comment: Remember, Poynter’s focus was a newspaper website. However, bear this in mind for portal type design and intranet design.

7. Users only look at a sub headline if it engages them.
Comment: So make sub-headlines relevant and of course make them the keyword phrases users and search engines use.

8. Navigation placed at the top of a homepage performed best.
Comment: Again, if you understand how users are patterned by other tools they use (Word, IE, Outlook Express)- the goodies are at the top of the page.

9. People’s eyes typically scan lower portions of a page seeking something to grab their attention.
Comment: This seems consistent with “Information Foraging Theory” where users are said to hunt for information by “scent” or navigation and content of the highest value to them.

10. Shorter paragraphs performed better than longer ones.
Comment: Attention is clipped on the Internet. Short bursts of attention are the environment you are designing for at all times. Note: Longer product descriptions do better than shorter ones in ecommerce situations. As with all usability findings, context is key.

11. The standard one-column format performed better in terms of number of eye fixations.
Comment: Most users are overwhelmed by the average web page that they try to deflect information as a coping strategy. It is the same phenomenon that occurs at a party when you focus on one conversation and ignore the other conversations around you by categorizing them as “noise”.

12. Ads in the top and left portions of a homepage received the most eye fixations.
Comment: Interesting, but I wouldn’t recommend putting ads there. *Just because they receive eye fixations doesn’t mean they put a smile on the user’s face*. This is one of the main points of this article!

13. Close proximity to popular editorial content really helped ads get seen.
Comment: One of the golden “rules” of usability is that anytime you satisfy the user’s task (interest, goal, objective), you increase the likelihood or create the conditions that they will be open to other stimuli (advertising, cross-selling etc.)

14. Text ads were viewed mostly intently of all types tested.
Comment: Text ads are popular because they are less distracting, camouflage well with the page and are often not known to be ads and therefore annoyances to the user. Oh, and since Google “pioneered” them- they are the de facto standard in effective web advertising.

15. Bigger ads had a better chance of being seen.
Comment: Also repeat advertising on a page by the same company is being used on many sites to reinforce exposure.

16. The bigger the image, the more time people took to look at it.
Comment: Using larger images (file sizes) is easier these days since 20% or more (USA) are on high speed connections, but using thumbnails with large images is always a safer bet.

17. Clean, clear faces in images attract more eye fixations on homepages.
Comment: Humans are wired to recognize patterns and hard wired to other human faces.

18. Higher recall of facts, names, and places occurred when people were presented with that information in text format.
Comment: Good recall depends on the level of relevancy, good copy-writing and content usability (structure and display).

19. New, unfamiliar, conceptual information was more accurately recalled when participants received it in a multimedia graphic format.
Comment: It is known in the field of cognitive science that the more emotion involved in a learning transaction, the higher the retention and recall.

20. Story information about processes or procedures seemed to be comprehended well when presented using animation and text.
Comment: And the animation or text must be clear, easy to understand and in the language or conceptual world of the audience.

Wireframes never really cut it for me. Creating static diagrams of very dynamic sites make it difficult to articulate interactions to developers…normally requiring hand-holding to ensure things are built as designed. Developers loooove hand-holding.

Before I start a new project I normally interview the developers that I’ll be working with and ask them what they expect from my prototypes in order to do their job the best they can. Most tell me that they want everything defined to the point that there is no question what needs to be built. (Personally I prefer working with developers that have more of a hand in the design so that they’re engaged and accountable for what they’re building…but thats another article). With today’s tools (like visio), this is difficult to achieve.

We need more from our prototypes…they still need to maintain lo-fidelity and rapid development, but need to contain all the interactions and work like the final product.

Welcome to the world of Simulations.

Simulations were originally used by Boing to test drive features of the 777 before they were actually built. In the same way, they enable us to build a web application that we can test drive (and usability test!) before we build the final product. They allow us to create working tabs, forms, error handling, and can even make global changes.

Boxes and Arrows recently posted a comparative review on various simulation tools available today…

Axure RP4

The latest version, RP4 (there is actually a Beta of 4.3) has certainly added a number of new features compared to RP3. RP4 provides the ability to create a basic sitemap (indicating pages) and the ability to link these pages together. RP4 offers masters for rapid changes to an entire project. RP4 allows for basic annotations but doesn’t offer a robust requirements management solution. Of the products reviewed, Axure RP4 falls in the mid-range for pricing. With the addition of a true simulation engine, this RP4 could certainly gain ground against the higher-end products. However, at its current price, it’s a great entry point into the world of simulation.

Scenario Design: No
Page Design: Yes
Widget Library: Yes
Dynamic Display: Yes
Data Interaction: No
Decision Logic: No
Annotations: Yes
Centralized Server: No
Portable Distribution: No
Requirements Management: No
Enterprise Support: No
Export to MS Word: Yes

LucidSpec

Much like Axure, LucidSpec offers the capability to create static “prototypes.” The product does not contain an actual simulation engine, thus limiting the product’s ability to save and reuse data at a later time. The product allows the design to “describe behaviors” or specifications in annotative form. However, it does not offer a solution for tying a non-visual requirement to visual elements.

Scenario Design: No
Page Design: Yes
Widget Library: No
Dynamic Display: Partial
Data Interaction: No
Decision Logic: No
Annotations: Yes
Centralized Server: No
Portable Distribution: No
Requirements Management: No
Enterprise Support: No
Export to MS Word: Yes

iRise

iRise offers a real simulation engine that allows users to save, edit, and delete requirements data. Of the products reviewed, iRise Manager provides the most comprehensive requirements management solution. Studio generates a portable simulation known as an iDoc, which can be reviewed with the free iRise Reader. Shared Server enables collaboration and incorporates a model for check-in/out capabilities and synchronization with the requirements management server. The shared server also provides an alternative delivery method, allowing stakeholders to view the simulation by accessing a URL. iDoc Express is a cost-effective service offering, where companies hand over requirements and receive a comprehensive simulation at a fixed price. No product purchase or installation is required. This is by far the most mature product in this space, with the most extensive list of recognizable customer names.

Scenario Design: Yes
Page Design: Yes
Widget Library: Yes
Dynamic Display: Yes
Data Interaction: Yes
Decision Logic: Yes
Annotations: Yes
Centralized Server: Yes
Portable Distribution: Yes
Requirements Management: Yes
Enterprise Support: Yes
Export to MS Word: Yes

Serena Composer

Composer fits at the lower end of the higher tier products. It offers the ability to model business processes at a very high level much like MS Visio. It then extends that ability to creating activities and detailed page designs. Composer provides greater support for requirements management; it is probably closer to iRise than any other tool. The challenge with Composer is that all users must own a licensed seat to view anything created within the product; this really limits the ability to share with stakeholders.

Scenario Design: Yes
Page Design: Yes
Widget Library: Yes
Dynamic Display: Partial
Data Interaction: Partial
Decision Logic: No
Annotations: Yes
Centralized Server: No
Portable Distribution: No
Requirements Management: Partial
Enterprise Support: No
Export to MS Word: Yes

Enterprise Simulator

Simunication is all web based. This is most likely the product’s biggest advantage over some of the lower- and middle-tier applications. Its interface, however, is quite cumbersome for the non-technical user. It offers the ability to simulate data through a scaled-down simulation engine. The workflow is driven primarily by creating use cases, then designing screens around those cases. Delivery is simplified by its all-online approach—thus anyone with a web browser can access it.

Scenario Design: Yes
Page Design: Yes
Widget Library: No
Dynamic Display: Yes
Data Interaction: Yes
Decision Logic: Yes
Annotations: Yes
Centralized Server: Yes
Portable Distribution: No
Requirements Management: No
Enterprise Support: Yes
Export to MS Word: No

Sofea Profesy

Profesy is comparable to Composer in product maturity. It offers requirements management with a scaled-down simulation engine. Much like Composer, there isn’t an easy way to distribute the simulation outside of the tool/editor in which it was created.

Scenario Design: No
Page Design: Yes
Widget Library: No
Dynamic Display: Partial
Data Interaction: Partial
Decision Logic: Yes
Annotations: Yes
Centralized Server: No
Portable Distribution: No
Requirements Management: Yes
Enterprise Support: Yes
Export to MS Word: Yes

Benefits to the user experience professional
User experience professionals who leverage simulation technology are able to visualize projects much earlier within the development lifecycle, while producing requirements that are much clearer than those generated through traditional requirements gathering processes. In fact, two of these packages, iRise and Serena, were actually created to help business analysts visualize requirements when they didn’t have access to user experience professionals for that part of a project!

One key feature that static wireframes lack is the ability to interact with the interface; by using a simulation tool, this limitation is removed. Software interactivity and ease-of-use, in addition to the portability and reusability of the simulation, are key points to consider in choosing the right simulation software for your company. The next several years should be quite interesting as each of these products continues to improve, adding new features and offering tighter integration with third-party products.

I recently posted about the Netflix recommendation system and their reaching out to make it better. I also mentioned how I think that Netflix is one of the best examples on the internet of a site that is both beautifully designed yet very usable.

User Interface Engineering took a deep look into what makes Netflix such a great site by talking with the Netflix design team.

Here are some insights to their “Release early, release often” mentality…

Benefits of Fast Iterations

• Fail Fast
  A major benefit of fast iteration is you also fail fast. Failing fast means you invest less time in the things that don’t work. If you quickly find out what works and what doesn’t work, then you take action to turn it into something that does work.

  Ironically, teams that fail fast improve as fast, if not faster, than those who try to get it right the first time. The reason is simple: Teams trying to get it right the first time fail as often as everyone else does. However, when they fail, they fail really slowly and struggle to pinpoint problems because they’ve changed so much at once, making it harder to identify solutions

• More Experimentation
  The faster you fail, the more experimentation you can do. You can try out ideas that might not have a lot of support, but could be potential winners. This allows for an innovative environment.

  Perhaps you’ve heard of Google’s 20% time? They expect their engineers to work 20% of their time on a personal project — an experiment they find personally interesting. This program has the effect of bootstrapping experimentation, so it will happen more often.

• Learn Quickly
  We’ve all had the experience of sitting in meetings arguing whether something will work or not. Usually, both sides just don’t have enough data to go on, and they end up going with their gut or with the loudest arguer (for better or worse). Fast iteration helps solve this problem by giving developers a platform on which they can test quickly, helping to collect data about any outstanding questions instead of resorting to opinionated arguments.
• Provide Continuing Interest
  In addition to improving your design, fast iterations may have a psychological effect on users. Those users who use your app with any frequency will notice the changes, and if the good ones stick, they’ll appreciate your ongoing efforts to improve.

  The best teams not only design the changes, but design the process for introducing the change. They experiment with methods to overcome the users’ natural resistance to change, providing migration paths and clear benefits for each improvement.

• Reduced Risk
  Quickly iterating helps reduce risk during design. If teams can make many small changes instead of a few larger ones, they mitigate risk because they know which changes have what effect. If a design team makes many changes at once, they have a harder time knowing which parts work and which parts don’t. When you make only one or two changes at a time, you know immediately what effect it has. Reducing risk is a valuable outcome of moving to fast iteration.

Side Effects

These benefits don’t come easy. There are significant changes design teams have to make to their core process to iterate quickly. It’s not a switch a team can turn on or off.

• Culture Change
  Most designers are accustomed to long release cycles. Fast iteration and fast evolution of design creates a different kind of design environment. Gone are the grand visions of the redesign, where teams spend months retooling vast areas of the site. Replacing it is the idea that the site is a living, breathing design that needs constant care and attention. The team at Netflix calls themselves “compulsive data wonks”. They rarely dream very far in the future. Instead, they’re concerned with what’s happening right now.
• Design Determinism
  When teams make the switch to fast iteration, it changes the site’s testing methodology. Testing becomes ongoing. After a release, you test for a certain period of time to determine what to keep and what to throw away. Then you start the process over again immediately. And repeat.

  To some designers this sounds overly deterministic: Doesn’t this take the fun out of design? If all the decisions are cut-and-dried, what does that say about creativity? What about longer-term effects? Is it possible that some features take longer to catch on than others, and that an early flop might not mean it’s not a valuable feature? With fast iterations, if the feature doesn’t work now, then it’s not right for the site, no matter how creative it is.

• You’re Either With Us…
  Netflix’s Chief Talent Officer, Patty McCord, told us their process of fast iteration causes uncomfortable situations for some designers. Once, a designer had spent time and energy working on a feature that testing showed didn’t work. When it came time for the team to remove the feature from the site, the designer was distraught. He had become too emotionally invested in his design, and it got in the way of his job. He ended up parting ways with the team and moving on. Unfortunately, the process of fast iteration affected more than the product itself.

Adobe announced that they will donate their virtual machine software to Mozilla, to work on as an open source project. Mozilla will use it within Firefox (by the first half of 2008) and Adobe will continue to use it in Flash Player 9. The name of the open source project is Tamarin and it will be governed and managed by developers from Adobe and Mozilla. News.com calls it “the largest code contribution yet to the open source Mozilla Foundation”. As Kevin Lynch, chief software architect at Adobe, told news.com: the move furthers the company’s plan to allow developers to mix and match programming technologies, including AJAX-style Web development and Flash for media and animation.

I foresee this as a bold move to the inevitable…making photoshop, flash, and dreamweaver web applications. Its a ways off, but I think that eventually all applications will be web-based. Heck, computers will likely end up being just an internet host…and all file management will be hosted (and backed up!) online.

Now in its second year, we celebrate world usability day today. This day is meant to bring more awareness to our professions, and to making things, well, more usable.

I encounter websites, applications, and material things on a daily basis that aggravate me how difficult they are to use…which in turn inspires me and gives me hope for the future of usability. Theres a lot of work to be done!

With that, on pretty much the worst day for this website to go down, the world usability day website displays a bunch of code. I’m guessing this is not the intended display. Woops!

————

UPDATE: The World Usability Day website is now back up and working beautisly.

UXmatters performed an eye tracking study on forms and label placement. The results conclude that non-bold text above the field and left aligned pose the least amount of eye work, hence a faster and easier user experience. Drop-downs should only be used when necessary and placed below the more important fields. Placing the label as the default option in the drop-down performed better than a label above the drop-down menu.

Here are the conclusion bullet points from the study:

• Label position—Placing a label above an input field works better in most cases, because users aren’t forced to look separately at the label and the input field. Be careful to visually separate the label for the next input field from the previous input field.
• Alignment of labels—In most cases, when placing labels to the left of input fields, using left-aligned labels imposes a heavy cognitive workload on users. Placing labels above input fields is preferable, but if you choose to place them to the left of input fields, at least make them right aligned.
• Bold labels—Reading bold labels is a little bit more difficult for users, so it’s preferable to use plain text labels. However, when using bold labels, you might want to style the input fields not to have heavy borders.
• Drop-down list boxes—Use them with care, because they’re so eye-catching. Either use them for important data or, when using them for less important data, place them well below more important input fields.
• Label placement for drop-down list boxes—To ensure users are immediately aware of what you’re asking for, instead of using a separate label, make the default value for a drop-down list box the label. This will work for very long lists of items, because a user already has the purpose of the input field in mind before the default value disappears.

Communicating design ideas is one of the most important skills that a designer or information architect can have. Lets face it, to be a good designer, you also have to be a good seller. You could have the best concept in the world, but unless you can clearly articulate why its the best concept in the world to your stakeholders, it will never see the light of day.

For most of us, these skills don’t come naturally…they are developed from experience and discipline. Here are a few tips that can help you develop these skills (with a few excerpts taken from the Cooper newsletter)

Have a good story to tell

Human beings think in stories, and contextualizing the proposed design solution with a story helps your collaborators imagine what the eventual user experience will be like.

Only put as much detail into the design as the idea or concept allows.

It is harder for people to evaluate high-level concepts when their eyes and attention are drawn to the multitude of details. It helps to use Lorem Ipsum for your text, a low fidelity sketch via Visio or PowerPoint, and fake data. This helps people only focus on what’s important to you. Make sure to constantly stress that its a “high-level concept” to keep people thinking the same way about it as you did when you created it.

Get all the decision-makers together in the same room

I cant stress how important this one is. Walking a design around to different stakeholders individually will get you completely different results than if everyone is in the same room together…normally causing endless tweaks to your design. Unless everyone can be there, I would highly recommend you re-schedule for a time that works for everyone. Though it may delay approval a bit, it will save you time and decrease iterations.

Carve out time in the schedule for design communication

Communicating design does take time, no doubt about it. But it will save a lot more time by reducing the thrash that occurs when developers don’t have a clear understanding about what it is they are supposed to build. Get developers involved early in the design process…their input is invaluable.

Here in Denver, the voting process was quite a mess. New digital voting machines were in place, and in many locations it took 2 hours of waiting in line to cast your vote. Lots of people did not get to vote because they were pressed for time and couldn’t wait that long.

I voted early and did not feel the effects of this problem. I felt that the voting system was efficient, and the voting machine was extremely easy to use (granted that i am a tech savvy geek).

The voting process as I experienced it:

Check-in: 5 Minutes

There were 2 booths. At the first booth I signed my registration card in front of an election official. I then brought the card to another booth where someone scanned my card and typed some stuff into a computer. She then handed my card to a person next to her that typed some more stuff into another computer and then printed my voter access code for me to use at the booth.

Voting Machine Training: 5 Minutes

The assistant educated me on every detail of how to use the voting machine and what i will expect for the review and submission process.

Voting: 5 Minutes

I then went about casting my votes. Once i was done, i hit a big red button to submit my votes. I then came to a review page, where i could go back and make changes. Once I reviewed and approved the review pages, my selections printed out on a device next to the machine, and the machine asked me to verify each page of the print outs. I could also go back and make changes there. I then came to a screen that was the final, final, final page and said clearly that once i hit that red button again, that was it. I hit it and walked out.

Factors that are more likely to have caused the long voting lines:

• This time there were only 50 or so voting places in CO, last time there were well over 100.
• The ballot was the 2nd largest in history
• Many voters are not computer savvy, so the learning curve was likely more steep for them

The voting machine interface:

The voting machine interface consisted of a numerical pad (to input your 4-digit voter access code), a knob-wheel (to scroll though the ballet and highlight a candidate or Yes/No answer), a select button (to select/deselect your choice), and a “cast your vote” red button for the final submit. I was given 3 chances to review my selections and edit to ensure accuracy. The digital screen was very large and extremely easy to read.

I am curious to hear from some of the volunteers that dealt with all of the voters to see how people struggled with these machines…thats where I would start to troubleshoot the problem. The mayer has vowed to ensure the problem never happens again.

UIE has released a new e-book, “The Designer’s Guide to Web Applications“, and as a promotion for the new book, they have released the first chapter (10 pages), “Structure & Flows” for free as a pdf.

The free chapter explains how to use Hubs to help architect an application structure.

Table of contents (the italics section is free):
1 Skeletons …………………………………………….1
1.1 The Hub ……………………………………………2
1.2 A Hub With No Data ……………………………5
1.3 The Interview …………………………………….7

2 A Real Application: SupportSuite …………..9
2.1 A simple hub and spoke—or is it? ………..10
2.2 An interview appears! ……………………….12
2.3 Hubba hubba …………………………………..13
2.4 A hub for hubs …………………………………16
2.5 Finishing touches………………………………17
3 Revealing Structure in the Design ……….19
3.1 Tabs ………………………………………………21
3.2 Menus ……………………………………………23
3.3 Tab Menus ………………………………………26
3.4 Breadcrumbs ……………………………………29
3.5 Links ………………………………………………32
3.6 Titles ……………………………………………..36
3.7 Progress Indicators ……………………………37
3.8 Knowing which element to use …………….39
4 Designing the structure ………………………40
4.1 Command Architecture ………………………40
4.2 Seeding the structure …………………………41
4.3 Enter the users …………………………………42
4.4 As we learn more, more changes ………….44
4.5 There are many possible structures ……….48
5 Creating a Winning Design ………………….49

Resources:

• Free First Chapter Download
  
• Book Page