Molly Malsam

Posts by this author: RSS

Bad User: error messages matter on mobile applications too

Lately, it seems I’ve been experiencing a rash of extremely uninformative and even appalling error messages oPoorly composed error messagen iPhone apps. The latest one, shown in this post, made me laugh out loud. “Bad User,” I was told. I felt like a 1950s Catholic schoolgirl getting rapped on the knuckles with a ruler. Bad User!

It’s looking like more and more mobile apps are being deployed without thoughtful planning for program states users may find themselves in. Mobile applicationss, while more lightweight and easier to develop and deploy, still require as rigorous a process as a web application is treated to. As I mentioned in a previous post, Bad error messages still abound, one of Jakob Nielsen’s Ten Usability Heuristics is to:

Help users recognize, diagnose, and recover from errors. Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.”

While the error message referenced in this post does suggest a solution, it does not indicate the problem. In the instance I received the message, I was doing THE main function of the application,  so I had no way of understanding what was abnormal about the request or what I could do to recover. Of the reviews I’ve seen on the App Store, many of them complain about apps that don’t work and don’t tell why they aren’t working.

It’ s not enough just to have a smartphone app — thousands are out there. Following usability guidelines is perhaps even more important than in desktop applications because the context of use simply demands it. Don’t blow any opportunity to communicate with your users by calling them names when your app fails.




In praise of page guides

I’ve been working with Axure’s 6.0 update for a few weeks, and so far I think my favorite feature is the addition of page guides.  Page guides make aligning elements so much easier, and since they are standard for most design tools, they were overdue in Axure.

The guides are easy to use — just click and drag from the left rule or top rule to pull a guide down. Options for aligning to guides include snap and glue. The guides can also be created globally, making grid templates a breeze. I have to unlearn my old method of creating grid guides, which was more laborious and clunky.

Axure position guide

Axure position guide

Aligning widgets has also been simplified. When you click and drag a widget, a semi-transparent box displays its position and size in a guide to the right of the widget. This is a popular feature that has been included in some other rapid prototyping tools, and thus another welcome addition to the Axure toolset.

Also, a small but effective change to the icon set makes alignment icons easier to see and understand.

Axure, you’ve made me very happy! What do you think of Axure 6.0? What are your favorite features?

Ratings overload?

Though I’m all for the ratings information people freely provide on various social platforms, I often wonder if at some point there will be so many things to rate, people will stop bothering. So I found the following site and video pretty entertaining:

Jotly – Rate Everything

In the video, the narrator reviews ratings on the best ice cube in his glass, girls walking down the street, hiding places, and other people’s reactions. Enjoy!

Books on X/HTML & CSS

Over the past couple of weeks I’ve been looking over a number of books designed to teach X/HTML & CSS. It’s a bit overwhelming knowing where to begin with all the versions and types of web coding. I landed on a book that I really enjoyed: Head First HTML with CSS & XHTML. Of the books I looked at, this one was by far the most engaging book on the subject.

Most of the reasons why the book was so interesting are also principles of good design:

  1. It is highly visual. Good images are more memorable than just words and make it easier to learn and understand concepts.
  2. Explanatory words are placed right alongside illustrations, rather than referenced elsewhere. It was very easy, for example, to look through code samples that were annotated line by line.
  3. Concepts are presented in multiple ways to accommodate different learning styles.
  4. Appeals to the emotional desire to have fun while learning are incorporated, through humor, fun games and realistic exercises.
I highly recommend this book for anyone interested in understanding more about the topic. You won’t finish the book ready to go straight to Dreamweaver and whip up a complex web site, but you’ll definitely know enough to be able to understand what’s going on under the presentation layer hood for most web interfaces.


Prioritizing your primary users’ tasks

I’ve done this several times now, and I bet I’m not alone. I go a popular web site to look at used cars. My eyes scan for the first input area, which is how the majority of users who have a specific task in mind approach a page, and I immediately see a series of search options near the top left corner. I select a make, a model, a maximum price, specify the search radius, and click Search…wait, what? Search New? That is not what I expected. I was looking for a used car. Now, after making four choices already, I have to start over again in the Used Cars area.

While this is not a show-stopper — I now know what I have to do — it’s extremely annoying and indicates an interface that wasn’t designed with primary and secondary users in mind. A vast majority of those in the market to buy a car are looking at used cars. Though I know this intuitively, a brief search for supporting data demonstrated that 41.6 million used cars were sold in 2000 vs. 5.5 million new cars, so about 88% of all car sales were used. I can only imagine how much higher that is in these economic times.

Because this is a primary user task, the task “search for a used car” should be the top priority on the home page. It would be so simple to swap the location of these two search elements. Some variation in styling would help set the two apart as well, since they have the exact same components. For that matter, why the repetition of search inputs at all? Two buttons could appear under the same input area, one for searching used cars and another for searching new cars.

Probably a less common use case but still one that seems reasonable is a search on both new and used cars. Maybe a person is not sure what they want to buy, and wants to see the difference in prices and features between new and used cars. This particular site currently offers no way to search both, even in the advanced search. Why force users to make a data set choice when they may not want to? Both of these issues could have been avoided by a good definition of the primary users and their key tasks.

How much do you know about your users? Do you have user profiles or personas created for your primary and secondary users? Have you watched them use your site? Have you spent time with them to learn more about their needs, goals and desires? Do you regularly review, interpret and react to your web analytics and search logs? These types of activities are foundational to user experience development, and if you create a product that people use, you should be involved in a variety of these activities on a regular basis.

Contact Perficient today to see how we can help you improve and fine-tune your user experience.

HTML target=”_blank” attibute: to use or not to use?

I’ve had this discussion several times in my career in the user experience field: Should this link open in a new tab/window (HTML link attribute target=”_blank”) or in the same window? My understanding has generally been that if the link goes to an external site or to a help or informational-type page, it should be opened as a new window along with some affordance that the link goes away from the site (per WCAG 10.1). However, I dug a little deeper into the pros and cons on this topic and found a number of good arguments on both sides.

Let’s go over the reasons to use a new tab/window first:

  1. For external links, a new tab/window more clearly communicates that the destination is an entirely separate site, and doesn’t “close” your site at the same time.
  2. For external and help or informational links, both windows can be viewed simultaneously, assuming the target window is sized appropriately.
  3. With the newer tab-based browsers, users have a much easier time managing multiple open URLs and even prefer this to a long history in the same tab.
  4. With mobile devices, new windows are better than same windows because if the user wants to go back to the previous page, they don’t have to reload it.
  5. Users with multiple monitors like to have separate windows to display on separate monitors.

Accessibility tips

I recently listened to an interview with accessibility expert Derek Featherstone. He provided some of the following practical and valuable tips for Web accessibility.

  1. A site designed to conform to good usability, copywriting, and Web standards goes a long way to making a site accessible. Things like using the proper heading structure (H1 on every page, followed by H2 instead of H4, etc), making sure all form fields have labels, and conducting usability testing are all strongly recommended.
  2. Make sure that you can do everything on your site efficiently with a keyboard. You can include this in your test scripts.
  3. Be careful if you’re using HTML5, because not all browsers and operating system combinations support it completely.
  4. Don’t worry too much about JavaScript. Most screen readers can handle it.
Of course there are many more guidelines and standards in Section 508 and WCAG, depending on your accessibility requirements or desires.

Mega Menus: Spool vs. Nielsen

Today UIE’s Jared Spool posted an article criticizing mega menus. I’ve confidently designed a couple of these based on Jakob Nielsen’s assessment that Mega Drop-Down Navigation Menus Work Well. I’m not convinced that “mega menus aren’t evil, just troubled” based on Spool’s article.

My primary issue with the article is that five out of the six “epic forces battling your mega menus” simply don’t apply only to mega menus. The first point – that there’s no visual clue that mega menus exist – is not inherent in mega menu design. Mega menus can have the same affordances as a standard menu. Options can be styled like buttons, and I disagree with the assertion that “no de facto standard has emerged to help designers communicate when mega menus are hiding behind navigation links”.  A down-pointing arrow next to each horizontal menu item or a right-pointing arrow next to a vertical menu item is a pretty standard affordance (see or This affordance implies a hidden secondary menu; no need to have anything additional identifying the menu as a “mega menu”.


QR codes for the dead

Did you ever think your smartphone would come in handy at a cemetery? The Seattle Times recently reported on the use of ‘living headstones’ affixed with QR codes. The destination site includes a history and pictures of the person’s life.

The codes are offered by Quiring Monuments, who have sold about three dozen in the past few months. The monument maker’s web site shows the image to the right as an example of how the code will look and work (see the site for the sample memorial page).

One thing I find interesting about this service is that the site is password-protected. I wonder how many people will be willing to set up an account to view information about their loved ones. However, it might be a useful way to connect future generations more easily with their past, and could be a nice way to pull in genealogical research.

What are your thoughts? Will this take off or is it a fad?


Sharing Axure Prototypes

Perficient UX team members often use Axure to create design prototypes. We prototype varying levels of fidelity based on the stage of the design process and the particular project’s needs, from basic wireframes to advanced interactive prototypes. A generated prototype includes HTML and JavaScript files as well as associated images. If you don’t have a dedicated server and URL for staging and hosting, these files can be challenging to share with clients for review and feedback.

Fortunately, Axure has a newer feature that allows for easy distribution of prototype files. AxShare, using Amazon Web Services, was developed by Axure as a way to generate prototype files to the cloud for others to view. Simply create an account, upload a prototype – 10 MB or less – and within a minute or so, a URL is generated that you can send to others for review. You can add password protection if desired. There’s also a discussion feature, though currently not very robust, that allows viewers to add page-based comments to the prototype.

One limitation is that you cannot have more than 10 active prototypes in your account, which shouldn’t be a big deal unless you like to save prototypes as examples. Another potential concern is that each version of your prototype generates a new URL, so if you are doing rapid prototyping with frequent reviews, you don’t have one place that people can go to see the latest and greatest.