What Is Larry Thinking? #60 => Mobile Web Development

In this edition…

What is Larry Thinking? => An Overview of Mobile Web Development

About a year ago, I created my first mobile-centric Web site, using iWebKit. iWebKit is a CSS, JavaScript, and HTML framework for creating sites that look and work better on iOS devices. That was an interesting experience, but just the beginning of what’s possible when it comes to mobile Web development.

Over the past few months, I’ve been doing a lot more research, development, and other work involving mobile Web development, and I thought now would be a good time to share what I’ve learned thus far for those of you thinking about dipping your toe into the mobile Web world. After presenting some of the basic ideas and tools, the newsletter has links to many excellent resources in this area.

Apps vs. Sites

At first, the inclination for companies was to create dedicated applications for mobile devices: desktop users would go to the primary Web site, mobile users would install and use the app. These days, the trend is moving away from creating dedicated apps and creating better Web sites for mobile users instead. There are many good reasons for doing so, considering the downsides of native apps:

They require different skills than Web development, meaning you have to hire new employees or train existing ones
They must be written in different languages for different platforms: traditionally, Objective-C for iOS devices and Java for Android (which doesn’t even included the Windows mobile platform or BlackBerry)
They require that the user download and install the app
They require that the user update the app for any change
App contents won’t appear in search results
You have to maintain two (or more) development tracks: traditional Web and mobile app.

For new businesses, native apps are even more illogical, as few users are going to download and install apps for companies with which they don’t currently do business.

All that being said, there are still situations in which a native app makes the most sense. Specifically, a native app is more appropriate when:

You need to access device features, like the camera
You need to access restricted device data, such as the user’s contacts
The site/application is demanding in terms of graphics and processing power

These days, for the most part, the move is away from native apps, and towards building better Web sites instead. This is largely possible thanks to newer technologies. For example, HTML5 supports local storage (i.e, the ability of a site to hold a decent amount of information on the user’s device, and therefore be used offline) and location services. For desktop users, reliance upon new technologies is tricky, as there are too many antiquated browsers still out there. But mobile devices tend to have the most current browsers that support the newest technologies.

Once you’ve decided you want to create a mobile Web site, as opposed to a native mobile app, there are two choices. Before getting into those, let’s look at how the mobile Web experience is unlike the desktop (or laptop) experience.

How Is the Mobile Experience Different?

There are a number of differences between accessing a Web site using a mobile device and using a computer. Of these, the most obvious is normally the screen size, although the iPad’s screen size (as well as other tablet’s) is not that significantly smaller than some laptops. But clearly a mobile phone has a small screen, which must be addressed in terms of how content is presented. For example, a wide, fixed page width and large images won’t work well on a mobile device.

Less obvious differences include a slower, more restricted network connection. This means that the Web page, if not optimized for the Web experience, will take much longer to load.

Mobile devices also lack traditional input devices: keyboards, mice, and trackpads. Common demands of traditional sites, such as lots of typing or clickable elements placed closely together, can be completely impractical within the mobile confines.

Those are the obvious differences, but the important similarity between mobile and computer Web experiences is the user’s intent. Never think that “mobile” means the user wants a lesser experience.

Considering how the experience differs, there are two routes you can go for supporting mobile devices: create a separate mobile Web site or make one responsive site. There’s quite a lot of debate as to which approach is best, so let’s look at what each means in detail.

Two Separate Sites

An option is to create a dedicated site for mobile devices (e.g., served at http://m.example.com) and a dedicated site for traditional users (http://example.com). This is a very common approach, with most major sites using this structure. With a dedicated mobile site, the HTML, CSS, JavaScript, and media (e.g., the size of the images) can all be optimized for mobile devices.

If you want to make things a bit easier on yourself, you can use the jQuery Mobile framework, which makes a Web page look and function much like a native (iOS) application. I’ve used jQuery Mobile on a recent project: it’s easy to use and has many slick features. For example, it has built in Ajax that makes the loading of subsequent pages much faster.

Commonly, a server-side script is used to automatically redirect mobile devices to your mobile-specific Web site. This is an acceptable policy, but you ought to insure there are ways for the user to get back to the traditional site, should that be the user’s preference. And, as is the case with all device detection, false identifications are probable.

The downsides to creating separate sites begin with the need to maintain two different sites, which means extra work. Second, by using device detection, you’re making assumptions about what the user wants solely based upon the device they’re using. Third, this approach is not optimal for search engines.

One Responsive Site

Alternatively, you can create one Web site that dynamically changes based upon the device in use. This is known as responsive Web design, or rwd. RWD is largely accomplished using semantic HTML5 and CSS3 media queries. For example, the default Web page might layout content with a header, three columns in the body, and a footer. For devices with smaller screens, the CSS3 media queries would restructure the layout to be one long vertical column instead. You can see this in action in the newest version of my own Web site; just resize the browser window to see the net effect. (Note to self: expect many replies about this not working, or not working well; it’s a work in progress). There are also plenty of other examples you can find online.

Responsive Web design is further broken down into mobile-first or mobile-last approaches. In one case the site starts off as a mobile-ready version that upscales for desktops; in the other, the desktop version is standard, with it downgrading for mobile devices.

The downsides to responsive Web design are that it takes a lot of work to get right, and that the end result is that no device is getting its most optimized experience.

Where I Stand

My inclination right now is to practice responsive Web design. An rwd site is easier to maintain, plays nicely with search engines, and should be the most future-safe, as it depends upon device attributes, not the specific device type or name. Not that having separate sites isn’t reasonable in some cases, though. When you have a site that’s serving millions of users and billions of page views, presenting an optimized, efficient mobile Web site makes a lot of sense.

Where Should You Start?

First, if you’re not already, you should be using HTML5. It’s safe to use for all browsers and is the backbone of mobile Web development. Second, if you’re a designer, you can learn about CSS3 media queries, if you aren’t using them already. If you’re a developer, not prone to doing much with CSS (as is the case for me), check out the good frameworks, like jQuery Mobile or Boostrap.

And, of course, read, read, read! The rest of the newsletter presents some good resources.

On the Bookshelf => Head First Mobile Web

Although I generally detest O’Reilly’s Head First book series, the “Head First Mobile Web” is the best book I’ve read thus far on the topic of mobile Web development. It provides a good survey of the landscape, with lots of specific code, and even goes into the basics of native apps. (And it does all this while trying to be cool, with large pictures of hipsters saying silly things; I hate Head First.)

On the Web => Responsive Design with CSS3 Media Queries

One of the keys to responsive Web design is the CSS3 media query. Benjamin had previously shared with me a good tutorial on what CSS3 media queries are and how you use them.

On the Web => Mobile Websites vs. Responsive Design

The Google Mobile Ads Blog posted a simple but quick breakdown of mobile-dedicated Web sites vs. responsive design back in July, if you’d like more discussion of that debate.

On the Web => Bootstrap from Twitter

A great and popular framework for developing responsive Web sites is Bootstrap, created by a couple of developers at Twitter. Bootstrap is not just for responsive Web design; it’s actually a framework of common elements and features used by today’s modern Web sites (e.g., nicely formatted alert boxes, differently sized buttons, and so forth). I just used it on a project, and coincidentally, the new WordPress theme for my own site uses Bootstrap, too (I just started using Standard by 8BIT). You can see some examples of barebones Bootstrap usage at its Github pages.

On the Web => This is Responsive

Brad Frost, one of the most important names in mobile Web development, has worked with another developer to create This is Responsive, an ongoing repository of rwd resources. Frost also has a great newsletter in which he shares responsive Web design resources.

On the Blog => Introduction to Mobile Web Development Slides

Back in June, I was in San Francisco to do two days of training on JavaScript and jQuery. One afternoon was spent on mobile Web development, and I’ve posted those slides on my site.

Larry Ullman’s Book News => “PHP Advanced and OOP” and the Yii Book

The third edition of my PHP Advanced book, now titled “PHP Advanced and Object-Oriented Programming” has gone to the printer and should be available in bookstores within the next couple of weeks (depending upon where you’re at and how good your bookstore is). The final table of contents have been posted on the blog, for those interested in how it turned out. I’m pleased with the end result and hope you will be, too. The book does assume intermediate level knowledge of PHP and MySQL (like that you’d have after reading my “PHP and MySQL for Dynamic Web Sites: Visual QuickPro Guide” book.

For the next four months (or however long it takes), I’m working on my forthcoming Yii book. I’m finalizing the table of contents now and should post that on my blog this upcoming week. The plan with the book is this: to start, I’m only going to publish it electronically (in multiple electronic formats). I will be publishing it as I write it, though. By the end of this month, I should reasonably have Part 1 of the book done, which will be a couple of chapters. At that point in time, I’ll make the book available for purchase.

At any point in time from there on, you’ll be able to purchase the book for the full price (probably a $15 minimum, but pay what you want). Whenever you purchase the book, you’ll get the book as it’s complete to that point. As I post additional chapters or parts, those people that have already bought the book will be able to download the latest version for free. People who have bought the book will be able to download the most current version at any point going forward, at no extra cost. (The only exception would be if I ever rewrite the entire book to such a degree that it would constitute a new edition, but I don’t see that happening.)

Once the book is done, done, done, I may make it available in print copies (may). I also plan on selling individual chapters, too. As errors are found, or minor updates are made to the framework, I’ll post modified versions of the book. Those people that have bought a copy (or a chapter) will then be able to download the latest update.

That’s the thinking, anyway. More news to follow!

P.S. Someday I ought to create an official title for this book; I’m tentatively thinking of just calling it “The Yii Book”. What do you think?

Series

Blog post categories

Note