theThought's thoughts

@Media WebDirections Conference : Day 1 - Sessions 3 and 4

The morning of Day 1 finished with a second presentation on JavaScript, however this one focused on the use of JavaScript on the server.  Having not learnt from my experience in the morning I thought I would attend to learn more about this concept that I had heard of but never practiced.

Tom Hughes-Croucher

This presentation had a promising start.  He was bright, breezy, humorous and excitable always a good combination in my opinion. Alas the presentation, for me, went steadily downhill.  It became more and more complex,  Tom lost his witt as he became more embroiled in the technicalities and I became steadily more and more detached from the proceedings.  I am not saying it was a bad presentation because it was not it was just not a presentation for me (I had had a shower that morning and I had not yet achieved a level of geekiness that allowed my subconscious receptors to translate what was being said).

Here is the gist of the presentation:

The big advantage Server Side JavaScript (SSJS) has over Perl, Ruby etc is that people are already familiar with the syntax and are used to writing in it.  A quick straw poll of the attendees demonstrated this when everyone said they had written JavaScript routines but only a few had experience of PHP, Perl or Ruby (no one asked about .net).  Effectively JavaScript IS the language of the web.

In addition libraries are increasingly being made available that simplify complex tasks such as jQuery, Mootools and YUI.

But SSJS has been around for quite some time so why is now the right time to push it as a viable solution.

Professionalism.  JavaScript coders are no longer seen as 2^nd class citizens they are a respected part of the development community

Runtimes.  There are a number of these available, they have been placed inside browsers for a start.  They include V8, SpiderMonkey and Rhino.

Speed Placing these runtimes in browsers has resulted in a drive for fast execution. V8 (part of Chrome) is very fast.  This is because leading browser manufacturers, like Google, are trying to make speed of execution a unique selling point.

Runtimes are not Browsers, there is no Document Object Model (DOM), there is no accessibility to specialised APIs.  It is only the pure JavaScript implementation.

• Rhino is equivalent to JavaScript v1.7
• SpiderMonkey is equivalent to JavaScript 1.8
• V8 is equivalent to ECMAScript 3

Brendan Eich talked about Harmony which is currently in development this will be equivalent to ECMAScript 5.

This latter statement put into context much of the presentation given by Brendan in the fact that those new facilities being placed inside Harmony but not yet available in browsers (via their JavaScript runtimes) would be available on the server as part of a SSJS implementation based on Harmony.

Here is where Tom became quite animated.  The speed and capability improvements discussed by Brendan and shown in the new runtimes means that Server Side JavaScript has real potential to deliver power and performance without the issues encountered by client side JavaScript.  When combined with libraries such as Note.js it becomes a great way to deliver browser agnostic web pages with powerful capabilities.

Unfortunately Tom’s increased animation was demonstrated by an increasing willingness to go into code level detail most of which went over my head.  It was clear that you need a linux server (no Microsoft Servers here today) and that you need a deeply technical mind to handle all the potential.  I have neither of those at my disposal so it was an interesting presentation that will result in little to no difference in the way I work.

Jonathan Stark

Jonathan’s presentation was the complete opposite.  I saw elements in this presentation that made me bubble with excitement and tremble with unequivable potential.  Jonathan is a specialist in Mobile Application development he has previously focused on iPhone development but it increasingly moving cross platform.  He is currently writing a book on Android and is hoping to look at other platforms like BlackBerry in the near future.  He started his presentation with three clear statistics

• 4.6 Billion cellphones are identified as currently active today
• 15% of these are smartphones
• 56% of public wi-fi connections were made by smartphones

This, Jonathan says, means that the smartphone is here and it is a dominant methodology for viewing the Internet.  These smartphones are able to be extended through custom applications that fall into the following categories:

• Native – Written for the specific device using languages like Java and Objective C
• Web – Browser based applications
• Command Line – often SMS based connectivity

Each of these types has its own challenges.  Native development is very fragmented with no one technology/language capable of developing a solution for all devices.  Web apps may be more consistent across devices but they are run in sandboxes and can not use many of the rich capabilities of the device such as camera, accelerator, compass.  Lastly command line apps suffer from discoverability issues.  How do you let people know about your service.

Although the above is the standard statement made for mobile development it does not give the entire picture.

Web development is done through standard web technologies such as HTML, CSS, JavaScript.  Apps using this technology are the cheapest to build, the technologies used are the most standardized and the solutions are the easiest and most cost effective to distribute.  If Web Apps could use the advanced technologies on the device, if they could provide a smoother user experience more in line with Native Applications they would probably be the best way to write an application.

jQuery

An extension of the jQuery initiative has been constructed by David Laneda.  It is called jQuery Touch.  Its purpose is to provide a more app orientated experience for a web based application.  It can be added to any webpage and then used to introduce smartphone like interfaces that would usually take a long time to build and test.  This includes the types of menu systems, buttons and transitions you would expect to see on a smartphone like the iPhone.  Add to this the HTML 5 capability to cache web assets on the device so that they can be used offline and you have a web application that looks like a native one it just lacks a few features

PhoneGap

The developers at PhoneGap do not really want this technology to exist.  They have built it because of the fragmentation of native app development.  Their aim is to give developers a path to cross device development.  PhoneGap gives a developer the ability to convert a web app into a native app.  It works for:

• iPhone
• Android
• Symbian
• BlackBerry

During this conversion the developer is given access to device capabilities such as the phone and vibration through relatively easy mechanisms to implement.  PhoneGap is only available on a Mac platform as the submission procedure for Apple is unchanged.  It is written so that the developer ends up creating an Objective C solution that can then be submitted.  It contains templates for each device delivery mechanism so that conversion/compiling process has to be done separately for each device type but this is still greatly reduced compared to the alternative process.

At the end of the presentation the inevitable question was asked regarding section 3.3.1 of the Apple terms and conditions.  Jonathan stated that Apple have indicated that, at present, PhoneGap is not affected by this changes made to this section.  There is no guarantee, however, that it will remain that way.

The presentation was good, there were clear examples of how to do the work, Jonathan built them on the fly showing the simplicity of the basic process.  The results looked good and apart from the seemingly difficult installation process for PhoneGap, nothing seemed particularly arduous – especially compared to learning Objective C and Java.

The Missing Session

There was a fifth session to the day called Hot Topics.  I believe it was supposed to be an open forum.  As much as I would have liked to have attended this I was unable to.

@Media WebDirections Conference : Keynote - Day 1

Yesterday I attended day one of the @Media/WebDirections Conference at Queen Elizabeth Hall, South Bank, London.  This is my second conference in a number of weeks following the Future of Web Design (FOWD) conference in May.  I was intruiged to see how different this conference was especially as at least two speakers at FOWD were also speaking here (Remy Sharp and Aral Balkan).

The differences were quite significant.

Firstly this event was much smaller, although located in a large facility (the Queen Elizabeth probably sits about 2000 people) I think there was less that a quarter of that number.  It was the same type of gender mix, predominantly male with a smattering of females (although that smattering was even lighter here) and a similar role mix although by the looks of them there were more developers and less designers.

Secondly, as you will see from this post and the next one, the content was more technical.  I should have realised this after the workshops but just how much more technical was a big surprise.

Lastly, and unfortunately, it was a little less organised, especially around those luxuries that you come to expect at these conferences such as wi-fi connection and power sockets.  As a result I was unable to get any quality Internet access which meant that I was unable to tweet (My blackberry was on low power too and its too slow for typing tweets in a conference).

Despite this last point I enjoyed the day and learnt a lot - which in the end is what it is all about

The event started with a short introduction that explained the merging of @media conference and the webdirections conference and was followed by a keynote by Brendan Eich.

So I have to admit that I am not familiar with the big names in the scripting industry especially those that orbit the W3C.  At FOWD I saw the workshop and presentation of Molly and she gave off an air of almost angelic reverence to these people (including herself by inference).  The same reverence seemed to be in the air for Brendan.  For those other people who read my blog who are equally unfamiliar Brendan is one of the co-founders of JavaScript.  He worked for Netscape and now works for Mozilla.  He is deeply technical, I think a portion of his oxygen intake (lets say 40%) has been replaced by code.  He promised something fast and furious and that is what we got.

His talk was effectively about the future development of JavaScript.  I think that people like me think JavaScript just is and don’t think too much about its evolution.  But evolving it is.  There are a raft of new developments on the table for the next round of standardisation approvals some of which are being adopted by browsers right now and are likely to be ratified by 2013 through a project called Harmony.  This includes:

• Const
  The ability to define constants in addition to variables that can be scoped within functions or globally
• Destructuring
  The ability to see arrays in any order to swap the elements and rotate them to see [a,b] = [b,a]
• Functions in Blocks
  The ability to create inline functions with the same name within a block of code without conflict
• Let
  A better type of var that handles scope better and is less likely to leak to higher level functions
• Default Values
  Where parameters in functions can have defaults that are adopted if no value is applied to that parameter when the function is called.
• Arguments as Parameters
  Where a parameter of a function does not have to be a single value but could be an array of values

As you can see from the above items and descriptions.  This is a technical subject and Brendan was quite obviously in his element.  He talked rapidly (as he promised) and slides flashed before our very eyes.  His content was assured and direct.  At this point in the proceedings I felt that I was keeping up especially as many of the above conventions can be seen in more mature languages such as C.

However this is the point at which things started to change.  Having discussed those elements where most if not all members of the working group are in agreement he started to move to those more bleeding edge ideas where not everyone has agreed the way forward.

I am not going to attempt to list or describe all the topics he covered.  For two reasons:

• There were a lot of them
• I am not sure I understood them enough to write with confidence and not mislead

There were some elements worth noting:

Proxies
These seemed to be constructs that would allow developers to extend current functionality.  For example the Math object a fundamental construct within JavaScript can be enhanced by Proxies with developers either extending or overwriting the native functionality.  This may be useful where different providers have diversified with their implementation and developers want to be consistent (across browsers for example)

ByteArrays
A better way to manipulate complex objects, at least better than string arrays which is effectively the only option currently available

Improved Random Number Generator
Brendan did not say much about this except a clear message that the current implementation is not very good and probably should be avoided especially if it is going to be used in the construction of unique identifiers like those used in e-Mail request URLs.

Brendan finished his presentations with some predictions.

WebKit the major standard, currently, in browser construction, will fracture with Google and Apple taking the implementation in two different directions.

Harmony will be implemented in FireFox and IE first with Apple and Google to follow at a later date.  This is mostly because Apple and Google’s browser development teams are quite small compared to those of Mozilla (Firefox) and Microsoft’s (which has recently been reformed to make IE9).

Native App stores (Apple and Android) will cause a resurgence of native code initiatives (like Objective C, Flash etc) but in the long run open source initiatives like JavaScript and ECMAScript will win out.

Today @Rem taught me that "Browsers have Wings"

Today was day one of WebDirections in London (tomorrow is a rest day, the conference starts properly on Thursday).

It was workshops day today and I attended “Browsers have Wings” a workshop by Remy Sharp (@Rem).  The topic of conversation was HTML 5 APIs.

Remy started with some context indicating that HTML5 is rapidly becoming a brand name accumulating many elements that are not actually HTML 5.  For example often associated with HTML5 are technologies like GeoLocation, WebWorkers, WebSockets and WebStorage.  These API’s however are not part of the HTML5 specification they are simply being developed alongside and used in association with HTML5.  I believe this is rather like the OS/2 PS/2 confusion way back when where people would associate OS/2 with the PS/2 even though they were completely different.

So what is included in HTML5?

• Canvas
• Video
• WebForms
• Offline applications

With the exception of WebForms these were the topics for the day, although we did do work on the other associated API’s as well.

This was not a workshop for the Novice, almost everyone in the room was an experience developer with HTML/JavaScript/jQuery experience.  They were from a range of organisations including Sunday Times and the World Health Organisation as well as numerous small companies.  There was no time wasted on basics such as the simple DOCTYPE declaration or how well formed (or not) the markup should be.  Instead it was straight into the first topic.

Video

In this section we learnt how to embed video natively and how to degrade this for browsers that do not support HTML5.  We learnt how to replace the native controls with custom controls, which events are available and how we can control the volume, play position etc.  We were running locally so there was no real discussion regarding buffering but we did learn how to know when the video was loaded and ready to play.

Canvas

Having settled in to the topic and done our first exercise (the whole session was hands on – with people typing like mad) we moved on to the Canvas element.  First up was understanding the difference between SVG and the Canvas and when to use which.  For example:

• SVG is excellent for vector graphics where as canvas is very pixel based.  
• SVG has an object tree and so there are layers, canvas is flat no layers at all

Once we had got this under our belts we learnt how to draw basic shapes (rectangles, circles) this is very similar to the process used in Flash so was easy to get used to, however, the lack of layers made it sound like it was really restrictive.

Next we learnt that we could move beyond basic flat shapes to gradients and from gradients to patterns and from patterns to images and/or video.  This concluded with an exercise where we created a link to an image and drew that image into the canvas.  Why do this you might ask?  Well we were then able to manipulate the image drawn to the canvas (for example make it greyscale).  This was done by manipulating the individual pixels of the image.  In my case, trying to be adventurous I combined the canvas and image with a slider to allow the user to change the transparency of the image.

GeoLocation, Storage and Offline

After lunch (a brief affair of very English sandwiches) we moved on to a trio of topics.  Starting with GeoLocation we learnt how to capture the current location of the user, demonstrating how the user has to give permission for this to happen.  We learnt how to understand if something went wrong (for example the user said no) and how to know whether something went wrong even when it seemed to go alright (understanding the accuracy of the location data).  The exercise related to this seemed to revolve around trying to prove that Brighton is not the centre of the universe.

In the Storage section we learnt about how useless cookies are and how useful local and session storage are.  We learnt how to store data and retrieve it and how to inspect the current data using our browser.  During the day we working primarily in Chrome with Remy giving clear indications (when he remembered) of the support in other browsers.  Lastly we looked at how to make an webpage work offline, this is principally around the building of a manifest file that indicates what should be cached to the browser, what should not and what to do if a file was is not available when offline.

WebWorkers and WebSockets

We were now getting to the end of the day, however the examples were getting more and more complex and the time spent on each getting less and less.  We were coming to the end of the rollercoaster ride and we were definitely going downhill. 

WebWorkers are a way of introducing threads into the browser.  The Browser rendering service is single threaded so routines that consume the thread for a long period can cause instability warnings to appear.  Web Workers get round this by building new threads and allowing javascript to run inside those threads.  The WebWorkers are sandboxed so they cannot manipulate the DOM or file I/O but they can do heavy weight algorithms without tying up the interface.

WebSockets are a way of creating transactions with a server.  Better than AJAX or Comet.  They are very thin threads of push notifications that do not include headers (only the data being passed).  This allows them to be much faster and to allow realtime conversations with server based web services.

Looking to finish on a high Remy boldly suggested that we work collaboratively on an exercise to end the session.  This would combine a number of the technologies we had been looking at including:

• Canvas
• WebSockets

The idea was that users would be able to draw an image in a canvas, take a snapshot of that picture place it on the left side of their screen and then either create a new image for refine the existing one.  The snapshots captured would be pushed to a web service so that other people could see them.  The right side of the browser was used to show the images that other people had created.  Clicking on those images would make them appear in your own drawing canvas so that you could enhance them and take a snapshot for others to play with.

In Summary

Many people criticise conferences and workshops because they are perceived to give little value.  I have to say that this event was a perfect example of how wrong these people can be.  Remy was Sharp (sorry I could not resist) he obviously knows his stuff, can create code on the fly in an instant and certainly massively increase my basic knowledge of the API’s.  I have to be honest and say my mind was spinning a little towards the end but I am sure that my upcoming flight to KL will give me the perfect opportunity to review what we did and understand it fully.  Thanks Remy, Thanks WebDirections.  I look forward to the main conference, which starts on Thursday.

An Update (Next Morning)

I was almost right.  The following morning @Rem posted the "finished" application on his site (http://rem.im/collab-drawing.html) a number of people have been having fun on it.  Feel free to have a go.  Send the link to a friend so that you can adapt each others pictures.

Future of Web Design (Day 2) - Aarron Walters And Sarah Parameter

Welcome to the afternoon, lunch has been consumed (at Starbucks) and we are raring to go for the third of four sessions for the day.  In this session two very different presentations around the key concept of design (not development).

Aarron Walters – Learning to Love Humans

This presentation is by one of the founders of mailchimp (http://www.mailchimp.com) not a service I have thought of subscribing to but one that is recognised in the industry for its innovative design.  The presentation was called amusingly “Learn to Love Humans”.  It aimed to show that emotion should be a strong factor in the development of a website design.  It started with the premise that the changing nature of the internet (specifically the increasing use of social media) means that people are starting to expose themselves as human beings rather that remote non-entities and that web design should reflect that.

This was followed by an glimpse of Maslow’s Pyramid of needs which Aarron indicated could be translated into an equivalent pyramid of interface design needs.  Aarron stated that interface design needs to be functional, reliable, usable, pleasurable.  Today’s designs tend to be able to fulfil the first three of these to varying degrees but few (if any) could be described as pleasurable.  For example 37Signals designs implementations for BaseCamp are often heralded for their ease of use and functional approach to project management but they cannot be described as pleasurable.  On the other hand WuFoo (a forms creation tool) brings a colour delight to forms creation so increasing the pleasure of what is basically a database interface.

In effect Interface Design needs to incorporate the concept of personality, personality is an important part of every individual.  More importantly it is a platform for emotion and emoting is one of the first things we do when we are born.  We quickly learn that broadcasting emotion can result in the satisfaction of needs.  Interface Designs need to bathe users in emotion.

Tapbots is a company that have succeeded in this concept.  Their iphone applications are a brilliant example of bringing pleasure to non-pleasureable activities. 

Weightbot, for example, brings just the right blend of function and pleasure to the tracking of weight (an activity that usually indicates a not too positive frame of mind).  Designed on the concept of Wall-E, they combine clean, functional design with the basic features of a face to make their application more attractive, more pleasurable to Humans.

Aarron indicated that there were a number of approaches to the adding of pleasure including:

Treats – Providing mild amounts of humour within the site

Discovery – Using easter eggs to deliver additional pleasure when something good or bad happens

The main aim of this type of design can be used to overcome humans natural inclination to doubt, it can also have the additional benefit of bringing forgiveness when something goes wrong.

Overall this presentation was just what this conference needed.  An emotion response to design issues, not steeped in the technicalities of how to deliver such experiences but a real view into how designers should be thinking when building the websites of the future.

Sarah Parmenter – 10 Tips for iPhone Interface Design

Sarah is a designer focused on the field of iPod/iPhone/iPad design.  She provided 10 key thoughts crucial to successful design of an Apple App (how to get it past Apple’s approval process and into the hands of users).  Sarah brought her not inconsiderable knowledge of app design and the oddities of Apple to an audience who are probably unfamiliar with many of these issues.  Her ten thoughts focus on:

• Making a clear Development choice between App and Web App
• Clearly defining the purpose of the application from fun tool to serious entertainment
• Provide Inspiring design documents – do not just send designs by e-Mail
• Be Prepared for UX interjection – expect clients to have their own ideas
• Understand the orientation, dimension an hierarchy elements of iphone design
• Unravel Hi-Fidelity UI – know when to bring this into the discussion
• Take time to design a beautiful icon – it is the flagship of the product
• Understand the App approval process

This presentation was clearly targeting freelance designers (as opposed to developers or those of us who work for corporate). It talked about the right ways to approach pricing and hints on how to engage customers effective.  It was concise clear and great content for this type of event.

These two presentations were by far the best of the day the presenters knew their audience, pitched their content at the right level, had a clear message and brought it forth in a commanding way.  Its great to be able to attend events with this level of quality.  Long may it continue.

Future of Web Design (Day 1) - HTML 5/CSS 3 workshop

This week (17th to 19th May).  I am attending the Future of Web Design conference in London. Today was Day 1 (workshops) and consequently I attended a HTML 5/CSS 3 introductory workshop run by Molly Holzschlag a web standards advocate for Opera (www.Molly.com).

Having said that is became clear as the morning progressed that as far as HTML 5 is concerned commercial implementation of the standard is not something that should be considered right now.  Very few of these browsers have implemented some of the new capabilities and consequently there is little advantage in implementing the features let alone a lot of effort in terms of handling those browsers that do not give any support.

The morning of the workshop focused on HTML 5, the afternoon on CSS3.

HTML 5

The session started with a little scene setting.  Effectively a “Why should we be interested, what is HTML 5?” introduction.    The key justification being that today all the major browser manufacturers (Google, Microsoft, Opera, Firefox, Mozilla) have agreed to adopt HTML 5 and are currently working on their implementations.  This is the first time in the history of the Internet that all of them have made a concerted effort to agree on one standard (although their implementations of that standard are less likely to be consistent).

There seem to be five design principles behind the implementation of HTML 5:

• Backward compatibility
• Interoperability
• Clearly Defineable UserAgent Behaviour
• Improved Error Handling
• Evolve Don’t Recreate

Each of these is a challenging objective, for example backward compatability has always been a key driver for many software developments however every iteration makes this more and more difficult.  At some point the Internet is going to have to forget the past or be bogged down by it.  In terms of HTML 5 backward compatability is about equally supporting those who write in HTML 4 and those who write in xHTML 1.0 formats.  The new DOCTYPE declaration was discussed especially in terms of its simplicity.  HTML 5 has no equivalent DTD definition (due, at least partly, to the fact that the concept of DTD’s is dead) consequently the declaration is much simplified.  HTML 5.0 does not have to be a precisely formed as xHTML it was generally thought by the audience that this was not a good idea as it would lead to sloppiness (someone not closing <p> tags can get away with it).   This is no different to coding where someone can use Goto if they want (just don’t expect to get a programming job if someone notices).

The next section focused, briefly on the new elements being introduced in HTML 5 including:

• Section
• Article
• Aside
• Header
• Footer

The key objective here seems to be the removal of DIV tags that are simply sectioning out key parts of the document structure.  It was not made clear whether any of these would have any real advantage over the current use of DIV tags except clearer markup and more obvious CSS 3 synchronisation (as CSS 3 supports these element types as well).

There was also a brief mention of the other elements being looked at such as Mark, Meter, Progress, Time, Command, Datagrid and Details but as these are not yet fully defined no details were really provided.

The next section focused on the improvements to Forms.  Many of the concepts of Web 2.0 will be supported.  The autofocus and required attributes for example significantly reduce the amount of JavaScript that has to be written to deliver client side verification.  New Input types such as Range (for sliders) and search provide new ways of capturing data from the user.

The link tag has also been enhanced with new types such as icon, prefetch, archives, external and license.  The session closed around a discussion on the three most talked about new elements, those that provide embedded media without the need for a plugin.  Canvas provides a drawing palette which can be based on a combination of SVG and javascript to create a fully interactive visual experience.  Video and Audio provide broadcast components reducing the need for Flash (maybe).  The  key argument with the latter two is codec’s.  Which ones will be royalty free and therefore available in browsers?

There was also a brief mention of ARIA (accessibility for Rich Interactive Applications).  This extended only to a definition of the term and the fact it is an offshoot of WIA (Web Accessibility Initiative).

CSS 3

It would be a mistake to think that the whole of the afternoon session was dedicated to the new features of CSS 3.  In fact nearly 90 minutes was a discussion around the basic concepts of CSS including a definition of the term cascading, several discussions regarding specificity (including how to say it in German) and other general rules regarding the use of CSS.  Probably the most stressed point made during this 90 minutes is to not use the !Important facility.  It was identified that this is a hack and a poor one at that that designers should avoid using.

Once discussion did get around to CSS 3 most of the new features were very briefly discussed such as:

• The new Selectors
• Border changes including the use of images and rounded corners
• Multiple columns
• Real Font Support
• Colour control through Hue Saturation and Luminence (HSL)
• Animations
• Transparency
•  Shadows

Each point was glossed over with simple examples of most of them.

Probably the most poignant aspect of the afternoon was the constant switching between Safari, Chrome and Opera as Molly attempted to demonstrate the effects.  This really brought home the fact that no one browser has fully implemented CSS 3 as it currently stands and that the implementations are not consistent.

The session ended with a discussion regarding some of the newer concepts of CSS 3 (those that have not been implemented properly by anyone yet) these included concepts such as FlexBox (a flexible way of creating boxes of content within boxes) and some ways of creating grid structures without using tables.

Some of these latter examples showed how truly complex CSS 3 might yet become.  In its attempt to increase the presentation and dynamics of the internet it is becoming more like a programming language, unfortunately it is unwilling to be verbose so some of the codes are getting shorter and shorter (many are just two letters long).

In Summary

I have to say I was a little disappointed with today.  As a workshop I had hoped that we would go indepth regarding the attribute and reasons for using HTML 5 elements with some good examples of how they might be used.

I had hoped to be told more about how we could implement them today even though most browsers can fully support the features, how graceful degradation  and progressive enhancement could be applied to bring these new features to today’s customers.

This, sadly, was not the case.  Too much time was spent explaining principles I had hoped those in the room already new.  Yes we all learnt something but I think we could have all learnt more.  As a HTML 5/CSS 3 primer it was okay but I could have and have already got 90% of that just “Googling” on the internet.  Lets hope that the next two days brings more realism and less theory.