Application Download
From MobileDesign
[edit] Applies to:
User Interface: Included,
Excluded
Hardware: Category: Thing,
Category: Another thing
Application acquisition is one of the first touchpoints the application has with the customer. If this is not handled through a carrier or third party aggregator, the following measures should be implemented.
[edit] Design
From a desktop web site, the fastest method to get an application onto a personal communications device is to send the URL to the device using SMS. The opportunity of easy information entry on a desktop website should be used to gather any personal information that may be needed by the application, or the download process. Always limit required input on the mobile device. The URL may then encode any personal information (or better, encode a session ID so personal information is not sent across the network directly).
Unfortunately, some carriers have disabled the user's ability to click on a URL found in a text message. For example, the Motorola RAZR on Verizon's network in 2005 and 2006 blocked the capability.
WAP Push accomplishes the same goals as sending SMS with a URL, but with some advantages and disadvantages. These messages are designed to not be forwardable, which protects a bit from piracy. They also may not cost the user, depending on carrier settings. Carriers that block URLs from SMS messages likely allow them from WAP Push messages. However, users must have WAP Push (or "Service messages") enabled with the phone user interface, which may not be true by default.
From a mobile web site, a simple link to download the application is sufficient.
[edit] Applicable Devices and Platforms
Downloaded applications.
[edit] When Used
Applications available off of the carrier's deck.
[edit] Rationale
URL entry is difficult and tedious. Many users can not find the URL entry mechanism on their mobile browser.
Also see: Any that apply, Else remove it entirely
