Design Principal #2 Compatibility • Pave the cow paths • Degrade gracefully • Research common behavior; solve real problems • Support existing content • Evolution not revolution • Don’t reinvent the wheel (or at least make a 16 better one!) Design Principal #3 Utility • Priority of Constituencies: o When in doubt… value users over authors, over implementers (browsers), over specifiers (W3C/WHATWG), over theoretical purity. • Secure by design • DOM consistency (HTML5 and XHTML5) • Separation of presentation and content Design Principal #4 Interoperability • Specify well-defined behavior o Specific instead of vague • Handle errors well o Improved and ambitious error handling plans o Prefer graceful error recovery to hard failure • Avoid needless complexity o Simple is better Design Principal #5 Universal Access • Support for all world languages o For example, <ruby> (Ruby annotations, used in East Asian typography) • Accessibility o Support users with disabilities o Web Accessibility Initiative (WAI) Accessible Rich Internet Applications (ARIA) o WAI-ARIA roles can be added today 24 o Supported by screen readers
So now that we’ve given you the background of HTML5, some of its features, and implications for the future of web development, how can you apply it in a practical situation? Developers need to ask: How is my site going to be used? Is search engine traffic an important part of my business model? If you answer “yes” to this question, a Flash-based website is out of the question. The reason? Search engines cannot parse any content inside a Flash “movie” (well, ALMOST none) and probably won’t be able to for the forseeable future. Not all HTML-based websites are necessarily search-engine friendly, but if you hope to get traffic from Google, Yahoo, MSN, and Ask eventually, you’ll need to start with an HTML-based website. 2) How will my site be accessed? If so, you’ll probably want to go with an HTML-based site. The increasing prevalence of broadband lines (and access to even higher speeds in a typical corporate environment, like T1 or T3) makes Flash a more appropriate option for a much wider variety of sites than it used to be. But it still takes, on average, 5-10 times as long for a Flash-based website to load as one based in HTML, simply because the file size is necessarily high to accommodate all the bells and whistles that go along with it. Users on a slower connection won’t appreciate the longer download time, and may click to another website before yours even loads. 3) Is the feel of the user experience absolutely critical to my product or service? Fashion companies, high-end real estate developers or agents, art & design professionals, and young or high-end retail brands are just a few of the industries for whom user experience can make or break their website, so it would make sense to go with Flash. For these companies, word of mouth traffic is far more important than search engine traffic, where the only search terms these companies really need to show up for is their own name, or the name of their product. This limited amount of search engine optimization (SEO) can be done fairly easily without compromising the design. 4) How often will my site need to be updated? If you think you’re going to be adding pages, changing copy around, or building out new sections of your website fairly consistently (say, more than 3-4x a year), you should stay away from Flash. Even for the most experienced Flash programmer, building out new pages & sections can be very time-consuming (and thus very expensive for you). Once an HTML layout is set up, any new content can be dropped in fairly easily. In summary, HTML is relatively scalable, while Flash is relatively UN-scalable. 5) How much content do I have? If you’ve got a bunch of content (more than 20-30 pages), a Flash website may be not only file-size prohibitive, but cost-prohibitive. The three Flash websites I cited above either have a ridiculous ad budget (Rolex/Nike) to spend on huge sites, or a talented in-house team of designers (SOM). For small businesses, this often means HTML is the way to go.
Function – HTML5 provides native support for many features that were only possible with plugins or complex hack so Plugins may not be installed Plugins can be disabled or blocked (iPad does not ship with Flash plugin) Plugins are a separate attack vector Plugins are difficult to integrate with the rest of an HTML document (plugin boundaries, clipping, and transparency issues) Plugins are crash prone Experience – Function –If your site’s core function is in the content you publish, then the interface should take a back seat. Make an interface that’s transparent and not distracting to use. Consider developing with function as the centerpiece when content is the primary focus – news sites, blogs, research sites, etc. Experience – consider developing with “user experience” when you really want to make an impression – launching a new product, the marketing division of a company, building “buzz”, when you want to tell your story