When it comes to designing a mobile video application that must be deployed on the leading device operating systems — including BlackBerry, iPhone, Android, Windows Mobile and Symbian — there are a huge number of variables to consider. It’s not just an iPhone world.
My company recently developed a mobile video application for a client that wants to deliver personalized video news from leading broadcasters and programmers, and we gained a ton of real-world experience in design and development for cross-platform mobile applications. Along the way we learned it’s almost always about making tradeoffs that balance platform, carrier, device and network capabilities with the requirements of the users.
Here are 12 tips for getting it right:
1 – Maximize code-sharing and system architecture across the support platforms. Code sharing between platforms is obviously desirable, but may not be possible in many cases because platforms require the use of different programming languages, SDKs and frameworks. Even if you succeed in sharing common code between platforms, you’ll need to be especially careful when altering the shared code to ensure it works as expected on all platforms. Thus, shared code can result in a greater workload than simply maintaining completely separate sets of code.
Architecting your application with common components and layers will ease portability of the application across platforms. Just to name a few, you can isolate modules for communication, video player sequence, thumbnail download and ad manager. In most cases, you can expect to share 90% of your design across platforms, which makes your design more maintainable and extensible.
2 – When in doubt, use the native video player. Because you want to meet or surpass video quality requirements for supported devices and carriers, you need to decide which video player(s) to use. Your options are to use the Flash Video player, the video player native to the platform, a third-party player or to build your own.
Your choice depends on which device platforms you need to support, as well as the source of the video. If the video source is a single entity with a single video format, consider yourself fortunate. But if you are aggregating video from many producers you can expect a variety of video formats.
Flash video is not available on all platforms. There aren’t many third-party players that offer cross-platform technology with acceptable video quality. Native players offer a decent video experience, tend to be very stable and usually have reliable vendor support. In most multiplatform cases the first choice is native players.
3 – Select video encodings that best match each network technology. To get acceptable video performance on a range of supported network technologies and situations, you’ve got to deliver video that’s encoded to best match the bit rate provided by each network. The question is whether to offer one or multiple bit-rate encodings.
A single-bit-rate video allows for a simpler implementation, but you have to pick a bit rate that plays sufficiently well on both slower and faster connections and, even in the best case, this will not provide the best possible video experience. Multiple bit rates require more storage on the server (to store the multiple encodings), and are slightly more complex to implement, but they offer optimum video experience in all network conditions.Many sites transcode each video clip into several different bit rates that are stored on the server. That makes it possible to detect which network technology the user has and stream the best match: 80Kbps for Edge, 200Kbps for iPhone, 600Kbps for Wi-Fi.
4 – Device/application tradeoffs. Among the many device/application tradeoffs you’ll face are what to do about screen size and resolution, battery, keyboard, touch device and user interface navigation.
For instance, user interface controls vary widely. There are at least three types of navigation on the mobile devices: track wheel (older BlackBerries), track ball (newer BlackBerries, Android devices), touchscreen (iPhone, BlackBerry Storm, Android) and others. The track wheel offers two-way navigation (go to the next or previous control) and the UI should be built so it is usable and reachable with only this navigation method. Track ball devices offer four-way navigation and greater flexibility but you should be careful not to build a UI that’s too complex. Touchscreens require larger UI elements so they can be touched and operated with finger or stylus.
The ability to use the mobile application with one hand is important. One way to achieve this is to keep the most used and common options and menus of the application always on the same side of display.
5 – Select which devices to support. It’s a fine line between choosing to support the broadest range of devices and not compromising the quality of your product. For instance, some device platforms don’t offer a video experience comparable with the others.
If the native video player for the platform is unable to sustain the required frame-rate of the other supported mobile platforms, and if video quality is important for your application, then the smart decision is to not support any devices that don’t deliver a great video experience to the user.
6 – How to handle out-of-network and low-bandwidth conditions. Unlike wired connectivity, wireless network connectivity cannot be perfectly assured, and it’s a challenge to gracefully handle conditions of limited or lost connectivity. Sophisticated solutions such as pre-downloading, buffering video or dynamically switching bit rates can remedy no- or low-network conditions, but these can be complex to implement and can affect delivery performance.
There are several good reasons for avoiding such complex implementations: mobile network connections are getting more reliable and faster, it is increasingly rare to have no or bad connectivity (especially in a city), and sophisticated implementations require too much memory on the device and use up the available battery charge more rapidly.
To sustain an optimal user experience, keep the player design simple and make sure the user is notified of any problems with the.
7 – Know when to store application data on the device. Your application will perform faster if it stores temporary data on the device, but that will annoy some users who are concerned about it taking up too much of memory/SD card space. The best design is to be able to work in both modes (with storing and without storing) and let the user decide.
8 – Use native and common user interface and follow platform UI guidelines. For every application, there’s always the challenge of how to create a user-friendly interface for the user. This is even more difficult for mobile handsets that which have limited screen size, small keyboards and so on. The question is whether to use the native user interface, which may look rather simple, or to build a fancier custom user interface.
Because users prefer common user controls that are familiar (such as list controls, buttons, checkboxes, rating controls and so on), sticking to the UI guidelines of the platform and using the native controls that the platform offers is the best choice for most applications and ensures wider user adoption.
Building the application is just the start, of course. You have to make sure it runs as flawlessly as possible and you need to be able to diagnose and fix functional and performance problems, and gather usage statistics and analytics.
9 – How to test. To assure the best possible reliability of the product, you must test the applications in all its functions in all supported configurations: modes, devices, carriers and so on. To do this requires work, time and can be costly. Your options can include in-house testing, beta testing by users and third-party testing services.
In-house testing is a great way to establish stability for the core functionality, but is really not a viable means to test all of the numerous combinations of configurations. Beta testing can give you access to a larger user base, and can result in considerably more feedback on your application because beta testers will not only report bugs, but will also provide valuable feedback on the usability and user-friendliness of the application.
Paid testing services are the best way to test comprehensively on all devices, and to be sure that the testing is more extensive and systematic than with beta-testers.
10 – Why analytics are important. Analyzing usage information is a great way to improve your application and can be exceedingly useful in detecting location-specific or device-specific issues. A number of free analytics solutions — such as Google Analytics, Mobclix or PinchMedia — can be integrated easily into your desktop, mobile or Web applications. They offer modest variations of the same level of usage information for your application, including location, number of users, device-platform information and so on.
11 – Integrate crash/error reporting mechanisms in the application. Even though your application may be stable enough to deploy, you will always want to detect all crashes or misbehavior of the application.
Most mobile platforms allow an application to implement some level of crash handling and error reporting by providing access to internal logs and information regarding the crash or error. This can be challenging to implement across different platforms, and might possibly involve a server for automatically uploading the crash/error report. But being able to analyze a rare crash is invaluable to making your application rock-solid in all circumstances.
12 – How to further facilitate testing and troubleshooting. It’s obviously valuable to see key internal application information during testing or troubleshooting, but how do you expose internal application information that you normally don’t want users to encounter accidentally? The answer is to implement key or touch combinations that open a “debug” dialog with the key internal information that provides an inside look at the application.
Any key combinations should be so uncommon that they will never be accidentally pressed by the user, and they may be specific to the device. Because the iPhone and other devices have touchscreens, you can possibly create a unique sequence of multi-touch gestures constrained in time. For other devices chords of key strokes work reasonably well. Having access to this information makes it easier to support the application into the future.
That’s a sampling of what you have to consider when you’re developing cross-platform mobile applications. Managing such projects is quite another matter, and a story for another day.
Lew Roth is vice president of business development at Partners 1993 and can be reached at lew@partners1993.com.
