Mobile Web Mistake

1. MYSTERY MEAT NAVIGATION

Not a new term in our industry, ‘mystery meat navigation’ (en.wikipedia.org/wiki/ Mystery_meat_navigation) was coined to categorise a usability nightmare that was quite popular in the early days of the web: image-heavy navigation without textual labels to describe each option. Somehow we seem to be OK with unlabelled navigation icons again. A group of five buttons with no descriptive text to tell you what they do? When did that start making sense?

With so little room on your typical mobile screen for the icon bar, cramming in text labels often feels a step too far, and with mobile operating systems themselves offering many native examples of this type of navigation treatment, it’s easy to follow their example. And while we’re talking about unlabelled interactions, gestures count too. If your users need to be trained to perform a gesture, the chances of them finding it on their own are very slim. Who hasn’t seen the YouTube videos of babies using iPads? They demonstrate how discoverable simple, natural gestures with obvious target areas can be. Tapping, swiping, and pinch to zoom are so intuitive that no instruction manual is needed. You can easily understand an interface that implements those well. However, even the more common gestures can benefit from good labelling. Apple’s first implementation of the iOS 7 lock screen accompanied the ‘Slide to Unlock’ message with an upward-pointing arrow at the bottom of the screen, which confused users into assuming a slide up would unlock when in fact a left-to-right swipe is required. This was ultimately changed for the final release of the operating system. ‘Why did that happen?’ is a great symptom of mystery meat. When users experience a behaviour that they can’t explain, it’s doubtful they understand what caused it or how they can duplicate it. Therefore, it’s unlikely to be a behaviour that they will use. So how can we change this for the better? Visual cues are essential. If a user is expected to perform an action, there should be a clear visual indicator that the action exists, as well as clear hints about what

2. UNOPTIMISED ASSETS

The number of individual HTTP requests is an important factor of a site’s performance. Each one requires a separate connection. Too many open connections bogs down loading times. To address this:

CSS files – the fewer the better. If we split our CSS across many individual files to aid management, that creates a performance hit at render time. There’s nothing wrong relying on many CSS files in your workflow, but use tools like Compass and LESS to compile them at build time.
·Images – CSS Sprites are the short answer here. Combine multiple images into a single one, and use strategic background position values to mask out the one you’re after later. Sprites are becoming a less valuable tool over time, so they’re best used for common interface elements and the pieces of your site that won’t change. But CSS effects are increasingly powerful, and graphic styling tastes have changed to require fewer effects. The need for UI imagery is rapidly reducing. If you can, use CSS styling.
·Vector graphics – SVG is great, but it doesn’t sprite well (codepen.io/adrianosmond/pen/LCogn). Web Fonts offer us a more performant way of encapsulating multiple vector shapes in a single file. They’re more limited with only single colour rendering, but that makes them well-suited to UI imagery. The problem is creation.
Two tools I’ve found effective:

IcoMoon (icomoon.io) is a web app for importing SVG shapes, assigning characters to glyphs, and saving as a web font with cross-browser compatible files and CSS syntax.
Font Custom (fontcustom.com) continuously polls a directory of vector images and rebuilds the contents of the directory to a single output web font when it detects changes.
Since web fonts are treated the same way as type on your site, you can use any CSS type effects, such as text-shadow.

3. 24-BIT PNGS

24-BIT PNGS Strangely, we seem to be increasingly comfortable with uploading files we’ve saved from Photoshop directly onto our servers without further optimisation. In the case of our transparent PNGs, this is particularly disastrous. The problem was highlighted a few months ago by a website (hawksworx.com/blog/oakleys-monster- page-of-baubles). This single-page site weighed in at a whopping 85.4MB. A lot of this was due to unoptimised PNG-24 images. Curious to see what sort of savings were possible, I ran one of its images (1,468KB original file size) through my PNG optimisation flow. First, I halved the image size without much quality loss by dropping the colour level to 64 bit using an app called ImageAlpha (pngmini.com). Then, I passed it through another app called ImageOptim (imageoptim.com), which throws a handful of optimisation techniques at any image you give it. As a result, it shaved off a further 10 per cent from the overall file size. I got it down to 472KB, which is a third of the original size. If I’m willing to play with the newer WebP image format, I can shrink it even further to 316KB. WebP requires detection for support and serving a fallback image (github.com/igrigorik/webp- detect) for browsers that haven’t implemented it, but if download speeds are my priority the extra work might just be worth it. The resulting images were nearly identical, especially when viewed in context as an element of a page I quickly scanned. Not every image on the web needs to be saved out at maximum quality. Most can get away with significantly less than our modern defaults. Keep in mind that our users will not scrutinise our images the way we do, and likely won’t even notice the lower quality.

4. 600PX EMAIL

When we talk about how we design, we often overlook the inevitable emails that our sites and apps generate. It’s an unglamorous subject. HTML emails require a lot of ugly coding, and most of us in the field prefer plain text. But we often have to create them. If we’re going to spend time making sure our sites are a pleasure to use, surely the emails that we send out deserve the same treatment?

A common standard for universal inbox support is a 600 pixel wide layout. That number comes from a time when only desktop inboxes were considered. But mobile screens are often smaller than 600 pixels wide, so emails that use that number start zoomed out so the contents fit the screen. The resulting tiny text forces a user to zoom in before they can see what the email is about.

“There are useful starting points for

responsive emails we

should be using”

Responsive email templates are, in fact, possible. Like all things HTML email, they’re not at all easy; arcane hacks and workarounds should be expected. Luckily, others have done much of the hard work for us. There are responsive email templates out there we can use as starting points. One of the best I’ve seen comes from Phil Wareham, his responsive template (github.com/philwareham/responsive-email) is a masterpiece of deep knowledge of the inner workings of email clients. Because reading a desktop-optimised email on a mobile device is such an awful experience, and because there are useful starting points for responsive emails, we should be using these in our work when possible. Speaking of email, another common mistake to be aware of is missing email summary text. Many clients attempt to show you the first couple of lines as context instead of just the email’s subject. If the first few elements in your email’s DOM are images or other non-textual markup, the potential for garbage appearing in your summaries is high. As a case in point, the iOS Mail inbox. This is why those in the know recommend a textual summary of the email’s contents somewhere near the top, before your content. (You can always hide it with display:none ).

10 As an industry, we’ve spent a lot of time convincing ourselves the fold is dead. The debate is over. People know how to scroll. Right? Well, there’s one place where it could still matter: actions connected to revenue. Any key business conversion tool like ‘Add to Cart buttons’ or ‘Get a Quote’ links should probably be visible above the fold. Compare these two product pages: At Mobify, we’ve experimented with button position, and we’ve seen conversions increase when it becomes more obvious. You won’t lose truly motivated customers without a visible ‘Cart’ button, but it may just be enough to lose any would-be customers that only have a passing interest. If you can take a given page and distill its purpose down to a single action you’d like a user to take, their ability to do so without scrolling is likely to perform better.

CONCLUSION

I introduced this article with a personal account of a bad mobile experience. It finishes with a cautionary tale. After my frustrating session of form errors, I finally managed to book my room and receive a confirmation email. When I arrived at the hotel, I discovered they weren’t actually expecting me. Through all of the form re-submissions as I attempted to fill out the booking form, I must have missed the date fields getting reset along the way. Consequently, my stay was accidentally booked for the night I made the booking, not the night I intended to arrive. I’m still owed a hundred bucks because of a bad mobile experience. Let’s stop racking up the debt. Hopefully, by reading this feature, it’ll help you to identify mobile design anti-patterns in your own work projects and thereby contribute to improve the mobile web experience for all.