UXD - User eXperience Design

Design Pattern 7: Required fields

It is one of the first problems of HTML markup that had no standard way to communicate to the user what they should do, I'm talkin' about the required form field. Personally, I have used some sort of asterisk in the past, coloration can work as well, but anything eye catching can distract from an error state (hey, you didn't notice we required that field, try again). So it caught my eye that the good people at reqall have an interesting pattern. In this case, make required fields have a bottom that is different from the non-required fields. This is fairly subtle, it took me a moment to figure out what it meant, but I give them kudos for trying something new. This is a long neglected design pattern of how to handle this in a consistent way, and this is a good a place to start. Its also a way to give a shout out to this service which mashes up text-to-speech, reminder lists, task distribution and has a nifty iphone interface as well, check it out!.

How to do it

Here's a capture from their stylesheet, an interesting element here is I didn't know that you could restyle the drawn box of an input, so there is room for much variation. I also like the way they specified 'solid' to get rid of the horrid default 'picture frame' style of merging borders when they don't match, which always makes me flashback to 1998 web design.

input.essential {
	border-top-width: 1px;
	border-right-width: 1px;
	border-bottom-width: 3px;
	border-left-width: 1px;
	border-top-style: solid;
	border-right-style: solid;
	border-bottom-style: solid;
	border-left-style: solid;
	border-top-color: #016098;
	border-right-color: #016098;
	border-bottom-color: #990000;
	border-left-color: #016098;
}

Pixel by Pixel...Or how I spent my last 2 weeks designing a few icons

"Our product is shipping globally, and we're not going to customize each device to the language of it's destination country.  So we need you to design a set of icons that will be used in place of textual messages."

Challenging, but simple enough, right?  Immerse yourself in the product, do some user research,  brainstorm designs that are meaningful, descriptive and culture neutral, and there you go.  Oh, and one more thing...the device's display is 128 x 64 pixels with 1 bit color depth.

Such was the nature of the project I recently worked on, and it was a challenge of a very different kind then I had faced in a while.  With either greater resolution or more color depth, It's relatively easy to depict pretty much anything with a high degree of recognizability.  Shading, perspective, non-linear surfaces are all time consuming but doable with one or the other.  Yet with only 2 colors and not many more pixels at your disposal, your so much more limited in what you can do.  Take a look at some early GUI icons to see what I mean...

   

Since I couldn't use more than 2 colors, I couldn't anti-alias, so I was basically confined to horizontal, vertical and 45 degree diagonal lines.  Forget about perspective.  Since true perspective doesn't involve straight lines, depicting a product from an angle on such a small scale is out of the question.  And shading--which is essential in illustrating that a surface displayed head on is curved--is just a matter of starting on the darker side with a high frequency of black, and then lessening the frequency as you move to the 'lit' side of the surface (Take a magnifying glass to a newspaper add to see what I mean).  Again, not an option here due to the small screen size, there just want enough room to do that.  I felt a lot like a writer being asked to weigh in on a complicated subject using 50 words or less.  They say brevity is the soul of wit.  I had to be clear and concise if I had any chance of success.

At 128 x 64, every pixel matters.  And at 1 bit color depth, rotating, scaling or otherwise transforming anything in Photoshop is useless because the software automatically anti-aliases, creating shades of grey that were forbidden.  So I had to design pixel by pixel--make a 1 x 1 selection, put my hands on the keyboard cursors and get to work.  See Wikipedia's entry on Pixel Art for a good reference. 

As it turns out, I was more at home on this project than i though I would be when found out the requirements.  You see back when I was a kid, the first computer graphics program I ever used was on my father's DOS machine.  The program itself wouldn't fit on the computer's hard drive, so it had to be loaded via floppy disk--the old 5 1/4" ones.  The computer didn't have a mouse, so almost everything I created had to be tediously drawn pixel by pixel using the cursor keys.  It took me months working 2-3 hours a night, but I created some pretty good stuff.  In particular, I remember drawing a hockey rink, with players, stands and all, which I'm pretty proud of.  Using Photoshop/Illustrator now, with the capabilities so far advanced over what I had to work with at that time, It's hard to see how I did what I did, or for that matter why I spent months doing it.  But there's something about taking time to do something right, struggling through the frustration that comes with the absence of 'Undo', picking yourself back up after making a mistake that renders 10 hours of work useless.  Creating art is a sprint.  Back then it was a marathon.   

So I forgot about my mouse, left the color picker behind, and zoomed in at 1600%.  I soon found the hang of it again, and I got in the groove I remembered from way back.  After a lot more time than I though it would take, I had a set of icons that worked...and that's the key.  And in the end, I feel a little more satisfaction than I would have if I was allowed to let Photoshop do it's magic. 

Design Pattern 6: Directory lists : point/counterpoint

I encountered a similar situation to Noel's when developing a site recenty. The design called for, or made reference to, a opening and closing header with details shown or hidden by a click on that header. I approached it in a different way, which may be interesting to compare the two, but leave it out there to debate the merits of each. When solving a problem, I normally begin with the same axiom that was mentioned in an earlier post - What is it? What is it's nature? HTML markup, as you may know doesn't have much in it, a mere 20 or so tags, but with the addition of ID's or classes, you can uniquely identify everything the web has to deliver, which is pretty powerful.

In looking at the elements controlled by another element, the most fitting markup is a directory list. For some reason these elements are mysterious and not too often used. It is a list <dl> that can contain two elements <dt> and <dd>. Normally they have a default display of one element being bigger and the other slightly indented, as to look like a directory. So, with little or no work we can describe the two types of list elements, the 'header' - <dt> and the information that can be 'opened' the <dd>.

So having my markup, well, marked up, I can set aside the HTML, produce some styles for the list, but what about the complicated part? Adding the behavior to hide/show, make the <dt> clickable, swap the GIF's that indicate opening and closing, and while we're at it why not a 'expand all' or 'close all'. Finding it was no mean feat, but with some very creative google searching I found the script - http://www.tjkdesign.com/articles/toggle_elements.asp. So this handles all the heavy lifting, and basically degrades nicely in a non-javascript situation to show all elements. Problem solved.

The satisfying thing about this solution is that the code is clean, and easy to change, and any presentation issues are handled within CSS, along with any behavior in javascript, and handled by the client. I think the two approaches compliment and contrast each other nicely, add your own solutions to the comments if there are even better ones.

Design Pattern 5: Can u rd this?

Over the past several years, the web has been innudated with blurry, hard to read text. Users are forced to squint, struggle and enter this text exactly in order to proceed with their goal. I'm refferring to a method called a captcha, an image that normally contains letters that are intentionally obscured so that computer programs cannot 'read' them. While the need for this is understood, security against malicious scripts, the burden it puts on the user has only increased since these letters are usually not a 'word' and bent 'm's and 'l's easily become unreadable. All of this is to tell the system you are actually a human being, hardly something humans feel necessary to prove.

The amazing thing in the research realm of computer vision is that some algorithms are becoming able to 'read' this obscure text, making it necessary to make them even more unreadable. Recently, I have found this alternate 'maptcha' - being used on a number of sites, replacing the text with a simple addition problem. Not only was it less burdensome on the eyes, it seemed a bit fun to do a small math or counting exercise. I am curious if this is terribly insecure, or just a small revolt against the difficulty many users have with the other method. Either way, a great pattern to emulate, and much easier to use.

Use a Task Flow to Show “How do I ___?”

Although task flow diagrams (sometimes referred to as interaction flows, process flows or work flows) are a standard in most IA’s toolkits, it can be confusing for those unfamiliar with this particular tool to know when to start diagramming. When in the process is it started? How much information is needed before diagramming? How much detail should be added? When is it considered complete? 

The short answer is to start diagramming once the task is identified because it’ll help in flushing out the requirements. The diagram starts to identify what the user and the system need to do. It delineates a repeatable pattern of activity. It answers the question: “How do I _____________”.

After you have an identified task (I like to use Use Case Diagrams to call out the high-level tasks), the start point and end point need to be established. For example, let’s say your business requirements state that the web application is only accessible by authenticated users; therefore, a user needs to successfully login in order to see the home page. The initial diagram has the user starting on the login page, submitting their information and viewing the home page after the system logs them in.

But wait … I did say *successfully* login, didn’t I. O.k., so we add a decision point to the diagram to show that only successful logins allow a user to access the web application. Don’t worry just yet what the details are for the system to successfully authenticate a user. The purpose of the diagram is to identify the process, not to define it. For now, all that's needed is to show that the login information must be vetted before the system allows access.

Granted, the previous examples are simplistic, but simple is where task flow diagrams start. This basic statement “How do I ____________” turns into an initial task flow, delineating the steps needed to complete the task from start to finish based on the information known at that time. The first iteration is generally the ‘happy path’ and identifies the main flow of a task.  As more steps are uncovered through requirements, the flow is updated and modified to accommodate the new information and show the various decision points and/or alternative paths as they become known. The end result is a flow diagram that conveys both the overall structure of the main user tasks and the sequencing of activities to be programmed into a repeatable activity.

Design Pattern 4 - Inline help

I just had quite an enjoyable spring break trip with the family to Washington DC. For a town with lots of visitors, it was important to help people manage the different ways to get around, or more importantly get out of the way of the residents. Among many places, within the beautifully designed metro stations, there was often voice over assistance on different helpful topics. While I was surprised at the lack of multi-language support amongst these alerts, there was a particular custom that made me think of a similar pattern in software design, the help system.

Often designed separately, help in software systems is almost always out of sight of the actual user experience, and thus out of mind. On my projects I make it the habit to make room for, and design with inline help in mind. Inline meaning the help topic is written out on the page next to the area where it will be consumed. I find it keeps people from having to take fingers off the keyboard and mouseover a "?" icon to see if it anything helpful is there hiding. During planning, if the final text is missing, placeholder text is substituted. It helps show the developers that labels alone cannot help users determine how to proceed with completing the task. It also reminds us of what kind of help will be needed eventually in each interaction. I'm surprised at how much reaction it spurns in design meetings and helps clarify confusing procedures amongst other benefits. In short, the pattern is to provide some help where we are looking, rather than make users hunt, or worse, ask for it.

Back to DC, in the Smithsonian, as well as the metro, there are many escalators, and if you pay attention to the voice over, the helpful message is to "stand on the left and walk on the right". Having been plowed into more than a dozen times by people trying to get past me, it finally dawned on me that this is lacking inline help. I took this (blurry) picture in the Smithsonian, which it had two footprints on each side of the tread. The 'help' actually contradicted the rule. With some bad photoshop I erased the footsteps to the version shown here. While reminiscent of some ancient dance chart, I thought if this was the way it was stenciled, that people pick up on the intended behavior because it is where their focus is, not on the announcement, but on their feet.

Site Maps -- Still Needed for Web Apps?

In a previous post, I talked about creating a Use Case Diagram as a means to moving the 60,000’ concept to a level of detail that’ll allow us to begin development. Since that diagram identifies the overall functionality, the team can use that to start designing the data model, writing user stories and generally working towards a more detail view of what we’ll eventually need to develop.

The site map is another diagram I’ve found helpful to bring further definition to the concept.

On some projects, usually those that were understaffed, the site map was typically drawn up after the project was in the end stages of development and only because someone in marketing asked for it. Oh, everyone on the team knew what was being built and the relationship between the areas, but it was all verbal -- no one had taken the time to set it down on paper.

At Pathfinder, we sketch out a site map early in the process to give a physical representation to the verbal concepts floating around the team. The ‘we should separate this’, and ‘let the user skip from here to there’ and ‘oh yeah, both these areas relate to each other’ kind of ideas that float around before requirements are actually written.

The very act of documenting work to further define the concepts and gives the team a visual artifact for future decisions. The site map, no matter how rudimentary, begins to identify and categorize the user activities into a relational hierarchy and provide a framework for the application. It helps in project scoping and planning because it begins to further identify the details of a project, which can then open a conversation as to what is needed now and what can be postponed to later. It is a concrete drawing that you can show the client and ask, do you agree? Is this what you want?

As with Use Case Diagrams, a Site Map gives you an overall view of a project -- not necessarily all the details but a high level view of the end goal. Both documents are relevant because both give you a checkpoint to refer back to once you’re in the details of a project to make sure that you’re still on track to meet the project objectives.

Use Case Diagrams

Projects start off at the 60,000 foot level -- the client wants a widget that allows their users to do X, Y & Z -- and need to be brought down to a level of detail where coding can begin. Something I use to start this process is a version of the UML Use Case Diagram.

For those of you not familiar with it, a Use Case Diagram describes the needed functionality in a system. Unlike flow diagrams, however, the use case diagram doesn’t represent the order or number of times the functionality needs to be executed and it doesn’t display any subroutines. Instead, it’s a high level diagram that identifies the primary tasks an actor/persona needs to be able to do.

The beauty of this diagram is that you’ve now captured the overall view of what the system needs to be able to do in order to allow the user to complete all their tasks. With the high level activities clearly identified, the diagram easily lets you communicate with your client and get their sign off that the needed functionality has been accurately captured. From here, the team can move onto further defining what’s needed to support this functionality: data modeling, user stories, task flows, etc.

It Starts with the User Story

Having recently been asked about the difference between a use case and a user story, I came up with this explanation:

Use cases detail the interactions between an actor and the system in a sequence of steps and are generally used to capture the functional requirements of a system before implementation. Because of their scope, i.e., they take in more exception scenarios, they can be too large to be used for iteration planning since they would be split across multiple iterations. Also, there is a bit of a learning curve to interpreting use cases which can leave the non-technical customer out in the cold.

A user story is a short description of a feature as told from the point of view of the user (generally your persona). They consist of one or two sentences written in the language of the user, and are used to estimate the degree of difficulty to implement (which ties in with iteration planning). At Pathfinder, we also include acceptance tests when we write the user story as a way to set out the criteria that determines when the story's goals have been met. Again, written in plain English so that both technical and non-technical team members understand what success means for that feature.

For our Ruby on Rails projects, we're writing our user stories in a format that'll help the developers convert them into automated tests using the Rails framework:

As a [role]
I want [feature]
so that [benefit]

From here we create the acceptance criteria, which we write as scenarios in a specific format (givens, events and outcomes) in order to help with writing the automated tests:

Scenario 1: Title
Given [context]
  And [some more context]…
When  [event]
Then  [outcome]
  And [another outcome]…

We'll then go on to create flow diagrams, requirements and wireframes to further flesh out the details of this feature, but it all begins with the User Story and Acceptance Tests.

Goldberg workflow

In a current project there is the need to use email to allow customers to 'sign up' for information updates. In working through the user experience I have been looking deeper into how different programs have enabled email to process and initiate workflow that it led me to solve a problem in a surprising way. It also reminded me of how in user research it can be nonsensical and even counterintuitive how people use software to help them with their tasks. Its all a strange rube goldberg like process, which gives me an excuse to share the "Pitagora switch" video, which always invigorates me when a software project seems to lose momentum.

I started with a basic problem of the customer (In this case, me) who is a amateur oenophile. I try a new wine and would like to keep track of my thoughts and rankings in the easiest way possible. I have an account on Corkd, a wine rating site, but the customer experience is lacking in some ways, and adding wines is a chore. A friend mentioned that he only buys wine based on label, and that is important, so I would like to keep a photo for reference as well. Many sites do photos, many do blogs, but I wanted to do them both together. So I set up my own site with a bit of wordpress and a domain name, I was up and running. However, it still seemed a chore, if I was enjoying a wine, I would have to go to the computer, log in, write, set up, upload photos, remember which one... oh, again, too much work, and the site and content stagnated.

Armed with some experience in the email interfaces to these blogging/cms systems, I came up with a weird way to make the process easier. It does involve an iphone, but that is just to enable the 'mobile' experience. As I went through it, it worked perfectly, and was quite a bit of fun, not to mention a triumph of non-linear thinking! To summarize:

1. Enjoy some wine - be sufficiently inspired to blog something about it
2. Use the iphone (or I suppose any picture phone) to photograph the wine label
3. Email the picture to flickr (check flickr account details for your personal email address that posts the picture)
4. Set up flickr to be aware of the 'wineskeptic' blog by pointing it to a script within wordpress that will accept XML posts
5. This enables the little 'blog this' link above the picture, using the iphone web browser enter the tasting notes. Save.
6. Check the blog, notes and picture are posted, success!

I hadn't really used the flickr service for anything but archiving and sharing photos before, and its a very cooperative model they enabled. The photo is not the main reason for the post. If you have experiences with similar ways you mashed up some technologies to solve a workflow problem, please comment!