Selling HTML5 Business Case - The value to the business?

[johnmoxon]

Hi There,

I've been using HTML5 for personal projects for the last few months and recently I was given the chance to attends a HTML5 workshop on behalf of my employer one of the biggest companies in Australia. On my return I was able to talk about all the new wonderful cool things we can do with HTML5, what will happen in the future and how we can even start implementing this now.

My superior however posed a question to me that has left me somewhat stumped in being able to sell HTML5 as a technology to my business minded superiors and we should start implementing today;

1. What is the business value of HTML5?
2. What value can be gained for the business in building sites and apps in HTML5 in-opposed to developing the traditional way?

I returned with: "we can build semantic machine readable content, with which we will be able to weight our content and give it more importance, and giving less importance to (a)side information that may otherwise dilute a page". I argued that very shortly this will allow search engines to be able to gain a greater understanding of our page contents value and therefore in time, semantically marked up HTML5 content will be promoted above non-HTML5 content in search engine results.

However again my superior made another good point. Semantic markup is open to abuse. Like Meta keywords and descriptions before, these we seen as a useful way to tell search engines what our page contained and what it should be categorised with. However as we all know Meta tags were abused so badly, they no long represented an accurate measure of a page's importance against a given user search, and with that in mind were dropped from search engine algorithms.

So with that in mind, on Friday I need to present a case to my superiors that states the business value of HTML5 and why we should start using it now. If anyone can lend their business brains I would be most grateful. I want to contribute to pushing HTML5 forward and the best way I can think to do that is to convince my employer to lead the way by implementing HTML5 now. If we can convince multi-national corporations like mine to take up the technology, then others we surely follow suit.

Yours sincerely
John Moxon

[JAB Creations]

(X)HTML5 is more search engine friendly, more people generally means a higher potential for revenue. Google and other search engines will be able to better understand what you site is about and the more on-topic the content the greater the amount of traffic you'll likely gain.

I generally recommend XHTML 1.1 though if you're looking for close to the best of both worlds I would recommend using XHTML5 served as application/xhtml+xml. It's exceptionally strict though that is the value inherent with XHTML, there are lot less mistakes you can effectively get away with and your code will be much cleaner. Use XHTML5 and instead of fixing HTML errors you can concentrate on expanding upon what you've already built.

I code my site to be WAI AAA compliant and if you want a higher level of quality that is also search engine friendly I would recommend using the description, keywords, language and robots meta elements. Use noarchive and either no/index and no/follow (nofollow or follow) separated by commas in the meta robots element. Limit your keywords to no more than seven words, only Yahoo (last I read) considers them though Google may silently consider them...too many is considered spamming and they must appear in the content on the same page to be worthwhile. Find the longest description for a normal search result on Google and that is your maximum allowed meta description though also make sure it's not too short, I imagine 70 characters would suffice though keep an eye on Google Webmaster Tools.

By sticking to some basic though very strict coding practices you ultimately save more time. If you code poorly you'll end up spending more time fixing things than actually learning to code strictly so ultimately it's best to approach things with stricter coding practices.

[johnmoxon]

Hi Jan Creations and thank you for your reply. we certainly understand the virtues of good coding practices which can be applied in most cases regardless of the markup language used. However the question was more specifically, how do we convince our employers that we should switch from HTML4 or XHTML to HTML5. The business minds will tell me that it is too big a change across our architecture which is not widely supported and doesn't really add any business value. Saying it is mire search engine friendly (as I myself have argued) does not really work as the business can argue it is unproven, open to abuse and there may not be as search engine friendly as we think.

Any ideas?

[Xdega]

I am not coming at your with super experienced business brains I'm an enthusiastic student, but here is my addition to the discussion:

One key thing I would push. Accessibility..
HTML5 allows for more semantic development, ask yourself why? Simply put, moving forward with HTML5 is saying that your business wants to be able to cater for a larger audience. Be it smartphone "android" users, Blind people (that require screen readers), or your typical desktop user, HTML5 markup is the future of this increasingly connected world we are living in. I also think that because HTML5 markup is more semantic (makes more sense) and requires less messy JavaScript etc, It is ultimately going to be much more streamlined in a full on team development environment thus saving on costs.

There is more that could be said beyond the semantic markup etc though. Such as the web app side of the spec. The media and canvas elements are very compelling and interesting, and allow cross browser "plugin-less" implementation. The "web forms" side of the spec allows us to throw away messy JS verification in place of natively supported alternatives.

On the "web apps" side of the HTML5 spec, I would recommend that you check out this presentation from Bruce Lawson. He always does a great job of explaining things with a sense of humor to boot: http://vimeo.com/6985053

Best of luck, and keep us posted on how everything goes. I know you may not be able to disclose the Information (if so, that's fine), but out of curiosity what is the name of the corporation that you work for?

ps: Let's also not forget that a LOT of html 4.01 and even some XHTML 1.1 markup will validate with HTML5 for the purposes of transition. They key thing that HTML5 brings is ADDITIONAL markup that allows better coding practices and lots of new interesting "goodies" if you will.

[johnmoxon]

Hi Xdega, thanks for your reply and I'm watching the video as we speak. Not sure if it would be wise of me to post company specific details on a public forum, I'll tell you I work for a large company in the travel industry and we are currently pushing e-commerce through desktop and mobile environments. I will keep you updated if we choose to move to HTML5 and please if anyone else in the community would like to contribute ideas then I would love to hear them.

Hopefully we can all take these arguments back to our own employers/industries and help HTML5 move forward.

[JAB Creations]

how do we convince our employers that we should switch from HTML4 or XHTML to HTML5. ... ?

As I said before the cost of production is reduced because you have to write better code, in regards to XHTML served as application/xhtml+xml. If you write poor code or abide by a language that allows poor practices then you may spend ten to a hundred hours (depending on the scope of the project) fixing problems whereas learning the strict method of coding might have taken one to ten in ratio.

[johnmoxon]

Ah okay, I see what you're getting at. Thanks Jab that makes more sense to me now.

[zcorpan]

Depends on what you're doing. If you have only content that can be done with HTML4 and no plugins and trivial javascript and no native apps for mobile, then there's very little value. However, if you're serving video content for instance, then you can reach a wider audience by using <video> (on mobile Flash is not a given but <video> is supported on newer devices and browsers -- unfortunately <video> has another cost associated with it since not everyone support the same codecs). If you use Flash for various things, you could maybe save development time and lower barrier to entry for developers (no need to learn Flash) by using HTML5+CSS3. (Assuming most of your developers have good knowledge with HTML and CSS but not everyone have good knowledge with Flash.) If you are providing multiple native mobile apps for different platforms then you could save development time by providing a single Web-based app that works on all platforms.

So in short: get a wider audience, and lower development cost.

I returned with: "we can build semantic machine readable content, with which we will be able to weight our content and give it more importance, and giving less importance to (a)side information that may otherwise dilute a page". I argued that very shortly this will allow search engines to be able to gain a greater understanding of our page contents value and therefore in time, semantically marked up HTML5 content will be promoted above non-HTML5 content in search engine results.

It's a nice theory but unfortunately we're not there yet. Search engines don't care about the new elements, as far as I know. Maybe they never will. You can only speculate at this point.

[zcorpan]

I generally recommend XHTML 1.1 though if you're looking for close to the best of both worlds I would recommend using XHTML5 served as application/xhtml+xml. It's exceptionally strict though that is the value inherent with XHTML, there are lot less mistakes you can effectively get away with and your code will be much cleaner. Use XHTML5 and instead of fixing HTML errors you can concentrate on expanding upon what you've already built.

I would say there's no business case to be made for application/xhtml+xml at all. Rather the opposite. It requires you to boil the ocean, makes the pages not work at all when an error happens to slip through your system (which has happened to everyone I know who have used application/xhtml+xml, including experts who are very knowledgable in XML), and provides no real features that text/html does not provide.

[JAB Creations]

I just wrote two good paragraphs and the forum software lost it when I accidentally hit a macro key. I'm just going to say this, my entire site is served as application/xhtml+xml and I wouldn't have it any other way. If XML parsing breaks I fix it on the spot and exceptionally few bugs make it to the live version of my site. XHTML5 makes perfect sense for businesses because broken products cost money.

[Xdega]

I just wrote two good paragraphs and the forum software lost it when I accidentally hit a macro key. I'm just going to say this, my entire site is served as application/xhtml+xml and I wouldn't have it any other way. If XML parsing breaks I fix it on the spot and exceptionally few bugs make it to the live version of my site. XHTML5 makes perfect sense for businesses because broken products cost money.

Although fact still exists that your website could be enhanced with HTML5 elements such as canvas. Thinking along the lines of the background especially, imagine it a little more animated?
Kinda like this: http://www.go2script.com/items/style/14

So basically although XHTML is great for static pages, the media elements that Zcor was mentioning are still improvements and worth perusing HTML5 for that alone if you plan wish to develop rich multi-media applications.

[JAB Creations]

Although fact still exists that your website could be enhanced with HTML5 elements such as canvas. Thinking along the lines of the background especially, imagine it a little more animated?
Kinda like this: http://www.go2script.com/items/style/14

So basically although XHTML is great for static pages, the media elements that Zcor was mentioning are still improvements and worth perusing HTML5 for that alone if you plan wish to develop rich multi-media applications.

I don't put the cart in front of the horse. Keep in mind that except for the search engine I've written all the software there except maybe about ten lines of JavaScript code (blog, chat room, forums, threaded private messaging, CMS, administrative tools etc). There's still a bit of work left to do before I can get to the more fun stuff like that however it is on my list to-do list.

You can set the wallpaper with any URL you'd like here at least...
http://www.jabcreations.com/blog/?promp ... -wallpaper

[zcorpan]

https://twitter.com/paul_irish/status/71288149975896064

[Amtiskaw]

Firstly, you should be clear about what HTML5 is, and is not. HTML5 is intended to be as backwards compatible as possible with its predecessors. A lot of the early work around HTML5 was around specifying behaviour that was already pervasive in browsers, but just had never been written down in a standards document. As such, the threshold of 'converting' sites and applications to HTML5 is very low, and in fact, it's not even clear that such a term is really meaningful. What is it that makes a site HTML5, vs HTML4? You might say it's the doctype, but you can use new elements like canvas within a site that has an HTML4 doctype, and they'll work just fine in modern browsers. Conversely, you can change a HTML4 doctype to that specified by HTML5 without changing anything else. Does that make the site HTML5, or an HTML4 site with an invalid doctype?

If you look at the latest HTML standard from the WHATWG, you'll notice that it doesn't have a version number at all. It is instead referred to as a 'Living Standard'. This is a somewhat controversial term, but it reflects the belief of some (all?) of the WHATWG members that a traditional version-based model, is not a good fit for HTML, and does not represent how the HTML standard has, and continues to, develop in the real world.

Traditionally, software platforms have been developed and released in discrete versions, with new versions requiring installation and adoption. Versions would be given identifying numbers to distinguish them, and would have an enumerated set of features. HTML isn't like that, and never has been. Despite some efforts to enforce a traditional versioning model on it, in reality HTML has always evolved in a continuous way. Different features are added at different times by different browsers. New features sometimes undergo radical change before behind stabilised, or get dropped entirely. Sure, you can choose a set of features and a cut-off date, write a spec around them and call that a version, but it's an essentially arbitrary process, and the web will quickly evolve past what you've written.

The upshot of this is that you shouldn't think about adopting HTML5 as a traditional platform shift, but simply carrying on what you've always been doing, that is using HTML, but using newer features and up-to-date practices. This shift in mindset isn't necessarily an easy one, especially for large organisations that are used to the traditional version-driven model of software adoption, but it's an important one. Those who don't manage it are liable to find themselves perpetually behind the curve on making the most of the web.

How this impacts on your business case is, I think, to emphasise that adopting HTML5 is not about shifting platform, and does not carry the inherent costs and risks that such a switch entails, but simply using as many or as few new features as you want to build better software and sites. The next part of your business case should focus on how these new features can make your software and sites better, while saving the business money...

Compatibility
HTML5 builds upon HTML4, clarifying many areas that were unclear or undocumented in the earlier spec. For example, it standardises the algorithms that browsers should implement, or appear to implement, when parsing HTML, and how they should behave if they encounter invalid mark-up. This means sites will work far more consistently across browsers, and will lower the cost of development and testing. In particular, it will make it far easier to make sites that work across new platforms like mobile devices and tablets. For example, if you want videos on your sites to work on the iPhone and iPad, you will need to use HTML5, as Flash is not supported.

Richer Experiences
Using new features in HTML allow you to easily achieve things that were difficult or impossible before. You can use the canvas tag and SVG to produce complex, animated, interactive graphics. You can use new elements like date pickers to better capture and validate user input. You can embed audio and video into your sites. Using these new features will reduce development costs, cut the need to purchase third-party components, and allow you to build sites that do more and provide a better user experience. They will increase customer satisfaction and make your company more competitive. If you don't adopt these features, sooner or later your competitors will, and you will be left trying to catch up.

Better performance and lower operational costs
Creating sites using HTML5 allows you do use mark-up that is more concise and expressive, and reduces the need to use third-party components like script libraries, widgets and embedded Flash. This will reduce the amount of data that your site sends over the wire, thus decreasing your bandwidth costs and increasing the performance of your site on client computers.

Better search engine rankings
Google have already stated that they measure site performance and will be increasingly using it to inform search-engine ranking. Your superior's concern re. meta tags is understandable, but not well-founded. The problem with meta-tags is that they sit apart from the content of the document, thus making it easy to have metadata that is wildly unrepresentative of what the content really is. Using HTML5 elements such as <aside> or <nav> means putting semantic structure into the document body itself, but actual meaning is still derived from the content. For example, using meta tags, I could have a page selling prescription medication, but give it tags saying it is an article about fishing. With HTML5, I don't have that ability, all I can do is wrap sections of the content in elements that suggest which bits are the title, the article body, navigation, etc.

This isn't an infallible approach, and it is still open to abuses and gaming by the dishonest, but search engines employ many techniques and heuristics to weed out untrustworthy sites. For those they deem trustworthy, this semantic information can be used to index them more effectively. The fact that Google are one of the major forces behind the WHATWG and HTML5 (Ian Hickson, who edits the spec, is a Google employee), and used research on their own data to guide what new tags would be most useful, should be proof that search engines see value in the use of these semantic elements.

[zcorpan]

Good post Amitskaw. Some nitpicks:

Compatibility
HTML5 builds upon HTML4, clarifying many areas that were unclear or undocumented in the earlier spec. For example, it standardises the algorithms that browsers should implement, or appear to implement, when parsing HTML, and how they should behave if they encounter invalid mark-up. This means sites will work far more consistently across browsers, and will lower the cost of development and testing. In particular, it will make it far easier to make sites that work across new platforms like mobile devices and tablets.

Yep, but this happens anyway even if you're using HTML4.

For example, if you want videos on your sites to work on the iPhone and iPad, you will need to use HTML5, as Flash is not supported.

Video is a new feature, so it's not a great example of what you wrote above. Also, HTML5 video today does not enjoy great compatibility (different codecs and implementation in mobile browsers still suck).

Better search engine rankings
Google have already stated that they measure site performance and will be increasingly using it to inform search-engine ranking.

Yep, good performance is good.

Your superior's concern re. meta tags is understandable, but not well-founded. The problem with meta-tags is that they sit apart from the content of the document, thus making it easy to have metadata that is wildly unrepresentative of what the content really is. Using HTML5 elements such as <aside> or <nav> means putting semantic structure into the document body itself, but actual meaning is still derived from the content. For example, using meta tags, I could have a page selling prescription medication, but give it tags saying it is an article about fishing. With HTML5, I don't have that ability, all I can do is wrap sections of the content in elements that suggest which bits are the title, the article body, navigation, etc.

This isn't an infallible approach, and it is still open to abuses and gaming by the dishonest, but search engines employ many techniques and heuristics to weed out untrustworthy sites. For those they deem trustworthy, this semantic information can be used to index them more effectively.

It doesn't follow that using <nav> etc. will give you better search-engine rankings, or that it makes a difference at all.

The fact that Google are one of the major forces behind the WHATWG and HTML5 (Ian Hickson, who edits the spec, is a Google employee), and used research on their own data to guide what new tags would be most useful, should be proof that search engines see value in the use of these semantic elements.

It's not proof, it's speculation.