Examples of Mobile Design: Anti-Patterns

This entry is part 3 of 3 in the series Mobile Design Patterns

Mobile Design Patterns

In the first article we’ve seen some useful tips and tricks for better organization of forms, galleries and search functions; in the second one we’ve seen, through some examples of more or less known applications available in the marketplace, which are the most common mobile patterns used to give suggestions, make invitations and provide feedback.

In this article, the last one in this series, you’ll discover the most common anti-patterns and understand why and when to avoid them. Let’s discover more about the world of the so-called “anti-patterns”.

What are Anti-Patterns?

As for the definition of “pattern”, let’s see what Wikipedia says an “anti-pattern” is:

An anti-pattern (or antipattern) is a pattern used in social or business operations or software engineering that may be commonly used but is ineffective and/or counterproductive in practice.
The term was coined in 1995 by Andrew Koenig, inspired by Gang of Four’s book Design Patterns, which developed the concept of design patterns in the software field. The term was widely popularized three years later by the book AntiPatterns, which extended the use of the term beyond the field of software design and into general social interaction. According to the authors of the latter, there must be at least two key elements present to formally distinguish an actual anti-pattern from a simple bad habit, bad practice, or bad idea:

  • Some repeated pattern of action, process or structure that initially appears to be beneficial, but ultimately produces more bad consequences than beneficial results;
  • An alternative solution exists that is clearly documented, proven in actual practice and repeatable.

Many anti-pattern ideas amount to little more than mistakes, rants, unsolvable problems, or bad practices to be avoided if possible. Sometimes called pitfalls or dark patterns, this informal use of the term has come to refer to classes of commonly reinvented bad solutions to problems.

The first thing that many web designers intend to do when they start developing a project for a new customer is to work on interfaces that they want to be new, edgy, creative, and innovative. It is not unlikely, however, that the effect they wish for is not the one actually produced. On the contrary, most of the time they’re just bad, hard to understand, and harder to use.

What a good web designer should always keep in mind is that during mobile app development they should try to work off an old web development background. Creating interfaces for mobile applications is not merely the act of translating old user interaction models to a new platform. People often assert their “creativity” and “innovation” by introducing non-standard UI elements, which is no good at all.

Recently, developers have been paying increasing attention to the good principles to be followed in the creation of graphical user interfaces for mobile applications. For this reason, many of them are making appropriate changes on existing apps and it is not always easy to find more or less known models of anti-pattern. In this regard, I have considered it more appropriate to provide you a mini-series of “rules” (or if you prefer, tips), a sort of guide to follow in order to avoid realizing an unwanted anti-pattern:

  1. Offer one-click access to the main page: let your users easily come back to the home page of your mobile application in a quick and intuitive way.
  2. If you want to insert a “Contact us” link, remember that it would be better positioned in the top right than in a hidden footer: clear, visible and easy to click.
  3. Remember to style tabs so that each one of them has its own icon, for example, and that the selected one has some features that distinguish it by others, such as a color or effect, so that the user knows in which space they are operating.
  4. If you are looking for a way to innovate with your mobile app, think about and focus on your core features, on what you intend to offer to your users, on what could be their problems and needs and rely on best practices for the interface design. If you design a custom control, don’t forget to test it and improve it to make sure it is simple to use.
  5. Users expect familiar icons to offer specific features, so choosing a familiar icon and using it in an unfamiliar way will cause confusion. Do you think this system to add people to the “Favourites” category is correctly thought out?

    fig1

  6. Avoid the so-called “Idiot box” and use more effective and less disruptive techniques to provide feedback or go on with navigation.
  7. If you want to display a set of data on a chart, remember to visually represent only elements in charts and graphs that are necessary to communicate the information represented on the graph. Useless data only creates confusion and slows the whole process. Look at this example:

    fig2

  8. Don’t let your users loose in an ocean of … buttons!

    fig3

    Use standard patterns for displaying page level actions and provide contextual tools for item level actions rather than repeating the same button.

Conclusions

We’ve come to the conclusion of this mini-series dedicated to mobile design patterns.

I hope the topic was of interest to you and that these three articles will be helpful for your future works.

I’ll be back soon to talk about the design of interfaces for mobile applications. Thanks for your attention.

Mobile Design Patterns

<< Examples of Mobile Design Pattern: Part 2

Free book: Jump Start HTML5 Basics

Grab a free copy of one our latest ebooks! Packed with hints and tips on HTML5's most powerful new features.

  • Anonymous

    Good job! I really appreciated all of your articles.
    Waiting for the next..

  • TomJ

    A couple quick questions. In item number 6, what is the “idiot box” you refer to? I’ve never heard that term before, so I don’t understand the point you are trying to make. In item number 8, I understand what you are saying here, but do you have an example of a better way to approach that problem with the invoice example you provided? I think you bring up a lot of great points, and I understand the desire to be brief/concise in your writing, but I think your writing (in general, as I read a lot of your articles!) could be even more effective if you explain things a little more or provide more concrete examples rather than relying on the reader to already know what you are trying to say.

  • Jimmy

    Example 8 looks pretty good to me – clear, concise, straight-forward – what would you replace it with. The whole context of that screen needs to be considered of course, but I just don’t understand what you are getting at.