P
A
B
C
A
S
Thoughts, links, pictures on music, food, wine, film, tech etc.

2010-11-01

I spake this:

My Dublin Web Summit Talk

I wrote and read this at the Dublin Web Summit last week.

I think a conference with all presidential address style talks on technical topics would be great fun!

Here's the script:

Simple, Fast, Great


Here is my thesis:

Simple things tend to be fast. Fast things tend to be simple. Great things tend to be both simple and fast.

And to clarify:

When I say simple, I mean low conceptual overhead. Not necessarily basic, but easy to understand, easy to use.

When I say fast, I mean responsive.

And by great, I mean the stirring of emotions and the evoking of strong feelings of delight, wonder and awe.

So, to rephrase:

Easy to use software tends to feel fast. Software that feels fast tends to be easy to use. Great software tends to be both easy to use and very responsive.

WHERE WE’RE AT

Let’s look at the web.

I’ll talk first about simplicity. I want to look particularly at some examples at the infrastructure level.

First, there is the protocol. HTTP. What a beautiful thing is HTTP, nestled so comfortably upon TCP and its good friend IP.

TCP and IP together transfer bytes from one computer to another. At the speed of light. Sending information at the speed of light. It doesn’t get more elegant than that.

HTTP. Mmm. Mmmmm. Mmmmmmmm. HTTP, which makes it so easy to POST data online, which trivialises PUTting updates and any time we like we can GET it all back.

Connected to Port 80.

GET /home

HTTP/1.1 200 OK

So, so, simple. Ugh. SO SIMPLE.

And HTML. My good friend HTML. Simple labels surrounding portions of text to give that text meaning. Hidden from view. But allowing us to link all of this information together.

Like a book. A book with a circulatory system. A book that’s ALIVE.

This is a <h1>header</h1> and this is a <p>paragraph</p>.

We stand on the shoulders of simple giants. Simple protocols, simple markup.

And then there’s speed.

As developers, we hear a lot about performance. Oh, this system beats that system in the other benchmark. The specs on this machine are faster than that one. This database will perform N thousand operations per second.

Great. Raw speed : that’s cute. And important.

Depending on the context, it’s the perceived speed that really matters. Perceived speed has much less to do with the time it takes to do something, and much more to do with how responsive something is.

BUILDING ON THIS

EMOTIONALLY RESPONSIVE INTERFACES

The ultimate user interface, against which we should measure every other, to me, is the human body. 100,000,000 years of of intensive user testing have yielded a beautiful, elegant, modular system; each part efficiently playing its role, and the pieces that are exposed to end users offering simple interfaces to hidden, inner complexity.

What are the characteristics of this amazing human machine?

Firstly, humans are wonderfully responsive. How much more satisfying it is to speak to each other directly. Eye contact, touch, response, sensitivity. We are tactile beings, noticing nuanced responses in each other. Everything from the crease of our eyes when we smile to the tone in which we say things generates high emotional response in each other.

Second, our bodies are wonderful at handling long running processes. During lunch, think about the journey of food through our bodies, all of it handled by a complex independent nervous system, independent from the central nervous system. Other internal systems keep the body running without affecting external responses. If anything goes wrong, we usually know about it; fail fast. If everything works out, we know all about it, and we move on to the next meal.

Finally, our brain has this wonderful asset; the subconscious, an always-working stream of thought that continues to process, behind the scenes, everything we’ve fed the conscious brain, and bubbles up inspiration, revelation and other general magic. Automatic asynchronous thought. Tasty.

What does all of this have to do with the web?

The web is in transition. It’s been in transition for the last 15 years, from a delightfully simple transmission system for scientific, connected documentation, to an applications platform, a platform for creating, consuming, processing and distributing information.

An application platform.

With the advances of HTML5, and the present acceleration in the innovation of the browser vendors, we developers are slowly gaining access to nirvana: a truly distributed, write once, run everywhere application stack.

Cue javascript

And so, to a topic close to my heart: javascript. Javascript, the programming language of the web.

Think about that. The programming language of the web. Our programming language. Our common ground. Ubiquitous. The truly ubiquitous language.

Think about that just a little bit more. Ok. Got it? There’s really something great about that.

Our wonderful language. Our powerful language. Oh, we didn’t know it for years, but javascript, like the other parts of the web, is also built on the shoulders of giants. Simple objects, so elegant that they spawned their own data-structure standard in JSON. Functions as values. Closures. Events.

Easy to learn, difficult to master.

Simple. Fast. Great.

And with HTML + javascript, the web is our collective application stack. So. Much. Power.

And with great power, comes great, great responsibility. We can create beauty. We can create wealth. But we can also create monsters. Marquees. Effects. Flashes.

Simplify & Speed up the Web with JS

But the role of javascript, in the browser at least, I think, is to simplify the web. But not only to simplify, but to make the web feel faster.

The simplicity comes from javascript’s implicit ability to change a page without needing to make a new request. Think of the conceptual clarity of an interaction that updates a page instantly versus an interaction that requires a page refresh. No network overhead. No conceptual overhead.

Updating a page with javascript is so fast, in fact, that it often helps to artificially slow down the speed of response of an interaction. Why? To make the response more human like. If someone responds to a question too fast, we don’t take them seriously. If an interface responds too fast, the same principle applies.

Javascript helps to take away the constraint of network latency, and gives us back control of how responsive the applications that we’re building can be.

The relevancy is that today we have so many tools for building these kinds of apps. Prototype, jQuery, mootools, dojo, these are just the start. A movement is afoot, toward development of client-side applications: thick clients that are delivered via simple web pages. Client side templating languages make organising view files a cinch.

And it’s all just the internet.

If we want to build software for humans, I think that we should build our software like humans. Emotive, responsive interfaces. Long running processes should be sent to the background, processing away while other things happen. And an asynchronous aspect that allows our interfaces to respond now, process behind the scenes, and bubble up inspiration.

The Event Loop - build responsively

The traditional way of thinking about a computer program is a set of commands that are run, step by step, one after the other.

An event loop is the programming equivalent of the subconscious. A constant stream that we can send tasks to, and once they’re processed, they can bubble back up and announce their presence. Javascript has a great event loop. Evented programming allows us to update an interface immediately, send a task to the background and specify what to do when the task is done. Power to the people.

If we shift our paradigm of programming from a vertical set of serial commands to a horizontal set of events and callbacks, we can control the perceived speed of our applications. We can make things feel fast.

Where it has led me

I try to be led by these principles as much as I can in my own work.

Ketchup, the web app that I launched earlier this year, for taking notes online. Right now, it’s more or less a manifestation of these principles of how an app should work:

First, the main meeting view is always responsive, all the time. Every user action updates the view immediately, and then gets updated from the server-side.

Next, Every note gets added to the page immediately ; there’s no Save button. The “Save” button is still a hangover from an age in computing where compute and storage was expensive. When do I not want to save?

I’m also working on a javascript framework, eyeballs.js. Eyeballs is all about designing these kinds of interfaces in a manageable way. Amongst other things, eyeballs lets you organise your code in terms of models and controllers, and to specify callbacks on saving your models that encourage you to update the view immediately and respond on success or failure. All in a manageable way.

I’m excited about the future of eyeballs and the future of human-centric interfacing on the web in general. I see us, in the future, having even more power to control the experience of users and even more opportunities to simplify our interaction with the web, and make the whole thing feel really fast.

IN SUMMARY

In summary, I think that the web is one of the greatest things to happen in the history of the world. No single technology has brought us all together so efficiently. Made access to information so widespread.

The web is founded on simple principles. These principles have helped it spread and succeed. But it’s always felt kind of slow.

As developers, we have access to technologies and techniques to make the web feel faster. We can also use powerful tools to simplify the experience of using the applications we build.

These are the principles that guide me every day. I think that they are pretty solid principles, and I’m going to keep on working with them at the forefront of my mind. Maybe they will work for you, maybe they wont, but I promise you, if you build something and it’s easy to understand, easy to use and responds like a baby when you tickle its belly, you might, you just might be on to something great.

Thank you.


 
Made by Paul Campbell. paul@rushedsunlight.com. Twitter. Github.