We’ve been doing animated interfaces on the web since someone first came up with the JavaScript rollover effect back in the mid 1990s. Things really got going with the introduction of the CSS :hover selector, though it was not until almost a decade later, that we started to see quite sophisticated animations on the web, with effects built into, or on top of various JavaScript libraries and frameworks.

But it was really the arrival of the iPhone, with its 2D and even 3D transitions between application states, coupled with the arrival of CSS transitions and transforms that saw complex animations really start to take off on the web.

However, just as typography is about much more than just choosing fonts, animation is far more than simply using Homer Simpson’s favourite effect, the star wipe. Animation has a long history (there’s even speculation some of the earliest cave paintings were a kind of animation), as does the theory on animation, perhaps most famously outlined in what’s considered something of a bible for animators, The Illusion of Life: Disney Animation, which outlines 12 basic principles of animation. I’m pretty sure the star wipe is not one of them.

At Web Directions, we’ve long recognised the increasing use, and importance, of animation in user experience and interface design, and we have in fact been looking for several years for the right person, with a mix of practical skills, and theoretical understanding to speak on this subject, without any success.

Then, a couple of months back, we happened upon Transitional Interfaces, by Pasquale D’Silva, which was pretty much made to order.

Animation leverages an overlooked dimension — time! An invisible fabric which stitches space together. You don’t have to be a math dork to understand this.

It’s a fantastic, detailed, well written, lovingly illustrated and above all practical article. So, we asked ourselves, “have we found our presenter on animation?” What we typically do when we find an article like this, is go looking for past presentations by the writer. But we really couldn’t find much, other than some rather quirky bits on Vimeo. A bit of a man of mystery it would seem was our Pasquale.

Which presented a dilemma. Do we take a risk on someone who we’re not sure won’t possibly freeze on stage? Or who’ll not translate from the written and visual to the spoken arena? So we started a bit of a dialogue with Pasquale and his combination of knowledge, enthusiasm and modesty all said to us we should get him on board. Not only that, but after a bit more discussion, we felt maybe a workshop in addition to the conference session would be in order.

Because Pasquale typically works with animation tools like Quartz Composer, we decided that to give the workshop even more relevance to web designers and developers, we could begin with a session on implementing animations with CSS, which is something John has written about and even developed tools for. So, two people who’ve only exchanged emails, Pasquale and John, are going to be doing a workshop together on animation for the web at Web Directions. Don’t you love it when a plan just comes together?

We’re really excited about this presentation and workshop, which represents something about Web Directions we’re really proud of—working to uncover talented professionals in our medium, and encouraging and helping them bring their expertise to a wider audience.

Want to learn more about animated user experiences and the web, then don’t miss the workshop, or Web Direction South 2013.

Since we began one of the very first ever conferences for web professionals in 2004, each time we come to putting together the program, we go right back to the drawing board. We ask what is it you most need to hear about today, and who are the best people to talk about these topics.

The low risk option would simply be to find some well known speakers, and cover whatever is being hyped right now. But that’s never been our way.
Instead, we scour the world for the true experts who are innovating on the web. People you may not have heard of, but who really know what they’re talking about, because they work day to day at the leading edge of their field.

We also felt after last year that perhaps we’d lost a little focus, and really spread the content out across too many tracks. So for this year we’re bringing back the focus and there’ll be just two tracks, simply called Design, and Development.

Our Design track covers web, user experience, and interaction design, with an eye firmly on the horizon in these exciting times. Content, big data, the disappearing interface, animation and thinking beyond the web, beyond mobile. Come along and get inspired by the possibilities.

Our Development track covers JavaScript, HTML5, DOM, and all things front end engineering (security, performance and more). As with our Code conference, it’s a mixture of in-depth keynote-style sessions, and shorter, condensed, highly specific presentations.

Then our famous four keynotes at the beginning and end of each day, bringing everyone together for some inspiration, as well as a few challenging ideas: certainly something to talk about with all the new connections you will make at the parties that close out both days of the conference.

Workshops

And just in case that’s not enough for you, on October 22 and 23, the two days before the conference, we have 5 optional full day workshops and masterclasses, each one a deep dive lead by a practising expert:

• Aaron Walter — Designing for emotion
• Matt Magain — Sketchnoting 101
• Axel Rauschmeyer — Diving deeply into JavaScript
• Relly Annet Baker — Creating web content
• Pasquale D’Silva and John Allsopp — Animating your user experiences

If you’re travelling from out of town, we’ve got some info about convenient hotels at our site — but the best tip is to get in early and grab a bargain!

We’re really excited about the lineup this year, we know it’s going to be something worthy of a 10th birthday celebration, and hope you’re going to be able to join us.

Code conference “Show Reel”

want to know what all the fuss is about? Check out the show reel from the recent Web Directions Code conference, a 3 minute slice of atmosphere and sound-grabs from speakers and audience members, as well as a hand picked selection of videos from past conferences.

For most of the history of what might loosely be termed computer games, dedicated consoles (and handheld gaming devices) ruled the roost. And none loomed larger on the landscape than Nintendo, with combined sales of hundreds of millions of units.

The dominance of this handful of device makers (essentially Nintendo, Sony and Microsoft) meant that developing games for wide distribution on these devices was expensive, and tightly controlled by the device manufacturers. And games generally cost $50, $100 or even more.

The success of smartphone and tablet platforms has impacted these traditional dedicated devices,and their entire ecosystem tremendously. Sales of consoles and gaming handhelds are down dramatically (down 27% in the US in 2012, year on year), as are sales of games (down 23% for the year in 2012).

In response, Nintendo recently announced the Nintendo Web Framework

a development environment based on WebKit technologies, supporting application development on the Wii U system using HTML5, JavaScript, and CSS. It also supports the Wii U GamePad controller, Wii Remote controllers, and JavaScript extensions such as video playback. With the Nintendo Web Framework, development times will be reduced and Wii U applications can be easily developed using common Web technologies

We can only hope that games built with the framework will also be able to be run (legally and technically) on other platforms, at least within reason.

Regardless, developing games for this once exclusive platform promises to become a whole lot easier, and more democratic. And if you think games built with HTML5 aren’t a reality, the entire UI for SimCity is built with web technologies

the whole UI is done in javascript running a custom version of webkit. :D

— Maxis Scott (@MaxisScott) March 10, 2013

Want to try it out? Sadly, it’s still not available. But you can sign up to express your interest here.

More on games and the Wii U

The Wii U web browser’s HTML5 gaming capabilities from HTML5 Game Developers Lost Decade Games

People mentioned in this post

Scott Clarke (@maxisscott): Javascript/UX developer for the SimCity UX team

Companies mentioned in this post

• Nintendo
• Microsoft
• Sony
• Lost Decade Games

With HTML5, extensibility of the markup language pretty much went out the window, despite the criticisms of many (including it must be said, me).

But extensibility is deeper than simply new language elements. As the web platform becomes increasingly sophisticated and powerful, it has also increasingly been seen as a competitor to “native” platforms such as iOS and Android. And where these platforms iterate quickly, with major new versions in the timeframe of each year or even more frequently, the web is seen to iterate far less quickly. We as developers need to wait not just for new browser versions (which in the case of desktop versions of Chrome and Firefox at least, is in the order of weeks), but whole new features of the DOM, CSS, and HTML, which typically is in the order of years.

Many have been frustrated with this pace of change, anxious that it puts the web at a disadvantage over the commercial platforms with far faster evolution. But the suggestions as to what might be done about it (for example, that the web should have “a single source repository and a good owner to drive it”) have not been on the whole realistic, or even really solutions to the challenge at all.

Now Yehuda Katz, Alex Russell, and numerous other high profile web developers, browser developers and specification authors have suggested a new way forward, summarised in The Extensible Web Manifesto.

In essence, the goal is to have new browser features implemented at a lower level, as DOM APIs, accessible through JavaScript (these might also be described as “imperative” features), as opposed to more high level, declarative features accessible at the level of the markup language.

Katz describes the situation of offline web apps, and how the approach to building a high level, “magical”, declarative feature, AppCache, went wrong, and how developing this functionality at a lower level might have avoided the problem, by empowering developers to build the solution they needed for their use cases.

We could have built offline support as a new JavaScript capability, with the manifest feature built on top of that capability. Then, when the manifest failed Facebook (and lanyrd, and the Financial Times), they could have dropped down into JavaScript and written something that worked for them.

Instead of placing our faith in central planning, we should let the ecosystem of web developers build the features they need, on top of low-level capabilities exposed efficiently and securely by the browser.

Will this be the approach to developing new web features we see more of? With members of the W3C’s Technical Architecture Group, or TAG, such as Alex Russell, Anne van Kesteren and Marcos Caceres firmly on board, along with the inventor of JavaScript, Brendan Eich, and numerous influential W3C and Browser vendor figures among others, I think it’s a fair chance.

But with an approach that at least superficially seems at odds with HTML’s self appointed benevolent dictator for life Ian Hickson’s, where does that leave the WHATWG in all of this?

Further Reading

• The Extensible Web Manifesto
• Extend the Web Forward
• The W3C’s Extensible Web Community Group (open to all interested parties)
• The future of web innovation
• ProllyFilling (‘polyfill[s] for a not yet standardized API’)
• .NET Magazine interview with Tab Atkins on the Extensible Web Manifesto

People mentioned in this article

• Joe Hewitt
• Alex Russell
• Anne van Kesteren
• Marcos Caceres
• Brendan Eich
• Yehuda Katz
• Tab Atkins

But state surveillance is at least something we can have a chance of controlling. (Re)introducing judicial oversight of what data is collected, how it is stored, who it can be accessed by, what it can be used for and so on — this is all at least imaginable, even today.

But what about surveillance by your fellow citizens, whether done with malice or otherwise. Consider the following, excerpted from The Google Glass feature no one is talking about:

First, take the video feeds from every Google Glass headset, worn by users worldwide. Regardless of whether video is only recorded temporarily, as in the first version of Glass, or always-on, as is certainly possible in future versions, the video all streams into Google’s own cloud of servers. Now add in facial recognition and the identity database that Google is building within Google Plus (with an emphasis on people’s accurate, real-world names): Google’s servers can process video files, at their leisure, to attempt identification on every person appearing in every video. And if Google Plus doesn’t sound like much, note that Mark Zuckerberg has already pledged that Facebook will develop apps for Glass.

and

Finally, consider the speech-to-text software that Google already employs, both in its servers and on the Glass devices themselves. Any audio in a video could, technically speaking, be converted to text, tagged to the individual who spoke it, and made fully searchable within Google’s search index.

Connected the dots yet?

It’s not a stretch to imagine that you could immediately be identified by that Google Glass user who gets on the bus and turns the camera toward you. Anything you say within earshot could be recorded, associated with the text, and tagged to your online identity. And stored in Google’s search index. Permanently.

and

The really interesting aspect is that all of the indexing, tagging, and storage could happen without the Google Glass user even requesting it. Any video taken by any Google Glass, anywhere, is likely to be stored on Google servers, where any post-processing (facial recognition, speech-to-text, etc.) could happen at the later request of Google, or any other corporate or governmental body, at any point in the future.

I’ll leave you to ponder the endless implications of this: you might be some time :). And good luck with judicial oversight: I mean here in Australia at least we can’t even get Google to pay taxes.

The most important Google Glass experience is not the user experience – it’s the experience of everyone else. The experience of being a citizen, in public, is about to change.

Bringing it back to our everyday lives as developers and designers today though, this really made me think of some of the words in Ben Hammersely’s, and Jon Kolko’s keynotes from Web Directions South last year. So, what kind of world is your app creating, not just for your users, but for all of us?

Postscript prediction: Camouflaging makeup to trick facial recognition software, as referenced in James Bridle’s Waving at the Machines, will be the new cool.

Helvetica Neue Ultra Light

Helvetica Neue was commissioned by Linotype in 1983 as an update to Helvetica for the digital age. Along with its variant Ultra Light then, you could see it as one of the first classic typefaces of the computerised era. Expect to see it, as well as other fine, elegant and clear typefaces, everywhere.

The Candy-Colored Clown They Call the Sandman

What exactly would you call that color scheme? Candy Store? Bubblegum? Hello Kitty? Kvetching aside though, first of all, on a superficial level, expect to see happy happy happy color everywhere. On a deeper level, the interface design trend here is less use of color as ornamentation and eye, and more subtle use of colors (albeit of eye popping neon and pastel ones) as a tool in their own right only appearing when useful to highlight data or give UX clues in an otherwise black and white context.

Much simpler icons

All those skills you’d perfected in Photoshop to design luscious, glassy, shiny, reflective 3D icons and other tidbits of interaction goodness? Forget them and start learning about 2D icons instead: and do it today, all those people who have been designing for Metro for years have got a massive head start on you :)

Newsflash: earth found to be flat afterall

On a related note, from this day forward, all the worlds you create shall be flat (until we tell you otherwise). Say goodbye to gradients, text shadows, box shadows and their ilk.

“New types of depth”

At first it seems like a contradiction, how can there be depth in a flat universe? But this may be the single stroke of overarching unique interface goodness in iOS 7. Expect to see more use of interface layering, and as you move between layers, beautiful and subtle use of translucency and transparency give context and dimensionality. And yeah, that parallax effect that creates a scarily 3 dimensional space as your peer through the portal of your screen? It’ll be interesting to see what designers might do with that in the web context.

In summary: deference, clarity and depth

These three words are being kicked around a lot. The new one to watch for mine is “deference”. This refers to the idea that the UI defers to the content — it helps users understand and interact with it, but it never competes. This will sound very familiar if you’ve been reading about the idea of the disappearing interface: more on this, and everything else that’s hot about design right now, at Web Directions South 2013 :)

When we first moved into the Web Directions office, we had an old iMac (I mean old) set up as a motion activated security camera. One of the guys who used to share the office with us had built a very simple app that when it detected movement (I’m assuming by analysing images) it sent a photo to a specified email address. Sadly, the Mac and app went when the guy moved out. I say sadly, because a few months back we could really have done with this to help catch whoever came by one night at 3am, smashed in our door, and took several devices.

But then it occurred to me this is something we can build in the browser. All we’d need to do was

1. Detect motion (with the DeviceMotion API (though it’s a bit more complex than this in practice as we’ll see in a moment)
2. Capture an image using WebRTC and the HTML5 canvas
3. Send the image via email (we won’t cover that today, as it is really more a server side issue, but there’s all kinds of ways you could do it) to ourselves.

So, let’s get started. We’ll begin by detecting motion.

Detecting motion

You’re probably thinking, there’s an HTML API for this, DeviceMotion. Which is exactly what I thought. The problem is, while well supported in mobile and tablet browsers (these devices almost universally have gyroscopes for detecting their orientation in 3D space, and accelerometers for detecting their acceleration in 3D as well) it’s not supported in any desktop browser. But, there is a related API, DeviceOrientation which reports the angle at which the device is in 3 dimensions, and which is supported in Chrome, when the laptop it is running on has the sensors to provide this data (I know that the MacBook Pro, but not Air support DeviceOrientation). DeviceMotion and DeviceOrientation work similarly. They both are events sent to the window object when something changes about the device. We can provide event listeners for these events, then respond to the data they provide.

Let’s create event handlers for each of these kinds of event

if (window.DeviceMotionEvent) {
  window.addEventListener('devicemotion', motionHandler, false)
}

else if (window.DeviceOrientationEvent) {
  window.addEventListener('deviceorientation', orientationHandler, false)
}

For each type of event, we make sure that the window object supports the event type, and if it does we add an event listener to the window for the type of event.

Ok, so now our Window can receive these events, let’s look at what information we get from each event, and how we can detect whether the device is in motion.

As mentioned, the most logical way to do so is via DeviceMotion, but here’s the complication. An ideal device for using as a security camera is an old laptop. It’s powered, so the battery won’t go flat, and on tablets, only Chrome for Android supports getUserMedia, for operating the device’s video camera. But, we can use DeviceOrientation to detect motion as we saw on some laptops in Chrome. Let’s do that first, then quickly look at how we can do the same thing for devices which support DeviceMotion events.

Here’s our handler for DeviceOrientation events.

function orientationHandler (orientationData){
  var today = new Date();

  if((today.getTime() - lastMotionEvent) > motionInterval){	
    checkMotionUsingOrientation(orientationData)
    lastMotionEvent = today.getTime()
  }
}

and similarly, our handler for DeviceMotion events

motionHandler: function (motionData){
  var today = new Date();

  if((today.getTime() - lastMotionEvent) > motionInterval){	
    checkMotionUsingMotion(motionData)
    lastMotionEvent = today.getTime()
  }
}

Because DeviceMotion and DeviceOrientation events fire many many times a second, if we were to respond to every single such event, we’d have a very warm laptop, and on battery powered devices, much shorter battery life. So, here we check the current time, and only if the time since we last responded to this event is greater than some interval we respond to the event. Checking for movement a few times every second should be more than adequate.

The event listeners receive deviceOrientation events, with data about the event, including information about the device’s orientation around 3 axes—alpha, beta and gamma.

• alpha is the device’s rotation around the z axis, an imaginary line extending out vertically from the middle of the device when it is lying flat on its back. In theory, alpha=0 is facing east, 90 is facing south, 180 is facing west, and 270 is facing north, but due to practical reasons, alpha is really only accurate for relative motions, not absolute directions, and so for example can’t be used to create a compass.
• beta measures the rotation around the x axis, a line horizontally through the device from left to right. 0 is when the device is flat, positive values are the number of degrees that the device is tilted forward, and negative values, the number of degrees it’s tilted backwards
• gamma measures the device’s rotation around the y axis, a line horizontally along the plane of the devices keyboard (or screen). Positive values at the number of degrees it’s tilted to the right, and negative values, the number of degrees it’s tilted to the left

Responding to the event

So, here’s how we’ll respond to the the event, and determine whether the device has moved.

function checkMotionUsingOrientation(orientationData){
  //detect motion using change in orientation
   
  var threshold = .7; //sensitivity, the lower the more sensitive
  var inMotion = false;
  
  var betaChange = orientationData.beta - lastBeta //change in beta since last orientation event
  var gammaChange = orientationData.gamma - lastGamma //change in gamma since last orientation event
      
  inMotion = (Math.abs(orientationData.beta - lastBeta) >= threshold ) || (Math.abs(orientationData.gamma - lastGamma) >= threshold)
  //if the change is greater than the threshold in either beta or gamma, we've moved 

  if (inMotion) {
    //do something because it is in motion
    }
  }
  
  lastBeta = orientationData.beta;
  lastGamma = orientationData.gamma;
  //now we remember the most recent beta and gamma readings for comparing the next time

The orientationData argument is our deviceOrientation event. Along with the sorts of information we’d expect from any event, it has 3 properties, alpha, beta and gamma, with no prizes for guessing what these contain.

What our function does is gets the beta and gamma values from the event, and subtracts the difference from the last time we measured these. If either of these differs by more than some threshold we’ve set (in this case a little under 1 degree) then we’ve detected a movement. We finish by storing the most recent beta and gamma values. We’ve not bothered with alpha values, because Chrome, at present the only browser to report these values on the desktop, doesn’t report alpha values, and because moving a device only around one axis is extremely difficult, so if there’s movement around beta or gamma, then that’s good enough for our purposes. Essentially when the device is lying flat on its back, anyone walking in the vicinity will trigger this event.

How about doing the same thing when device motion events are supported? This time, instead of reporting the devices orientation in space, we get information about its acceleration in each of the same axes, x, y and z.

• motionData.acceleration.x is the acceleration of the device, in metres per second per second (ms^2), to the right (relative to the device) (so negative values are acceleration to the left)
• motionData.acceleration.y is the acceleration of the device, in metres per second per second (ms^2), forward (relative to the device) (negative values are acceleration “backwards”)
• motionData.acceleration.z is the acceleration of the device, in metres per second per second (ms^2), upwards (relative to the device) (negative values are downwards)

Here’s how we’d use this to detect motion.

checkMotionUsingMotion: function(motionData){
  //agorithm courtesy
  //http://stackoverflow.com/questions/8310250/how-to-count-steps-using-an-accelerometer

  var threshold = 0.2;
  var inMotion = false;
  
  var acX = motionData.acceleration.x;
  var acY = motionData.acceleration.y;
  var acZ = motionData.acceleration.z;
  
  if (Math.abs(acX) > threshold) {
    inMotion = true
  }
  
  if (Math.abs(acY) > threshold) {
    inMotion = true
  }  
  
  if (Math.abs(acZ) > threshold) {
      inMotion = true
  }

  if (inMotion) {
    //do something because it is in motion

  }
}

Here we take the acceleration in each axis, and if any of these is greater than a threshold amount (to ensure we don’t get false positives) then we’re in motion. You can see it’s a little simpler than using deviceOrientation, as we don’t need to calculateany change.

Taking the photo

So now we can detect when the device is moving, we want our security camera to take a photo. How are we going to do this? Well, one feature of WebRTC is the ability to capture video with a device’s video camera. At present, this is supported in Firefox and Chrome on the desktop, and the Blackberry 10 Browser (which also supports devicemotion events, so your Blackberry 10 phone or Playbook can serve as a security camera if you need it!), as well as Chrome for Android (though you need to enable it with chrome://flags). WebRTC is a very powerful API, but we’re only going to need a small part of it.

We’ll use the getUserMedia method of the navigator object. This takes an options object, as well as a success and a failure callback function as its arguments.

var options = {video: true};
navigator.getMedia(options, gotVideoStream, getStreamFailed);

Our options variable is a simple object, here we just set its property video to true (if we wanted audio we’d also set an audio property to true).

We’ve also passed it two callback functions, gotVideoStream, which will be called once a video stream is available, and getStreamFailed, which is called if we don’t get a video stream (for example, if the user refuses the browser’s request to use the video camera). getUserMedia uses callbacks, rather than returning a value, because it takes time for the user to choose whether to allow video to be enabled, and as JavaScript is single threaded, this would block our UI while the user waited.

Next, let’s use video stream.

function gotVideoStream(stream) {
  var videoElement = document.querySelector("video");
  videoElement.src = window.URL.createObjectURL(stream);
}

OK, there’s a bit going on here, so let’s take it one step at a time. Navigator calls our callback function, passing an argument stream. This is a MediaStream object. We then use the createObjectURL method of the window’s URL object to get a URL for the stream (this way we can then make this URL the value of the src attribute of a video element, then this video element will show the output of our camera in real time!).

So, we’ve now got a working video camera, that shows the video feed from our devices camera in a web page. No servers, no plugins! But we still don’t quite have our security camera. What we need to do is take a snapshot from the video stream, when we detect movement. So, let’s first take the snapshot

Taking a snapshot from the video element

Here we’ll take a snapshot of the video element at a given time. Note this works regardless of what’s playing in the video element (so you can do a screen grab of anything playing in an HTML5 video element like this). Ready?

function takeSnapshot(){
	var canvas = document.querySelector("canvas");
  var context = canvas.getContext('2d');
  var video = document.querySelector("video");
  context.drawImage(video, 0, 0);
}

Here’s what we’re doing

• we get a canvas element from the page
• we get its 2D drawing context
• we get the video element from the page
• we use the drawImage method of the canvas to draw the video into the canvas starting at (0, 0) (the top left of the canvas).

Yes, it really is that easy. Just as you can use canvas.drawImage with an img element, we can use it with a video element.

Now we’ve got all the pieces, let’s put them together to create our security camera.

Remember this part of our motion detection functions?

if (inMotion) {
  //do something because it is in motion
}

This is where we call takeSnapshot, and then the current frame in the video element will be captured to a canvas element. You could also save this in localStorage, or send it via email to someone, or otherwise do something with the image. I’ll leave those parts to you.

And that’s really all there is to it.

I’ve also got a fully working version available on github. It’s a little more complicated to read through than the code here, but it’s copiously commented, and the basic working code is the same. Or you can see it in action here (just make sure you use Chrome with a device that supports orientation events, and has a webcam).

Notes for those following along

Note though, to make it work from your local drive, you’ll need to run it through a webserver (Chrome won’t enable the camera from file:// although Firefox will). You’ll also need a device that supports either device orientation or device motion events, which to my knowledge currently means only a MacBook Pro (not MacBook Air).

Links for further reading

Som more reading on the various features we used to build our security camera.

• The getUserMedia Specification at the W3C
• Capturing Audio & Video in HTML5 from HTML5 Rocks
• DeviceMotion and Orientation Events specification at the W3C
• This End Up: Using Device Orientation from HTML5 Rocks
• Cross-browser camera capture with getUserMedia/WebRTC
• createObjectURL at Mozilla Developer Network

We’ll be launching the program on June 17, 9am, AEST, and if you want a reminder, make sure you’re on our mailing list.

If you need pre-approval, or to register this Australian Financial year for budgetary approval, we’ve kept the price the same as last year, just $999, with our usual generous discounts for past attendees, and we’ll open up registration shortly.

In the lead up, we want to start whetting your appetite, and we’re releasing some of the until now exclusive for attendees videos of previous events, one per day for the next three weeks. There’ll be big ideas, design, and development goodness from the likes of Lea Verou, Jeremy Ashkenas, Nicole Sullivan, Josh Clarke, Angus Croll, and many others. See the full schedule to plan your next 3 weeks of watching pleasure!

First up is the wonderful keynote from last year’s Web Direction South by Ben Hammersley, The Flower, the Field and the Stack. Enjoy!

But a platform we’ve been excited about for some time, Blackberry 10, makes web technologies first class citizens.

BlackBerry’s browser is a modern webkit browser, with industry leading scores in terms of performance, and feature support. But, unlike with many other platforms, Web developers get access to low level device APIs right from JavaScript. You can debug your apps using a web browser on your desktop, while they run natively on the device, and then package your apps to be deployed in BlackBerry World, the app storefront for the BlackBerry platform.

So, if you’ve already got mobile friendly or optimised content or apps, it makes sense to consider spending that little bit of extra effort to turn it into a BlackBerry 10 Native App.

Web Directions Code Blackberry App Competition

To give you just a little more incentive, BlackBerry are holding a competition for Australian and New Zealand residents, with top entrants showcased at Web Directions Code, and some pretty awesome prizes. And you don’t have to be attending Code to enter!

What you have to do

1. Check out http://developer.blackberry.com/html5 for platform documentation/tools
2. Create a mobile app using web technologies (and phoneGap or WebWorks)
3. Submit a .bar app file to csaunders@blackberry.com (with a short description for voters) by noon on May 1st AEST.
4. Win awesome prizes!

so, you’re thinking this is going to be a lot of work. Think again! And to give you a little more incentive, here’s what’s on offer.

Prizes

First Prize

1. All expenses paid trip to BlackBerry Jam Asia 2013
2. BlackBerry Z10 smartphone
3. $2000 cash

Second Prize

1. BlackBerry Z10 smartphone
2. $1500 cash

Third Prize All

1. BlackBerry Z10 smartphone
2. $1000 cash

All voters at Web Directions Code will walk away with great swag!

Judging

Judging will have two components:

1. A crowd vote by attendees at Web Directions Code
2. Judging by a panel of Judges including Chris Saunders from BlackBerry and John Allsopp from Web Directions

The Workshop

To make it even easier to enter, Chris Saunders from BlackBerry will be hosting a workshop at Web Directions secret lair in Sydney, from 2pm to 5pm, Friday April 26th. Just bring your laptop, and code, and have Chris on hand to help you get up to speed, and maybe even complete your porting job, as well as test on some real live Blackberry 10 devices, before winding up the week with a beer. Then head around to #Fridayat4 to catch up with many more from the Sydney web community

It’s free, but places are limited, so sign up now, and get in the running for a trip to South East Asia later this year for BlackBerry Jam Asia (including flights and accommodation), cash prizes, and brand new BlackBerry devices.

Thanks to everyone that came along in Melbourne — all 200 of you! As we mentioned on the night, the rooftop marquee (a substantially larger and better laid out space) was torn down in the winds on Good Friday, leaving us with no choice but to move to the less ideal basement space. Thanks for bearing with us.

We started the evening with Mark Dalgleish, who always does such a great job of presenting. This time he went all recursive on us and talked through Bespoke.js, his DIY presentation Microframework. Check out the presentation itself here.

Next up, for something completely different we had Carla Hackett who showed us all about the fine old art of hand lettering. Carla’s beautiful presentation is all written up in this blog post, and check her out on Instagram for all the examples of hand lettering she finds on the streets of Melbourne. For another example of how hand lettering might be used check out her intro to this Catherine Deveny interview.

Joji Mori was next, talking us through his fascinating PhD project, which is all about how we can commemorate online. Here is the work he has done for Black Saturday.

Then there was another change of course as Brad Barrow told us about Front-end testing, and introduced us to the startup he is part of, earl.io

Leading into the break we had Harriet Wakelam, who showed us How to Design Without P**ing People Off — harder than you think! Her slides are here.

After a quick refreshment break we jumped straight back into the deepend, as Alex Mackey demoed RX.js in a rush. You can download his full presentation here, and read his Intro to RX.js here.

Donna Benjamin was next, giving us a Hitch Hiker’s Guide to the Drupalverse. If your curiosity is piqued, get along to the Drupal Melbourne meetup some time, or check out the IRC Channel (not for the fainthearted :).

Chris Chinchilla showed us how easy it is to use PhoneGap to create mobile apps using our HTML, JS and CSS skills. To connect with Chris, get along to Mobile Monday Melbourne.

Michael Mifsud showed us an interesting experiment he has done whereby he outsourced his holiday via GitHub.

And then to end the night Leni Mayo told us all about The Innovator’s Dilemna, using NoSQL vs MySQL as an example. Check out The Innovator’s Dilemna book here.

And that about wrapped it all up for the first What Do You Know season for 2013. We’ll be back round August/September — see you then!