Thought Lessons When Creating HTML Mobile Websites

Working for almost a year now on Audible’s mobile website┬áhas taught me a thing or two about mobile development. It was my first mobile web development experience and I was eager to get started. It was also my first real experience with creating an adaptive site using percentages instead of fixed pixels.

In many ways, creating a website for mobile is pretty identical to creating a regular website, the only real difference being that users don’t have a large screen. However the mobile platform comes with it’s own bed of issues.

Lesson 1: Standalone mobile website or adaptive design?

Adaptive design is usually the best method for doing a mobile site, especially if the site is smaller in nature. This way, you can reuse the HTML you already have for the desktop site and not have to worry about redundant content or code. Adaptive designs can actually be created rather quickly, even from a pixel-based layout already in place, and you can easily control what sections of the site you want a custom mobile version for (For example, on my own site, if you look at the site on a mobile device, you’ll notice that it looks exactly the same as the regular layout – except for this blog section, created to make it easier for users to read on a smaller device).

However the mobile site I created for Audible was completely standalone from the regular website, so I didn’t really need to mess with the junk of media queries and hiding things with CSS. This was optimal for the site since the Audible website is massive, including a login system for users, checkouts, account areas and shopping. Trying to do this site in an adaptive design would’ve ended up not being too user friendly.

Lesson 2: HTML5, CSS3 & Mobile Browsers

I’m sad to say I didn’t get the chance to use HTML5 for this mobile site. When I started coding, there still wasn’t a whole lot of push to use it, and it was before I switched all of my coding to even use the HTML5 DOCTYPE. However, I was able to freely (or so I thought) use as much CSS3 as I wanted to, for I no longer had to support IE, yay right?

Unfortunately, the mobile world comes with it’s own IE in the form of Blackberry. At the time I coded the site a year ago, Blackberry only had minimal support for CSS3 – it didn’t support opacity or certain selectors. Which meant, of course, having to use some sloppy code that would’ve otherwise had been a lot cleaner.

Fortunately for us developers, the mobile world is dominated by webkit browsers. For the most part, sites on Android and iPhones/iPads/iPods pretty much look the same. Unfortunately, the Blackberries can be a pain in the arse to deal with, since they don’t have as much support for newer technologies as other devices.

Another blow to the wonderful mobile browser testing field is the new Windows 7 phone that came out – with IE7 built in. Yup. It’s like the early 2000’s all over again isn’t it? Luckily though, IE9 is supposed to be shipping on those soon, if not already.

Lesson 3: Don’t Forget Landscape

On our regular desktop browsers, we normally code for a specific size, say 960px wide, even when doing responsive web designs. We know that no matter how big the monitor is, we can set a maximum width that our site will never expand past. Our monitors, while different sizes, are normally the same aspect ratio, i.e., you can’t flip the monitor around and view it portrait wise (well certain monitors you can, but it’s not common). However, with mobile world, the user has the ability to flip his device and make your site wider or narrower on the fly.

This is when you have to make a decision for your users. When the user flips from portrait to landscape, do you simply zoom into the site, but keep the same dimensions? Or do you adaptively resize the site so the elements now stretch across the new expanse of space?

What I Really Learned

  • I really, really enjoyed mobile development, and am thinking of moving my business into that area
  • Mobile development, at least at this stage, takes me A LOT longer than regular development, probably because:
  • Mobile development comes with way more mockups than the average desktop web site. I’ve done over 100 for Audible so far, and I’m still working on them.
  • While you can emulate a native app, a mobile website will never feel as nice as a native app, no matter how well done it is. You still have loading times, limited access to phone features, and you still have to visit the browser.

I’m still on the fence about whether I want to learn native app development. Last year I spent the entire summer working through the Beginning iPhone 3 Development book and I still feel like I know next to nothing about the process!