MShift’s browser-based interface gives developers a lot of control and capability for building wireless applications. Unfortunately, the process is not very automated, so it can take quite a while to get this design environment up and running correctly.

MShift’s MobileShift Toolkit lets developers build wireless sites either by deriving them from an existing Web site or by basing them on a design layout. An MShift solution targets devices by their supported markup languages (HDML or WML for cell phones, HTML or CHTML for PDAs and pagers). You can then customize the display for particular devices’ screens. The platform supports 137 international languages, including many that use large character sets, such as Japanese.

Projects involve four levels of development: Commands, Cards, Decks, and Stacks. Commands are the single instructions used to display and process information; they let the developer, for example, insert images and button actions. Cards are similar to HDML or WML cards, which correspond to a single screen on a cell phone and are made up of a set of Commands. Decks are a collection of Cards that handles a specific interaction between the device and the site, such as a purchase or a database query. Stacks, which are usually associated with a specific device or Web site, contain a group of Decks.

The developer must have a precise idea of how the information will be processed and displayed before creating the corresponding Decks, Cards, and Commands. Not much of the development process is automatic—the Web designer must explicitly describe the flow of information for each wireless interaction. Compared with other platforms we reviewed, MShift’s approach is much more code-intensive, aimed at people who are comfortable hand-coding HTML pages as opposed to those who prefer WYSIWYG development environments.

What the MobileShift Toolkit lacks in automation, however, it makes up for by offering more granular control than most of the other wireless solutions we looked at. The MShift system allows complete control over every aspect of the information collected, processed, and displayed on the device. Commonly used functions are built in or, alternatively, the developer can enter specific HDML, HTML, or WML tags. The MobileShift Toolkit can handle cookies, redirects, and even custom referrers (the URL of the page a user came from).

MShift’s Web-based environment allows for distributed development, and the thorough help system makes for a very quick learning curve. But command-by-command entry for every line of text, form field, and processing instruction drastically slows down the construction of a wireless page.

Once our test taxi-driver application was built for the PDA, RIM pager, and WAP phone, we ran it on each device to see how MShift’s MobileShift Engine performed. The application performed well on all functions except JavaScript validations and alerts. Because very few wireless devices currently support JavaScript, it’s up to the mobile application server to handle JavaScript and send the appropriate results to the device, something MShift doesn’t do.

Once all the Commands are created for a particular site and deployed for production, the MobileShift Engine handles request calls from wireless devices. The MobileShift Engine can be either self-hosted or hosted by MShift as an ASP solution. The product detects which device is making the request through which gateway (and in what language), stores cookie and session information if necessary, processes the appropriate Commands for the page, and serves up the proper response page to the wireless device in the correct language and format. Like Aether, the MobileShift Engine does automatic image conversion, which allowed for very fast, beautiful image scaling and rendering.