Intro to HTML5

Seth Ladd’s introduction was the highlight of the night for me.

New JavaScript capabilities

He started talking about the new capabilities of JavaScript Libraries:

Web storage

aka Local Storage or DOM Storage
A way to store data on the client side (crash safe), making it crash safe and a good way to store, for example, user preferences. It is similar in some way to cookies, but offers more storage (5-10MB)and better programmatic interfaces.
http://diveintohtml5.org/storage.html

Web SQL Database

Web Storage is useful for storing simple key value pairs but not for more complex relational data. That is where the new Web SQL Database API comes into play. It brings SQL to the client side. Databases can be created on the fly, updated queried like any server side database and can involve asynchronous transactions for a more responsive user experience.
http://html5doctor.com/introducing-web-sql-databases/
http://openbit.co.uk/?p=135

Application Cache API

Prior to HTML, most browsers performed some kind of caching, but it could be inconsistent and of limited value (e.g. try refreshing a web page when you have no internet connection). With the offline application caching API, you (the developer) can specify exactly what should be cached by using a manifest file. This can result in a faster browser experience with less load on the server and, of course, means web pages can still be browsed even when you go offline.

Web Workers

Web workers are kind of like threads for your HTML apps. Your can now spawn background workers running scripts in parallel to the main page.

Web Sockets

Bi directional, full duplex communication channels over a single TCP socket, designed to be implemented in web browsers and web servers.

Notifications

How do we deliver a more desktop like experience to users?
Notifications can appear transiently in upper right hand corner. They fade in and fade out rather than being intrusive or modal.

Drag & drop

This was one of the most interesting (at least from a visual perspective) aspects of the new JavaScript APIs. Drag & Drop provides a very desktop like experience. Similar functionality could previously be provided by using libraries with JQuery, but now you no longer need to do crazy workarounds, or browser specific solutions.

Geo Location

Imprecise forms of geolocation have been available for a while, for example via best-guess based on your IP address. But the new Geo Location capabilities provide more reliable ways to provide location specific or customized content and functionality.

New HTML5 Capabilities

Seth’s next section was HTML5 itself, i.e. the new capabilities in HTML itself.

New semantic tags

He talked about the new semantic tags (such as section/article/header and aside) that can be used as a way to avoid ‘div’itus.

New link relations

Several new rel attributes for the <a> and <ink> elements have been introduced for HTML5.

Micro data

Is intended to provide a simple way to embed semantic markup into HTML documents, without the complexities of approaches such as RDFa (Resource Description Framework in Attributes).

ARIA attributes

Attributes for enhancing the accessibility of RIAs (Rich Internet Applications)

New form field types

e.g. can specify valid input ranges

Audio & Video

e.g. audio & video tags can interact with JavaScript, Canvas
e.g. Javascript can control video

Canvas

A Canvas is a 2Dimensional drawing surface that can be manipulated pixel by pixel.

New CSS Capabilities

Finally, Seth talked about the new CSS aspects of HTML5, including the new font support, columns (no JavaScript required!) and Sliders, which can be implemented using just css with no JavaScript required.

HTML5 <video> and <canvas> Tags

The 2nd of the 3 presentations was by Tab Atkins Jr., on the new HTML5 <video> and <canvas> Tags.

Closure JavaScript Library

The final presenter was Nathan Naze on the Closure JavaScript Library.
Closure is Google’s ‘Standard Lib’ for JavaScript. It is designed for large scale web development and is the Javascript library behind Google web apps such as GMail, Blogger and Google Books.

It was started in 2005 and is made exclusively by developers working on their 20% projects.

My overall impressions of Closure were that it is a complex, powerful and stable JavaScript library but with a steep learning curve best suited to large scale development (e.g. enterprise apps developed by large teams). It seems a useful library, but not something I would consider using for the upcoming GTUG HTML5 campout for example, where something a little more lightweight might be more useful.

Links
http://www.webreference.com/authoring/languages/html/HTML5/

The demo for our BlipWiki project (which I blogged about here) unfortunately had technical difficulties so our presentation didn’t go so well. One of our 2 browsers couldn’t seem to connect so we didn’t get to show our Wiki updating in real time in the way we would have liked. Still, I think we had a great application at the end of the weekend, and I certainly learned a lot, met a lot of great people, and got to know Google Wave much better. A great weekend…

There are photos and videos from the weekend posted here and a write up in the San Jose Mercury News.

I joined the Blip Wiki team. A Blip is simply a single message within a ‘Wave’ conversation. A Wiki, of course, is a software tool that allows users to easily create, link and collaborate on documents. So, our goal with the ‘Blip Wiki’ project was to bring the incredible collaboration capabilities of Google Wave (real time updates, autocorrect context sensitive spelling etc) to the easy document setup and linkability of a Wiki.
Although Wave can certainly be used to collaboratively create documents as it is, Wave is inherently conversation focused. We wanted Blip Wiki to be inherently Document focused.

To do this however, we needed to use our own instance of a Wave server i.e. use the Google Wave Federation Prototype Server rather than the regular Wave server hosted by Google. We also needed to come up with a new client (something like tiddlywiki) and, most importantly, ensure our client can communicate with the server. Our project won the award for the most ambitious pitch at the start of the weekend!

Federation Prototype Server and example client

We got off to a good start by getting the Wave Prototype Server downloaded, building and running (it runs on top of OpenFire, a real time collaboration server that uses XMPP/Jabber). We then got the demo wave client running and talking to our server. We managed this by late Friday evening.

Client/Server protocol

Next, we created our own demo client and tried to get it interacting with our Wave server. That is when we started running into problems. First, the client/server protocol has not yet been formalized, and there don’t seem to be any definite plans to do that yet either. For example, although this Client Server Protocol White paper describes a protocol and data model, it does not give any details on the format that should be used, or suggestions on how to use it. There is a lengthy discussion in the Wave Protocol Google Group about this. For example, someone suggests that the client server protocol is just protocol buffers ‘over the wire’. But a protobuf is really just a simple data format, and while I assume ‘over the wire’ means RPC, it is all a bit vague.

Submitting changes

The client/server protocol used in the example client (a “toy’ text client) is for “illustrative purposes only”, according to this doc. We couldn’t seem to find much documentation for it, perhaps because it is not supposed to serve as a standardized example. As a result, we found it difficult to reverse engineer. So, we ended up resorting to using the Client example code to marshal our data to and from the server. The example client code in effect became a sort of interface to the server for us. A client side stub, if you will. (We had this running in the web tier servlet layer).

Receiving updates

So, after we had used the Client example code to submit changes (blip updates) to the server, our next hurdle was understanding the data that gets returned. Ideally, we would like a ‘delta’ of the data. That is, after the server has done it Operational Transformation magic, we would just like the latest and greatest version of the data to display on the client. However, this proved difficult to get from the server. Instead all I could seem to get was a non-delimited complete history of the blip. I admit that this was done using pretty hacky code. I am sure there must be another, better way!

So, we ended up taking a similar approach to the example client, and just displaying the latest submissions.

Demo ready – almost…

Right now, we have a working client and server with updates made on one user’s WikiBlip automatically showing up in another users.

It would have been really nice to be able to deploy our local Wave Server to app engine, but apparently this isn’t possible since the OpenFire jars required aren’t on the whitelist of allowed jars.
It also would have been nice to experiment with our local Wave server talking to the real Google Wave server (e.g. to have a regular wave client user be able to interact with a blip wiki), but apparently this is not possible due to authentication issues.

So, we chose a very difficult task for the weekend! But, we have a working version ready to demo and it has been a great weekend all in all.

Thank you’s

A big thank you to

• Sriram and Sreejith, my BlipWiki teammates
• Kevin and Van from the GTUG
• Stephanie, Brian, Fred and all the all Googlers who made the weekend possible and great!

I will post again later with the results of the demo…

I am not too familiar with Wave yet, so this should be a great opportunity to get to know it better, meet a bunch of fellow techs, and hopefully produce something cool by the end of the weekend. Looking forward to it…

Registration is free, so if you are interested you can sign up at here.