Technical Challenges in Content Delivery to Mobile Devices

As developers, in building our applications to meet the stated technical and functional project goals, we overcame a number of challenges.  Here, I'm speaking specifically about data-centric mobile applications and device-level user interface, and not really about voice applications - except in a specific area that I'll cover later.

The original conception of the Mobile VIFF project was very broad in scope, and we early on made several naive assumptions that led to our making a few decisions about functionality that were not realistic in terms of existing and available mobile technologies.  While theoretically we did not reach beyond the current state of technology, we discovered many issues with respect to the implementation at the carrier level (platform) of various technologies.  I do not mean to blame the carriers here, although I have to say that I do find myself a little perplexed as to why - in an age where open standards and interoperability form a technical holy-grail of sorts - we see so many fundamentally differing technical implementations and widely differing platform capabilities. 

To muse on that a little more, we developers see ourselves as being fundamentally important to the success of the carriers' offerings and yet it is still extremely difficult to "get on the deck" with a given carrier.  In my opinion, the carriers are doing themselves, their customers, and the developer community a disservice by not opening access to their decks and also not being more proactive about agreeing on standards and offerings.

That said, I really want to focus on the challenges facing the developer in developing mobile, data-centric applications.

We had decided early on that we wanted to - where practical and reasonable - implement "cutting-edge" content delivery methods, but also felt that to reach as many users as possible we would make certain functions also available using "older" technologies.  So, when looking at the options for delivering encapsulated content, we decided we would make available a "simple" version using SMS and a "cutting-edge" rich-media option using MMS.  We decided to implement the simpler SMS content delivery first and work from there.

SMS - Short Message Service...

Our first surprise came when we discovered that even a "tried-and-true" standard like SMS - that world-wide delivers billions of messages monthly - is not so much a standard as a guideline.  Something as simple as inserting line-breaks in content is not, in fact, specified in the protocol as a requirement and it is often not implemented at all by certain platforms.  This makes it very difficult to deliver even the simplest "structured content" (i.e. a list) in an easily understandable fashion.  We all know that the character limit for SMS messages is 160 characters and this too is a serious limitation.  To use a concrete example, we wanted to allow the user to have the screening dates and times for a VIFF program to be sent via SMS to their phone.  Ideally, it might look like:

Absolute Wilson

is playing:

GR7 09/27 7:30pm

RID 10/01 8:00pm

VCT 10/02 4:30pm

This is still within the 160 character limit and would work quite well.  Unfortunately, because few carriers offer a way of embedding formatting characters (e.g. line feeds) the user might see something like:

Absolute Wilson is

playing: GR7 09/

27 7:30pm, RID 10

/01 8:00pm, VCT

10/02 4:30pm

which is obviously confusing and not ideal.  Of course, where the line breaks completely depends on the device so there's no way to predict how this will actually display on the user's device.

To link or not to link...

It seemed to us that the simplest way to give users a link to the Mobile VIFF Program Guide (a complete, dynamic XHTML-Mobile Spec view of the extensive VIFF program and a core component of our project – described elsewhere) would be to send it to them via SMS. Of course, they could also key-in “wap.viff.org” on their mobile browser.  To get the link sent to them, users could:

• Enter their phone number on a standard web-form (via a browser running  on a computer, not a mobile device obviously)

•Send a blank text message to the MUSE short-code (used just for VIFF at that point).

•Dial the Mobile VIFF Interactive Voice Guide (which was 866-303-FILM and is described later) and using voice-command or touch-tone, navigate to a voice-form that would allow the user to read or key-in their mobile number.

Then, our system would send the user an SMS message with just the link to the mobile guide.  Simple enough... imagine our surprise when we tested the ability to CLICK the link on various mobile devices.  There is nothing even close to a standard as to how this is done and varies not only by OS and device manufacturer, but also from one device to another by the same manufacturer.  Some phones have an option menu item you have to dig for - taking many OK clicks, others used a scheme where you high-light the link and then press a special button (rarely obvious) somewhere on the keypad, etc. Thus, we were unable to even give users meaningful help as to how to do this.  Still, this is probably still the best way to send your users a link to a mobile application and avoid forcing them to actually key in the URL.

MMS to the rescue... not.

So, given all the limitations of SMS, the obvious solution would be to use MMS right?  After all, MMS allows for a massive 32K byte package, let's you embed pictures and other rich-media, gives complete control over document formatting etc. etc.  The problem is this. There is no "standard" MMS as implemented by the carriers.  Further, widely differing device profiles means that even on a specific carrier's network, you don't have any true guarantee of control over basic formatting elements of an MMS message.  Finally, there is no guarantee that you - as an application provider - will even be able to send messages to arbitrary customers on a given carrier's network - you just might find yourself shut-out because you're not "on their deck".

The MUSE team tried to create a platform form MMS message delivery that would to some extent bypass some of these limitations.  I know that Jim Udall spent a great deal of time implementing this, and did get it working, but we were, unfortunately, unable to make use of it.  Jim was implementing a technology that would attempt to reformat messages to at least display on the majority of MMS-enabled devices and be in some respects platform/carrier neutral.  Hopefully, this will be "ready for prime-time" by the time the MUSE3 projects start to roll.

XHTML Mobile Profile

Often referred to as XHTML Mobile Spec[ification], this is a stripped-down version of the XHTML protocol understood by all common web browsers and is understood by all modern mobile devices.  Virtually all common devices made in the last five years or so understand this protocol and it forms part of the WAP (Wireless Application Protocol) specification.  It's actually pretty simple to implement and work with... which also means that it's extremely limited.  But the real problems begin when you consider how various devices implement the protocol.  If you're careful - as we eventually were - you can develop an app that works pretty much anywhere but with the proviso that you will forgo some functionality to achieve this. 

The first thing we realized - and this should be obvious - is that you need to be very careful about the design of pages and code to the lowest common denominator with respect to screen size and resolution.  You might think that you can figure out what the device is (i.e. it's capabilities) using something like "UserAgent" but alas, you'd be wrong.  While the protocol supports sending you this, the carriers often strip this valuable parameter in the returned headers, or, worse, send a generic platform level user-agent string! So, you can't guarantee to get it.  We toyed with implementing a registration function that would let the user choose a "view" that suited their device but eventually gave up on this idea because of the sheer complexity of doing it and the annoyance this might cause users. 

You should also pay close attention to how you output internal links in your app - as we discovered in testing. Many devices will decide for you how a link should be represented and it's often not what you expect.  For instance, some devices don't implement #-type anchors on a page at all.

A final gotcha is that the support for various image formats in XHTML MP is poor at best.  On many devices, .JPG's will not display at all and you will wind up using .GIF's - which is pretty annoying not to mention usually results in larger file sizes.  And forget .PNG's.

The Price of Freedom

The promise of the mobile phone is quite obviously mobility - i.e. freedom to talk pretty-much wherever you happen to be.  When you add mobile access to data-centric applications, well, the whole thing changes.  It is the promise of a whole new way of thinking about information: to be able to access whatever you want whenever you want it.

As we were developing the various apps that the Mobile VIFF project comprises, we immediately realized that while all modern mobile phones and PDA-phone hybrids support data, if users are on a pay-as-you-go plan, or do not have a good data-plan, using some of our applications would become prohibitively expensive.  Some carriers charge for casual data use as much as 30 cents per kilobyte which means that viewing a still image for a film could cost upwards of a dollar!  Clearly, we would have a problem if people unknowingly racked-up $500 phone bills viewing the VIFF Mobile Film Guide.  So, when you go to wap.viff.org the first thing you see is the attached warning.

Scary, but necessary.