Designing RIAs...the Right Way

Anyone who knows me will tell you that I frequently preach that the only way to successfully design an application that is easy to use and meets user goals is to take a step back and think about it as a whole. I often get pushback with the usual "That sounds like waterfall to me" argument. Like I have said before, it doesn't matter what it is called to me as long as it works.

So the folks at Forrester set out to investigate how to create successful RIAs. The report focuses mostly on Cynergy who is one of the big guys in the field of RIA development (so they know what they are doing). I have to say that I am not surprised by the findings or by the way Cynergy designs and builds applications. To me it seems like common sense. But I am glad that this "official" report calls some attention to it.

You can buy the report from Forrester or get a free PDF of it from Cynergy.

PixelBender Filter required... I think?

If you read my blog you know that I don't currently have a Mac. This is true, however I have used enough of them to really fall in love with some of the UI details. One of them is the way in which when you minimize a window it kind of warps as it shrinks into the dock.

I don't know much about PixelBender effects, but this seems like something that could be accomplished. I am not even sure what keywords to use on Google to search for such an example. So, if you know of an example of how that effect might be accomplished in Flex using PixelBender (or without using PixelBender) I would really like to see it.

User Experience Designers...Listen up!

A couple days ago I posted a question here (and on some other discussion lists) regarding how usability can fit into the Agile process. I revised it slightly and added some clarification:

What are the best methods you’ve experienced with regard to incorporating quality design & usability practices into Agile software development?

There is some debate in the software industry regarding the scope of UI design work to be completed before Agile software development can begin. What are your thoughts? When is a detailed prototype necessary? When is it not necessary?

I promised to post my thoughts so here they are.

The method that I am currently using involves some upfront design time which I consider the architecture phase. During this phase is when you gather and process all the data about various types of end users and their goals. Throughout the architecture phase, we work on low-fi wireframes and/or mockups that address high level global interaction patterns such as type of navigation, inline editing vs. popups vs. separate edit screens, etc. I liken this to the engineers' decisions to use a particular technology, library or persistence strategy. Some of this stuff needs to be thought out early since changes later are expensive and destabilizing. Because, end user satisfaction is a top priority for our customers, I propose doing usability testing during this phase (and all through development). 

While wire-frames and paper prototypes can certainly be tested, we have found that nothing works as well as a clickable prototype. Someone suggested above that just build the real thing and test that. We have repeatedly seen that a very detailed prototype can be built in 4 to 6 weeks where the actual product can take 6 -12 months. Of course with agile development you have something every 2 - 3 weeks but it does take a while to get to something that can be a true test of the user experience. The level of detail in the prototype and wireframes/mockups is really determined by the complexity of the interaction. If one pattern can be reused, there is no reason to prototype every use case of it.

This process can work very well but requires some commitment of time before development begins. This doesn't have to be a year long effort but depending on the type of application somewhere between weeks and months seems appropriate. Regardless of the amount of time required, this is often labeled "Anti-Agile or Waterfall". 

What lead me to asking my original question was my desire to know how others are doing it from a tactical perspective. Can the process I describe above scale? Is it truly anti-Agile? If it is, does that really matter if the result meets user's needs better? 

If the goal is to deliver really good software, not just really good code, I am ok with being slightly less Agile.

User Experience Designers... speak up!

A colleague posed a question to me today that I think is a very important question:

What are the best methods you’ve experienced with regard to incorporating quality usability practices into Agile software development?

Before posting my answer, I am interested to hear what all of you think.

As usual, I mostly agree with Jakob Nielson

If you work in the web world, it is pretty likely that you know who Jakob Nielson is. If not you can read about his work and thoughts here. 

He recently posted an article talking about Agile Development and Usability which, like I said, I mostly agree with. Really the only part I cringed at was where he says:

"It's perfectly feasible for developers to do interaction design and usability."

Now, I have no problem with developers being involved with usability testing. I think it is extremely valuable to for them to see first hand how users act. The part that bothers me is that it is next to impossible for developers to have an unbiased opinion when analyzing the results of user testing. In my experience, it is because developers know the ins and outs of the system too well to appreciate the way users perceive the system. A designer on the other hand is in a better position to be looking at the system the way an actual user would.

Like I said, I mostly agree. His suggestion for usability and design to happen in a parallel track is one that I have advocated for a long time and has been very successful for me. His suggestion that Foundational User Research should occur before a development project even exists is spot on. This work and much of the work done by interaction and experience designers is just as much a part of the product strategy process as it is the development/ implementation process. So, part of it must be done during the strategy phase long before developers start writing code.

Strategic Relevance for UX

This is a great (but long) article worth reading if you are building a User Experience (UX) group.

Usability testing on a budget... but only on a Mac

If are designing software you no doubt realize the importance of usability testing your wireframes, mockups and prototypes. However, most people hear "usability testing" and automatically assume that means a giant effort at a giant cost. Well the geniuses over at Clearleft have a solution called Silverback. The real power is in its simplicity. It allows you to put a user in front of a screen and point and click their way through whatever you put on the screen while it records screen changes, mouse clicks and video of the user.

All that and its only 49.99.

It really begs the question, "Why didn't something like this already exist?"

Unfortunately, for those Windows users, it only runs on the Mac. If you know of something similar for Windows users, feel free to comment.

MXNA is down. What do I do?

That title isn't meant to be rhetorical. I really don't know where to go for my daily news. I guess I didn't realize how much I rely on it. It is a good reminder of how what we think and what is true are not always the same. If you asked me, I probably would have said that I use it sometimes but it isn't essential to my daily life. The reality is that it truly is essential.

I have to pack some kind of User Experience lesson in here, so here goes. Don't trust what user's tell you. They become so unaware of the things that use all the time that they take them for granted. Anyone who looked over my should on any given day, they would probably notice that every time I am doing a build (which takes a couple of minutes), I switch over to my browser window which always has the first tab open to http://thoughtfaqtory.com/flex/mxnaviewer/.

So keep that in mind when you want to find out how users actually use the software you build. Just remember to ignore what they tell you and pay attention to what they show you.

User Experience Problems - Not just for software anymore

Recently, I found myself the unfortunate victim of a poorly redesigned User Experience. No... this wasn't a new version of some software program. This was a change in the cafeteria at my office. Bear with me...this isn't just me ranting.

I don't eat in the cafeteria much. In fact I almost never eat in the cafeteria. I do, however, get a drink at the cafeteria daily. Up until last week, the process was very simple. I could go to the soda machine which had the cups, lids and straws kept in a plastic dispenser directly to the right of the soda machine. So the process of getting a drink was simple. Pick up the cup, fill with ice and soda, retrieve a cover from the dispenser, get a straw and off I go.

One day I noticed there were no straws next to the machine. I assumed the dispenser needed to be refilled. I asked someone for more straws and he quickly walked out into the the area where all the tables are (the soda machine is in the area with the kitchen and salad bar) and opened the cabinet below the counter where the utensils and napkins were stored and pulled out a box of straws. I took one and off I went.

Ever since that day, there have been no straws near the soda machine. They are now stored along side the napkins and utensils.

So here is the problem. The straws appear to now be kept in the current location for the sake of keeping them near the place where the extra stock is stored, instead of where they are actually needed. This is often a problem in software development as well. How many times have you heard a developer say "it is easier to put the button here" or "we have to do it this way for techincal reasons." There may be times when it is techincally challenging to make software do what is best for its users. However, the problem could have easily been solved before it was a problem, by thinking about how it might be used.

One could argue that many people who come to the cafeteria are there to eat so they will likely need napkins and utensils as well. However, the is a whole other type of visitor, that frequent the cafeteria. This is also a common problem in software. As developers, it can be very difficult to think about anything other than "The User". The problem is "The User" is a combination of every possible type of user which leads to an interface created for a person that doesn't really exist. If the cafeteria manager thought about "customers here to eat", "customers here for a snack" and "customers here for a beverage" then it would be obvious that things should be set up to accomodate each of them. For example, customers planning to eat would likely need utensils, napkins and straws. The current set up would work well for them. Customers who came in just for coffee or a soda would probably never need to visit the seating area at all. Placing sugar, creamer, straws and napkins right by the checkout would make a lot of sense.

We can do this in software design as well by thinking about the types of users the system might have. The point is to make sure you are supporting the real users of your software so that you don't make the system difficult or ineffecient for a significant amount of them.

User Experience - Homer Simpson Style

I happened upon a Simpson's episode the other day that, despite having nothing to do with User Experience, made me think of a common experience in web applications. The episode in question is called The Wizard of Evergreen Terrace. The basic plot of the episode is that Homer realizes that he hasn't done much in his life and decides to be an inventor. Obviously, many funny gags follow. The thing that prompted this blog entry was one of Homer's inventions. He called it the "Everything's ok alarm". Basically it beeps loudly every three seconds unless something isn't ok.

If you are wondering what that has to do with the User Experience of software, let me set the stage. How many times have you been prompted with an Alert box telling you that some was "ok". This might be something like "Your changes were saved successfully" or something to that effect. The reality is that, while it would be appropriate to Alert the user when changes failed to be saved, it isn't appropriate to say "everything's ok" with the software equivalent of an alarm going off.

Homer's invention illustrates the absurdity of using the wrong method of communication in the "real world", however, sometimes we forget that the same care must be taken when selecting a method to communicate in software.

A better way to alert the user that something was successful would be to display a message, perhaps next to the save button, saying "Changes were saved at 12:34 pm" This notifies the user that the changes were saved without forcing the user to acknowledge what a great job the software did doing its job. It also adds more value because it indicates the last time changes were saved which may be important in some applications.

So lets leave the "Everything's OK alarm" to the cartoons... and I don't want to see any software equivalents of the "makeup gun" either.

Required reading for RIA designers and product owners

With the holiday season usually comes less time and more work. Funny how that works. In the little spare time I have left, I stumbled upon what I think is a must read for anyone working on RIAs. I found Magic Ink - Information Software and the Graphical Interface to be full of useful information for both designers and product owners. One of the biggest challenges for UI designers, especially living in the Agile world, is convincing the rest of the team that slowing down and really "designing" the interface is valuable and in fact necessary for success.

The author makes numerous references to the work of Edward Tufte but also extends some of the concepts of Tufte by illustrating how and why the techniques he suggests can work in an interactive medium such as RIAs.

While the RIA technology described is not Flex or Silverlight, I think those two technologies are likely to be the most common platform for RIA development. So while reading Magic Ink, don't get hung up on the fact that the applications mentioned are HTML or desktop widgets. The concepts apply to any and all RIA platforms.

Is Flex just a Fancy-Pants technology?

I had to comment on this entry. I usually don't post comments on other peoples blogs on my own blog, but this is worth getting into here.

The point he makes about building the user interface with the end user as the sole focus is absolutely true. I don't design a UI that is intended to just be sexy or flashy. The trick is, there are times when things that seem like they just add visual flash to an application do add value in terms of supporting user goals. For example, it might seem like it isn't important to animate a menu opening. However, the value is that that transition from closed state to open state serves to show the user how they got from point A to point B. It is the same as if you are riding in a car and close your eyes for a portion of the trip. When you open them,there is a period of "where the hell am I?" even if you recognize where you are after only a few seconds. Seeing how you got somewhere makes it easier to understand how to get back here the next time you need to as well as how to get back home.

If you have ever used a Mac you surely have noticed that minizing a window animates its transition to the dock. Just visual flash? Not really. If you have ever accidentally minimized a window, it would be obvious where it went because you see it go there.

This is a minor example. You get much more value from what seems to be visual flash if the task at hand is more complicated as long as that "flash" was added solely to support a user goal. The fact that he mentions AJAX or Flex as "Fancy-pants" really shows that the author doesn't entirely understand the value of Interaction Design. Perhaps his focus is on the HCM space, but that doesn't make you an expert on the best way to meet user goals. Suggesting that all applications should run inside Office or Google is rather silly. That is like saying that your toaster should make ice. Software is built hopefully to support user goals. Bolting on functions to support unrelated goals complicates the interaction for its original purpose and certainly doesn't give you the ability to focus solely on the new function's purpose. You automatically box yourself into a framework that isn't necessary. Also, chances are, users know how to use their web browser more than Office, so why not use a technology that is easiest to use by the target audience.

Not to long ago, it would have been easy to say "why do we need to invest in the fancy pants computer to do our HR tasks, why don't we just use paper since people use it everyday?"

Thoughts from the onAIR Bus Tour

Wow! I have to say that the creative energy that was in the room was contagious. You couldn't help but get excited about all the things that AIR makes possible. The demos, even the brief Buzzword demo from Ryan, were amazing.

As a UI person, the thing that puts these AIR apps above many other apps is the commitment that their creators have made to the user experience. You definitely get the sense that serious thought was put into how their target users work. Does it mean that they weren't doing Agile? Not necessarily. Given the speed at which many of these apps were built, one might say that it couldn't be done without Agile. I don't have the answer. Perhaps someone who worked on Buzzword, Pownce, Finetune, TwitterCamp (Daniel did you design the UI too?) can post a comment and give us a clue how the UI design fit into your process.

Thanks to all those who gave me feedback on my TimeTracker. I will be incorporating many of the suggestions in coming versions.

The Great Escape

Imagine this. You are in a foreign country where you don't really speak the language and are walking down a street. On this street there are many shops to choose from though you can't really understand the name of the shop or what each one sells. Maybe you are on this street for the first time and are feeling a little adventurous so you decide to go into one that you think might be interesting. You open the door and are surprised to see that it sells "widgets". You are not interested in widgets. In fact, you find them slightly mysterious and are afraid of them in general. What do you do?

Most likely you would turn around and walk out the door. Now imagine that you turn around and the door you just came in is gone. You have no choice but to progress forward through the "widget" jungle hoping that you don't hurt yourself or someone else in the process of trying to find the exit. Finally you find your way out and head up the street.

This isn't a totally unrealistic scenario in the real world. I have been in some stores where you walk in the font door and are force through what seems to be a maze in order to find your cheese... I mean exit. For some reason, it always seemed to be office supply stores that were set up like this. I haven't been in this kind of store in quite some time perhaps because someone realized that users...I mean shoppers, don't like to feel trapped or not in control of what they do next.

Users of software are no different. They like to feel safe while using an application. They also like to feel like they can explore it without "hurting themselves". Giving the user an escape route in the form of a "cancel" button reassures them that it is ok to go through the next door and that they can always turn around and come right back through it if they desire.

Taking away that feeling of safety on one screen can have dramatic effects on the way they use every screen going forward.

One other thing to keep in mind is you need to make the escape act consistently on all screens. Don't make it take you back one step in some cases and take you back to the beginning in other cases. Once you make that mistake the cancel button starts to seem like a roulette wheel in which the user will have no confidence.

The Psychology of Color

So I found myself in the hospital last night/this morning. And as all the nurses came in and out over the course of the evening I noticed that all had blue scrubs on. No surprise there really, until early this morning when one came in wearing scrubs with a orange patterned shirt. Immediately, I assumed that she was a "head" nurse or in some way more important that the others. Was she? I have no idea.

The point is there are times when we differentiate something with color intentionally, such as marking a value in a report red if it is negative. Most people know that difference in color is easily noticeable. For those book-smart types this would be known as a pre-attentive variable. Others are shape, texture, size and orientation. However, often times you see things in applications, on websites and in printed materials (or in Emergency Rooms) that may seem more important unintentionally.

So be careful when you choose colors for elements of your interface. We want users to think the important things are important; not the ones that happened to wear orange that day.

Never be surprised by the way users actually use your app

This post from rhjr.net is a great example of the way users actually think. So don't be surprised when a user enters an email address where you were expecting a web address.