Translating Geek Into English
In this edition…
Two weeks ago, I had the honor of doing two days of training on JavaScript, jQuery, and Mobile Web Development for a group of about 20 community college instructors. For the JavaScript and jQuery parts, I used presentations created as ancillary materials for my “Modern JavaScript: Develop and Design” book. Because those ancillary materials are owned by the publisher (who will freely give then to instructors), I cannot post those parts of the presentation online. Here, however, are the slides for the “Introduction to Mobile Web Development” part of the training.
The presentation introduces the core concepts when it comes to mobile Web design, and then discusses jQuery Mobile in particular. Most of the information comes from various online resources, and whatever else I’ve figured out along the way. The one book I have read that discusses mobile Web design is O’Reilly’s Head First Mobile Web. I absolutely detest the Head First series, but found that book to be a decent introduction to the topic.
As I’m in the midst of writing a book on JavaScript, I’m hyperaware of browser market share at the moment. Although my “Modern JavaScript: Develop and Design” book takes a progressive enhancement approach, which means the end result will work reliably across all browsers and devices, it’s still good to pay attention to what people are commonly using. At the very least, watching the browser market share helps you to know what devices and browsers to test on first. Anyway, InfoWorld had an article last week discussing how IE’s market share is dropping towards 50% (really? still that high?), based on statistics from NetMarketShare. As the article points out, in the mobile realm, Safari remains the clear leader, even increasing its share to over 50%. This despite the fact that Android phones far and away outsell iPhones. But Safari is also running on the iPad and the iPod Touch.
An interesting note to me is that the two most commonly used browsers–IE on the desktop; Safari on mobile devices–are not the browsers that most developers and designers are using, at least not as their primary tool. This is another example of the developer’s primary hurdle with any Web site or application: bridging the gap between what the developer thinks is right and what people will actually do!
As you may have seen, Amazon announced their new lineup of Kindles today, from the $79 base version to the $199 Kindle Fire, a rival to Apple’s iPad. One thing that piqued my interest about the Kindle Fire is that it includes a new, custom Web browser, named Silk. Amazon posted an introduction to Silk, along with a six-minute video, on their site today, too. A lot on that page and in the video is marketing hype, but they raise some interesting points about the fact that Web browsers are fundamentally the same as they were 15 years ago, and aren’t ideal for today’s use, especially with all the mobile devices. Now the solution they came up with seems to be something akin to a reverse CDN: Whereas a CDN takes the load off of one server and shares it across a network of servers, Amazon Silk uses Amazon Web Services (AWS) to reduce the load on the device. From just what I’ve seen, it doesn’t seem like they’ve addressed a problem with browsers, but rather with the HTTP protocol, introducing their own gateway to improve the communications. It’ll be interesting to see what impact this new approach has, and how, if at all, it affects Web development in the years to come.
Oh, and it may be time for me to buy a new gizmo!
Some time back I posted a link to an article I read on the Chicago Tribune’s Web site (the article was later pulled from that site, for an unknown reason). The article discussed how the Financial Times and ESPN created “mobile apps” using HTML5 instead of native code. It’s an interesting concept:
It’s this last point that impacted the Financial Times’s decisions to go with a Web app, as detailed in this recent article at Macworld.
To be fair, an HTML5-based app is clearly lacking many features that conventional mobile apps can offer. And because HTML5-based apps use the device’s browser, it’s a different, less branded, user experience, even though some steps can be taken to equate the two (as the article discusses). But just one year ago, if you wanted to develop mobile apps for iOS devices, you had to: own a Mac, know Objective-C, and distribute through Apple’s App Store (okay, you didn’t technically have to, but you essentially had to). To develop mobile apps for Android devices, a separate set of skills, software, and destinations was required. Now you have two great alternative routes: using HTML5 or Adobe Flex+AIR (as I’m doing).
