Rob Adams's User Eccentric

Snackr: Don't Read Blogs, Snack On Them!

My coworker and friend NJ has created a new way to read and digest your RSS-syndicated news feeds in the form of a ticker-like desktop application built in Flex and AIR called Snackr. I've been using it to help him test it out for a month or two now and I have to say it's really cool. Prior to Snackr, I read a handful of the feeds I've added to my reader application (mostly those written by my friends or coworkers) and mostly ignored everything else. I just never wanted to spend the time to slog through that huge backlog of news in one sitting, and since I only opened my feed reader once a day at best, I didn't have very many sittings. But now that new feed items scroll by the bottom or side of my desktop, I can constantly glance over at the headlines and see if anything interests me. Plus it gives me something to do during a boring meeting or to kill time between tasks (although I'll warn you - it doesn't do much to improve your productivity!)

]]> Some tips:

You can drag the ticker to any of the edges of your monitor, including the edges of a second monitor.
You can change the ticker speed via the preferences (second icon from the left). I like to slow mine down all the way since I find the default speed too distracting.
You can add feeds just by copying the feed URL, clicking on Snackr, and then doing Cmd/Ctrl-V to paste.

Now, quit reading this and go check it out!

A Pattern Library for Information Design

I'm not usually one to recycle links, but this pattern library for information design was too good to pass up. Christian Behrens catalogs around 55 different ways to display information that helps application designers and others go beyond blasé bar and pie charts when a different visualization would be more appropriate. As I covered in the FIG section on Information Design, it's important to spend time getting content displays right by thinking of them as information design problems. This website helps us get better at that by giving us some concrete new tools and techniques to play around with. I'll definitely be keeping it around to refer to later.

Found via Ethan Eismann.

Thermo: The Board Game

As many of you may know, I�m currently hard at work on Thermo (demo video), our next generation RIA design tool, along with the rest of the design team. I wanted to share one of the research techniques we�ve used that�s proven to be quite effective.

]]> Many design and research experts have promoted the use of paper prototypes for early-stage testing of design concepts. Historically, I�ve been lukewarm on the idea; not because it�s a bad idea per se but because the kinds of projects I tend to work on (complex desktop software for application designers and developers) have many moving parts that are difficult to simulate on paper. I felt that it would be near-impossible to use paper to recreate the experience of using the product with enough accuracy that we would get good data through testing.

With Thermo, however, I had no choice. There were so many new and untested concepts that we had to start iterative design and testing as soon as possible if we hoped to make the product usable. Although we had working code in various stages of completion, the �real thing� lacked the refinement I needed. Besides, testing on the real build is dissatisfying during early-stage design. Code changes take time that slows the process and leads to fewer opportunities for design exploration and iteration. Building interactive prototypes in Flash or another rapid-development technology can help ameliorate this problem if you have the resources to do so, but even they take longer to change than I would like (Thermo, of course, will make it even easier to build interactive prototypes for testing, but we have a bit of a chicken-and-egg problem there� And even Thermo prototypes will still be digital, which is never as malleable as paper). So NJ and Ethan and I bit the bullet and sat down to build a paper prototype of Thermo.

I affectionately call it "Thermo: The Board Game".

Surprisingly, the prototype actually worked out extremely well. Although there are definitely aspects of the interface we could not express via paper (detailed content manipulations, low-level feedback such as rollovers, and subtle motion effects are all examples), we were able to express enough to get really good data on where our design was helping users understand the new concepts and complete the key tasks and where it was leading them astray. We conducted eight rounds (!) of iterative redesign and retesting, not stopping until we were convinced our target users were grasping the key concepts and applying them to accomplish their goals after only a brief period of experimentation with the product.

During the course of designing and running the study, I learned a few things about paper prototyping that I�ll definitely be keeping in mind for the next time.

Figure out up front what parts of the design you�re likely to get relevant feedback on via paper and what parts you aren�t. This way you can guide people past the parts where paper just doesn�t provide enough information for them to figure it out on their own and get to the parts of the task it does test well. Ideally, you�ll have a chance later on to study a higher-fidelity prototype to get full coverage of your workflows.
Sketch out the workflow via hand-drawn storyboards before you or your designer starts cranking out high-fidelity comps. This will help you understand what pieces of the UI you need and how the user might interact with them. In the worst case, you can always hand-draw something on the spot, but it sucks to be missing whole sections of the product.
Make sure you have high-resolution printouts or your participants will have too much trouble viewing your UI elements. Laser printers are a must. We forwent color in favor of high-quality laser printouts and just used colored pencils to draw in the parts that had to be in color to support user comprehension of the design. If your design uses color more extensively than ours, get a color laser printer.
If you have lots of fiddly little bits of UI that need to be individually moved around, consider printing out your interface on large-sized paper to make them easier to grab and manipulate. I used tabloid (11x17) printouts for everything. This obviously doesn�t simulate how well your design will perform at lower screen resolutions, but paper isn�t the right way to simulate this anyway (see point 1 above).
Running paper prototypes is slow. Don�t be afraid to stop the participant from going down a path that is really going to get them into a bad state and waste lots of time in the session. However, use this as an opportunity to see why they wanted to go down that path - understanding their mental model will help you fix your design.
Strike a balance between formal study techniques and informal conversation. Avoid guiding the participant, but feel free to chat with them as they go to understand what they�re thinking. Correct any mistaken assumptions that are an artifact of the low-fidelity paper, but make sure you record points where you have to help them or explain something - these are design problems you need to fix.
Have lots of scrap paper, printouts of UI elements, and scissors with you when you run the prototype. You�ll be doing a lot of on-the-spot arts and crafts as you adapt the UI to what the participant is doing.
If the participant is really confused, feel free to make on-the-spot design changes to see if it helps them understand what to do next. In your later iterations, you should find yourself doing this less and less.
Have someone else take notes. You can�t take notes and interact with the participant and run the prototype all at the same time, and it�s important for the researcher to be the one running the prototype and interacting with the participant. Although not all note-takers do as good of a job as you might, I find almost everyone can do a good enough job after 5 minutes of training and viewing an example of a well-recorded session.
As with any iterative testing session, schedule debriefs and redesign sessions soon after each round. Digest the problems quickly and help your design team to come up with solutions and rev the prototype. Problems always tend to get solved quicker when there�s a hard deadline - I only allotted one week between rounds.

Even though designing the study and constructing the paper prototype was a huge undertaking, I�d definitely do it again. If your product makes use of new concepts or patterns that your users may not be familiar with, it�s an invaluable way to get feedback quickly, incorporate that feedback into a new design, then retest to make sure your solution works. Paper allows for a turnaround time that no other technology can match. I�ll paraphrase one of our senior engineers, Mark Shepherd, who said �it may have taken you eight rounds to get this far, but back in the old days it would have taken us until Thermo version 8!�

Excellent Example of Eliminating Work

Yesterday's xkcd demonstrates a FIG best practice in action:

Although one might quibble with it's means, the Wifi autoconfig program depicted here does an excellent job of following the FIG best practice "Use the impeccable memory and powerful processing abilities of computers to eliminate work for your users." More systems should attempt to follow this autoconfig program's good example.

FIG Evaluation - The New Dilbert.com

(Disclaimer - as always, the opinions expressed below are my own and are not necessarily shared by my employer.)

Dilbert.com recently relaunched with a new site design that uses primarily Flash. Good technology choice. Unfortunately, it seems to have gone downhill from there.

The new design has received quite a bit of negative user feedback, and much of this is quite justifiable. The new Dilbert may use Flash, but it uses it in many of the wrong ways.

]]>

First off, notice the fairly small amount of screen real estate devoted to the content the user cares about (the comic strip itself). Only one strip, today�s, appears in a fairly small box - the rest of the screen is given to ads and overly elaborate navigation. What�s worse, the Sunday comic (which has always been larger than the weekday strips) is still crammed into the same small box! To see the whole strip, the user must use arrows to scroll from frame to frame, a ridiculous amount of navigation excise!

The Dilbert.com designers had an opportunity to make the site more effective at viewing and browsing the comic strips than was the old, fairly clunky HTML site. For example, they could have implemented smarts that recognized the last time the user had visited Dilbert.com and displayed all the comics he hadn�t yet seen. They could have provided filtering tools that gave users easier access to the archives, or allowed them to view top rated comics without navigating to a new screen. The new �Mashups� feature could have been implemented in-place by clicking on the comic to modify the last panel instead of creating a whole new screen and scattering the main page with navigation links. Sadly, the design team dropped the ball and chose to create a traditional HTML application with a sprinkling of animation.

Speaking of animation, the new site design uses motion in all the wrong ways. For the first week it was launched, there was a continuously playing movie plopped in the lower-left corner of the screen. This is almost always a bad idea - continuously playing animations distract the user from main content. They�re annoying and they often don�t even serve their intended purpose of drawing the user�s attention; most web users have been �trained� to ignore animation since they equate it with useless banner ads. This was quickly removed, fortunately, but the site still uses motion gratuitously. Text bounces and icons jump, but the design never employs motion to help users understand the structure of the site, how to explore their content, or how to accomplish their goals. The ability to employ motion to help guide users through the site is one of the biggest advantages Flash gives to designers, but Dilbert.com fails to take advantage of it.

On the positive side, the site does do a good job of preserving web idioms such as bookmarking and back button support, something many Flash sites fail to achieve. The site designers seem very familiar with traditional HTML website design, which served them well when managing URLs but poorly when designing the actual screens and navigation structure.

Overall evaluation: Thumbs down.

Dilbert.com - List of broken FIG best practices

Eliminate unnecessary navigation in your applications.
Integrate highly related information into a single content display whenever possible.
Avoid splitting information across multiple screens or states.
Only use page-to-page transitions when the user is pursuing a clearly different goal.
Use intra-screen changes to modify the screen as the user advances through tasks that are related to the same goal.
Employ sound visual hierarchy to communicate the important elements on the page and to guide the user�s eyes to the next part of their task.
Make it easy for users to not just find content, but explore content.
Display controls in the context of the content they manipulate.
Avoid gimmicky or gratuitous motion
Employ motion to apply physical principles that help users understand the workings of your application
Use the impeccable memory and powerful processing abilities of computers to eliminate work for your users.
Discover your users� real tasks to better understand what flows you must make more efficient.

enabled=�false� Considered Harmful

Oftentimes when designing applications, certain functionality needs to be present in some situations but not in others. The traditional way of dealing with this on the desktop is to enable the controls that provide access to that functionality when it is available and to disable them when it is not. For example, consider the following application snippet where the �Merge� function only applies when the user has selected two records.

Unfortunately, disabling controls without explanation is often a pathway to confusing your users. The problem is that disabling a control does not, by itself, provide the user with any indication of why the control is disabled. It may seem obvious to us, the system�s designers/developers, but to a new user experimenting with the application�s functions the reason the control is disabled may be quite opaque, especially if the function is far away from the means of enabling it (e.g., with application menu items). Time and again in user testing, I�ve watched participants fumble when a function they were expecting to be able to perform is inexplicably disabled.

]]> But if disabling controls is confusing, what can we do instead? It heavily depends on what your design is trying to achieve, but here are some ideas:

If the user must select additional content before the operation makes sense, as in the example above, consider keeping the control enabled but asking the user to choose the second item in a pop-up box. Consider including help text in the box informing the user that they could have multi-selected list items using control-click to avoid the dialog.
If the user needs to do something more complicated, consider leaving the control enabled but providing help text explaining how to get the function to work when the user hovers over or clicks on the control. Remember that modal dialog boxes are bad, so consider using something less intrusive like a callout to provide this information.

If anyone has other ideas on how to avoid the disabled state, please do email them to me or post them in the comments.

I'm at Interaction 08

I'm currently in Savannah, Georgia for Interaction 08. So far it is shaping up to be a really cool conference. If you see me around be sure to say hi.

NJ and Steven are here as well. If you ask nicely we would love to show you the Thermo demo and get your thoughts on what we should be doing with the product!

Help Us Help Users Learn Thermo!

Are you a writer with strong design skills or a designer with strong writing skills? Would you like to work on the Thermo team? If so, I think I might have a proposition for you.

We're looking for someone who can help us create learning material to help designers get up to speed on Thermo, a new tool that will allow designers to create the next generation of rich application UIs. You'll work closely with myself, Ethan, NJ, Mark, and Steven to design and develop the way people will learn this exciting new tool. Not sure if that's an incentive or a threat, but there you go :).

If you're interested, check out the job description and email Randy Nielsen if you think its a good fit. Don't write me about it - I'll just have to forward it to him and I can't guarantee I'll do so in a timely fashion :).

Get Your Design Out of My Content

On Monday, I attended a course taught by Edward Tufte on Presenting Data and Information. I've flirted with Tufte's ideas before, and Tufte fans may recognize some of them from Designing for Flex part 5 - Designing content displays. This is the first time I've heard a summary of Tufte's work from the man himself, however, so I uncovered some ideas that build on Part 5 and offer some additional guidance.

]]>

Content first - Especially for information structures, users care about the information itself, their content. Avoid obscuring information with application chrome, navigation controls, and decorative design. This shouldn't be new to anyone who has read Part 5.

Design dense content displays - Tufte argues that information overload is a failure of design, not an artifact of presenting too much information. He points out that the human brain receives an enormous quantity of information every second through the senses and has absolutely no problem interpreting it. If your information is confusing, its because you are presenting it in a way that doesn't make sense to your viewers and you should fix your design. I'd add, however, that designing very high density content displays is difficult to do and its easy to wind up with a confusing clutter if you are not a skilled information designer. Incorporate content displays with three or four variables and see if you can integrate more without confusing someone who has never seen your display before.

Nothing can be erased without erasing information - Good information designs have few elements that are irrelevant to the information itself. Whether these elements are needless graphical decorations or irrelevant controls or application chrome such as panel borders, all stand in the way of the user understanding his information. The test to apply is: if you can erase any page element without erasing actual content, do so. Obviously for RIAs and other computer displays this isn't always possible; some amount of navigation cruft is necessary. But it must be kept to a minimum and away from the content, which should consume the vast bulk of the screen.

Avoid "relentless sequentialtiy" - Relentless sequentiality is Tufte's term for information that is segregated onto different screens in a stack, preventing the user from making comparisons by seeing the information all on the same screen. Tufte uses this term to slam Powerpoint, but it can also be applied to many application interfaces that segregate related information into different screens or views. Note that designing content displays to support comparison is covered in Part 5 of D4F.

Direct reading - Many information displays spatially move information away from the content it is related to. For example, arrows in diagrams are not labeled or are labeled only in legends. Icons are used instead of text. Figures are referred to by number instead of being included directly inline. Footnotes or (shudder) endnotes are used instead of sidenotes in the margin, which are much easier to follow. Avoid these practices. Include additional information right next to the content it elaborates on, using techniques such as callouts or overlays.

Don't segregate information by type - for technical reasons or (even worse) simple force of habit, many applications separate different types of information (text, pictures, video, etc) into different screens or sections. Don't do this. Data type doesn't matter to users - include all information relevant to a given topic in one section, regardless of what file format it is in or what department in your organization created it.

Design for the viewer's fundamental cognitive task - I believe that what Tufte calls the user's "fundamental cognitive task" is what I call a "goal" in Part 2 of D4F. Regardless of what you call them, your users' goals should guide the design of your content displays and your application as a whole.

Problem, relevance, and solution - When producing presentations, Tufte urges you to consider three things: what is the problem we propose to solve? Why is that problem relevant? And finally, what is your solution to the problem? These are also good questions to ask when designing content displays and other application elements such as error messages. It may help to rephrase the questions as "What question does the user have? Why is this information relevant to their question? How will this information help them answer their question?"

Everything is information - Tufte doesn't say this explicitly, but I believe it's important to point out that information design runs throughout your application, regardless of your organizing structures. Every pixel on your screens communicates something, or fails to. Many people seem to believe that information design is only relevant to charting components or dashboards, but this simply isn't true. The principles behind designing dense yet clear displays of information should guide every design decision for every screen your application has, from content displays to forms to dialog boxes.

FIG Update - Parts 7 and 8 are now live!

As many of you may have noticed, Designing for Flex - Part 7: Making your application fast went live before the holiday break. Just yesterday, Designing for Flex - Part 8: Making your application safe went live, thus completing the Designing for Flex article series! It's been a long trip (I started work on the series text itself in July) but it's finally over.

However, this doesn't mean we're done with the Flex Interface Guide or our efforts to provide you with guidelines, components, and other useful material to help you create the great experiences we all dream about. We're currently working on adding more sample components and we still have a placeholder for an official set of interface guidelines, as you may have noticed. In the meantime, it would be great to hear your feedback on what we've already published (Is it useful? Is it correct?) as well as hear what else we could be doing to help you more.

Feel free to get in touch with me directly or post to the Flex Interface Guide forum.

FIG Update - Parts 5 and 6 are now live!

Hey everyone, just a quick update on the Flex Interface Guide (FIG) project in case you hadn't already noticed. Part 5, Designing Content Displays, went live two weeks ago and Part 6, Guiding with Motion, went live today. These two chapters discuss two aspects of Flex application design that I think are of particular interest to many designers and developers since they discuss topics that are somewhat unique to Flex and Flash. Check them out, and as always, please do send me any feedback you may have.

I actually just sent the final edit of Part 7 along to the Dev Center folks, so that article should show up in a couple of weeks. Part 8 should follow shortly after the holiday break. Once I've got those off my plate, I'm hoping to pick up the slack on this little blog project you're reading right now...

RIA Accessibility and the Law

I found an interesting news article on the IxDA list today concerning an accessibility lawsuit brought against Target by the National Federation of the Blind. One of the findings of the federal district court was that "web sites such as Target.com are required by California law to be accessible".

Now, ever since the early days of the Americans with Disabilities Act, government websites have had to adhere to minimum accessibility requirements defined by the section 508 guidelines. In general this is a good thing - government websites should be accessible to all citizens regardless of their physical capabilities. However, privately owned websites were not, to my knowledge, generally considered to be under the same constraints. Following the section 508 guidelines was generally considered a best practice, but it was up to each private company or individual to determine how closely they needed to adhere to the guidelines for their business goals.

]]> Although getting more websites and companies to take accessibility seriously is an awesome goal, I'm ambivalent about making section 508 mandatory even for private company websites. First off, we risk stifling innovation. Some sites use data visualization techniques that don't translate well to screen readers, but make the experience much more comprehensible for the non-disabled users who view them. Screen readers often can't process these techniques because they lag a bit behind some of the more modern web features, but in the future, screen readers may also pick up support for these features and provide a better experience for all users. But if these web innovators can get sued for failing to support section 508, this innovation may never occur for anyone

The second problem is that section 508 offers minimum guidelines for accessibility but doesn't mandate a great experience for disabled users. All too often, designers and developers use accessibility checklists to adhere to minimum requirements at the expense of creating a great experience for able bodied and disabled users. Section 508 provides no incentive for providing some of the accessibility features most needed by disabled users. I discuss this in a bit more depth in the Flex Interface Guide article on Merging the Web and the Desktop. So forcing section 508 on private companies may make web experiences worse across the board for everyone for marginal gains for some disabled groups.

On the other hand, section 508 does at least guarantee a minimum level of accessibility for certain groups that rely on screen readers and other assistive technologies. Most web sites and web applications should take these guidelines seriously. But there is a big difference between "should" and "must", and we should be careful about the unintended consequences of applying "must" too liberally.

I wanted to point out that, contrary to popular misconception, accessibility is not an issue of "HTML supports it but Flash does not". The Flash Player has supported accessibility features equivalent to HTML for several releases now and this support is baked into Flex (although not, unfortunately, enabled by default - be sure to compile with the -accessible compiler flag or by setting the "Generate accessible swf file" option in the Flex Compiler page of the Flex Builder project properties page. Instead, it's an issue of "rich" user experiences versus cookie cutter widget-heavy UIs. Widget-heavy UIs are easy to make accessible in Flex and HTML, but richer experiences built in AJAX or more fluid Flex techniques require more work to achieve minimum section 508 compliance. Yet it's these very techniques that create more usable and enjoyable user experiences on the web.

MAX BOF on the FIG

This may be a little late in coming, but I wanted to let everyone know I'm giving a Birds-of-a-Feather (BOF) session at MAX 2007 on the FIG tonight at 7:30 pm CT in room 178A. If you're at MAX right now, swing on by! I'll show off the stuff we've made, sneak some of the stuff we haven't published yet, and I hope to hear from all of you to see what you'd like us to do with the FIG in the future.

NJ will be there as well.

Introducing the Flex Interface Guide!

For the past two-and-a-half months, I've been hard at work on a project that some of us on the Adobe Flex team have been working to get off the ground for some time now. But we finally did it, and the first part of the Flex Interface Guide (or "FIG" for short) is now online on the Flex Developer Center!

So what is the FIG? And why spend so much time on it instead of working on getting more features and components into the Flex product line (although we're always doing that too)? Primarily because the FIG does several things for us that merely revving the product alone won't ever accomplish.

]]> The FIG describes (and in some ways prescribes) the kinds of RIAs that we intend folks to build with the Flex platform. Good RIAs. Great ones, even. RIAs that are as well designed as Adobe XD showcase apps such as the Tour Tracker and some of the best customer applications like Yahoo! Maps and Picnik. By articulating the design principles and practices behind these applications, we hope to make it easier for Flex designers and developers to learn how to design their own applications to be as good or better than these.

But the FIG is more than just advice. Articulating what we think makes a great RIA helps us understand what we need to do to make building such RIAs even easier in the Flex framework than they are today. If a best practice we discuss in the FIG is more difficult to achieve in Flex that you'd like, we're going to take that really seriously and make it easier as soon as we possibly can. One way we'll do that is by revving the Flex framework and tools, but another, faster way is by releasing components and sample code on the FIG site itself that developers can pick up and use to easily implement many of the FIG design idioms.

Note that what's available right now is only a first set of content; I'll be adding more real soon. But even what's up there now is fairly extensive, and it's all in "public draft" form. This means I really, really want to hear from everyone on what they think of it! Check out the FIG feedback forum (how alliterative!) and post comments, kudos, criticisms, rants, and flames! Ok, maybe not flames.

Oh, and a shout out to the guys at Wheeler Street for helping me to design and develop the FIG components. Aaron and Paul, you guys have been great. If anyone is looking for Flex consultants, give them a ring!

MAX Talk: Creating Learnable Applications

Thanks to everyone who attended Stephen and I's talk at MAX 2006; I thought it went pretty well and we already received some great feedback. I'm looking forward to getting the reviews!

Since I'm not sure if the organizers are posting the actual Powerpoint file to the MAX website (it may be some form of PDF), I'm posting the entire thing here. The notes contain some additional explanation for some of the concepts that I only touched on in the talk, as well as pointers to additional reference material that you may want to check out if this subject interests you.

Download the talk.