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.
?? 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.
"Dumb" phones
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:
·
Government jobs that require that your cell
phone does not have a camera
·
Many Health and Human Services buildings that
deal with minors and much of the court system has security in place that
doesn't allow cameras in the building
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.
"Smart-er"
phones
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.
Smart
phones
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.
Tablets
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.
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.
WebKit
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.
Mobile size me!
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.
But all of this begs the question that is discussed in the section that follows.
What
is mobile?
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.
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.
The
"One Design" myth
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.
Mobile
simulators
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.
Time for action – installing an Android development package
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 .exe file. Run the installer:
It will be a .exe file. 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 exe version 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:
What
just happened?
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.
iOS
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
ver 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
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.
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.
Time for action – installing the Mac OS developer's package
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:
What
just happened?
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.
Summary
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? Let's get started!
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? Let's get started!
