- Choosing a Proper Layout for Mobile
- Working with Components
- Considerations When Going Mobile
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Working with Components
Everything in your site can be broken down into components. Sometimes these are simply elements. Other times, they are groups of elements. A search input, a navigation menu, and sliders are all examples of elements.
When creating the mobile or smaller versions of your site, you need to take into consideration what should happen to each of these elements.
Navigation
No matter how brilliant your current navigation system is, odds are, you will need to change it to make it fit on smaller devices.
You could always wrap the navigation to a new line; however, this often looks sloppy and comes across as lazy. Still, this will work if your navigation is text based and if you can align the words so that they are balanced and the line looks intentional instead of heavy on one side. If your navigation is reliant on hover states or mega menus, you will need to create a new system or method for handling all your links.
You should consider two other methods when you are compressing your navigation. The first is to use a menu that drops in, and the second is to use an off-canvas solution.
Both solutions require the use of a menu button or icon that will take the place of your text.
Applying a menu that will drop in requires either using multiple layers, injecting a block of code on a click or tap event, or using classes to change the height and visibility of the content area.
Using an off-screen navigation solution is similar, but it slides in the menu by using animation (either JavaScript or CSS3 transitions) to make the content appear. This should be familiar to you because it is the type of solution Facebook implements in its mobile application and is also used in many Google products as a way to access the menu. Google+ and Google Music use this type of navigation to give you access to settings, playlists, images, groups, and more.
Because every project is different, you will need to play with the breakpoints for when your site navigation changes from text to the menu change. Figure 8.5 demonstrates a site displayed at different sizes, with the navigation changing.
)
Figure 8.5 As the site is viewed on smaller devices, the navigation changes so that it is hidden until activated by the Menu button.
Some plugins might help you with your off-canvas navigation:
- Foundation Zurb (http://foundation.zurb.com/docs/components/offcanvas.html)
- Twitter Bootstrap (http://getbootstrap.com/examples/offcanvas/)
- Pushy (www.christopheryee.ca/pushy/)
Search
Unless your site has an absolute absence of content, you probably have a search box. The good news is that this particular search input adapts very well to mobile layouts.
Depending on your developers, there is already a fantastic chance that you are using the proper input element. HTML5 introduced a special input element made just for searching. It looks like the following:
<input type="search" name="search" />
The benefit of using the search input for your search is that mobile browsers can change the keyboard that appears to use it, and they can even add an icon and show you previous search entries when the field is activated.
The drawback of using this input is that some browsers automatically style the input to match the styles of the OS. For example, iOS rounds the corners of the input to make it appear like the default search element of iOS. This is good because the user can visually understand that it is a search field, but it is also bad because it could throw off your design (rounded corners on a flat design or a second magnifying glass added to the one you have already put on the page).
You have several options for handling the display of your search bar. You can choose to put it just below the header (which contains your logo and menu buttons) of your site, or you can choose to place it in the drop-in or off-canvas navigation area.
Either option is fine, but you should do some A/B testing, use heat maps, or apply other testing methods to make sure the search remains accessible and easy to find. Mobile users can be a finicky lot and will leave your site if they can’t find what they need as fast as possible.
Content Areas
You might not give much thought to the content of your site, but if you are running a comparison site, an eCommerce site, or an informational site, you will run into the problem of having tons of content and not enough screen to properly display it all.
You have three common solutions for handling this particular issue:
An accordion (or drawer) shows a particular title or question. The content is hidden until the title is tapped or clicked, when the accordion opens and shows the hidden content. This is commonly used on FAQ pages and pages that want to hide content-rich areas until the user has activated them.
Note that some accordions allow only one section open at a time and automatically close any other open sections. Pay close attention to your user testing to make sure you are not frustrating users who would like to have multiple sections open at the same time.
- Tab systems are useful to display short terms that then open content areas that the user can then go through and view. This particular system suffers from the same autoclosing feature of some accordions and also forces you to cram buttons and text into a small space. This system works best on medium-size screens, but you can also use it successfully on smaller screens if you pay proper attention to text or icon size to activate the tabs.
With a grid system, you have the option of arranging your content into columns. As the screen size of the device viewing your site shrinks, these columns will start to compress until you decide that the content is no longer legible. At this point, you can “break” the columns so that they take up 100% of the available width instead of the preassigned 25%, 33%, or 50% of screen space.
The downside to using columns to break apart displayed content is that your pages have the potential to get very long. I’m not talking about a couple hundred pixels long—more like a carpel tunnel–inducing, finger-sprinting marathon of a page of long swipes. You should stick to using this particular style of content display for smaller content areas.
Sliders
I’ll skip the discourse on sliders because I know that, when it comes down to it, some people will tell you that they absolutely need one. In addition, when you are working on retrofitting a site, you will need to know how to handle them.
First, because speed should be one of your primary objectives, you need to remember that sliders are inherently slow. This is the result of having to load multiple images into an area and then get them restyled so that they can be displayed in order. DOM processing is also slowed, and mobile devices will have to work harder to download, inject, and then redraw all the images on and off canvas as needed. Another side effect that you might not be aware of is the tradeoff in battery life. As the mobile device works harder to display your page, CPU and memory are used more and battery life can be affected.
Second, sliders are problematic on mobile devices because of the “pause on hover” effect that no longer works with mobile design. With this effect, the slider on a desktop would normally continue to show one slide after the other, but it stops when the mouse cursor is hovering or stopped on one of the slides. Mobile users might also become frustrated with sliders when they do not respond to screen swipes and when the users have no way of pausing or stopping the sliders.
Many mobile users are comfortable with the concept of swiping to move content around, but when that behavior is unavailable or seems to act funny due to slide timing, this can be a source of aggravation.
To successfully use a slider on mobile devices, remember the following:
- Let users move the slider.
- Make your slider touch/swipe friendly.
- Minimize the amount of data or number of slides in the slider.
- Load content by use of a deferred method (such as lazy loading) so that the site does not appear broken or waiting to load content.
A couple sliders that work well with mobile devices are BXSlider (http://bxslider.com/) and Owl Carousel (http://owlgraphic.com/owlcarousel/).
Links
A major consideration when moving from a desktop-only site is the size of your links. You might have noticed while visiting various sites that buttons and links are much larger when viewed on mobile devices. This goes deeper than just the Web: The developer guidelines for Windows Phone, Android, and iOS also specify that touch targets, or areas where the user can tap, should be big enough for a finger to tap.
How big is that, exactly? Well, it varies, and various pixel density values can make it somewhat difficult to narrow down. However, the following sizing values will get you started in the right direction:
- Use a minimum size of 34px by 34px, but consider using at least 44px.
- The width of your target can be longer than 44px, but the height should be at least 34px.
- Be sure to provide adequate space between targets—use at least 8px, to minimize accidental tapping.
Learn more about designing for touch devices by visiting these sites:
- iOS guidelines on Layout (https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/LayoutandAppearance.html#//apple_ref/doc/uid/TP40006556-CH54-SW1)
- Windows Phone 8 Human Interface Guidelines (http://msdn.microsoft.com/en-us/library/windowsphone/develop/ff967556(v=vs.105).aspx)
- Android Metrics and Grids (http://developer.android.com/design/style/metrics-grids.html)