We had a great time and lots of productive hacks were put together. Rather than do anything too hacky myself, I had a good play with WordPress 3, almost out in full. I decided to use its ability to run multiple blogs from one installation to revamp my photographic home on the web, cazphoto.co.uk.

I’m really pleased with the flexibility of WP3, particularly how easy it is to build custom menus for each site – something I used to do by hand when building bespoke themes for clients – but no longer! Thank goodness for that.

Anway, here are my best pictures from the weekend:

[Yahoo! boss David Filo welcomes the geeks to Open Hack 2009]

I had a play about with the BOSS search API, but wasn’t in an actual team as such. I also enjoyed an evening bike ride on the Flickr Bikes – which automatically took a photo every minute when the bikes were in motion. Riding round central London on a push bike was a bit of a hairy experience, but we returned unscathed to tell the tale!

[The two Flickr Bikes were available for a ride]

There was, of course, a little problem with the wifi (isn’t there always?) but the team from Yahoo soon sorted it out. And the was, of course, plenty of fuel for hacking geeks:

[Essential supplies for the hacking geek]

It was great to be in the company of such innovative minds (and a little intimidating too!). There were some great ideas put together during the session. Mr Duck was even on the winning team for Best Harware Hack! Clever duck…

I did a bit of hacking with some bookmarklets and javascript to switch to user-defined style sheets, giving the option of looking at any website as reversed video with much larger text, for instance. Here are a couple of screenshots:

[Regular video Flickr,  but with large text]

[Reversed-video style sheet is easier for users with some visual impairments or other disabilities]

I hope to be able to use some of the techniques in future projects.

I was also rather amused  by the tshirt one of the other geeks was wearing:

[Clueless!]

There were some excellent panels – links to the trascripts, slides and audio etc:

• Denise Stephens talking about her life with Multiple Sclerosis.
• Antonia Hyde from United Response talked about learning disabilities.
• Jonathan Hassell of t he BBC on Dyslexia
• Kath Moonan from Abilitynet talked about Why she hates the Interweb.
• Artur Ortega & Leonie Watson shared their expertise on screen readers and JavaScript
• Audio files for most of the session are available now too

[Kath  hates the interweb!]

[Leonie and Artur talk about Screenreaders and JavaScript]

[The panel takes questions at the end of the day]

Richard Ishida

Richard is the W3C’s Internationalisation Activity Lead.

Character Encoding

• There are many options, but Unicode is the best – it supports many languages in a single character set – making it easy to architect multilingual solutions, and have a mix of languages on a single page (if required).
• Makes storing and retrieving multilingual data in a database much easier
• Also provides extra characters such as © ™ etc
• Has wide support in browsers, scripts, editors, databases etc.

You can declare the encoding in the HTML:

<meta http-equiv=”Content-Type” content=”text/html; charset=utf-8″ />

Or if you’re using XML:

<?xml version=”1.0″ encoding=”UTF-8″?>

Databases must be told to save data as utf-8 also – to maximize compatibility. For more details, see:

Richard’s presentation: slides (PDF) | audio (mp3)

• Plug & Play:
  Drop in a widget, little or no JavaScript knowledge required, just customise some options and go – no flexibility
• Some assembly required:
  Write common utilities, use pre-made code to distance yourself from browser bugs – flexible, until you hit a browser bug
• Down and dirty:
  Write all code from scratch, deal directly with bugs, quirksmode can save your life – eccessively flexible – almost too flexible
• Use JavaScript library:
  Makes JavaScript bearable, gets the job done fast, simplifies cross-browser support – easily customisable

John then did a comparison between the various JavaScript libraries, including jQuery, Prototype, YUI and Dojo, which are commonly in use. A developer survey showed that jQuery and Prototype were used by around 32% of developers; YUI was 22% and others around 14%.

John’s full slides give much more detail of each library’s strengths.

John’s presentation: slides (slideshare) | audio (mp3)

Jonathan Snook

Culture
We come from a culture where developers tend to like to reinvent the wheel, whereas designers like to reuse. If, as developers, we want to use components of others’ work (under GPL or whatever), this provides us with some distinct advantages. Look how many times the Linux distribution has forked!

Tools
There are loads of PHP frameworks out there, and also for other languages. We dont’ have to write everything from scratch, but make use of pre-existing libraries and functions.

Flash - now has built in sockets support. Useful for charts in pages (if you need them)

Types of Data
Location, Time, Relationships etc

Pitfalls
Dynamic APIs can foul up your application; service availability; you are middleman – if something goes down people blame you, not the service provider.

Benefits
Dealing with well-tested code. Speeds up development. Solve problems outside original solution.

Ideas
Enables you to get stuff out fast. Iterate fast and often. Eg Overheard RSS feed built really quickly (using library elements from Cake PHP). You can see what works. You can put stuff out in hours, rather than days or weeks.

Jonathan’s presentation: slides (blog+links) | audio (mp3)

Nate Koechley

Nate began by giving us a bit of historical context to the way Yahoo! has evolved over the years.

He then covered topics such as Yahoo’s server architecture, graded browser support [see below], progressive enhancement, unobtrusive JavaScript etc.

He suggests we all have an interesting set of decisions to make regarding front-end design:

1. Do what is standard
   if impossible, then
2. Do what is common
   if impossible, then
3. Do what it takes

Then we get on to:

1. Do what is simple
   +
2. Do what is flexible & progressive
   +
3. Do what is open

This is in order to satisfy the multiple audiences for any website: Users, Developers, Machines.

At Yahoo!, they focus on 8 specific areas:

1. HTML
2. CSS
3. JavaScript
4. Accessibility
5. Internationalisation
6. Performance
7. Infrastructre & Process
8. Tooling

They use tools such as JSLint to check code for quality, and adopt the idioms it promotes to improve their code. Also, unit testing with YUI Test.

There’s much more detail in his slides (see below).

Nate’s presentation: slides (blog/slideshare) | audio (mp3)

Drew McLellan

Intro
Tools should be as simple as possible, but no simpler. Don’t overcomplicate things! CMS required if you need to repurpose content (eg for RSS) and have a lot of aggregated content. Need to take control over editing process.  You don’t always need to use a CMS all the time – to all parts of the site. No. Use it for the bits that they need now.

What type of CMS?

• Offline - eg Dreamweaver with Contribute. Can be very good for existing large static sites, which weren’t already built with a CMS. Won’t let you publish to schedules, multiple languages etc.
• Online - web app which runs site. Content edited with web-based forms, content stored in databases. Custom-built to off-the-shelf.
• Off the shelf - will generally let you build anything. Methods to manage pages; custom functionality can be added with plugins. eg Blog sites. But anything out of the ordinary – often falls over.
• Bespoke – custom-built, designed specifically for running your site.

Everyone hates their CMS! And CMSs aren’t forever!

Common Features

• /shiny/happy/urls
  Use readable, reliable and hackable URLs
  Readable – users should have a good idea of what a page is about from looking at the URLs. Search engines will index things better.
  Reliable – should be a URL forever (or as long as possible).
  Hackable – users can intuitively change a URL to get to other content.
• Data feeds
  Can your CMS let you publish RSS etc.
• Data stored in an open format
  CMS isn’t forever – but if you want to change it, can you get the content out if you need to – to port it to another system. Also the need to get the data in in the first place.
• Customisable and accessible admin interface
  Works without Javascript; can be branded
• Search
  Difficult to get right – does search return sensible things – are they relevent to the user
• Multi-site support
  Can it administer more than one site? Perhaps reuse some content on another site.
• Multi-language support
  Think about it now even if it might not seem like you need it right away. Should be OK if you’re using unicode.
• Caching
  Does it cache the results or generate it each time? Performance issues might bite you on the ass later.
• Web 2.0 features
  Are your users going to want to tag content? Use of microformats
• Bi-Directional Content
  Trouble really starts when users can update the system too – need user accounts, possibly moderation, business rules for deletion of data. Can of worms! Also think about future features – eg for user forum later on.

Off The Shelf
cmsmatrix.org has data on 915 CMSs!
Start at the bottom – WordPress, Moveable Type, TextPattern, Chip etc.
Beware the pimped out blog software – don’t launch a new site with a weblog cms already creaking.
If you are going to customise things – avoid getting into an unsupportable configuration at all costs.

Medium scale
see photos – beware, don’t be tempted to overdo things – do you really need all these features?

Enterprise Level
Documentum, LiveLink, Joomla etc

Build your own! [I have!]
Libraries, Django, rails, cake, symphony.
Goal – reuse core functions as much as possible.

Planning for the future
Know your plugins, be aware of licensing issues, plan for future but don’t buy now. know your limits, know your design constraints, speak with existing customers, don’t get charged per users, know your exit route!

Drew’s presentation: slides (slideshare) | audio (mp3)

James Graham / Lachlan Hunt

What can you do with it now, what in the future?

Intro
Next iteration of HTML spec. Long overdue for overhaul. What are we trying to achieve? Do things you can’t do now without JS, for instance. Working on HTML and XHTML together. Authors can choose which is most appropriate for them.

Design Principles

• Compatability – Browsers must remain compatible with existing content, old sites MUST still work.
• Degrade gracefully – make new features work in, or at least not break, new browsers.
• Don’t reinvent the wheel - fix what we already have, don’t reinvent it from scratch.
• Pave the cowpath – consider Use Cases – look what authors already do and improve where neccessary.c.f. Microformat Date/Time pattern.
• Evolution, not revolution - make incremental improvements. Can’t discard existing content and start fresh.
• Solve real problems – ensure work is relevent to web developers. Identify the problems first, then find solutions.
• Priority of Constituencies - have to prioritise the needs of:
  Users, authors, implementers, spec writers, theoretical purity
• Secure by design – protect end users from malicious intent
• Separation of Concerns – Separate presentation, structure, semantics where doing so provides real benefits. <b> and <i> are still in the spec.
• DOM Consistency – minimize differences between HTML and XHTML, allow scripts to work now.
• Avoid needless complexity – authors won’t use something complex if they don’t understand it
• Well-defined Behaviour – 97% of web has syntax errors! Define precisely what browers must do with all possibly bad input.
• Handle Errors – authors make mistakes all the time, the spec must define how browsers handle the errors.
• Media independence – make sure pages work on different media, devices and platforms.
• Support World Languages – support pages in any language, bi-directional text etc
• Accessibility - provide for the needs of users with disabilities. Built-in preferred over add-on accessibility, where possible.

When can we start using HTML5?
As soon as the browsers start implementing the features. FF3, IE8 support some of the spec.

What can I do with it?
Common elements of a blog – header, main nav, article, sidebar, footer. So we get:

<header> element – for site-wide header, not H1. Title/subtitle etc.
<nav> element – screenreaders could jump straight to it easily
<article> element – for the main body
<aside> element – for sidebar etc, pullquotes.
<footer> element – for copyright info

These can add more consistency than using <div>s and variable class names.

<section> elements can be nested – each of which has H1 – without worrying about correct nesting of H1, H2 elements.

<time> – for posted date of blog item. Attribute has machine-readable timestamp, tag wraps human-readable content.
<figure> – represents image(or table etc)+caption, <legend> nested inside to associate it together.
<caption> not used for reasons of backwards compatibility.
<meter> – attributes shows rating of content – the bar is drawn by the browser not meant as a graphic. Eg, content of element is 3/5, the bar is drawn by the user agent. Also progress bars
<progress> for dynamic (ajax) apps.
<video> – native video support in browsers, DOM APIs for providing custom interfaces, no more dependance on Flash. Browser provides the controls etc. Casual authors can quickly cope with video files.
<canvas> – dynamically draw graphics and text, graphics-oriented DOM APIs.

Offline Web Apps – offline caching APIs, local storage, SQL database.
Developer Tools – HTML5 conformance checker – exceeds the capabilities of traditional DTD bases validators. Gives more useful info.
Parsing HTML5 – libraries for python, ruby. off-the-shelf parser reduces reliance on RegExpr hacks.
The Community – diverse group of individuals and organisations. W3C, WHATWG trying to work together. Open to everyone.
How to Contribute – general feedback, develop tools, research, community participation.

• blog.whatwg.org
• forums.whatwg.org
• wiki.whatwg.org
• Mailing list and IRC.