Mozilla.com/Mobile in Mind/Challenges

For the 2011 Q3 "Mobile in Mind" project, the first step is to identify a list of aspects of the site which will not translate directly to mobile. This can serve as an outline for the design process, where we address each of these challenges one by one to develop reusable design patterns. We should then be able to apply these patterns to mozilla.com to get a site design that can be more easily made mobile-friendly.

Mobile in Mind Challenge List

There is no Hover on Mobile

Challenge

Hover, as it exists on the desktop, doesn't exist on mobile. Firstly, the user's cursor is not present on the screen aside from their touch. This means that a user effectively can only scroll and click, not hover. Furthermore, since users are touching the screen in order to interact with it, their hand obscures elements as they click them.

Potential Solutions

Even if we'd like to provide this method of interaction on desktop, we need to find reliable fallbacks for mobile. One obvious answer is to trigger feedback on clicks as well.

Examples

Site-Wide:

• Main menu drop-downs operate on hover

Specific Pages:

• http://mozilla.com/firefox/features, http://mozilla.com/mobile/features - Top Features box rollover
• http://mozilla.com/firefox/customize - Personas hover-on-preview interaction
• http://mozilla.com/firefox/technology - Example rollovers
• http://mozilla.com/firefox/central - Tour page features rollovers

Large Amounts of Content Won't Fit

Having too much content can bury important information, especially on a small screen.

Examples

Site-Wide:

• Main menu drop-downs have too many subsections to fit, even when arranged horizontally

Specific Pages:

• http://mozilla.com/firefox/fx - Possibly too much copy on headlines
• http://mozilla.com/firefox/features, http://mozilla.com/mobile/features - Too much content per section, even if we were to create an expandable UI
• http://mozilla.com/firefox/technology - Really a lot of content, especially including examples.
• http://mozilla.com/en-US/firefox/central/ - 8 Steps is a lot of content for a small screen
• http://mozilla.com/mobile/home/ - Too many screenshots for small screens.
• http://www.mozilla.com/en-US/mobile/faq/ - Large amount of content under each section.

Content Must be Linearizable

Since the small amount of screen real estate on phones necessitates a linear browsing experience, the information hierarchy must be clear enough that making the content on a page linearized does will not confuse the user.

Examples

Site-Wide:

• Download button at the top of every page may need to be moved to the bottom or removed on small screens to allow page-specific information to rise to the top.

Specific Pages:

• http://mozilla.com/mobile - We could show one or two download buttons here to users, depending on their user agent. Making them choose between two is tough when space is at a premium.
• http://mozilla.com/plugincheck/more_info.html - What is the most important info on the page?
• Sidebar is of ambiguous importance:
  • http://mozilla.com/firefox/technology
  • http://mozilla.com/mobile/home/
  • http://mozilla.com/mobile/sync/
  • http://mozilla.com/mobile/getinvolved
  • http://mozilla.com/plugincheck
  • http://mozilla.com/press

Horizontal Space is Limited

The desktop convention of scrolling downwards on webpages is even more prominent on mobile, due to the limited horizontal space available on phones when held in portrait mode. Thus, interactions that require a lot of horizontal space to function will be frustrating to use on mobile.

Examples

Specific Pages:

• http://mozilla.com/firefox/fx - The content of the spinning wheel popup is horizontally oriented, and the panda graphic takes up a lot of horizontal space.
• http://mozilla.com/firefox/customize - The Add-ons gallery categories employ a tab metaphor that requires a lot of horizontal space.
• http://mozilla.com/firefox/video/ - Horizontal navigation for videos may be awkward.
• http://mozilla.com/firefox/central/
  • We won't be able to fit the large image on small screens and keep the same level of detail.
  • Absolute positioning of tooltips will be tricky at small screen widths.
• http://mozilla.com/about/contact
  • Google Map may need to be modified or omitted for small screens.
  • Horizontal list of options will wrap.
• http://mozilla.com/legal/fraud-report/index.html - ReCaptcha is fixed-width. Not sure how this would work on mobile, should be prototyped.

Popups Should be Used Sparingly

Popups can be great for letting a user interact with a specific object at a deep level while maintaining context in the page. On mobile, though, because the small screen size does not allow much content in popups and it is not something that users expect in mobile websites, many times other interaction paradigms may be appropriate.

Examples

Specific Pages:

• http://mozilla.com/firefox/central/ - with too much content in a popup, the user may lose context.
• http://mozilla.com/mobile/home/ - Launching a standalone video player directly may be appropriate here (Similar to what was done on Web O'Wonder)

Tabular Data is Difficult to Fit on Small Screens

Due to the horizontally-oriented nature of tables, they often won't fit on small screens. Luckily, in many cases the data can be represented in other methods.

Examples

Specific Pages:

• http://mozilla.com/plugincheck - Plugin details table
• http://mozilla.com/plugincheck/more_info.html - Fully Supported Browsers table

Complex JavaScript Animations Will Not Perform Well

Smooth animations on desktop cam evoke a sense of fluidity and technical marvel. On the diminuitive processors of many mobile devices, however, animations look choppy, make the page feel slow, and can even confuse the user about the state of the page.

Examples

Specific Pages:

• http://mozilla.com/firefox/fx - After being clicked (on a slow phone), the wheel takes longer than expected to react.

Other Considerations

• Videos will probably need to be reencoded to play on Android and iOS devices. We ran into this with Web O' Wonder.
• There are times where content should probably be altered based on the user's UA string. A few examples, singled out for consideration:
  • http://mozilla.com/mobile - Download button should reflect user's phone, like on the main mozilla.com
  • http://mozilla.com/firefox/channel - Need to see mobile nightly & beta
• We need to decide what happens when a user of a given device visits mozilla.com. Are they redirected to /mobile? /new? /fx? /mobile/home?