On January 9, 2007, Steve Jobs addressed a group of adoring Mac heads at the annual MacWorld conference. He talked about how Nokia had pioneered the mobile phone industry and created some of the best mobile phones in the market. He talked about how Blackberry had changed the world by creating devices that excelled at getting e-mails anywhere in the world securely and quickly, allowing you to respond to them instantly. He talked about how desktop computers were fantastic for browsing the Web, but no one had quite captured that desktop browsing experience in a handheld. Steve then showed the world the first iPhone—the world's first phone, e-mail, and mobile Internet device. The moment I saw it, I knew I had to have one.
I am, and have been an unabashed Apple fan. Both my parents were teachers and were able to check out Apple computers from the school library during the summer. This meant that I spent almost every summer of grade school in front of a monitor with the Apple logo on it. The iPhone was the culmination of all of those summers' enthusiasm times one thousand.
I went to the Tampa Apple Store after work on the day of the launch and I was the first one on my block to have a new iPhone. The data speed was excruciatingly slow and the phone dropped calls more than a freshman football player drops passes, but the device revolutionized what we thought a handheld could be. And with each release, the iPhone continued to get better. As it had done three decades earlier with the personal computer industry and two decades earlier with the GUI, Apple had ignited innovation in the handheld space that the world would never be the same.
Some five years later, it's impossible to imagine a Friday night without texting your friends and getting information on which restaurant in the area serves the best Persian Kebob, and then sharing the location with them all, so they meet you there without a single phone call exchanged between you. We live in a handheld world and many a pundit has stated, "If you don't have a mobile strategy, you don't have a strategy".
So, what is your mobile strategy? Whether you sell cupcakes on Main Street to 12-years-old girls, or servers to wall street traders, Drupal gives you a framework to create a first-class mobile website.
Drupal is an open source piece of software installed on servers that allows you to manage content for a website through a web-based interface. You can pair your content with one or more themes, which will wrap the content in the HTML design of your choice.
There are tons of better CMSs out there, both paid and open source. What makes Drupal what it is today are two basic things—one is the hundreds of thousands of developers contributing modules to the Drupal framework. Second is Drupal's approach. Drupal approaches web development as a series of Lego™ blocks, each one building on the other until the entity becomes greater than the sum of the parts. This book will attempt to demystify the process.
So what is it that you hope to accomplish with your mobile site? The chances are that it's one of the following three general goals:
Broadcast message: Includes either news or information. Allows you to share information about your business or non-profit with current or future customers.
Interaction: Allows your customers to find you, contact you, or in other ways, interact with you.
Location portal: For example, find the best Kebob in Arlington, Virginia.
What you hope to accomplish will give you a better idea of who your audience is and what type of hardware they might have.
In the beginning mobile telephones were large bricks that needed constant charging and had a very limited range. By the year 2000, Nokia and Motorola had most of the US Phone market selling what we now call "dumb" phones. Dumb phones were dubbed, thus, as a reaction to newer "smart" phones. They usually have a single color screen and a 12-key standard phone keypad with a power on and off button and maybe one or two other function keys. You can accomplish text input with a combination of presses on the keypad. The phone's secondary features such as storing phone numbers and texting are usually accomplished through a series of menus. The browsers on these phones use a protocol called Wireless Application Protocol (WAP) . WAP was evolved by necessity on these "dumb" phones in the early 2000s. WAP breaks up the content into a series of menus and text cards, and you can use the menus to navigate through the text cards to achieve something approaching a wireless Internet experience. Unless you know for sure that your audience is using WAP-only phones, you can probably choose to disregard it and author your site in HTML only. This book will only touch briefly on the WAP protocol and will turn most of its attention to full HTML sites, as the vast majority of mobile web traffic in the US and Europe are smartphones using WebKit-based full-HTML browsers.
In the beginning mobile telephones were large bricks that needed constant charging and had a very limited range. By the year 2000, Nokia and Motorola had most of the US Phone market selling what we now call "dumb" phones. Dumb phones were dubbed, thus, as a reaction to newer "smart" phones. They usually have a single color screen and a 12-key standard phone keypad with a power on and off button and maybe one or two other function keys. You can accomplish text input with a combination of presses on the keypad. The phone's secondary features such as storing phone numbers and texting are usually accomplished through a series of menus. The browsers on these phones use a protocol called Wireless Application Protocol (WAP). WAP was evolved by necessity on these "dumb" phones in the early 2000s. WAP breaks up the content into a series of menus and text cards, and you can use the menus to navigate through the text cards to achieve something approaching a wireless Internet experience. Unless you know for sure that your audience is using WAP-only phones, you can probably choose to disregard it and author your site in HTML only. This book will only touch briefly on the WAP protocol and will turn most of its attention to full HTML sites, as the vast majority of mobile web traffic in the US and Europe are smartphones using WebKit-based full-HTML browsers.
 |
However, there are some places where "dumb" phones in the US excel and are readily accepted. These include the following:
If you have a cell phone with a camera, it's confiscated by the security guards and given back to you when you exit. After having my cell phone confiscated at the door on a trip to traffic court recently, I noticed many of the lawyers in the building were carrying phones that look like they were from another era. As long as security measures such as these are in effect, there will always be a market for the circa 2001-era "dumb" phone with a T9 keyboard and a WAP web browser.
In the beginning mobile telephones were large bricks that needed constant charging and had a very limited range. By the year 2000, Nokia and Motorola had most of the US Phone market selling what we now call "dumb" phones. Dumb phones were dubbed, thus, as a reaction to newer "smart" phones. They usually have a single color screen and a 12-key standard phone keypad with a power on and off button and maybe one or two other function keys. You can accomplish text input with a combination of presses on the keypad. The phone's secondary features such as storing phone numbers and texting are usually accomplished through a series of menus. The browsers on these phones use a protocol called Wireless Application Protocol (WAP) . WAP was evolved by necessity on these "dumb" phones in the early 2000s. WAP breaks up the content into a series of menus and text cards, and you can use the menus to navigate through the text cards to achieve something approaching a wireless Internet experience. Unless you know for sure that your audience is using WAP-only phones, you can probably choose to disregard it and author your site in HTML only. This book will only touch briefly on the WAP protocol and will turn most of its attention to full HTML sites, as the vast majority of mobile web traffic in the US and Europe are smartphones using WebKit-based full-HTML browsers.
In the beginning mobile telephones were large bricks that needed constant charging and had a very limited range. By the year 2000, Nokia and Motorola had most of the US Phone market selling what we now call "dumb" phones. Dumb phones were dubbed, thus, as a reaction to newer "smart" phones. They usually have a single color screen and a 12-key standard phone keypad with a power on and off button and maybe one or two other function keys. You can accomplish text input with a combination of presses on the keypad. The phone's secondary features such as storing phone numbers and texting are usually accomplished through a series of menus. The browsers on these phones use a protocol called Wireless Application Protocol (WAP). WAP was evolved by necessity on these "dumb" phones in the early 2000s. WAP breaks up the content into a series of menus and text cards, and you can use the menus to navigate through the text cards to achieve something approaching a wireless Internet experience. Unless you know for sure that your audience is using WAP-only phones, you can probably choose to disregard it and author your site in HTML only. This book will only touch briefly on the WAP protocol and will turn most of its attention to full HTML sites, as the vast majority of mobile web traffic in the US and Europe are smartphones using WebKit-based full-HTML browsers.
|
However, there are some places where "dumb" phones in the US excel and are readily accepted. These include the following:
If you have a cell phone with a camera, it's confiscated by the security guards and given back to you when you exit. After having my cell phone confiscated at the door on a trip to traffic court recently, I noticed many of the lawyers in the building were carrying phones that look like they were from another era. As long as security measures such as these are in effect, there will always be a market for the circa 2001-era "dumb" phone with a T9 keyboard and a WAP web browser.
So between the "dumb" phone and today's high-end smart phones are what the industry calls "Smart-er" phones. They usually have color screens and a keyboard that enables faster SMS communication, but don't have the processing power or storage capability of a fully-fledged smart phone. Recently, cheap Android-based smart phones have supplanted these phones, but there are still a few of them in the market. They mostly use the WAP protocol that the dumb phones use, but with a few exceptions.
So, as with dumb phones, unless you know for sure that your audience is using these devices, you can eschew WAP and turn your attention toward building sites with standard HTML.
 |
About a year after the iPhone was released, word leaked out onto some blogger sites that Google was creating an open source operating system for phones. Based on Linux, the new OS would be made available free of charge to handset manufacturers and would also offer some of the advanced functions available to iPhone owners. Google would also allow developers to submit their applications to a common market where users of the OS could purchase and download these. The industry was instantly a buzz. Android adoption started out slow, but as the OS improved, more and more manufacturers started releasing phones with their tweaked version of the Android OS. The touch screens and features on a par with the iPhone at a fraction of the cost and on the carrier of their choice drove Android to success and made millions for Google in search revenue. More than that, it gave the iPhone some competition—and competition almost always drives innovation.
 |
Android's greatest strength was also its greatest weakness. Anyone could alter the OS and put it on their handset, which means that programmers had to contend with changes in the configuration from a multitude of hardware sources. When writing custom applications for the handheld, testing, and vetting each of the hardware configurations was, and continues to be, a nightmare for Android developers. And the submission process for applications to the Android App Store was not nearly as streamlined as for Apple's App Store. But creating a truly cross-hardware version of your application needn't be a lesson in patience.
Just as earth-shattering as the iPhone announcement was Apple's release of the iPad. Tablet computing has been around for a number of years, but with a stripped down version of Windows as its OS. Many users rejected tablets as they considered them reductive—"less" of a computer than their desktop—and they never really caught on.
The iPad was all about more. It was like an iPhone, but more than that. Like a laptop, but without a clumsy fold-out keyboard and the battery lasts for 10 hours.
Since then a myriad of Android tablet-style devices have been released with a varying amount of sales success, but as of the date of this book's printing, the iPad remains king of the tablet world and will for a number of years in the future. There's some marketing research to suggest consumers are buying tablets in situations where they normally would have bought a laptop for $500, and with the emergence of cloud computing, it makes sense to forgo a bulky laptop in favor of a lightweight tablet.
Now, I have replaced my laptop with a 3G iPad that is always connected wherever I go. It's possible for me to travel for days without touching my laptop and do almost everything I could do with it, including administering servers, writing code, and authoring this book.
The emergence of the tablet is one of those decade-definer events along with the social networking, the Internet, and the personal computer before it, that would change the landscape of computing in ways that no one could predict.
Although the Android platform and iPhone differ greatly, there's one very important similarity—their web browser. Both OSs have their web browsers based on the open source WebKit project.
In 2001, Apple needed a small, lightweight web browser for it's new Mac OS X operating system. They chose a little-known open source project called KHTML for its clean code, support of web standards, and minuscule (for a web browser) codebase. KHTML was basically a set of libraries you could use to render HTML documents in Windows. From the KHTML project, Apple spun off the WebKit and created their Safari web browser, and a few years later, Google created their Chrome browser from the same set of libraries. Because of its modern compact rendering engine, Safari was able to leapfrog Firefox and Internet Explorer in its support for emerging standards. It became the logical choice for both Apple and Google's handheld operating systems. When Blackberry updated its operating system to enable touch screens, they also chose the WebKit rendering engine, so when you're developing for mobile browsers, with a few exceptions, you're basically developing for WebKit, which makes life significantly easier than developing sites for the desktop. WebKit boasts some of the best rendering of CSS and HTML and some of the fastest JavaScript of any web browser.
But more often than not, you purchased this book because you have a particular website in mind that you need to "make mobile". I encourage you to rethink parts of your website that no longer make sense in light of a mobile paradigm. Things such as hover-based navigation, photo galleries of large-sized images, music, flash, or high-speed repeating animation on the home page will frustrate your mobile users for reasons we will make clear. So to "mobile-ize" your website, you may need to do more than just come up with some slick tricks and mobile-friendly CSS to make the mobile experience of your site first-rate.
Throughout this book, we will be working through an example website. Chapter 2, Setting up a Local Development Environment, will get the example set up, but if you have an existing site, feel free to set up a development environment of your own and add mobile additions to your existing site. The book is set up to work through the example adding features one-by-one, but the chapters will be generally self-contained and you can take them a la carte.
All-in-all, there are about 6500 different web-capable mobile devices. We will attempt to create a site that is viewable on the vast majority of those devices.
But all of this begs the question that is discussed in the section that follows.
Is mobile just a piece of hardware? We've talked about hardware, some of the software, iOS versus Android, and WebKit versus WAP browsers. But what exactly is "mobile"?
Mobile is a context—the context of the user rather than the context of the computer. With most computing, the assumption is made that it will be done on a desktop or laptop and there will be a storage device, a display device, and multiple user inputs such as keyboards, mice, and trackpads.
Mobile relinquishes those assumptions and assumes only the user. Nothing about the device and screen may be assumed, because we could be talking about a mobile phone with a four-line screen and WAP browser. Nothing about the keyboard can be assumed because very few mobile phones have physical keyboards these days.
A "mobile" website must be adaptive and able to be displayed wherever and whenever the user needs or wants to and cannot make any hardware or software assumptions.
And that is why, in my opinion, it should be a different website from your standard desktop version.
The theme-ability of the content and agile nature of the CMS make Drupal a perfect tool to solve some of these design challenges, as you will soon see.
So there's a theory of design. It states that we should design the website so that all the pieces work together in both a desktop context and in a mobile context. Use smaller design pieces that are adaptable to small screens and use CSS that will optimize the display for whatever the user chooses to view the website on. This is sort of a "one ring to rule them all" mentality.
I would disagree with this strategy. Not only is this an incredibly difficult task for a designer, but I think this approach overlooks a basic constraint. The ways in which we consume information on a desktop machine and that on a handheld device are completely different.
I believe the act of reading itself is completely different for all. More than that, I find the websites on which I'm most compelled to view content have two versions (a desktop version and a mobile version).
Feel free to disagree with me, but this is primarily the approach we will be taking in this book. And with Drupal as the CMS, you will see this approach becomes easy with the addition of contributed modules that separate content and allow different themes and JavaScript for different domain names.
For every rule there is an exception and there is, indeed, a place where the two-pronged site approach breaks down. Designing a website for tablets requires aspects of mobile design, a clear attention to touch events, and a design that's not quite tailored to the desktop and yet not quite a mobile phone.
We will discuss the ways Drupal can power your tablet strategy and try to cover the gap between the smaller mobile site and the full-version desktop site.
Before we set up a development environment, we need to set up a simulation of our mobile devices. We do that with either of the two packages—the Android development package or the XCode/iOS development package. XCode is available for Mac OS X only, but the Android development environment is Java-based and will work with any modern OS that has a Java Development Kit installed.
1. To download and install the Android development package, go to java.com and download the Java Development Kit (JDK) . Just having a regular Java package installed is not enough. You need to install the developer tools, too. Go to http://developer.java.com and search for the JDK developer download. It will be a
.exefile. Run the installer:
2. Once JDK developer is installed, the next step is to get the Android development tools. These are available at http://developer.android.com. Download the
.exeversion of the Windows installer.3. After the first Android installer runs, it will launch the Android Software Development Kit (SDK) and Android Virtual Device (AVD) manager. Yes, I know these are a lot of acronyms. Java developers love their three-letter acronyms. The SDK and AVD manager will ask to download the various android platform-specific APIs. Go ahead and choose the default options. Android will go through a series of downloads and install them after they are downloaded:
4. We then need to create an Android Virtual Device. Click on the Virtual devices tab and then click on the New button. Let's create one for Phone emulation and one for tablet.
5. Name the first one phone and select Android 2.3.3-API Level 10 (which is the latest, at present).
6. Choose a screen size. The QVGA skin should work for most phones. Then click on the Create AVD button to launch the Virtual Device:
One of the current problems with the Android platform is called fragmentation. This means that there are a lot of devices that have been sold with various versions of the software on them. As Google produces new distributions of Android, some devices get the updated versions and some do not. Depending on how much the device manufacturer and carrier have customized the Android software, they may make the decision that it's in their best interest to force the user to upgrade to a different device rather than to distribute the updated software to existing devices.
As a developer, if you create an Android application, you have a situation where there are hundreds (maybe thousands) of different combinations of hardware and software to test with your application. In addition, because of the open source nature of the Android OS, each manufacturer of hardware has the ability to alter the Android experience. This includes adding applications that showcase their hardware's features and adding APIs that allow their phones to connect to special networks or services that only they offer. As if that wasn't enough, phone hardware manufacturers often alter the hardware or software of a phone in response to a request from the phone carrier. Verizon is known for not allowing certain phone features to be used without their permission or to be used in a way that allows Verizon to charge for the service.
The myriad of combinations of hardware, hardware manufacturer additions, Android-based OS versions, and carrier additions has the ability to make potential Android developers homicidal. Google is taking steps to minimize fragmentation, but at present, we have a hodge-podge of customer conditions that can only be described as "less than optimal". This makes mobile web development that much more compelling because the version of WebKit that ships with them has very little differences between the various software updates.
As a platform, iOS has the same problem with fragmentation that Android does. Their application development has a tendency to be a bit tyrannical. No software can be installed on an Apple device without first being submitted to the Apple's application review process. Legend has it that Steve Jobs' insistence on Apple's control over the user experience was a big stumbling block for Verizon and Sprint in the early days of developing the first iPhone and it led to them pairing with AT&T in the US for its initial release. Once the iPhone released and was being sold very well, AT&T asked Apple to limit the amount of YouTube videos or the quality that could be played on an iPhone. Apple's response was something to the effect of "No, we're not dumbing down our user experience for you." Apple's laser beam focus on the user and user experience is simultaneously iOS's biggest draw and its greatest developer gripe.
There's an active community who regularly jailbreaks iOS devices, or rather enables applications from other sources to be installed. In terms of numbers, it represents a very small proportion of total iOS device users and there's always the possibility that jailbreaking your iOS device could lead to "bricking" (Apple rendering the device useless or "like a brick"). And bricking your iPhone is, most assuredly, not covered under the warranty.
All software on an Apple device is written in Objective C. This is a dialect of the very popular and proven C programming language that's pretty much only used by Apple. When faced with learning a completely new programming language and Apple's API additions to the language, combined with Apple's App Store policy and the fact that any application you develop has no guarantee that it will be accepted and appear in Apple's App Store, many developers, again, turn to the mobile web.
Mobile websites need only a URL to be visible from any iOS device. But the quirks of the iOS web browser—Mobile Safari—make for a lot of trial and error JavaScript and CSS. Fortunately, Apple has mobile web simulation software available with its iOS developer toolkit that will allow us to preview our site before uploading our changes to the live version.
1. In order to download and install the Mac OS developer's package, you first need to register with Apple as a developer. Go to http://developer.apple.com/programs/register/.
2. If you have an iTunes username and password, you're welcome to use it or create a new one specifically for your development work. There are two options. You can register as an iOS developer, which costs $99 for a year and allows you to submit iOS applications to the iOS App Store. If you're not planning on doing any iOS development, you can simply download XCode 4 from the Mac App Store.
3. Once you've gone through the free registration at Apple's site, launch the Mac App Store and search for xcode.
4. Once XCode is installed, you can use the Mac's computer-wide search to find the iOS Simulator, as shown in the following screenshot:
5. Launch it and click on the Mobile Safari icon in the bottom tray. Go to
http://dpk.local. It should appear in your desktop browser, as shown in the following screenshot:
Debugging CSS and JavaScript for web pages is never easy. It's made even more difficult with the proliferation of desktop operating systems and, now, handheld and mobile operating systems. No matter which browser claims to have "emulation" or modes that simulate this other browser or that, it's not a substitute for looking at the web page in the actual browsers. Debugging pages in Internet Explorer, requires an install of Windows XP and the browser itself. Don't settle for anything less. With handheld devices, you really need a virtual environment where the handheld OS is running a real version of the browser.
In this exercise, we created such a virtual environment. The XCode package creates the environment for the iPhone and iPad, and the Android development environment creates the virtual machine for any OS capable of running Java.
The changing mobile landscape requires a web content management system able to creatively address the problems of modern websites. Drupal is just such a CMS. I stated it earlier in the chapter, but it bears repeating—Drupal's worldwide developer base ensures that any problem you ever attempt to solve has been solved by multiple other developers in several different contexts.
The first task at hand is to set up a mobile simulator so we can view web pages as they appear on the device. We did that by installing an Android simulation environment on Windows and XCode from Apple's Mac App Store.
In the next chapter, we will take a look at our example site and get a sane development environment in which we'll build this fantastic mobile site.
We're going to outline a workflow that will allow developers in teams to work with Drupal in a way that allows everyone to do their jobs without stepping on anyone's feet, and at the same time, minimizing the amount of overhead work any developer needs to do. Ready to go?