Generalizing, I see 3 scenarios where web-based technologies (HTML, CSS, JavaScript) are used:

Web sites

What most web pages are part of!

Web applications

Also referred to as rich Internet applications, these are things like web-based email, web-based administrator dashboards, etc

Client-server type applications

These are applications that use shared resources (e.g. databases) amongst many people, typically in a controlled environment such as a corporate office. These may be complicated distributed systems.

When is what appropriate?

Web Sites?

Web technologies are obviously built for this scenario, so

• HTML/HTML 5 is likely most important (search engine visibility is important for most sites).
• AJAX is likely to enhance functionality but probably should be used with care (for accessibility and not impacting search engine visibility, browser navigation, bookmarking, etc.).

(In terms of Flash’s suitability, see note below about Flash and search engines)

Web applications?

In this scenario, a richer user experience may be needed but search engine visibility may not be as important (likely such apps require logging in). So,

• AJAX may be appropriate for simple sites/functionality.
• Flash (or Microsoft’s rival, SilverLight??) may be more appropriate for richer apps where the challenge of creating richer user experiences with the current versions of HTML/CSS/JavaScript proves difficult.

(At the @media07 conference, it was good to hear Jeremy Keith, a JavaScript guy — I think he coined the term DOM Scripting — also mention that as cool as JavaScript and AJAX can be, sometimes it is not appropriate; Flash is mature enough to be used for rich applications in many scenarios.)

There is a chance that HTML 5 and AJAX could pose a threat to Flash in the long term, as noted below in the aside about AJAX vs. Flash.

Applications?

Sometimes web technologies such as HTML/CSS/JavaScript are being used for technical/administrative reasons (e.g. simpler deployment and upgrade story) rather than user productivity and usability reasons (these technologies were never built for rich user interaction).

In the past, such applications were then limited in functionality and user interaction capabilities. These days, such applications are getting richer with things like AJAX but may sacrifice accessibility or introduce additional problems (such as bookmarking challenges, history and navigation problems, excessive page sizes to download, etc). Building these, or standard desktop conventions using web technologies can be time consuming, too.

At the same time, it often feels that either well-established desktop GUI experiences/patterns are being re-discovered/re-invented, or worse, getting ignored!

So,

• Something as widely installed and reasonably established as Flash may be a suitable alternative if deployment concerns are still there.
• But desktop applications feel most appropriate.

Note, even when the application is a complex beast, using shared or distributed backend systems, things like web services and other HTTP(S)-based communication is widely supported, not just limited to browsers. Desktop GUIs can make use of these to provide a rich user interface for specific applications (one simple popular example: Outlook 2003 and later which can use the normal network when connected, or HTTPS when away from the office, but you can still use the rich desktop application).

What about HTML 5′s potential?

So that might be the over-simplified scenario now. What about the future? In an earlier post about the promise of HTML 5, I noted the potential for better productivity and accessibility.

What will HTML 5′s impact be to the above? Here are some thoughts (rather than predictions!)

• HTML 5 will be excellent for both web sites and web applications (better accessibility etc that I mentioned in that previous post)
• HTML 5, depending on final feature set and browser adoption, could challenge a rising popularity of Flash for web applications. Alternatively, HTML 5 could take a while to come about so the investment in Flash-like technology may mean HTML 5 is slower to adopt for web applications
• For desktop-apps-masquerading-as-web-apps applications, HTML 5 is likely still not suitable. It is the wrong purpose, which is fine. HTML 5, as good as it promises to be can’t be used for everything!

What about applications deployed to intranets?

The whole idea of intranets seems to (for now) preclude installing custom desktop apps on each corporate desktop. Web applications seem appropriate. Newer technologies such as Flash (even SilverLight?) seem appropriate here. But some things may work well as normal HTML applications (with rich features) for book marking, internal indexing, etc.)

I am guessing in the future, the delivery and update of desktop applications will be easier than now (I like how most (all?) Linux distributions have package managers of some sort that can help update any software, not just the ones that come from the operating system vendor, such as Microsoft, and, I think, Apple).

Saying that, some desktop apps have their own way of checking for updates on PCs (and other platforms). But this means inconsistency and headaches for IT admins. For now, corporate firewalls and other technicalities may still pose a barrier for corporate-wide intranet deployment in many cases.

Aside about AJAX vs Flash

User experience expert, Jesse James Garrett, coined the term AJAX. However, he rightly notes it is not a silver bullet:

Ajax can interfere with a site, particularly as it puts the burden on the designer to clearly communicate to the user, to help them have appropriate expectations of how the application will behave. Ajax gets in the way of usability when it introduces behaviours people don’t expect, and the overall design doesn’t communicate with them effectively so that they do know what to expect.

A lot of people are interested in learning how it works, but they are choosing features where it is easiest to implement, rather than where it would be most useful or effective.

– Jesse James Garrett, Jesse James Garrett on Ajax, Amazon and Web 2.0, E-Consultancy.com, August 2007

One really interesting point Garrett makes however, in favour of AJAX, is that it can be introduced incrementally, rather than one big bang approach:

One of the big advantages of Ajax is it is something people can implement in an incremental fashion – unlike migrating to Flash. It is something you can implement in little bits and pieces, which is great, but you have to make smart choices about which bits and pieces you give priority to.

– Jesse James Garrett, Jesse James Garrett on Ajax, Amazon and Web 2.0, E-Consultancy.com, August 2007

Assuming HTML 5 includes even better support for AJAX-related capabilities (signs suggest so) this is one reason why I suggested above that HTML 5 (if it ever gets widely supported) could threaten use of Flash for web applications) in the long term.

Aside about Flash and search engines

A conversation between a couple of guys from the Google Search Quality Team and some webmasters included this useful point (which most people have often said, but good to hear it from a search engine’s mouth!):

Any special guidance for DHTML/AJAX/Flash documents?

It’s important to make sure that content and navigation can be rendered/negotiated using only HTML. So long as the content and navigation are the same for search crawlers and end users, you’re more than welcome to use advanced technologies such as Flash and/or Javascript to improve the user experience using a richer presentation. In “Best uses of Flash,” we wrote in more detail about this, and are working on a post about AJAX technology.

– Greg Grothaus and Shashi Thakur, Search Quality Team, Server location, cross-linking, and Web 2.0 technology thoughts, Google Webmaster Central Blog, August 2, 2007

Aside about Flash, Silverlight, and Accessibility

People are slowly acknowledging the potential of flash for web applications. Mike Davies, a developer at Yahoo, provides a decent commentary of the growing momentum behind accessible Flash.

When consulting for a major high street retailer, Macromedia representatives came to demonstrate Adobe’s Flex technology. We discussed general issues including Flash accessibility, and the representatives commented how accessibility improvements were always being made, and had already been substantially improved over the last few years.

That being said, Davies also provides links to articles describing where accessibility is still lacking or problematic in Flash.

Silverlight appears to be Microsoft’s response to Flash. It too has the potential to offer rich application and user experience across the web, based on its XAML markup. According to Keith Smith, product manager of the user experience platform and tools team at Microsoft, Silverlight has also got some built in accessibility support, and more is being built.

As with Flash, however, Silverlight is likely to be problematic from a search engine indexing perspective, for now, so above considerations about Flash probably generally apply to Silverlight.

Other web application technologies

This post has mostly referred to Flash (or Silverlight) as web application technologies, and occasionally HTML5. Of course there are many other potentials. I think the above points still hold if you consider the following potential web application technologies (some of which are even suitable for desktop applications)

• Adobe’s Flash, Flex and AIR platforms
• Microsoft’s Silverlight
• Mozilla’s XUL

I am sure I have forgotten to mention others (let me know!)

Rich, AJAX-based sites are taking off. When done well, they provide rich user experiences. Unfortunately, it feels as though accessibility is being left behind. This is a sad irony, given accessibility was important in galvanizing so much support for web standards.

Screen readers struggle with dynamic pages, tag soup is still prevalent, and some browsers still don’t implement standards properly.

In addition, HTML (as it was defined almost a decade ago!), CSS and JavaScript were not built with today’s web applications in mind. Some people therefore suggest other technologies such as Flash, which has come a long way, and now includes various accessibility features, too.

But there has long been a move to update the HTML specifications. It has been slow moving but recent months have seen a number of interesting things arise.

Proposal for HTML 5 is promising

The W3C has long had XHTML 2 specification drafts, while the Web Hypertext Application Technology Working Group (WHAT WG) has been suggesting HTML 5 to deal with rich internet applications that are becoming the norm today.

In fact, the W3C voted to adopt HTML 5 as proposed by Apple, Mozilla and Opera.

Not only that, but the W3C has agreed to the proposal of having Ian Hickson of Google (and spokesperson of the WHAT WG) and David Hyatt from Apple /Safari to be the initial HTML 5 specification editors.

XHTML 2 goes down the route of strict XML-based syntax and validation (markup errors result in errors on the browser, not browsers trying to still show the page). This is nice ideally, and could allow a clean start away from the current HTML mess. However, many have felt it will be difficult to adopt and not everyone will be able to ensure well-formed markup. The HTML 5 approach has been to be backward compatible (though it now also entertains an XML-version of the markup, i.e. XHTML 5).

The other concern is for older browsers that may have to render newer version(s) of HTML. HTML 5 tries to be somewhat backward compatible, so potentially an older browser will be able to render the new pages even if it is not as visually as appealing. (XHTML 2 seems to be like this too, given older browsers will just try to treat it as HTML and anything not understood would just be ignored.)

There are certainly lots of debates going on out there about HTML 5 versus XHTML 2 and various details of each specification, but the bigger picture is the potential for improved accessibility, productivity, usability, richer applications, etc.

Better markup is the foundation

The potential comes from the richer markup that is proposed.

HTML 5, for example, introduces a whole host of new elements, from structural elements such as header, footer, nav, and section. New multimedia elements include video and audio. And new form elements/types include date, email, and datagrid. There is even a proposed event-source to catch server side events. (Read the really useful HTML 5 differences from HTML 4 article by Anne van Kesteren, from Opera.)

Key benefits for users would include

• Consistency across web sites
• Accessibility

Key benefits for businesses, individuals and organisations developing web applications include

• Increased productivity
• Legal compliance (where accessibility is a legal requirement)

The consistency benefit is interesting: while some may fear that web sites will end up looking the same, some fundamental functional features are important for consistency across sites, such as form controls.

Why? We expect desktop applications to behave in the similar ways (e.g. the menu bar along the top of OSX or the top of each application in Windows, etc). In the same way some fundamental consistency of interaction on the web will be important too, for example, how dates are picked, how email addresses are validated, how data grids work, etc. This will help new users to a site quickly adapt, rather than having to learn a subtly new way of doing something similar to elsewhere.

This will be good for accessibility because assistive technology can more easily work out what a header is, or what a nav is. It will therefore be far easier to present navigation and usage options to the users of such software. Even browsers will be able to build more accessibility features right into the browser. All this without sacrificing design and development flexibility.

HTML 5′s proposals for numerous new input types and other semantic markup elements (e.g. calendar related inputs, better data grids, header/footer elements, etc) is really key, IMO.

Anne Van Kersteren provides some useful examples of form controls:

Nowadays web developers use nifty scripts to perform form validation on the client side. Soon you’ll be able to simply write the following:

<form>
 <p><label>Name: <input name=name required></label></p>
 <p><label>E-mail: <input name=email type=email required></label></p>

 <p><label>URL: <input name=url type=url></label></p>
 <p><label>Comment: <textarea name=comment required></textarea></p>

 <p><input type=submit value=React!></p>
</form>

– Anne Van Kersteren, Improve your forms using HTML5!, Dev.Opera, 13 December, 2006

Examples of why this is beneficial:

• Developers get to focus on developing sites and apps, rather than common controls (which would all be different between different sites).
• Users get familiar widgets (which are probably similar to the operating system, too, making such sites quicker to learn and use).
• Assistive technology will help their users use the site more easily. Assistive technology vendors will have richer elements to support but typically only do it once (per element per browser implementation!).
• Improved quality as not only would HTML bloat may be reduced, even more important might be the reduction in JavaScript, hence the reduction of buggy sites, memory leaks, performance issues, etc.

This would translate into more productive businesses and organisations. The content is also potentially easier and better for indexing for search engine.

All round win-win, in my view!

Of course this is overly optimistic. Some companies already provide these pre-packaged controls with today’s HTML so some perceived efficiency/productivity may not be as high as it sounds (ignoring the extra work that might be needed to make such controls accessible, search engine friendly, etc).

With something like HTML 5 being adopted and used widely, hopefully this means people can spend more time innovating, and less time dealing with browser problems!

When will this happen!

So lets come back down to earth again!!

Its all well and good to talk about the potential of something like HTML 5, but will it ever happen? Almost everyone will agree that this will all take a long time to adopt.

Browsers need to add new code. (Will those browser releases even be in remotely the same time frame? Does this ultimately depend on Microsoft’s Internet Explorer supporting it?)

And getting assistive technologies such as screen readers to support a new specification may take even longer.

If these new specifications are desirable, what will provide the impetus for tons of web developers to want to learn something new, for businesses to spend resources in up-skilling and moving to these?

Search engines.

What? Yes, search engines. If search engines were to buy into HTML 5 and say they will index the new tags, then businesses may have compelling enough reason to move into that direction. Better indexing may mean more accurate results. (Ranking of course is different to indexing which is a separate issue!)

Of course some people may now just have more HTML elements to abuse and stuff with inappropriate content. I don’t imagine any time soon search engines saying some elements will have higher precedence for ranking purposes, and instead continue to focus on social factors, how popular the site is, etc. But indexing is still important: let search engines find content, but let them also understand what is there so if the page does rank, then the right information can be shown, which helps users decide if they want to follow the link.

There are signs that things are moving in the right direction: Google as well as Apple, Mozilla and Opera are putting weight behind HTML 5. Ian Hickson has already started providing some initial analysis for HTML 5 parser implementors, for example.

But there is one big player missing in the above that can also be make or break. Microsoft. Whatever we feel about the company (most web developers that follow web standards despise IE!) their browser install base is so wide it cannot be ignored.

What about Microsoft and Internet Explorer!

This may feel odd to think about, but there’s another potential winner in HTML 5 adoption: Internet Explorer!

Microsoft’s IE is generally regarded as the least capable of modern browsers (e.g. buggy/limited CSS support, limited W3C DOM support, etc). With something like HTML 5, it is a clean slate for Microsoft.

If Microsoft want to rebuild their reputation with web developers, they should also buy into HTML 5, but this time truly support the standards, rather than go half way, win the wars and then act as most monopolies would!

There are people at Microsoft, such as Chris Wilson who leads the IE development, to whom standards is definitely important (their need to support older sites full of tag soup — partly their own doing — has slowed them down from making fixes and supporting even more modern standards) so it may be more realistic this time than in the past.

Where next?

There are definitely some odd technical decisions, outstanding concerns, and debates in terms of where XHTML 2 and HTML 5 are headed. With the W3C’s adoption of HTML 5, XHTML 2 seems dead for now, but it seemed to have a few good things which don’t seem to be there in HTML 5. HTML 5 also has a few seemingly inconsistent decisions. And so on.

So what can be done? A few things, I guess. E.g.:

• Read the HTML 5 drafts
• Join the HTML working group at the W3C if you have time!
• Get involved with the WHAT WG
• Start pressuring search engines and browser vendors! WebStandards.org, is this a campaign for you guys??