The Mobile Web and UI/UX

While some companies are already taking the plunge and creating mobile applications for the various platforms, still others are hesitant to enter that space. Whether they see it as a fad or something that’s not worth the effort, one of the best ways to take a step towards mobility is to create a mobile site to complement your desktop experience.

When mobile first became popular, this was hard to do, needing lots of custom CSS and thus having a high development cost, today mobile sites are very easy to make with the help of libraries such as jQuery Mobile. jQuery Mobile contains everything you would need to create a mobile site, and can be created with plain html (and maybe some CSS tweaking for theming). This solves the technical hurdle, but the real issue is that you need to recreate the entire user experience for mobility. The desktop experience and the mobile experience do share some commonalities, but there are special considerations, especially with regards to mobile websites.

Real Estate is Limited

This is the hardest part about mobility: there isn’t enough space for everything on your desktop site! The first priority might be to look at all your information, and see if you can either move it to other pages, or remove it all together. Designing a mobile site is not a matter of just taking everything you have and making it so that it fits on the screen and doesn’t scroll horizontally. Users do not want to scroll through tons of content to find what they need. In an ideal world, there is no scrolling at all, unless it is textual information.

Even on a form factor like a tablet, you shouldn’t have to scroll all around the page to find the information you need. It should be right there, or on another page. Jump lists are a great way to take a handful of links, and compress it down into one on-screen button. This saves you screen real estate, as well as giving users a uniform place to look for links to other pages (so make sure it stays in once place throughout the site!)

Links Are Buttons

Textual links are a great thing when you have an exact pointer like a mouse. Mice are precise and accurate. Fingers, on the other hand, are not.

We still need links though, and that is where buttons come into play. Buttons solve two issues: size and visibility. It’s easy for links to get lost in a wall of text if you’ve changed the default link color to something other than the bright blue of the default link color. They are also hard to click, especially if they are close together, and force your users to either zoom in to the site, or try multiple times to click the link that they want.

Buttons are large enough to be clicked easily, and should provide enough spacing between links for accuracy. And we don’t need to have large buttons. Looking at pictures of mobile applications should give you an idea or the size you need. You can also tell if the buttons are too small by trying the site out on your mobile device, and seeing if it is hard to click the correct button.

Fixed Anything Won’t Work for Mobile

Long time designers are familiar with the 960 pattern. It is a design pattern that breaks the web site into twelve or sixteen columns, for a total of 960 pixels in width. This is great for fixed-width sites, because even at a resolution of 1024×768 (the smallest resolution a full-screen website on a small monitor will typically support), you can still see all the content without horizonal scrolling.

The problem with mobility is that there are no fixed dimensions for the screen. There is no minimum you can assume to support, because the reduced screen real estate means you need to use every pixel. As such, designs must be reactive, and use all the available space. Some groups have already adapted the 960 grid system to support mobility, such that elements will compress or expand as the device is rotated or different devices are used. For instance, your desktop site will show in standard 960 pixel format. On a mobile phone, elements will compress down to a few columns so that everything will still be visible without scrolling, and you can hide or show certain elements depending on the resolution. These systems should become the new norm for website design, as mobility is fast becoming the preferred way for users to access information and interact with web sites.

If you are looking to evaluate these multi-form templates, you might try Boostrap by Twitter, which just launched support for multi-device scaling sites.

Flash? Silverlight?

Let’s be clear: if Adobe isn’t even supporting Flash on mobile devices, it’s time to admit that Flash is a dying technology. While many sites still utilize Flash, on a mobile site you are likely to either get poor Flash performance, or nothing at all, meaning users visiting your site will see nothing at all. That’s a quick way to lose a sale or a customer.

And Silverlight? Not supporting on anything but Windows Phone 7. If you are taking advantage of Silverlight, you’re in the same boat as Flash when it comes to mobile web sites.

If you still want some of the animations and other features of Flash and Silverlight, take at a look at HTML5, the new standard for HTML for both mobility and newer browsers. It adds a lot of missing features into HTML, including animations using the Canvas element. Companies such as Zynga are already writing full blown games in HTML5, so it should be more than capable of handling your site with great support on mobility as well as most newer desktop browsers (except Internet Explorer, which is lagging behind the pack in HTML5 adoption). This transition will help future-proof not only your mobile site but your desktop site as well.

Bonus: Take Advantage of Gestures

One thing you can’t do on a desktop is gestures. Swiping, pinching, and other multitouch gestures are not found on desktop browsers. You can utilize gestures to make your site feel more like a native application. If you have a picture carousel, for instance, you might turn that into a touch-friendly version on your mobile site, and allow your users to swipe to change pictures. This increases interaction with your site as well as bringing a sense of familiarity that a non-gesture-supporting site won’t be able to match.