In my last post I discussed changes in our process over the last 18 months, as well as looking at the choice between apps and sites and the potential of responsive design. In this installment, we will continue our strategy discussion by touching on iPads, testing mobile projects, and how to select target platforms.
Does ‘Mobile Design’ include iPads?
Ok, so iPads aren’t mobile. Sometimes they’re grouped in with mobile devices, but they aren’t really mobile devices. While they may be physically portable, shoppers don’t use them like mobile devices, their screens are bigger, and they have different (overlapping, but different) design metaphors and styles. However, they convert like crazy. Shoppers on iPads convert at roughly the same rates as full-size computer shoppers. Making your full (i.e. non-mobile) website compatible with iPads is relatively straightforward for most companies, and will absolutely have an impact on your bottom line.
Other tablets are coming onto the market over time, and if iPhones and Android phones are any indication, Android tablets will eventually be more numerous than iPads, but will probably not convert at quite the same rates. However, the same compatibility work you should be doing for iPads will also help with Android tablets, which will eventually make up a significant source of traffic.
Target Platforms- Who Do You Love?
One key thing our mobile teams have learned about mobile projects is to identify your target platforms early in the process, as early as is practically possible.. This is important because the breadth and types of target platforms can have a big effect on the effort involved in the project. Using analytics to look at the current usage patterns is very helpful in identifying which platforms should be targeted. Analytics can also be used to justify weeding out platforms that will be expensive to develop for and will represent a small minority of visitors- I’m lookin’ at you, Blackberry! According to our stats, Blackberry users are both less common and less likely to purchase than iPhone and Android users. When you consider the additional effort that is required to get mobile sites to function properly on some Blackberry phones, it can be more practical to drop Blackberry (or at least their older phones) from the target platform list.
Android can also be a bear when deciding on target platforms. Different versions of Android add new features and drop old ones, leading to increasing unpredictability about how an individual phone will display or handle sites. Manufacturers are notorious for not allowing Android system upgrades, so individual phones are locked to one or two versions of the OS. One way to manage expectations is to agree on a target Android version and use that version during development, QA testing and customer acceptance testing, ensuring that the functionality delivered works as promised without sinking into the quagmire of which features are supported in which versions.
Testing Your Patience
Testing can be another trouble spot with mobile development, but of course with testing, the harder it is the more essential it is. We are seeing challenges with devices, simulators and connection speeds.
The first area is with getting the devices into the right hands. It’s essential to ensure that all stakeholders (both client and vendor stakeholders) have access to the targeted devices in an effective and timely manner. That means that they need to have received the appropriate mobile devices before the beginning of the testing window at the latest. IT groups everywhere are struggling to make these devices available to stakeholders, so it’s essential to get this ball rolling months ahead of schedule (another reason to decide on your target platforms as early as possible – see above). That way the inevitable questions that come up can be answered and the phones procured early enough to complete testing on time. Under ideal circumstances, stakeholders would have these during the comp review process, so they can view the comps in context and understand how the site will look when built.
The second area is testing on simulators. Testing on simulators, while convenient and often easier than trying to procure a specific device, does not accurately reflect all of the features, constraints and limitations of the actual device. Simulators almost all consist of some kind of browser or browser add-on that simply presents the site in a window resized and decorated to look like a mobile phone. It’s not using the actual mobile browser code, it’s not subject to the processing power limitations or bandwidth limitations present on the phone. For many of these reasons it will mask problems that later appear on the real mobile devices. On the flip side, simulators can be buggy themselves, forcing developers to spend time fixing bugs that don’t exist on the actual mobile devices at all.
Finally, testing at multiple connection speeds is essential. The site should be tested on Wi-Fi, 4G, 3G, and 2G/EDGE networks to ensure that performance is acceptable in all cases. It’s important to do this not only in QA but also as the code is written, so that the development team understands the constraints present when shoppers are using the site and can tweak things as they’re being built, rather than coming back later and fixing finished code.
Hopefully the lessons we have learned and described here will be helpful while planning and executing your own mobile projects. Maybe the time we have spent metaphorically smacking our heads against these tiny computers can save you a few headaches down the road.