UXD - User eXperience Design

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.