Tag: html 5

The 1 Minute Primer for HTML 5

HTML 5 is getting a lot of press these days and I get a constant stream of questions from many non-techies, as well as developers, asking me to explain HTML5 in layman’s terms. So here it is.

HTML 5 is really a combination of three things: HTML, CSS and JavaScript. When all three of these technologies work together in a web browser then you have an HTML5 application. Period.

Why should we care about HTML 5? HMTL 5 brings many long awaited enhancements that make it easier for web developers to build more complex applications. More importantly, HTML 5 is being adopted by the major browser vendors: Google, Microsoft, Mozilla and Apple and this adoption is making it possible for developers to take advantage of the latest web technology that are built into web browsers.

How is HTML 5 “built into a web browser”? Web browsers have to interpret a web page first, and then display the content for you. Browsers contain logic that let’s them parse a pages’ code, and that code provides instructions for the browser to do certain things. Behind the scenes, in fact, the page you are looking at is built using code. It’s the browser that interprets the code and displays it in a way that makes sense to you. If you haven’t ever seen web page code then you can usually select View > Source on your browsers tool bar. Cool, right?!

HTML 5. HTML 5 is the latest version of the Hypertext Markup Language (HTML) specification which has been around in various forms since approximately 1991. HTML is a tag based language that defines the meaning and placement of elements of a web page. For example, a <button> tag defines a clickable button on a web page.

Cascading Style Sheets (CSS). Cascading Style Sheets, or more specifically CSS version 3 (a.k.a CSS3), provide the ability to apply styling to HTML elements. An example of styling would be to change the color of an HTML <button> from grey to green, as well as defining where on a web page it will be visible such as the top left corner.

JavaScript. JavaScript, which is really the meat behind HTML 5, is a type of programming language that lets developers implement actions within a web page. An example of an “action” would be when a web page visitor clicks a button that loads a picture. So, HTML defines the <button>, CSS styles the button, and JavaScript handles the action behind the scenes by retrieving the picture and then telling the browser how to display it for the end user.

This all sounds great, are there any downsides? Yes. First, HTML 5 is a standards-based specification that is still a work in progress. The specification and all its’ associated parts won’t be finalized for some time, possibly years. The good news is that browser vendors are keen to adopt this standard as much as possible. Second, implementation across different browsers isn’t 100% consistent. The good news is that there are tools and online resources to help developers work around many of these problems. Last, older versions of browsers (e.g. Internet Explorer 7 or 8, older versions of Safari, etc) don’t support HTML 5. There are strong campaigns under way to educate people to upgrade for security, performance and viewing experience.

So, there you have it. That’s a cursory pass at HTML 5 and I hope this post helps. I’ve added a few links at the bottom if you want to learn more about it.

Learn More:

 HTML5Rocks.com – includes information on features, tutorials and great slide decks.

w3Schools.com –  includes live “Try it” samples that let you explore the functionality.

W3C HTML 5 Specification –the World Wide Web Consortium is the group that writes the standards. If you are a techie, this is “the” specification that the browser vendors base their functionality on.

State of the Internet Browser 2012 – consumer browser usage will decrease

Over the next two years I see consumer browser usage decreasing and people will increasingly spend more time using native mobile applications. This has a number of interesting implications.

The facts. As a web application developer I pay close attention to browser and browser-related technology usage statistics and trends. Like most people, I judge statistics based on my own experience and the experience of my co-workers, family and peers.  Here are some trends which I’ve been keeping an eye on:

  • Smartphones are rapidly replacing non-smart phones around the world.
  • The number of specialized smartphone applications is continuing to expand.*
  • The number of games for smartphones continues to grow rapidly.**
  • The amount of time people spend on their smartphone, whether it’s playing games or using specialized applications, is increasing.

Also based on my personal experience are the following additional observations that further tilt the balance in favor of native applications:

  • Performance. Native smartphone applications, when built correctly, almost always outperform web applications: I’m referring to actions such as page refresh, general drawing capabilities and to a lesser degree but still a factor is the look-and-feel. This is a general fact of application technology: compiled applications perform faster than interpreted applications. For the most part, once I’ve used a native application, such as Southwest Airlines check-in app, I loathe having to use their web page. It just seems so clunky and slow in comparison.
  • Games. Ah yes, we can’t forget game performance as well as their look-and-feel. Why would I want a mobile browser-based game? What’s the point of building a high-performance, beautiful user interface game in a browser? See my previous bullet’s comment about compiled application performance. Yes, yes, yes I know that HTML 5 is making big strides, but we are talking mobile applications and the technology as it exist today. You can’t tell your customers that they’ll have to wait another year for better game performance, because by then your favorite browser will have such and such HTML 5 functionality figured out. Your competitors would jump right in, tweak their native app and leave you in the dust!

A Corollary. If you generally agree with my bullets above, the perhaps you’ll agree that the corollary is this trend:

  • Consumers are spending less time on desktop and laptop machines “browsing the web” and more time using their smart phones.

In addition to the reasons I already listed, there are many reasons for this. I suspect the top reasons are because it’s so easy to use your smartphone, and it’s right by your side all the time even when you aren’t home. You most likely have seen people with their heads down playing with their smartphones during business meetings, while eating, while standing in line, while watching TV and even during sports events.

What about the Browser Vendors? These trends have interesting implications for browser vendors. They have to be aware of what’s going on. It’s possible that this is one of the many factors behind their massive push to add HTML 5 capabilities in an attempt to stave off what I’m going to call “user erosion”, as consumers spend less time using web browsers.

But, there are some facts to consider related to building applications that run in the browser:

  • Still functionality problems between different browsers. While the latest generation of browsers are the closest they have ever been to parity, in terms of JavaScript and HTML functionality, web developers are still hacking code to make certain things work equally across all browsers. These “hacks” cost extra time and money to code and maintain and the functionality differences between browsers cause customer frustration when things look different or don’t work as expected. This is especially true in large, retail-type consumer apps were you have little control over what browser your customers choose to use.
  • Faster but fast enough? Today’s browsers have the fastest parsers ever, but it’s a fact that they still aren’t as fast as native code, and they never will be. For the geeks reading this, browsers incur a CPU cost associated with parsing and then executing interpreted code. Smart engineers are going to continue to close the gap, but compiled code will always be faster and more powerful than code running in a browser. Period.
  • Memory usage. Browsers tend to be what we call “leaky”. The longer you use one without restarting it the more memory it will consume. I believe this is less of a problem in mobile browsers where windows get closed a lot more frequently than desktop/laptop browsers. However, it’s still an important consider this in mobile phones where more memory usage equals less battery life. Native apps can definitely leak memory, but they are also starting from a smaller initial footprint, and there are much better tools available for finding native app memory leaks. For browser apps, you also have the browser’s memory usage in addition to your application’s memory usage.
  • Security. Security is getting better for web browsers. But…it’s still easier to build a highly secure native app today than it is to build a secure web app. Also, for better or for worse, I suggest that many consumers perceive native apps to be more secure than web apps. Do you want to do your mobile banking over a web app or a native app? And whether a perception is right or wrong sometimes is irrelevant because it always strongly affects people’s behavior.

Concluding Remarks

Consumer-based companies are going to make important strategic choices based on information similar to what I’ve written above. My guess is that the most successful businesses will be the ones that adapt to what their customers want and if your customers are spending less time “on the web” then you should seriously consider adapting. Just to be clear, I’m definitely not saying that browsers are going away. No one has as crystal ball, and new technology is being created all the time. However, the momentum and sheer size of these trends, with hundreds of millions of people buying and using smart phones worldwide, makes it well worth studying its potential impact on your business.

References:

Mobile Apps Put the Web in Their Rear View Mirror
Mobile Apps vs. the Web – Which is Better For Business?
Gartner Report on Smart Phone Sales in 3rd Quarter 2011

* Companies are building specialized apps that essentially replace the need for customers to visit their web site. However, these apps offer much more control and typically provide a more consistent user experience that the web. Southwest Airlines, for example offers three types of mobile apps in addition to a mobile web site: https://www.southwest.com/html/air/products/mobile.html.

** Books and games, respectively have consistently been the top two categories for the most popular apps, for example: https://www.gottabemobile.com/2011/07/06/ipad-app-store-breakdown-top-apps-categories-chart/

The pace of technological change: Do Android’s really dream of electric sheep?*

Google’s Android v1.5 (Rev 1) was released in April 2009. In 2010, there were three major dot-X releases of the 2.x platform: v2.1, v2.3 and finally v2.3 in December 2010. According to Gartner in a February 2011 report, Android grew from 3.9% of the worldwide smartphone market, to almost 23% in the span of one year, from 2009 to 2010. That’s roughly 888% growth.

As a developer, I’m awed by the pace of change and the rate of adoption. I like being on the cutting, and now the consumer competition is furious for mindshare, and the mad push is on for developers to build applications that take advantage of the latest software and hardware technology. It’s a developers dream. Cool new toys, ever better functionality and hardware with new releases just six months away!

And while I like to simply pay attention to the technology and ignore everything else, I’ve been asked a number of questions recently by other developers who work in a variety of industries from around the world, and to which I have no answer. If you read this please share your thoughts:

  • How do we plan software development cycles around mobile phone system(s) that change dramatically every six months? We are talking about both hardware and software.
  • If I build an application now, will it still work on the next generation of hardware which will come out in one year or less?
  • Will applications that were built on the latest mobile OS still be backward compatible in one year?

What’s interesting is we have been faced with similar questions before when Adobe Flex, Microsoft Silverlight and even HTML 5 were announced. And, yes, they are changing the way we build applications and to a large extent changing what our users expect to experience. However, internet browsers have been around for a while, web development technologies in general aren’t exactly new, and all computers these days come with a pre-installed browser. But, all the sudden we could more quickly develop beautiful applications in days and weeks that used to take many months, or years. And, it’s been an eye-opener as far as our surfing experiences go.

Many commercial applications have never been more powerful with built-in charting and dynamic access to data with very graceful interfaces. These applications opened our eyes to what’s possible by letting us build applications independent of the machine they ran on. And, in a sense it was liberating. The idea of building one version of the software and then deploying it across many machines and devices became true. I, for one, touted that I no longer had to worry about esoteric items such as pointers and garbage collection. The browser took care of all that for the most part, even though it still had a few issues.

Maybe I celebrated too soon. What’s changing now is the pace of adoption which is in the form device that fits in your hand, and you can carry with you anywhere even when you hike, that accesses the internet, and that has similar functionality to a desktop/laptop system. Smart phone access is changing how people communicate: live, work and play. It’s becoming the primary connection to the internet in many parts of the world. It’s becoming a primary work tool while on the road.

We, as developers, are at the heart of this change and with a front row seat.

Our use cases are changing to accommodate people accessing our applications while they are standing in line ordering their morning coffee. We’re back to looking at native applications which don’t run in the browser and are subject to all sorts of interesting limitations and challenges. We are back to adapting code to different devices, limited battery life, testy internet connections, varying processor power, and dealing again with problems related to device drivers.

It’s funny that I caught myself thinking how nice it would be to have a software framework that would let me abstract away all these pesty problems that low-level code development entails: a sort of Flash Player environment for low-level code on a mobile phone. I mused about how easy it was to use FlashBuilder “Burrito” to convert my Adobe Flex applications directly to Android without having to deal with Java code (which works very nicely by the way). Or, do I build a rich functionality web app?

But, you know, I chuckled as soon as I had a requirement that asked for closer access to the smart phone hardware and operating system: things related to power management, and getting more information from the device GPS. Do I wait until the functionality I need is built into an abstraction library…or do I build a native application today? Which applications do I build for the web, and which application should be native?

These are all business question that many of you will also face. I’m certain it’s being asked thousands of times around the world. And ultimately, whatever the answer is… it will change the way we all do business.

*I pay full respect to Philip K. Dick’s 1968 science fiction novel, Do Androids Dream of Electric Sheep?, that served as the primary motivator for the movie Blade Runner which was first released in 1982.