@media ajax conference

Last year I went to the excellent @media ajax conference in London. Sorry, it’s taken so long to type up my notes, but better late than never!

I could only attend day one and Clare went to day 2. She has posted separately, but here are my notes from the conference. Not especially a critique or a review, just notes for things to look into in more depth, mainly for the use of fellow numikons.

The inevitable start to the conferences was the question everyone was waiting for someone to try and answer in a single sentence “So… what is ajax”. In this conference it’s javascript and programming techniques making use of xmlHttp.

Javascript has grown up. It’s no longer the delinquent little adolescent of programming languages, used for cheesy DHTML effects. It’s a proper language used by proper programmers to do really useful stuff.

Good, nice and simple, and set the context of the sessions really- technical and meaty rather than airy fairy ‘building the business case for ajax’ type car crash presentations I’ve witnessed at other conferences.

Read all about it after the jump…

The state of ajax

And a busy year it was too in 2007. As Dion Almaer (Google)and Ben Galbraith (FeatureFifty) founders of ajaxian.com led us through a kind of ajax manifesto they had set out a year ago. offline apps, graphics, performance, framework consolidation

Offline apps

The pair talked about using ajax (javascript)as a viable tool for offline applications that can be installed and run locally outside of a browser and with access to the local file system for doing all those useful things that apps need to do like open and save files etc.

This was really interesting, because as an agency that’s always done a lot of Flash development Numiko have used these type of tools for a while for , such as screentime,and swfstudio to allow us to create applications in Flash. Adobe have made a big splashy sound this year with Air, which as well as allowing Flash developers to port web apps to local systems using the Actionscript Virtual Machine, also allow ajax developers to create offline apps using the HTML rendering engine, WebKit, as used in Safari, and the Mozilla Javascript Engine Tamarin.

Google Gears was discussed as another option for taking AJAX offline and also improving performance of web based apps. Gears basically consists of an installable set of APIs that are directly accessible through JS code. These APIs consist of a Local Server which can cache online content for offline use, such as an offline wikipedia. Gears also consists of a database for storing and accessing data on the local machine, and finally a worker thread pool which allows javascripts to be run in the background and in isolation of each other. This leads to significant performance enhancements. A demo was show whereby a javascript was being used to animate a graphic on screen, whilst simultaneously another script was calculated prime numbers, which is computationally expensive. Without gears the animation was jittery, as the browsers swapped it CPU resource rapidly between the executing each script. With gears, both scripts could run in their own worker pools and have direct access to the CPU through Gears, as opposed to through the browser process.

Graphical improvements

  • A demo of Yahoo Pipes which let’s users create their own mashups using a great visual interface. See my separate post on this.

Performance Increases

The talk moved onto performance improvements in engines that would make ajax applications more snappy, such as the new Firefox JS engine in FF3, which is 10x faster.

Framework consolidation

From the myriad of JS frameworks, there appeared to be emerging a few that were really well supported and had great communities extending them. These frameworkds have proved very useful for cross platform development of more complex executions of JS.

Discussed were:

Prototype

  • a bit of help on top of ‘raw js’ but, ‘close to the metal’

Script.alicio.us

  • a UI kit for prototype

JQuery

  • easy to use
  • pragmatic
  • again close to the metal
  • plug-in based

Yahoo UI

  • great for UI widgets

DOJO

  • JS for those who love java
  • A JS Lib with AJAX features
  • Recently recoded
  • Has a set of UI widgets in the form of Tundra
  • A visual effects Library
  • Provides mark up for rendering
  • A graphing library
  • Data binding features

EXT.JS

  • Makes the web look like a desktop application-apparently the best UI tool.

GWT- Google Web Toolkit

  • one for the Java lovers- write in java, export JS.
  • Used to build Gmaps, Gmail etc

DWR- direct web remoting

  • a server side RPC library written in Java that can be called from JS.

Some debugging tools useful for testing AJAX included YSlow, a firebug plugin that tells you how to improve performance on specific sites.

CouchDB- a new database based on JSON

A quick exploration of Amazon’s web services, S3- Simple Storage Service and EC2 – Elastic Compute Cloud, an on demand, grid based hosting and cloud computing set-up. It looks great, and because it is a distributed system, latency and hops to users tend to be less. It’s ultimately flexible and can grow or shrink in size depending on the traffic and computing power required. We’ll be looking into that some more.

I’m A Bloody Designer

This was a wicked talk by Mike Stenhouse. The slides can be found here

I really enjoyed this one, I think maybe because I’d come from more of a design background but learnt how to do technical things to make me more able to be more creative with digital media.

I also recognised a lot of the progressions that designers have had to make recently. Early web designers worked almost entirely visually, making things look pretty and thing a bit about functionality, but not much. Technical stuff was met with…. “I’m A Bloody Designer!” and the partnership with developers was a bit like throwing a hand grenade over a wall and waiting to see what came back.

A lot has changed now as complexity of web sites increases, and the designer now needs to be ‘system aware’, knowing and understanding how the system that he is designing for works, what the inputs and outputs are. They are designing the user experience, rather than just the visual look and feel of the site. Developers need to meet in the middle and become ‘Interaction Aware’, not leaving all the functionality design to the designer but collaborating with them.

This led to Mike’s experiences of extreme programming, where designer and developer share a computer for a while to learn more about what each other are doing and thinking on a particular project. Look at agilemanifesto.org and SCRUM as a project management methodology for dealing with this type of development.

We discussed the strengths of Agile development for web projects, and putting them into a constant state of beta, where they are constantly improve based on user feedback post pre and post launch. This led to ‘test driven’ or ‘red/green development’. Mike talked about a framework written in Ruby called webdrive that can automate unit testing, system and interface testing.

Mike then talked about Behaviour driven development, whereby specific behaviours of test groups and absorbed into the way that the system is designed.

Bottom line, designers need to bit developers a bit more, and developers need to be designers, it’s a bit like being bicurious…

Accessibility and Ajax

Next on the bill was accessibility issues surrounding AJAX with Derek Featherstone of the web standards project.

  • Put text in spans, not in onfocus as this doesn’t get picked up by screen readers.
  • There are a lot of screen reader issues with ajax, as they tend to take a cache of the page when it first loads. Thus when things start changing on the page without a reload, they’re still reading from a cache that’s no longer accurate. Therefore, there’s a workaround created by Juicy Studios that foces a virtual reresh within the screen reader’s buffer of the page.

Planning Ajax for Larger Teams

Next up was Planning Ajax for Larger Teams with Christian Heilmann. The slides are here

Web products are never finished and must evolve with the needs of the user. As an agency, adapting and educating clients to this fact seems like a real, but worthwhile challenge.

Conducting Code reviews

  • At Yahoo code reviews are mandatory before things go live. He recommended doing reviews as the project goes along, not a huge one right at the end.
  • Find problems and share solutions
  • Assess training needs
  • Share knowledge throughout the team
  • Identify code that should be hived off into reusable components
  • Look at the yahoo developer blog for more info

They also use lightening talks about the projects they are working on-

  • 5min presentation
  • 5min demo
  • 5 min discussion
  • See web projects as being made up from modules not views pages or sections
  • See visual look and feel as a ‘skin’ for each module’
  • And see that each module or application is an event. See more about this on the Yahoo Interface blog
  • Development time is not the time to innovate or change how you do things, don’t listen to the inner hacker. There was a strong reaction to this from the crowd in the following Q+A about having time to innovate. The answer was clear and simple. Make time, but don’t do it in live projects as it causes complete pain and makes team working difficult.
  • Find clear playtime when innovation is encouraged, taking risks is ok, and experimentation is key.
  • Use explanatory var and method names
  • See a separation between production code and live code- make the production code for humans and then ooptomise it for live code making it as fast as possible for machines.

Tools to do move into live code include:

  • Validation- tidy, JSlint
  • Minification- JSMIN, CSS minifiers
  • Consolidation of JS and CSS files into single, site wide JS and CSS files (minify and Combine)
  • Tag live code as such.

The waterfall development model doesn’t work, and in Christian’s experience, agile development has always produced better results.

Ajax a Work, A case study

  • Finally was PPK from quirksmode.org on using Ajax in a family tree project. He went through why we would bother to use ajax instead of ‘normal’ HTML and discussed the issues involved.
  • He discussed data structure formats, JSON vs XML, CSV, HTML, settling on JSON for speed and human readability.
  • And a lot about optimisation and preloading. Presume that the server is faster than the client at dealing with data. See http://yuiblog.com/blog/2006/11/28/performance-research-part-1/

Really good conference all in all, well organised, great speakers and proper level of detail.

I’ll hand over to Clare to do day 2!

Leave a Reply

Posted