Back in 2011, Mobile First perhaps was ahead of its time. I say “perhaps” because while mobile was nothing new, it was far from perfectly usable as far as surfing the web was concerned. But the web world caught on quickly and businesses started adding to their digital strategy a second site made for mobile. Mobile First, as the title would suggest, aims to go one step further and explores the idea as to why “websites and applications should be designed and built for mobile first.” There are several reasons, but the most critical reason I believe Luke cites is the fact that a mobile layout “forces you to focus and prioritize your products by embracing the constraints inherent in mobile design.” Less is more.
I work on many B to B web sites. The sites I work with statistically have proven the idea of mobility to be “aléatoire” or at least inconsistent in usage with the given target markets. Some of our sites show little sign of mobile connection, while others are showing easily a 100% increase with smartphones or tablets from one year to the next.
No matter the statistics, and Luke backs his findings with tons of data, today in 2013 mobile is a fixture everywhere, for every business. Mobile gives people access to sites anywhere at anytime. Why people use mobile to search info and browse the web is still up for debate, but I would venture that even if today’s use is largely, but not only, reserved for urgent on-the-go matters, in a few years time most of us will use mobile devices for all our web browsing needs.
It’s up to us to prepare our clients for this usage.
Let me start with Luke’s conclusion : “reduction is the best layout approach available to you on mobile.” I can’t agree more, and I would say reduction is the best layout approach for most any screen, small or large. To prove his point Luke scatters his ebook with loads of examples and screenshots on best practices.
But Luke’s book is more than just screenshots. It’s about applying excellent ergonomic techniques to mobile. The best way to see how Luke’s ebook Mobile First can be applied in real life, I decided to do an audit of a mobile website I worked on with my company. Most of our sites are now built “responsively”, or websites that adapt automatically to the screen-size. But it happens that this cannot always be done. For example, an older website that does not merit a complete rehaul will undergo an enhanced version for the smartphone. In those cases we attempt to identify the information most important for such use. Overall, I think websites should have the same content across multiple platforms and devices, but the content priority will be different, sometimes slightly, sometimes more, according to the device. Other ebooks (See Karen McGrane’s Content Strategy for Mobile) have dealt greatly on this point.
Or we can build a mobile dedicated site, such as is the case with Elyade. In this example, the demand was to build a mobile platform destined for their partner sellers. We did this mobile version about a year ago, well before I read Luke’s ebook. Let’s look at his points one by one to see how we did.
Site: mobile.elyade.com. Overall it is restricted for partners to reserve a “lot” (an apartment) for their clients. It has to be quick and to the point. Therefore, partners have access only to four major links as well as downloading their recap in excel format. Here are the screenshots of the first elements when navigating:
1. Use image sprites: we did not use sprites, but I do not consider that an issue for this example. I could be wrong.
2. Minimize the amount of navigation options: on the home page, five easy choices, very clearly spelled out. However, there is no link to see the desktop web site, though this is voluntary.
3. Size of and space around touch targets: we were very diligent to ensure spacing and target sizes. There is no back button, as we left that up to the device. We removed the logo, as it is a restricted area.
4. Screen density: I have no idea what our PPI was for the images used. This will have to be checked to the recommended 44×44 points. This wasn’t much of an issue on this app as there as few images and we rely heavily on CSS3.
A. top-aligned labels/labels inside input fields: we chose “inside” but we were not consistent across all forms. We did however insure that the label disappears as the user types the info and the color is darkened.
B. autocapitalize: we did not turn this off for the user-name, something that Luke suggests we do. I agree and we should have a correctif later.
C. autocorrect: same, we did not turn this off for the user-name, but should.
6. Hovering of navigation items: though we highlighted most links and buttons when touching (thanks to CSS3), this was not the case on the home page, most likely because we opted for images. Though that might have been arguably the appropriate choice considering the graphics, we could still have presented a highlight on-touch.
7. Placement of navigation controls: following Luke’s “one eyeball, one thumb” rule we placed most validating buttons on bottom while making “deconnexion” difficult to reach. We also paid attention to proper spacing, going beyond in most cases the recommended minimum spacing of 2mm.
8. General navigation: When navigating from the home page to the search form I say we get high marks. But our reservation form, according to Luke, would lack user experience common sense. The form has too much spacing between the fields (though this may be a browser debugging issue). We have a “date de reservation” field that cannot be modified, but it looks exactly like a modifiable field. Then we repeat most labels top-aligned and inside. This is useful for specifying the format, so we could have easily labeled differently the inside comment with an instruction, to be consistent. Our select menu on an iPhone is automatically well-rendered, but the labels are still too long for older versions.
And then there is the cancel button “annuler” right at the sweet spot, whereas “Réserver,” (to reserve) not to mention being cut off, is further from the right thumb. After filling out that long form, wouldn’t it be unfortunate to hit cancel accidently, even if there is a warning, and redo it all. This should be rethought for a later patch, most likely just delete the cancel button.
9. Viewport: We applied the suggested width=device-width.
There are many more points that Luke details in Mobile First. But just by nurturing the main issues that I selected should help us tackle any mobile device with greater care to user experience.
Personal thoughts on why this ebook is a must
Mobile First is an ebook must for any web agency looking to develop sites and apps for a mobile audience (which should be all of us by now). This is not about what’s the best way to develop, but what are the important UX factors to note when developing (whether responsive, adaptive, or other). And, of course, I always enjoy like minded philosophies where less is truly more.
Title of book : Mobile First
Author : Luke Wroblewski
Date of initial publication : 2011
Publisher : A Book Apart
Where you can buy it : abookapart.com