Lately, it seems I’ve been experiencing a rash of extremely uninformative and even appalling error messages on 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.
 
 
 

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

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!

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’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.

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.

1. You “break the back button” because the user does not have a back trail of URLs.
2. Users get confused by new tabs/windows.
3. Users have too many tabs/windows open if this gets overused.
4. If you force a new window, users who don’t like that functionality have no choice, whereas if you use the same window, users can use CTRL+click or right-click/Open in New (or with some mouse controls, a dedicated button) to choose whether or not they want a separate window.
5. Your web statistics won’t be as reliable because this will create artificially longer visit times when users are actually on other sites. Note: this is typically handled by a forced timeout after a designated amount of time without activity.
6.  If the user clicks the link to an external site, it likely means he/she is done with your site, and it will irritate them that you have left an unwanted tab/window open for them to close.
7. Some screen readers do not notify users when a new window has opened, causing accessibility concerns.

Thoughts or input? Please share.

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.

Portals often have highly complex information architectures. A design pattern that has become popular in the past couple of years to deal with this complexity is the “mega menu”.  A mega menu is a large, often two-dimensional drop-down panel that is displayed for one of more global navigation items, in which options are grouped into categories and typography, icons, and other imagery are used to help identify choices. ESPN.com is an example of a site that uses mega menus extensively.

Leading user experience voices Jakob Nielsen and Jared Spool have both published differing findings on the efficacy of mega menus. While Nielsen finds them to be effective, Spool says they are problematic and has described clients experiencing lower revenues and KPIs after mega menu redesigns. I address Spool’s points in a recent blog post on our neighboring Spark Blog; see Mega Menus: Spool vs. Nielsen.

What do you think? Have you experienced any reduction in effectiveness as a result of a mega menu redesign?

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 OfficeDepot.com or Walmart.com). This affordance implies a hidden secondary menu; no need to have anything additional identifying the menu as a “mega menu”.

The second, third and fourth “epic forces” are not at all unique to mega menus, but rather are issues with any secondary navigation that is hidden by default.  These relate to users finding trigger words, understanding category names, and having to move their mouse before they know where they want to go. These are all good critiques of any secondary menu that is not visible by default, but do not only apply to mega menus. I’d grant that mega menus tend to make you want to have a very basic and high-level primary menu where the category names might be vague, but that can be avoided by a carefully designed and tested information architecture.
The fifth “epic force” is the only one that really applies solely to mega menus – that they eat up a lot of real estate that might cover something the user wants. This only happens if the user accidentally hovers on the menu item though, and can easily be managed by implementing a proper mouseover delay (Nielsen recommends 0.5 seconds). 6/26 update: See Neo Insight’s excellent article for additional timing details. Therefore, I don’t find this to be a very compelling point.
I do agree with force #6 in general – hover events don’t work on hover-less devices, so that’s an issue – though again, it does not just apply to mega menus. Spending a lot of time developing content in hover events is problematic because of mobile devices, so if you expect your site to be frequently used in mobile settings, you might want to think twice about designing mega menus. You’ll either have to set the menu to display on finger tap, or be sure to design a landing page for each category that lists all the secondary menu options.
Spool’s report that their clients saw sustained drops in revenue and KPIs after rolling out mega menus does give pause. I would weigh it more considerably if I knew how many clients this happened to and how they specifically designed their menus and overall site. For now, I continue to concur with Nielsen, that used appropriately, mega menus have several advantages, including:

• They show everything at a glance.
• They support grouping and the ability to visually emphasize relationships among items, including varied font attributes.
• They allow for the use of icons and pictures for illustration.

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?
 

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.

Just recently came across this comic and had to laugh. University web sites are notorious for not providing key information for their primary users. What’s on your home page, and is it the most relevant information for your audience or is it what your business wants to place there?