If you are reading this book, you are probably a web designer or a web developer, maybe a jQuery fan or a webapp developer. Before coding, we need to address the mobile ecosystem and where jQuery Mobile fits into it. Let’s do it.
The first question that you should be asking yourself is why does jQuery Mobile exist? Why do we need something special for mobile devices if there are plenty of mobile browsers rendering standard desktop websites?
To answer these questions, let me copy and paste some extracts from my other book Programming the Mobile Web (O’Reilly). By the way, I asked for permission from myself for doing that.
As the Web has moved onto mobile devices, developers have told themselves a lot of stories about what this means for their work. While some of those stories are true, others are misleading, confusing, or even dangerous.
I’ve heard this many times in the last few years, and it’s true. It’s really the same Web. Think about your life. You don’t have another email account just for your mobile. (Okay, I know some guys who do, but I don’t believe that’s typical.)
You read about the latest NBA game on your favorite site, perhaps ESPN; you don’t have a desktop news source and a different mobile news source. You really don’t want another social network for your mobile; you want to use the same Facebook or Twitter account as the one you used on your desktop. It was painful enough creating your friends list on your desktop, you’ve already ignored many people…you don’t want to have to do all that work again on your mobile.
So, yes…it’s the same Web. However, when developing for the mobile web we are targeting very, very different devices. The most obvious difference is the screen size, and yes, that will be our first problem. But there are many other not-so-obvious differences. One issue is that the contexts in which we use our mobile devices are often extremely different from where and how we use our comfortable desktops or even our laptops and netbooks.
Don’t get me wrong—this doesn’t mean that, as developers, we need to create two, three, or dozens of versions duplicating our work. This is where jQuery Mobile comes to the rescue.
Almost every smartphone on the market today—for example, the iPhone and Android-based devices—can read and display full desktop websites. Yes, this is true. Users want the same experience on the mobile web as they have on their desktops. Yes, this is also true. Some statistics even indicate that users tend to choose web versions over mobile versions when using a smartphone. However, is this because we really love zooming in and out, scrolling and crawling around for the information we want, or is it because the mobile versions are really awful and don’t offer the right user experience? I’ve seen a lot of mobile sites consisting of nothing but a logo and a couple of text links. My smartphone wants more!
As we will see, there are techniques that allow us to create only one file but still provide different experiences on a variety of devices, including desktop, mobile, TV, and game consoles. This vision is called “One Web.” Today, there are a lot of mobile devices with very low connection speeds and limited resources—non-smartphones—that, in theory, can read and parse any file, but will not provide the best user experience and will have compatibility and performance problems if we deliver the same document we would for the desktop. Therefore, One Web remains a goal for the future. A little additional work is still required to provide the right user experience for each mobile device, but there are techniques that can be applied to reduce the work required and avoid code and data duplication.
This is the other fast-food way to think about the mobile web. Today, there are more than 3,000 mobile devices on the market, with almost 50 different browsers (actually, more than 500 different browsers if we separate them by version number). Creating one HTML file as your mobile website will be a very unsuccessful project. In addition, doing so contributes to the belief that the mobile web is not useful.
Frequently mobile webapps also make use of HTML5 features, such as offline or geolocation access, to provide a better experience. Geolocation is not an official part of the HTML5 specification, but a W3C API of its own; however, it is often mentioned under the HTML5 umbrella.
A webapp can be implemented in many ways (as shown in Figure 1-1) including:
Accessed from the browser
Installed as a full-screen webapp
As an installed webapp via a package officially implemented by vendors (sometimes called widgets)
As an installed webapp embedded in a native application, commonly known as hybrid
Figure 1-1. A webapp delivered as (from left to right) a browser-based experience, a full-screen installed application, and an embedded webapp inside a native app (hybrid)
We will cover how to create these webapps in the rest of the book. For more in-depth information, just cross the street to my other book: Programming the Mobile Web (O’Reilly).
A webapp typically generates new challenges for web designers and developers, such as loading views instead of pages, maintaining a two-way navigation between views, and creating rich controls specifically for touch devices.
If you read the last few pages (and I’m pretty confident you did), you are aware that mobile web design and development presents new challenges for us. We need to create webapps that are more than simple websites; there are too many devices out there with different browser compatibilities; and there are also too many libraries trying to solve the same problem with mixed community and device support.
That is why jQuery Mobile was created: to help designers and developers create mobile web experiences easily, and for those experiences to be multiplatform, customizable, and with unobtrusive code.
The extensive worldwide jQuery community also provides a great opportunity for the framework’s future.
The framework has received official sponsorship and support from many of the biggest companies in this area, including the following: