The mobile phone has become the latest interactive marketing venue but the rules governing it are different than for other forms of online advertising. Each phone has its own capabilities and quirks that need to be taken into account when designing and programming mobile applications and sites. To help get a better sense of some of the hurdles facing a brand that wants to use mobile advertising, we got Christopher Ehren, LeapFrog's Creative Director, and Jeremy Kolonay, LeapFrog's Director of Web Software Services, to sit down and answer some questions about designing and programming for mobile advertising. And because each had so much to say, we will be presenting this post in a three-part series.
What are the hazards of just trying to take a brand's existing site and transferring it over to mobile as is?
Christopher Ehren: You sacrifice usability by scaling down the interface elements and depending on them to be just as visible to the user as they would be on a full scale monitor. That's rarely the case. You've also got programmatic restrictions because mobile browsers aren't as full featured and plug-in ready as desktop browsers.
Jeremy Kolonay: So you're restricted to basically very limited feature websites that rely on a lot of server-side lifting as opposed to being able to do cool things with JavaScript or Flash.
Christopher: And any graphics that are used for informational purposes also might scale down adversely and not be legible. The type and the programmatic fonts might scale properly but graphics that contain information might not be legible.
Jeremy: Fortunately with the advent of Apple's iPhone and the growing popularity of the browser on Android, mobile phones are finally starting to make an effort to be able to give you a fully capable experience with a website. We aren't, however, getting a point of optimization for your screen.
How does the target audience influence what you design/create for a mobile advertising campaign?
Jeremy: Generally speaking, there are probably five or six major mobile platforms: Symbian, Palm, BlackBerry, Rim, iPhone, and the new Android - that your target audience will be utilizing.
Christopher: But you should still have a bare bones code only site for the very bare bones phones, especially for something purely data driven like a financial site or movie times.
Jeremy: There are a lot of different ways of doing this. It's not like building desktop browsers. You wouldn't necessarily build, unless you have an extensive budget and absolutely want to guarantee the best possible experience by device, a site for each platform so much as pick your lowest common denominator and try to do a little bit of enhancement for the screen sizes people are going to be using. At that point, your entire purpose of putting your site on mobile is to be as succinct and information ready as possible without any fluff that you would normally see for SEO or marketing purposes. If somebody is accessing your site from a phone, it's because they need something and they need it now.
Christopher: If it is a media site they are visiting, the chances are they are visiting from a BlackBerry or an iPhone or a very media sophisticated phone where those aren't necessarily issues. A lot of times, you can build in a redirect that detects what sort of device the users are coming from - if they are hitting from an iPhone, they can be directed to an iPhone specific site. The weather sites are one example of sites that do this.
In the next installment of this series, Christopher and Jeremy will talk about the best ways to make sure a mobile site is properly tested and created with the right amount of oversight to ensure an effective and satisfying mobile experience.
It's still prudent to have several versions of your mobile site available depending on from whichever device users are hitting it. Another thing that we haven't really touched on in addition to just look and feel is the actual way to interact with the site because the one thing I take for granted is that when I want to push a button, I push a button. I don't have to use some painfully tiny trackball or painfully tiny arrow keys to move a cursor down and hope that I actually stop at the button I'm looking for, and then do the deal where you press directly in the center of the button but more off to one of its edges. So you do as much as you can to make sure the controls, the things the user uses to interact with the page, are actually easy to manipulate regardless of the phone they are using.
Another thing I take for granted is that I have a full QWERTY keyboard on my phone. A lot of your more high powered mobile devices like BlackBerry do provide this for you but the Razor uses a T9 keyboard. It is just numbers, and you have to click every button three times to get the letter you want. The consideration is then to require actions that require minimal keystroking when building a site for a Razor. I might also consider my use of scroll boxes differently if there were phones that can't do comma boxes the right way.