Notes for HTML5, Exploring the boundaries

The following notes accompany these slides that you should have available as you read through this. To navigate the slides, use the arrow keys or the onscreen buttons. If you see an * at the end of a bullet point, you can click that text to expand it.

This presentation was created to help inform designers, producers and account folks inside Odopod about how the advances of web standards are impacting the work we do. 

I’ve found Chrome offers the most consistent support of the sites I link to with the exception of one that works in Safari (it is noted below).

Lastly, this is a charged topic for some and I welcome all civil comments. 

Introduction

  • Browsers are able to do a great deal more today without the need for plugins.
  • Factoring in mobile browsers, Flash is not as ubiquitous as it once was.
  • We need to understand the new boundaries when making decision on what types of sites to create and how to build them.

HTML5 = open Web standards

Html5 is a cocktail of interconnected technologies

  • HTML: used for data and structure.
    • Bring common web practices into the standards (moving common tasks into the browser).
    • Includes:
      • Semantics (New tags, Link Relations, Microdata).
      • Accessibility (ARIA roles).
      • Web Forms 2.0 (Input Fields).
      • Multimedia (Audio Tag, Video Tag).
      • 2D and 3D drawing (Canvas, WebGL, SVG).
  • CSS: used for layout and presentation.
    • Richer layouts, fewer graphics, codified transitions.
    • Includes:
      • Typography (fonts, multi columns, stroke).
      • Visuals (shadows, rounded corner, gradients, transparency…).
      • Transitions, transforms and animations.
  • JS: used to program page behavior
    • APIS added to the HTML5 spec as well as existence of mature, widely used libraries.
    • APIs Include:
      • Client Side Storage (Web SQL Database, App Cache, Web Storage).
      • Communication (Web Sockets, Worker Workers).
      • Desktop experience (Notifications, Drag and Drop API).
      • Geolocation.
  • See Google’s excellent overview for more details.

Some Sites

This is a collection of sites demonstrating a variety of features and some of the edges of browser capabilities.

  • Colly.com.
    • Great use of CSS, minimal JS.
    • Progressive enhancement makes content more available for search engines, accessibility, semantic web, and the broadest range of browsers and devices.
      • Starts with simple, clear HTML as lowest common denominator.
      • Adds presentation (rounded corners, rotated profile image, shadows and navigation images) via CSS.
      • Some layout touches are ignored by less capable browsers (he does not add workarounds).
    • Responsive design.
      • Using media Queries (part of CSS3 spec) to respond to screen width.
      • Grid adjusts like it would in a fluid layout (resize width of screen or view on iPhone).
      • Also drops some of the less essential elements (side bar).
      • At smallest width, images are removed from navigation.
      • Not a silver bullet, there are many challenges to applying this to more complex sites. Responsive design is most effective when combined with server-side logic.
  • Twitter.com.
    • Example of a well done web application as robust as a desktop application.
    • CSS for layout, JS for opening panels and loading data asynchronously.
    • Completely dependant on JS to work (and to a lesser extent, CSS).
    • Works across most PCs (not ie6) and iPad.
    • For iPhone/Android and other mobile devices they have other sites tailored to smaller screen (redirected by server) rather than trying to provide one experience that scales to all devices.
  • 20 things. Electronic book with nice features.
    • Offline storage (remembering last page read when you return to site).
    • Canvas for page flip and other animations.
    • Works with JS disabled, but not as well without CSS.
    • On tablets and mobile devices, animations are disabled and some layout elements are broken, but generally works.
  • Treme. Immersive media site.
    • Panning scene.
    • Day/night transition (la music).
    • More panning (inside treme).
    • HTML5 video with Flash fall back (Videos).
    • Translation (look for options at top of window when using Google Chrome) being provided by browser is a great example computers being able to parse data provided by open standards. Google, not the site authors are providing this enhanced experience.
    • Layout falls apart on mobile and older browsers.
    • With time, this could have been built with a progressive enhancement strategy and reached more browsers and devices.
  • Rough Guide to the World.
    • Everything and the kitchen sink.
    • Panning, loading, sorting.
    • Performs poorly even on desktops.
    • A good example of what should probably be done in Flash or scaled back to what is more feasible for browsers to manage.
  • WordSquared.
    • Multi-player game with real-time game play.
    • Socket communications between browser and server via JavaScript.
    • Huge map of playing board (click to expand it).
    • Renders on mobile, but they are not supporting touch events so you can’t place tiles.
    • Good example of something that would have required a plugin before.

Some Experiments

Experiments and demos that show great potential for the near future.

  • Google Gravity.
    • Uses CSS3 and JS Physics library.
    • Fun to mess with well worn expectations of an iconic HTML page.
    • Elements are still fully functional (try a search for odopod).
    • Works on broad selection of browsers, but only partly works in IE9 and below (no rotation).
  • CSS3 3D (Safari only).
    • CSS3 can do some fast transitions by having the browser (rather than with JavaScript) do the heavy lifting, and in some cases with hardware acceleration.
      • Slides, fades, rotations, etc.
    • Here, we see 3d capabilities.
      • Interaction and some calculations done in JS.
      • 3d render and reflection in CSS.
    • Works in safari – including mobile safari.
  • Face detection.
    • Web standards are extensible through JS.
    • Browser makers are working hard to increase JavaScript performance.
    • Here the site loads an image and parses it using JavaScript to find faces.
    • Did not work in mobile browsers for me.
  • Odosketch.
    • Prototype of our Flash drawing app running in canvas.
    • Surprising how close we got to the original Flash functionality.
    • Some performance differences (some better, some worse).
    • Canvas lacks sophistication of Flash options so there is not a pixel for pixel match with the original drawing.

Some Tools

  • Treesaver (site linked to in slides is a prototype built on treesaver platform).
    • Open Source, magazine platform that manages pagination, layout and navigation of content
    • HTML, CSS and JS (JS is optional).
    • Scalable, consistent behavior across many platforms.
    • Progressively enhanced.
  • Lettering.js.
    • JavaScript library provides individual lettering control.
    • Used on lost worlds fair series (can find them on page linked to from presentation).
    • Let’s markup be clean and semantic and layout extremely custom.
    • Several of the sites I looked at are not fully mobile compatible, only because the font types used are not supported on those browsers.
  • Three.js.
    • JavaScript library for 3d rendering.
    • Will be hardware accelerated in webGL browsers (currently only developer builds of next generations of browsers).
    • Works (slowly) on mobile.
  • Phonegap.
    • Framework for publishing cross-platform native mobile apps.
    • Uses web standards for development.
    • Exposes some additional APIs via JS for hardware features (e.g. vibration).
    • Essentially brings to standards what AIR provides for Flash.
    • There are several similar frameworks available.
  • AI to Canvas.
    • Provided by microsoft.
    • Export AI files (including animation).
  • Sencha.
    • Relatively simple timeline tool for creating animations.
    • Exports to CSS3 animations.
  • For both AI to canvas and Sencha:
    • Might not be production ready (have not seen adequate tests of flexibility, accuracy, performance or file sizes).
    • Won’t play on browsers lacking support for HTML5.
    • Adobe is very interested in this space and has demonstrated very early work in this area.

So, what can’t it do?

All in all the example sites and demos seen here and elsewhere are quite impressive under the right circumstances. It is to lose site of the limitations.

Some Limits to Web Standards

  • HTML5 and CSS3 are still works in progress and scattered support leads to increased development time.
    • 50%-60% of visitors won’t be able to render HTML5 content (milage will vary based on each site’s specific audience).
  • Mobile compatibility requires more than support for a technology.
    • Typically mobile webkit browsers support standards better than desktop browsers; however, the hardware simply can’t keep up with the same level of complexity.
    • Interaction models (stacks of pages) and gestures (pinch, swipe, etc) need to be added; some mouse metaphors don’t translate to touch (e.g. rollover).
    • While the majority of smartphones now have touch screens, other mobiles and other product categories (TVs) have 5-way navigation models.
    • Universal accessibility requires a comprehensive Progressive Enhancement approach that starts with a fully functional site using HTML only.
  • Canvas lacks blend modes and flexibility that Flash has, Video requires 3 codecs and lacks several commonly used features found in Flash video (alpha channel, buffer control).
  • Design tools are in alpha stages. For developers, compression and packaging tools are not integrated into the tools as they are in the Flash toolset.
  • Old browsers tend to stick around for a long time unable to take advantage of innovations. Furthermore, consensus required for standards slows and sometimes blocks ability to add features to standard (e.g. the need for three video codecs at the moment is due to lack of consensus). Rapid innovative is limited to the JS slice of the ecosystem where advancements are less tied to browsers and standards.

Enter Flash

Flash picks up where Standards leaves off.

  • Flash platform releases new features new build approximately every 18 months and typically add performance improvements more often. New versions of players are distributed very quickly to supported platforms.
  • Tools provide mature, collaborative processes.
  • Platform supports unique features today and more are (always) on the way.
  • In terms of rich media, Flash can go further, faster on supported browsers (tools allow complexity to be managed better and consistent platform lessens QA time).

Some Examples

  • Internet TV (and Odopod project).
    • Loading of assets (prior to experience and behind the scenes).
    • Alpha video.
    • Simple management of multiple layers of video and other graphics.
    • Generally managing the level complexity and keeping things working.
  • Johnny Cash Project.
    • At it’s core it is a drawing program (inside HTML5 capabilities).
    • Again the layers of complexity – layers of UI and managing the load, etc. would be more significantly time consuming with HTML.
  • Audiotool.
    • Collection of audio synthesizers, modulators and mixers.
    • Ability to build audio entirely programmatically.
    • Create MP3 files from within Flash.
    • Audio processing is coming to HTML/JS in next webkit and FF, but not yet in standards (I’m not sure if audio generation is included).
  • Max Racer. 
    • Multi player 3d game; Flash can open sockets between clients for LAN party.
    • Fully hardware accelerated 3d rendering (coming to future versions of Flash).
    • Support for USB game controller (steering wheel and gas pedal) (coming to future versions of Flash)..
  • Computer Vision.
    • This app uses an algorithm to see (through a web cam).
    • Can take snapshots of patterns to recognize later.
    • Camera access coming to HTML via device tag, but not in standards yet.
  • Voice Gesture.
    • Flash can access microphone input.
    • Here is a demo of audio processing and voice recognition.
    • Again, audio processing is coming to HTML/JS in next webkit and FF, but not yet in standards.

What’s best?

There is a ton of discussion right now regarding which of these technologies is better. Well informed folks recognize that it depends entirely on what you are trying to do and how much time you have to do it.

Cheat Sheet

There is a lot to remember so I’ve tried to distill it down to some basic takeaways.

  • HTML5 is a work in progress.
    • 50-60% of PC browsers don’t support any of the HTML5 additions (video, canvas, JS apis). IE 6, 7 and 8 need to age out to change this number significantly.
  • Flash and PCs (Mac and WIndows) excel at rich-media experiences.
    • Flash tools & consistent player reduce production and QA Time.
    • Complex media experiences generally wouldn’t port well to mobile regardless of technology.
  • HTML5 does not insure mobile compatibility.
    • Performance and interface need to be considered.
    • Beyond the newest smart phones, HTML is the only reliable technology (CSS or JS are often either missing or unreliably implemented).
  • Progressive Enhancement is the ideal approach.
    • Start with HTML and add layers of enhancement (CSS, JS, even Flash).
    • Not all features should be provided to all platforms.
    • This can be significant effort impacting both front-end and server programming.

Start with these questions

When trying to determine the right technology for a site, the following questions will help frame a productive conversation.

  • Platform requirements and priorities?
  • What is the desired experience (level of richness and complexity)?
  • Can the required platforms deliver the imagined experience?
    • Experience and determine platform requirements for you.
    • Consider: performance capabilities, screen size, interaction modes.
  • Can you target Platforms with unique experiences?
    • Ideal to look at each platform and design the right experience for that platform; sometimes it is unavoidable to do so.
    • Building and QAing multiple sites or one site that is progressively enhanced can be costly.

0 thoughts on “Notes for HTML5, Exploring the boundaries

Leave a Reply

Your email address will not be published. Required fields are marked *