Tags: interactivity

Looking back on ten years of codebar Brighton, I’m remembering how much I got out of being a coach.

Something that I realised very quickly is that there is no one-size-fits-all approach to coaching. Every student is different so every session should adapt to that.

Broadly speaking I saw two kinds of students: those that wanted to get results on screen as soon as possible without worrying about the specifics, and those who wanted to know why something was happening and how it worked. In the first instance, you get to a result as quickly as possible and then try to work backwards to figure out what’s going on. In the second instance, you build up the groundwork of knowledge and then apply it to get results.

Both are equally valid approaches. The only “wrong” approach as a coach is to try to apply one method to someone who’d rather learn the other way.

Personally, I always enjoyed the groundwork-laying of the second approach. But it comes with challenges. Because the results aren’t yet visible, you have to do extra work to convey why the theory matters. As a coach, you need to express infectious enthusiasm.

Think about the best teachers you had in school. I’m betting they displayed infectious enthusiasm for the subject matter.

The other evergreen piece of advice is to show, don’t tell. Or at the very least, intersperse your telling with plenty of showing.

Bret Viktor demonstrates this when he demonstrates scientific communication as sequential art:

This page presents a scientific paper that has been redesigned as a sequence of illustrations with captions. This comic-like format, with tightly-coupled pictures and prose, allows the author to depict and describe simultaneously — show and tell.

It works remarkably well. I remember how well it worked when Google first launched their Chrome web browser. They released a 40 page comic book illustrated by Scott McCloud. There is no way I would’ve read a document that long about how browser engines work, but I read that comic cover to cover.

This visual introduction to machine learning is another great example of simultaneous showing and telling.

So showing augments telling. But interactivity can augment showing.

Here are some great examples of interactive explainers:

• Cameras and Lenses by Bartosz Ciechanowski,
• An Interactive Guide to CSS Grid by Josh W Comeau,
• CSS :has() Interactive Guide by Ahmad Shadeed,
• Pizza Exchange Rate by Nathan Yau, and
• just about everything by Nicky Case.

Lea describes what can happen when too much theory comes before practice:

Observing my daughter’s second ever piano lesson today made me realize how this principle extends to education and most other kinds of knowledge transfer (writing, presentations, etc.). Her (generally wonderful) teacher spent 40 minutes teaching her notation, longer and shorter notes, practicing drawing clefs, etc. Despite his playful demeanor and her general interest in the subject, she was clearly distracted by the end of it.

It’s easy to dismiss this as a 5 year old’s short attention span, but I could tell what was going on: she did not understand why these were useful, nor how they connect to her end goal, which is to play music.

The codebar website has some excellent advice for coaches, like:

• Do not take over the keyboard! This can be off-putting and scary.
• Encourage the students to type and not copy paste.
• Explain that there are no bad questions.
• Explain to students that it’s OK to make mistakes.
• Assume that anyone you’re teaching has no knowledge but infinite intelligence.

Notice how so much of the advice focuses on getting the students to do things, rather than have them passively sit and absorb what the coach has to say.

Lea also gives some great advice:

1. Always explain why something is useful. Yes, even when it’s obvious to you.
2. Minimize the amount of knowledge you convey before the next opportunity to practice it. For non-interactive forms of knowledge transfer (e.g. a book), this may mean showing an example, whereas for interactive ones it could mean giving the student a small exercise or task.
3. Prefer explaining in context rather than explaining upfront.

It’s interesting that Lea highlights the advantage of interactive media like websites over inert media like books. The canonical fictional example of an interactive explainer is the Young Lady’s Illustrated Primer in Neal Stephenson’s novel The Diamond Age. Andy Matuschak describes its appeal:

When it wants to introduce a conceptual topic, it begins with concrete hands-on projects: Turing machines, microeconomics, and mitosis are presented through binary-coding iron chains, the cipher’s market, and Nell’s carrot garden. Then the Primer introduces extra explanation just-in-time, as necessary.

That’s not how learning usually works in these domains. Abstract topics often demand that we start with some necessary theoretical background; only then can we deeply engage with examples and applications. With the Primer, though, Nell consistently begins each concept by exploring concrete instances with real meaning to her. Then, once she’s built a personal connection and some intuition, she moves into abstraction, developing a fuller theoretical grasp through the Primer’s embedded books.

(Andy goes on to warn of the dangers of copying the Primer too closely. Its tricks verge on gamification, and its ultimate purpose isn’t purely to educate. There’s a cautionary tale there about the power dynamics in any teacher/student relationship.)

There’s kind of a priority of constituencies when it comes to teaching:

Consider interactivity over showing over telling.

Thinking back on all the talks I’ve given, I start to wonder if I’ve been doing too much telling and showing, but not nearly enough interacting.

Then again, I think that talks aren’t quite the same as hands-on workshops. I think of giving a talk as being more like a documentarian. You need to craft a compelling narrative, and illustrate what you’re saying as much as possible, but it’s not necessarily the right arena for interactivity.

That’s partly a matter of scale. It’s hard to be interactive with every person in a large audience. Marcin managed to do it but that’s very much the exception.

Workshops are a different matter though. When I’m recruiting hosts for UX London workshops I always encourage them to be as hands-on as possible. A workshop should not be an extended talk. There should be more exercises than talking. And wherever possible those exercises should be tactile, ideally not sitting in front of a computer.

My own approach to workshops has changed over the years. I used to prepare a book’s worth of material to have on hand, either as one giant slide deck or multiple decks. But I began to realise that the best workshops are the ones where the attendees guide the flow, not me.

So now I show up to a full-day workshop with no slides. But I’m not unprepared. I’ve got decades of experience (and links) to apply during the course of the day. It’s just that instead of trying to anticipate which bits of knowledge I’m going to need to convey, I apply them in a just-in-time manner as and when they’re needed. It’s kind of scary, but as long as there’s a whiteboard to hand, or some other way to illustrate what I’m telling, it works out great.

river

This is quite mesmerising—click on an image that takes your fancy; see it surrounded by related images; repeat.

I was doing some accessibility work with a client a little while back. It was mostly giving their site the once-over, highlighting any issues that we could then discuss. It was an audit of sorts.

While I was doing this I started to realise that not all accessibility issues are created equal. I don’t just mean in their severity. I mean that some issues can—and should—be caught early on, while other issues can only be found later.

Take colour contrast. This is something that should be checked before a line of code is written. When designs are being sketched out and then refined in a graphical editor like Figma, that’s the time to check the ratio between background and foreground colours to make sure there’s enough contrast between them. You can catch this kind of thing later on, but by then it’s likely to come with a higher cost—you might have to literally go back to the drawing board. It’s better to find the issue when you’re at the drawing board the first time.

Then there’s the HTML. Most accessibility issues here can be caught before the site goes live. Usually they’re issues of ommission: form fields that don’t have an explicitly associated label element (using the for and id attributes); images that don’t have alt text; pages that don’t have sensible heading levels or landmark regions like main and nav. None of these are particularly onerous to fix and they come with the biggest bang for your buck. If you’ve got sensible forms, sensible headings, alt text on images, and a solid document structure, you’ve already covered the vast majority of accessibility issues with very little overhead. Some of these checks can also be automated: alt text for images; labels for inputs.

Then there’s interactive stuff. If you only use native HTML elements you’re probably in the clear, but chances are you’ve got some bespoke interactivity on your site: a carousel; a mega dropdown for navigation; a tabbed interface. HTML doesn’t give you any of those out of the box so you’d need to make your own using a combination of HTML, CSS, JavaScript and ARIA. There’s plenty of testing you can do before launching—I always ask myself “What would Heydon do?”—but these components really benefit from being tested by real screen reader users.

So if you commission an accessibility audit, you should hope to get feedback that’s mostly in that third category—interactive widgets.

If you get feedback on document structure and other semantic issues with the HTML, you should fix those issues, sure, but you should also see what you can do to stop those issues going live again in the future. Perhaps you can add some steps in the build process. Or maybe it’s more about making sure the devs are aware of these low-hanging fruit. Or perhaps there’s a framework or content management system that’s stopping you from improving your HTML. Then you need to execute a plan for ditching that software.

If you get feedback about colour contrast issues, just fixing the immediate problem isn’t going to address the underlying issue. There’s a process problem, or perhaps a communication issue. In that case, don’t look for a technical solution. A design system, for example, will not magically fix a workflow issue or route around the problem of designers and developers not talking to each other.

When you commission an accessibility audit, you want to make sure you’re getting the most out of it. Don’t squander it on issues that you can catch and fix yourself. Make sure that the bulk of the audit is being spent on the specific issues that are unique to your site.

4 Rules for Intuitive UX – Learn UI Design

1. Obey the Law of Locality
2. ABD: Anything But Dropdowns
3. Pass the Squint Test
4. Teach by example

How do you mark up an accordion? — Sara Soueidan

I love this deep dive that Sara takes into the question of marking up content for progressive disclosure. It reminds me Dan’s SimpleQuiz from back in the day.

Then there’s this gem, which I think is a terrificly succinct explanation of the importance of meaningful markup:

It’s always necessary, in my opinion, to consider what content would render and look like in foreign environments, or in environments that are not controlled by our own styles and scripts. Writing semantic HTML is the first step in achieving truly resilient Web sites and applications.

Your Interactive Makes Me Sick - Features - Source: An OpenNews project

Browsers have had consistent scrolling behavior for years, even across vendors and platforms. There’s an established set of physics, and if you muck with the physics, you can assume you’re making some people sick.

Guidelines to consider before adding swooshy parallax effects:

1. Respect the Physics
2. Remember that We Call Them “Readers”
3. Ask for Consent

Given all the work that goes into a powerful piece of journalism—research, interviews, writing, fact-checking, editing, design, coding, testing—is it really in our best interests to end up with a finished product that some people literally can’t bear to scroll through?

Why Web Developers Need to Care about Interactivity — Philip Walton

Just to be clear, this isn’t about interaction design, it’s about how browsers and become unresponsive to interaction when they’re trying to parse the truckloads of Javascript web developers throw at them.

Top tip: lay off the JavaScript. HTML is interactive instantly.

The First Web Apps: 5 Apps That Shaped the Internet as We Know It

A great bit of web history spelunking in search of the first websites that allowed users to interact with data on a server. Applications, if you will. It’s well written, but I take issue with this:

The world wide web wasn’t supposed to be this fun. Berners-Lee imagined the internet as a place to collaborate around text, somewhere to share research data and thesis papers.

This often gets trotted out (“the web was intended for scientists sharing documents”), but it’s simply not true that Tim Berners-Lee was only thinking of his immediate use-case; he deliberately made the WWW project broad enough to allow all sorts of thitherto unforeseen uses. If he hadn’t …well, the web wouldn’t have been able to accommodate all those later developments. It’s not an accident that the web was later used for all sorts of unexpected things—that was the whole idea.

Anyway, apart from that misstep, the rest of the article is a fun piece, well worth reading.

• Listen to the audio.
• Watch the video.
• Download the slides.

Thank you very much, Eric. I kind of make Eric’s life hard because I change my job title every couple of weeks, so, “Okay what are you this week?”, and I can’t even remember what my job title is. If you go to the Clearleft website, it has my job title on there somewhere, but I change it all the time. There’s actually a Twitter bot called Jeremy’s Job, and you can follow that if you want to find out.

So hello. Are we having fun yet?

Good. It is, as always, an honour to be speaking at this prestigious event, and it’s lovely to be in San Diego. Who’s from San Diego? …all right; it’s a lovely place. A lovely place you have here.

I want to talk to you today about interactivity. This is a web conference, I want to talk about interactivity, so you might think, okay, fair enough, we’re going to be talking about JavaScript and interaction and all that kind of stuff. Yeah, we will, I’ll get to that, but that’s not actually the main crux of the talk.

I want to talk about interactivity full stop: the history of interactivity. We’ve been doing interactivity face to face before there was computers. I want to pull back and do the long zoom.

Jeffrey gave us a bit of a long-zoom presentation yesterday; he was giving us the history of technology that’s led up to the web, and the technologies we work with today. But I kind of feel he started a bit late in the process, because what? …the fifteenth century, the sixteenth century? Yeah, too late. I want to start a bit further back than that.

Pretty late in the lifetime of the universe and late in the lifetime of the solar system, and very late in the lifetime of the planet, we have the dawn of man on the plains of Africa.

There’s this species of ape that start to dominate the planet. There are many reasons why this particular species of ape has become so dominant, but one of them is down to interactivity—that man is a social animal—and its method of communication.

Now, many animals communicate. There’s a lot of phatic communication, a lot of phatic interactivity between animals: a cat will raise its heckles, and there’ll be threatening gestures and things like this. But what the human ape managed to do, which was so clever, is use language, and specifically using speech.

Through this evolutionary process, we developed the ability to move pieces of meat inside our mouth to vibrate the molecules of the air between two people, and use it as a way of transmitting data; a way of transmitting information. Speech is effectively this evolutionary hack that allows one human being to pass information from one brain to another brain.

Which is hopefully what’s been going on for the last two days, right? We’re in this room that’s filled with mostly nitrogen (about one fifth oxygen) and these molecules are getting vibrated. It’s speaker cones but the principle is much the same. By the vibration of the molecules of the air, ideas and information and data is being transferred from one brain into other brains, which is pretty amazing. That’s quite an evolutionary hack that we’ve got there.

So speech is probably the oldest form of interactivity. It allows data transmission and it’s probably one of the reasons why we’ve become a dominant species on the planet. This works, as long as you’re in the same place at the same time as another human being, and you’re using the same code base. In other words, the language needs to be understood by both parties. In this case, the code base is English. I’m speaking English; you’re understanding English. If I were speaking another language that you didn’t understand, this hack wouldn’t work. But it works as long as we’re in the same space, same time; that’s good.

The next sort of leap in interactivity was to change things on the time axis. We got representational art. This is a very old example of representational art from the Lascaux caves in France. Quite beautiful painting. The person who painted this is long dead, and yet we can still see it, we can still get information from it. We get the data, it’s a picture of an animal. So the advantage of representational art, of pictures, is that you don’t have to be in the same place at the same time; it takes the time dimension away from it. Which is great when you’re trying to get information across to people but you don’t want to stand there the whole time.

For example, here on the New York subway I saw this picture, this is getting a message across. Instead of having a person stand there and speak the message all day, they make an icon, and they put the icon on the wall and now that message can be conveyed at any time. The only disadvantage really to using icons or representational art like this is that they can be misinterpreted. So I look at this icon and I read it as ‘Press to exhale RSS.’

That’s the way my brain interprets it. And this can be a problem with icons in general. The intended meaning is mis-interpreted. The other issue with icon design—icon design is a very difficult discipline—what you choose to represent can date the message. For example, in operating systems today, the icon for Save in many programs is still this icon: a 3.5 inch floppy disk. I’m sure many of you in this room have never even used a 3.5 inch floppy disk, right? But the meaning has now been associated with Save, even though what it’s representing has long gone. I was talking to a friend; we were wondering when we are going to stop using magnetic media at all…like we’re all going to flash drives rather than spinning magnetic drives; probably going to be in a few years we won’t be using any kind of magnetic media. So icons can date. And just sometimes it’s very hard to express a message in an icon.

So the other alternative for getting the message across is to write it down. And then you’re back to the language problem—the code-base problem—that it will only work as long as you share the same code-base, the same language. But with some things you kind of have to do that because the icon would be too tricky. So here’s my favourite piece of interaction design, it’s this button: press for free cheese. it would be very difficult to design an icon that could be understood: press for free cheese. If you would like to try, please do so. I would like to see that.

By using language, by using writing, which essentially is speech written down, we can take out the time axis and we don’t have to be in the same place at the same time, we can express meaning over long periods of time. And it’s been done for a long time.

Here’s an item. It’s called the Ælfred jewel. It’s in the Ashmolean museum in Oxford. It’s a beautiful, beautiful piece of work, and it has writing on it. So it’s beautiful in its own right, but there’s also writing round the edge. It says… ‘Ælfred mec heht gewyrcan’, which translates to ‘Ælfred ordered me to be made’. I find this interesting for two reasons. One: it’s metadata. It’s metadata encoded onto the object itself. And two: it’s speaking as if it were a person. It’s referring to itself in the first person, ‘Ælfred order me to be made’, and immediately that changes how we interact with the object. I find, anyway, that when objects speak to us in this way, as though they were people, our brains are wired to treat them differently. And this is something we can use. We can use this on the web.

Some people do this on the web wonderfully. Have you ever ordered cards from MOO.com? Anybody used Moo.com? So Moo.com, they do lovely little business cards, and when you send in your order, you’ll get an e-mail, and the e-mail is from a piece of software, and it tells you it’s a piece of software:

Hello Jeremy, I’m Little Moo - the bit of software that will be managing your order with us.

Aw, that’s so cute! It’s not pretending to be a person. It’s right up front, saying, I’m a piece of software’, but it has a personality, which I find really interesting. It goes on and tells you when your order will be ready, and keeps reminding you, ‘I’m just a piece of software; if you need to talk to a person, go over here; you can talk to a person’, and straight away, your interaction with the company is nicer, is better, because of personality. So, putting personality into objects, into inanimate things, changes how we interact with those things. We can make them more like people.

Now, the Sirius Cybernetic Corporation, which defines a robot as ‘your plastic pal who’s fun to be with’ are experimenting with putting Genuine People Personalities into objects. Here’s an example of an object, in this case, Marvin the Paranoid Android, and his personality:

Marvin: All right, what do you want me to do?

Trillian: Go down to number 3 entry bay and bring the two aliens up here under surveillance.

Marvin: Just that?

Trillian: Yes.

Marvin: I won’t enjoy it.

Zaphod: She’s not asking you to enjoy it. Just do it, will you?

Marvin: All right, I’ll do it…

Zaphod: Good. Great. Thank you….

Marvin: I’m not getting you down at all, am I?

Trillian: No, no, Marvin. That’s just fine, really.

Marvin: I wouldn’t like to think I was getting you down.

Trillian: No…don’t you worry about that. You just act as comes naturally and everything’ll be fine.

Marvin: You’re sure you don’t mind?

Zaphod: No, no, it’s all just part of life.

Marvin: Life. Don’t talk to me about life….

Trillian: I don’t think I can stand that robot much longer, Zaphod.

It’s got a personality, but a very different personality from the Little Moo piece of software. But I like the fact that the personality is kind of belligerent. Aarron will be talking later about putting personality into your products, but a lot of people put very friendly personalities into their products. I’d actually quite like to see some pretty belligerent personalities every now and again on the web, it’d be kind of nice, like ‘Forgotten your password? …Idiot!’ Not everywhere, but sometimes, it would make sense.

On the web you get to have very customised interactions; it’s much harder to do in real life with physical objects but I have found an example of a physical object that has a personality. Eric mentioned I live in Brighton, and there’s this pub in Brighton called The Earth and Stars, and it has a chalkboard outside, and this chalkboard is updated. Usually a pub chalkboard would say, ‘come inside, we’ve got cheap beer, we’ve got good food’, but this chalkboard just has… it’s got a personality.

So I put together a photoset on Flickr called Existentialist Chalkboard where I’ve collected some of the stuff, like:

Why does everyone always look at me? I know I’m a chalkboard and that’s my job. I wish people would ask before staring at me. Sometimes I don’t have anything to say.

Or:

I’m the unluckiest chalkboard in Brighton. Summer’s coming and this side of the building is always in the shade. Please come inside and tell them to move me to the western wall.

You respond differently to it.

Stop looking at me like I’m a waste of space. I’m not just a chalkboard you know, I’m also a supporting wall. I provide shelter from wild beasts and tropical storms. Go inside so I don’t have to see you.

So every time I’d walk past this chalkboard on the way into work, if the chalkboard had been updated, I’d take a picture and I’d post it to Flickr and add it to the set, because this is a really nice example of a personality in a product. And so one day I’m walking past the chalkboard and I see it’s been updated, so I take out my camera and take the picture and I actually start reading what’s written there, and it says:

Call me paranoid but I’m sure someone’s watching me. Some are even taking pictures. I’m not sure of my rights as a chalkboard but I feel violated. I’ll be watching you, Mr Keith!

Ooh, the chalkboard’s talking to me! I was through the looking glass at this point. I was… it was a very strange experience. I mean, we customise these kind of interactions on the web because it’s digital; it’s very odd to have it happen in real life like that.

But I do have an example of a physical object that you can interact with. Very web-like in a way. And that’s a book. In particular, it’s this book, The Warlock of Firetop Mountain, which was the first “choose your own adventure” book from Games Workshop in the UK. So what you have, it’s text, but the text is broken into chunks, uniquely identified chunks of text, and you can navigate from uniquely identified addressable chunk of text to another uniquely identified chunk of text by making a choice. So let’s give it a go, okay?

Here’s a piece of text identified as number 208:

Further up the passage, along the west wall, you see another door. You listen at it, but you hear nothing. If you want to try opening the door, turn to 397. If you want to continue northwards, turn to 363.

So do you want to open the door, or continue northwards?

Open the door….

That sounded unanimous to me. Okay, so I navigate to 397. Let’s see:

The door opens to reveal a small room with a stone floor and dirty walls. There is a stale smell in the air. In the centre of the room is a make-shift wooden table on which is standing a lit candle. Under the table is a small box. In the far corner of the room is a straw mattress. You may either open the box or leave the room.

Leave the room… Open the box…

Oh some people want to leave the room… we’ll open the box!

The box is light, but something rattles within. You open the lid and a small snake darts out to bite you.

Okay, so it’s a snake. Why did it have to be snakes?

So what we have here is hypertext. This is hypertext. It’s physical; it’s an analogue hypertext which means it is limited in size; there’s a limited number of uniquely addressable chunks of text, but this is hypertext. Pretty similar to the hypertext we use everyday on the World Wide web, except there, the constraint of physical size is removed completely, and that is awesome, where you’ve got the biggest “choose your own adventure” game in history, and work on it every single day. That is fantastic.

The web. Hypertext. Choose your own adventure. There are two main forms of interaction on the web, ways of accomplishing interactivity, and it roughly breaks down into links and forms. Roughly analogous to GET requests and POST requests. So let’s look at both of those.

Links

First, links: hypertext. The A element. The most simple but yet the most powerful element in HTML.

We don’t really use links that well. In my opinion, we still treat the web a lot like text rather than hypertext, which is a bit of a shame. Some people get this right, like Wikipedia. I love Wikipedia. Who loves Wikipedia? We all love Wikipedia. It’s the most amazing creation. I mean the idea behind it is amazing and if you told people, I’m going to build this encyclopaedia that anybody can edit …sounds crazy; it’ll never work, but it worked and it’s amazing. Disruptive in the true sense of the word. What I also like about Wikipedia is that it is properly hypertext; the way it uses links is that the text itself has links in it.

Imagine if you were to take away all the regular text and only left the hyperlinks on Wikipedia, you could still get the gist, right? Every single link there is like a wormhole to another part of this “choose your own adventure” game that we’re playing every day on the web. I love that. I love the way that Wikipedia uses links. And it’s kind of the exception.

Let’s take a look at a news site, this is the BBC website. I’m not picking on the BBC, it’s just an example of a news story on the web. It’s done pretty much like a piece of text from a newspaper just put on the web. If you were to take away the textual parts and just leave the hypertext, in this case all that’s left is global navigation stuff, ancillary stuff. The actual meat and bones wasn’t hypertext, it was plain old text, and I find that …I find that’s a shame. I think we haven’t really got to grips with the web as a hyper-textual rather than simply a textual medium.

Now the obvious way you interact with a link is, you click on it, right? You just mouse over it, you click on it, that’s it, that’s the interaction. There are some other subtle interactions associated with that action of clicking, and that’s what Dan was talking about yesterday: that mousing over the link—which we can do with CSS hover pseudo-classes—is also a form of interaction. We can change the state based on that interaction by the user. And as both Dan and Luke mentioned yesterday, it can be abused in horrible ways.

Luke quite rightly pointed out that hovering over something is not an intent. You hover over it …you have to be hovering over something anyway, no matter what you’re doing on the screen. It does not mean you want to trigger an action, and yet we’ve used and abused hover in this way. The worst examples being those drop-down menus, right?

So here’s an example from a school website. If you mouse over one of the links, then you get …it’s like playing the game of Operation or something, because you’ve got to …if your cursor leaves the menu for a second, it’s like …oh, back to the start. This is a particularly egregious example. It’s horrible …and they’ll say “oh no, but we’re just doing what they do on the desktop.” No you’re not. On the desktop, you’d click to reveal the menu, and then they appear on mouseover. Just appearing on mouseover? You’re doing it wrong. Also, this is important information that’s being hidden. Anyway, Luke covered all that.

And it’s not just sites like these. Actually, where Luke used to work. Yahoo.com did a redesign last year, and see all those things down the side? When you hovered over one of those things, this would happen …this great big mega-thing would drop out. It was frightening, I tell you. It didn’t last long. They actually replaced that interaction with a really small fly-out thing that you then click to reveal the data there, which is great.

And you know what the worst example of this hover abuse is? Does anyone remember Snap Preview? Where like …yeah …piece of shit. Every time you hovered over a link it would pop up a window showing you what the web page looked like behind it. Like here’s a link, but the link is an image, and it links to a larger version of the image. So when I hover over the image, I get a preview of the image. It’s …I hate it.

And as Luke pointed out, the thing that’s becoming apparent now with hover abuse is that there are devices where you basically can’t do it. How do you do hover on an iPad, on an iPhone, an iPod Touch? So don’t interpret hover, mouseover, as an intentional act. Don’t hide important data behind it.

That said …that said, as Dan pointed out, you can use hover to do some nice effects. Nothing vital, not hidden information, but some nice effects for the experience. I’ll show you an example of that on a site I built.

This is a site I built, according to Jared’s different sort of design schools, this would definitely be self-design, in that this was something I built to scratch my own itch. I needed a site for bookmarking audio and creating a podcast, so I built this for myself. It turns out, other people use it, which is great. Has anybody seen this site? It’s Huffduffer.com?

Oh, cool, a few people …oh that’s awesome, that’s great.

So I was building this site, and as so often is the case, there’s a logo and the logo links back to the home page. So what I did was I added a hover effect that when you hover over the logo, you get this little manicule pointing back to the home page. But it’s not important. It’s like one of those effects that Dan was showing in his talk. It’s a nice little effect. If it weren’t there, that would be fine; you wouldn’t miss it.

Now this is an interesting page I’ve got up here, actually, because it’s a tag page, but you’ll notice the tag has a specific format. Book:author=Jeffrey Zeldman. This is what’s known as a machine tag. Is anybody familiar with machine tags? Okay, it’s something that Flickr started where you could tag things on Flickr with LastFM IDs or Upcoming IDs, and they all have this format. Something:something else = something specific. It’s very much like triples in the RDF world.

I was thinking about how do I show a tag cloud for machine tags. I didn’t want to show it like a regular tag cloud. I came up with this representation, where you’ve got something, then the something else, then the something specific done in your regular tag cloud, so you know, book, author, Jeffrey Zeldman is in there; this is a tag cloud specifically for machine tags. I saw a nice opportunity to use a hover effect here, which was that when you hover over the something specific, that it also highlights the other two portions of the machine tag, right? Book:author=Jeffrey Zeldman, and this is fairly straightforward.

This is a table. I’ve got a table header, and then I’ve got the table row with the table cell with all the tags in it. With a few little CSS rules, whenever the table itself was being hovered over, I want to highlight the link in the thead. Whenever the table row was being hovered over, I want to highlight the link there, and whenever the link itself was being hovered over, highlight that. So what’s happening here is all three declarations here are true at the same time. When you hover over that link, any of these links in the tag cloud, all three declarations are true.

It’s a nice little effect. One thing I should point out also; whenever you’re doing hover, you always add focus as well. What I tend to do is I do a search for the number of instances of this string :hover in my CSS file. I then do a search for the number of instances of :focus, and they should match. They should be the same. If they’re not, then you’ve missed out using :focus. And this is important for people who navigate with a keyboard as opposed to a mouse. So it is a nice little effect.

Now, as you well know, in certain older browsers from a certain company, you cannot apply hover pseudo-classes to anything other than a link, so those first two declarations at the top simply won’t apply in Internet Explorer 6, maybe 7, I don’t know exactly. I don’t know, and I don’t care, right? I’m not being callous, but it really doesn’t matter. It really doesn’t matter if they don’t get that nice effect. It’s nice to have: it’s not that important.

What’s interesting here is the way I’ve chosen to do this. I’ve done this with CSS with a pseudo-class, and yet this is a state change triggered by an event, so it is behavioural; why didn’t I use JavaScript?

Well it used to be this would have been done with JavaScript. We used to use mouseover. The mouseover event to trigger things like navigation, image swapping, stuff like that. It was one of the most common uses of JavaScript when JavaScript was first introduced. Form validation and mouseovers for navigation.

It was so common that it ended up getting moved from JavaScript into CSS, it was just such a popular pattern, and this is a pattern you will see over and over in the history of the web. You’ve got something that began life in a procedural language like JavaScript, moves to CSS, and the pattern is something moving from something procedural to something declarative. To do something in JavaScript is automatically going to be a bit more of a learning curve, because it’s a programming language. It’s not like markup, it’s not like CSS which is declarative. The learning curve is always going to be higher with something like that. But when a pattern is common enough, it’ll get moved from the more difficult procedural language into a declarative language such as HTML and CSS.

We saw yesterday there were things like animations and transforms now showing up in CSS. Is CSS the right place for that stuff? I don’t know. Probably not really. But, is a declarative language the right place for that stuff? Definitely, if it’s popular. If a pattern is popular enough, it needs to be in a declarative language, whether or not that declarative language is CSS, that could be debated. But you see what happens here? A really popular pattern moving from something kind of tricky to do, to being something easier to do. And we’ll see that with some other things too.

Forms

The other form of interactivity on the web, apart from Links, is forms. A little more complex. Forms in general, not just on the web. Forms suck, right? Nobody likes Forms. You think about when you have to fill out a form; your taxes, or going to the DMV or some place like that. Nobody ever gets a form and thinks “Oh goody, a form to fill out! Oh boy, goody-gumdrops!”

When I would visit your country in the past, I would have to fill out a form. This is the form here. A whole bunch of form fields, not much fun to fill out, especially not on an airplane that’s moving around. They’ve moved the system online, and they have literally taken the form from the offline world, and put it online, and this is the way most forms on the web are done. You take what already exists in the real world and you slap it online, and they’ve done it, literally, it’s a long, boring form offline, and it’s a long, boring form online. Oh, and what they have added, is three buttons down the bottom here, right? Cancel, Reset and Next. I know. Who does that? Like you’ve got one button that you’d actually want to press, and it’s equally prominent as the others. It’s horrible. Forms suck, OK, nobody likes to fill out forms and that’s important to realise.

When I was building Huffduffer, I had to have a form for people signing up, and I thought, “how can I make this form suck less?” I thought about introducing some personality, so I used CSS. This is just a regular form. Under the hood, this is a form element with input elements and label elements. But I’ve used CSS to style it differently, to make it a bit more appealing, because if I’ve learned anything from Eric Meyer, it’s that you can use CSS to bend any content to look like anything you want. That’s the great power of CSS. There’s nothing that says a form field needs to look inherently like a form field from offline, so I put this online, and actually it went down really well. People really, really liked this. They responded to it, kind of in the same way they respond to the Little Moo from moo.com. It’s got some personality in it.

Dan linked to this from Simble Bits, it was like, “Ooh, check out the cool Mad Libs form that Jeremy has done in Huffduffer.” I take it Mad Libs is a game you Americans play? Okay. I didn’t know this when Dan linked to it. What is this strange language that Dan is speaking? I thought it was some kind of street-speak: “Mad Libs on the form, Jeremy.” “Word up, homey, that’s great.”

So now I guess that term has stuck. Mad Libs forms seems to be the term for it, and you see it popping up elsewhere. This is the sign-up form for VaultPress. WordPress in the house?

All right. We’ve got some Automattic people there! So they shamelessly ripped off Huffduffer for this. I’m kidding! No, but it’s cute, you see this pattern, and it works. It’s nice. It’s nicer to fill out this form.

It has to be said, a lot of the appeal is the novelty. It’s the fact that it’s not like most forms on the web. If every form on the web was like this, that would not be a good thing. But Luke actually did some AB testing. Luke was working with a client, and he took a regular form, regularly styled form, changed it to the Mad Libs form, and ran tests on it, and I think they got like 35 to 40 per cent conversion increase from doing that.

But like I said: don’t go out and change all your forms to this style, because I don’t think that’s suitable for all forms. When I’m logging into my bank or doing a transaction with my bank, I don’t want to be filling out a Mad Libs style form. There are appropriate uses for this.

So the interactivity with a form is you fill in the fields, and off you go.

Now there’s two places where we can enhance the interactivity with forms, and one is form validation, and the other is the presentation of the UI elements of the forms themselves.

I mentioned that one of the earliest uses of JavaScript was mouseovers for navigation, image rollovers. The other really common use for JavaScript back in the early days was very much form validation, and it still is today; it’s one of the most common uses of JavaScript is form validation.

What we see once again is because it was such a popular pattern, it’s being moved from a procedural language, JavaScript, into a declarative language, except the difference is this time it’s not going from JavaScript to CSS; we’re seeing it move from JavaScript to HTML now, into the markup.

HTML5 contains a number of new input types that essentially are doing what we already do with JavaScript, what we already hack together with jQuery will now be native in the browser.

There’s a whole bunch of input types in HTML5: number, search, range, email, and they can have different UI elements attached to them. So for an input type=date, you can have a calendar widget pop up, as we are used to. We can do that today using JavaScript and CSS and HTML, but it’s a lot of work. Or it’s a big download from a plug-in for jQuery. And then you have to think about all the edge cases and you have to think, “is it keyboard accessible?” All the things you have to worry about whenever you create a UI element will be abstracted away when that UI element is generated by the browser. Moving that pattern even further down the stack into the browser is a very good move from HTML5.

That does not mean that JavaScript will no longer be needed. Even when we take these really common patterns and we encode them into a declarative language such as CSS or HTML, there are still going to be uses for JavaScript for adding behavioural interactions on the web. You’ll start seeing common patterns there, which I think will also get abstracted away into a declarative language. You start to spot these patterns from project to project.

Pattern recognition

One of the patterns I keep seeing over and over again is this pattern of progressive disclosure, where something is hidden by default, and on click—not mouseover, on click—content is revealed. Some examples that I’ve come across when I’ve been building websites:

• On the Clearleft website, there’s a link to Contact Us: you click it and it reveals a form.
• On another site, this is Frequently Asked Questions. By default, the questions are visible but the answers are hidden; you click on a question and that will reveal the answer.
• Or here’s another one. This is quite common on sort of social networking site there’s a log-in link up in the top corner. You click on the link and it reveals a form.

Three very different looking situations, different use cases: it’s the same pattern every time. You’ve some chunk of markup that’s hidden by default, and it’s triggered by a link.

I’m going to briefly delve into some code to show you—well, pseudo-code—to show you how this pattern is solved when I come across it.

In my markup, what I have is an A element with an href, and it is a valid address in the href, namely, it is pointing to a fragment identifier which is the ID of a piece of content elsewhere on the page. If you ever find yourself writing A href = octothorpe, hash, pound, whatever you say over here, then you’re doing something wrong. An href always should contain a proper address. Now here, it’s not a full URL, it is a fragment identifier of a URL, but that is an addressable piece of content, and you can see elsewhere in the page, I would have ID = login.

It’s worth noting, I don’t use IDs for styling. I’ve pretty much stopped styling IDs completely. I just use classes and specificity, and it’s a whole another debate to get into, but I do still use IDs for making things addressable because that’s what they’re there for.

So this particular type of link is a certain class of link, in that it toggles the display, so I’ve added this class of toggler. And then in my CSS, I say, well, display that login…I say display none. Problem would be, if I just do this and someone doesn’t have JavaScript, there’s a piece of content that’s been hidden, they can’t get to that piece of content. So you’ll see that the selector’s actually a bit longer than that. I’ve got this class selector before the ID selector; the class selector in this case it says, hasJS. Well that class has been applied using JavaScript—in this case it’s jQuery—and what I’ve done is I’ve applied a class of hasJS to the body, and that means in my CSS, as long as I begin all of my declarations with hasJS, I know that those rules will only be applied if JavaScript is available.

If you do nothing else with doing this interaction between CSS and JavaScript, something like this, I mean it doesn’t matter what you call this class or how you do it, but it’s a really nice way to be able to apply styles, confident that you’re applying styles only when JavaScript is enabled.

So this display:none rule will only get applied if JavaScript is enabled, and that piece of JavaScript has run. And in the actual JavaScript to do the clicking functionality is just: when any of these links with a class of toggler are clicked, I want you to toggle the display of the element; that’s it. And that applies to all those instances; the content form being revealed, Frequently Asked Questions, the login form. The CSS would change, whether it’s absolutely positioned or where it is in the page, but the JavaScript is the same pattern, the same pattern over and over again.

What happens is, if JavaScript weren’t enabled—and there are plenty of people without JavaScript enabled; there are plenty of user agents that don’t have JavaScript enabled—it still works. In the case of the login form, if you click on that link in the top corner to go to login, it would take you to the part of the page that has the login. With JavaScript turned off, this is visible. In this case, it’s at the bottom of the page, so clicking at the top of the page would take you elsewhere in the same document to that addressable piece of content.

This is important, to think about that situation. What if? What if JavaScript isn’t enabled. And that should be the default setting. You should begin by making a website that works without JavaScript enabled, and then you come in and add the behaviour on top of that, because what you’re doing then is you’re creating safe defaults, and defaults are really important.

Safe defaults

In the physical world, in object design and product design, it’s really, really important that objects have safe defaults. If you’re building an elevator and the electricity is taken away, you do not want the default behaviour to be to have the elevator drop, right? That’s an example, that would be a bad default behaviour, so you have safe defaults. And it’s the same on the web.

We are very, very fortunate that the front end stack is really geared towards this way of looking at things, as long as you’re using progressive enhancement, this will work fine, because we have these layers. Structure, presentation, behaviour. We’re all familiar with that. I will show you a demonstration of the separation of layers. I used to just have a slide that would have the words: structure, presentation, behaviour, but now I can illustrate it much better.

This is the upper back torso of my friend Lynn, and she has tattooed the front end stack onto her back, which I think is awesome. There’s structure, presentation and behaviour. This, ladies and gentlemen, is someone who really cares about web Standards!

We have safe defaults, as long as we’re using progressive enhancement. Begin with the structure of the HTML, add your presentation with CSS, then add your behaviour with JavaScript. And everybody’s on board with that. We’re all agreed, right? Yeah, progressive enhancement, woow, yeah, we love it.

And then Ajax comes along, and that idea gets thrown out the window. “Oh no, it’s a whole new paradigm now. We don’t need to be thinking about the JavaScript-off situation”, which is bollocks. I think progressive enhancement can be applied to Ajax. So confident am I that progressive enhancement can be applied to Ajax, that I have even coined my own stupid buzzword for the technique of applying progressive enhancement to Ajax, which I call Hijax.

Here’s how Hijax works. You want to build a website that uses Ajax. Step 1: build a website that doesn’t use Ajax. In other words, you build a website that uses the fundamental units of interactivity on the web, and as we saw, those fundamental units are links and forms. So you make sure everything is working with links and forms. Clicking on links, filling in forms, pressing buttons. That’s the fundamental unit of interactivity.

Then, and only then, do you go in and add the Ajax interactions. What you do is, every time someone clicks on a link or fills in a form field or submits a form, an event is triggered in JavaScript, on click, on focus, on submit. And what you can do is capture that event, you can sort of hijack the event—see what I did there—hijack the event and say, “no, instead of going all the way back to the server, I’m going to take care of this in the browser”, and you do an Ajax interaction.

To clarify what Ajax means, Ajax is updating part of the page with something from the server without refreshing the whole page. Communicating with the server without refreshing the whole page. That’s a really unsexy definition of Ajax, but I think it’s accurate. The more common definition of Ajax is, “anything that uses JavaScript”. I have a problem with this definition in the same way I have a problem with the definition of HTML5 as “anything…”

So Ajax is very specifically communicating with the server without refreshing the whole page. And as long as you begin by making the regular interaction and add the Ajax on top, Hijax it, you’ll have safe defaults, and you’ll be fine.

I’ll show you an example from Huffduffer.

You can edit these chunks of content, and when I was building this, I built this with those edit buttons next to each chunk of content, and there was a link that took you to a form, a proper URL; you click on it, you go there, you fill in a form, you click Submit: it’s done. Then, and only then, did I go in and add the Ajax and say, “Okay, when someone clicks on that link, don’t go all the way back to the server and bring me a new page. I want you to just bring me this chunk of content.” So this is what it looks like. You click on the button, and it happens in place; right there it gets replaced with the form, you do what you need to do, you hit Update, and off you go.

But if you switched off JavaScript, it would still work. It wouldn’t be as nice, you’d have to go to a three-step process, but it would still work. The default state would be safe. That’s really, really important.

Feedback

You will have noticed that at the moment I clicked the link, or the moment that I hit that Submit button, there was an animation appeared; your classic loading animation. That’s important. That’s important that you give some kind of instantaneous feedback to the user.

The reason why we haven’t really had to do this in the past is that the browser always gook care of this for us. Every time you click on a link in a browser, the browser gives you immediate feedback that it’s now going to fetch that page. Every browser does it differently; in Internet Explorer it might be the spinning E; Netscape Navigator had the lighthouse sweeping around; Firefox does it differently, Safari does it differently. But the important thing is, the instant you click on a link, the browser gives you some feedback, so we’ve never had to worry about that problem. We’ve never had to think about providing feedback to the user the moment they click on a link or form. With Ajax, where basically what you’re saying is, “I’ll take care of this, don’t you worry your little head, browser, I’ll take care of this”, it is now up to you to provide instantaneous feedback. And feedback is important. It’s reassuring. It makes the interaction, if not pleasurable, at least it’s comforting to get this immediate feedback.

There are examples of bad feedback systems out there, not just on the web, but in real life.

Okay. Traffic lights. Traffic lights the world over work much the same. I’m standing on one side of the road, and my feedback mechanism is on the other side of the road. It may be green and red lights; it may be walk/don’t walk. It varies from place to place, but the same pattern. My trigger is next to me on this side of the road. I trigger my intent, not by hovering over it, but by pressing it, and then I watch for the feedback that tells me when it’s safe to cross. And, as I’m crossing the road, I still have that feedback. The light might start blinking to say, “yeah, you might wanna hurry along there”, but I’ve got constant feedback.

These are traffic lights that are showing up all over the UK like a virus, like a plague, like a pox upon the land. So here, what you have is you have your target right next to you, about waist high, and you also have your feedback mechanism right next to you, also about waist high. In this case, it’s red man, green man. Okay, so this is what it feels like to use that. You walk up to it, you trigger your intent by pressing the button, and now you have to watch the feedback mechanism, which isn’t on the other side of the street: it’s right next to you.

Okay, problem number 1, you feel like an idiot, because you’re standing there …waiting to go.

Problem number 2, as soon as there’s three people, you can’t even see whether it’s safe to cross the road.

But most importantly, once you do actually start crossing the road, you have no feedback. Is the car going to come? Is the light still green? It’s behind you. The feedback mechanism is behind you.

I’m not making this up. This is for real; this is out there in the world. It’s shameful. I mean, somebody calling themselves a designer actually came up with that. I can’t believe it. It’s really, really bad because of the feedback.

Now, feedback is hard. It’s hard to get the right level of feedback. Here’s an example of a real life product. In this case, it’s a car, that is giving some feedback to the user, who is Alan Partridge, but interpreting that feedback is proving difficult:

Alan: What is that noise? (bleeping)

Lynn: I wish I knew. It’s the inticator, isn’t it?

Alan: The inticator? The inticator?

Lynn: The indicator.

Alan: Indicator …inticator …indicator. It’s really annoying, isn’t it?

Lynn: Mmm, absolutely. I must phone them and check.

Alan: Don’t… Don’t phone them. It’d just make matters worse.I’m going to go down there and speak to them myself.

Lynn: How much petrol have we got in the tank? Is it the petrol? Where’s the petrol gauge?

Alan: Actually, no, but I am low on windscreen washer fluid.

Lynn: Well maybe it’s possibly that? It’s got nothing to do with the structure of the car

Alan: No, the alarm…they wouldn’t set off an alarm because you were low on windscreen washer fluid. It’s far too …alarmist. There’d just be a light would come on, say, you’re a bit low. But not a big alarm like that. It’s just a panic measure. It’s like someone going OH MY GOD YOU’RE LOW ON WINDSCREEN WASHER FLUID. You don’t need to say that, you just say, you need a nudge. The car needs to say to you, effectively, say, “‘scuse me, I don’t want to distract you from your driving, but you might like to know the windscreen washer fluid is getting low” and they do that with a little light, which has come on, see it there, that one there.

Lynn: Yes, well the clock’s not right is it? That’s a possible…

Alan: You’re not going to get an alarm …the clock …the idea that …I’m sorry, Lynn, you know, I’m normally patient, but the idea that an alarm would be triggered because the clock isn’t right, is …is cloud-cuckoo land. Alice in Wonderland. That’s not going to happen.

I mean he has a point, that you don’t want to distract the user if what you’re trying to get across is a little bit of information, but you don’t want to interrupt them. You don’t want to pop up a big alert dialogue saying, “here’s what’s happening!”

On Huffduffer, I had an interaction using Ajax, and I needed to give feedback to say the interaction was done. But I didn’t want to be too alarmist, I didn’t want, “Oh my God, the interaction has finished!”

So I was thinking about how to tell the user that something’s happened without distracting them from their task, and I thought beyond the web. I thought about places that provide feedback mechanisms on screens, and I thought of video games.

So we all know SuperMario, right? And if you think about when you’re collecting coins in SuperMario, it doesn’t stop the game and pop up an alert dialogue and say, “You have just collected ten points, OK, Cancel”, right? It just does it. It does it in the background, but it does provide you with a feedback mechanism.

Right, see that? The numbers do that—and that’s going to be stuck in your head all day now, by the way. It provides a feedback mechanism without interrupting the user. You can see 100 points, 10 points, whatever it was.

In the case of Huffduffer, I’ve got this situation where there’s people on the site, and you can add them to your network or remove them from your network, just using those buttons on the side, plus and minus. I wanted to provide some feedback that the interaction was taking place, but I didn’t want to interrupt the user’s flow because they might want to add a whole bunch of people, remove a whole bunch of people. So I just took that interaction from the world of video games. So you get that nice little bit of feedback. Which works really well, actually. It’s kind of familiar and it’s quite pleasant.

Actually, I had people telling me that they were adding and removing people just to get that effect. We are rats in a laboratory sometimes, right? Someone needs to tell them, you’re not going to level up in Huffduffer, no matter how many times you press that button.

But it’s important to note here that what I was doing was, I took some inspiration from the video games. I wasn’t trying to emulate a video game; I wasn’t trying to create a video game in Huffduffer, but I saw an interaction that was good and I got inspiration from it. But inspiration is not the same as emulation.

So another place where I took inspiration was from the desktop, which was: when you’re logging in and you need to give your username and password. Well, on the Mac OS—and I believe Windows has something similar too—when you’re logging in, you’ve got this option to show password, if you want to have it there. I basically took that interaction and applied it to Huffduffer, where you get the same option, a little check-box that says, ‘show password’ and it swaps it from being a password field to being a regular text field.

But I didn’t make it look like the OS X logging into a WiFi network interface; I was just taking some inspiration. What I was not doing was emulation. There’s far too much emulation going on, on the web, particularly from the desktop world, where people are just trying to copy what you can do on a desktop. The worst offenders being the so-called Rich Internet Applications, which seems to be code for just trying to make it as much like the desktop as possible.

I don’t get it. Why would we want to take this fantastic interconnected web of hypertext documents, and take away all the things that are good about it, and make it feel more like sitting at your computer, alone, interacting with one programme. This is what Rich Internet Applications try and do.

I also hate this term, Rich Internet Applications, because this idea of something being rich …that’s not rich to me.

You don’t just see it on the web. You see the same kind of thing …you think about the world of gaming consoles, and the way that the Playstation and the X-Box were coming at this issue was, well we’re going to make the rich experience by increasing the number of polygons, increasing the number of pixels, making the game play faster, right?

If you see the advertising for these things, it’s always, ‘actual gameplay footage.’ Then the Wii comes along, and it’s got fairly crappy graphics, but the experience, the experience of using it is awesome, because it turns out that waving your hand around like it’s a tennis racquet, is way more of a richer experience than something with millions of polygons and pixels.

You see this in other places too. The movie industry would have us believe that to have a rich experience in a cinema, you have to wear 3D glasses. I call shenanigans. I cannot imagine that Casablanca would be in any way improved by being in 3D.

This word “rich”, I do not think it means what you think it means.

Or trying to create this idea of a virtual world. So yes, on the internet, we have no boundaries of space; it’s like the biggest “choose your own adventure” book there is, but we’re not bounded by the physical dimensions of the book. We can create worlds. Yet when people try to create worlds, what do they do? They imitate the actual world, and this is what Second Life does. It’s all about the polygons, it’s all about the immersiveness.

Now don’t get me wrong; I actually think Second Life is a really interesting piece of work and that you can do some interesting prototyping in Second Life, but I think it’s fundamentally flawed to just try and replicate the real world in a virtual world, because it misses what makes things online so special. That’s not what a rich experience is like.

I’ll tell you what’s a rich experience for me, is using Twitter. I find Twitter to be immensely enriching. It’s not a graphically rich website. It’s not even a textually rich website. 140 characters or fewer. That’s quite a constraint, it’s quite a limitation. And yet, the feeling I get—I get up in the morning, and I open up Twitter—it’s the closest feeling I’ve ever got to jacking into the matrix. Nothing to do with polygons and pixels; it’s the experience of connecting. The interactions, of seeing what my friends are up to, and experiencing it. No pixels, no graphics can ever replace that.

Saw a guy bike past me wearing an A List Apart t-shirt. Almost yelled out before realizing that would be, well, weird.

— Ethan Marcotte (@beep) August 30, 2009

Saw Cameron Diaz on her way to the gym. I was wearing the shirt I’d slept in, walking my dog, holding a bag of shit.

— Jeffrey Zeldman (@zeldman) August 24, 2007

Interactivity

What’s important here, what this has tapped into to create this rich experience, is interactivity. I don’t mean interactivity in the sense of mouseovers and hovers and all that. I mean people interacting with people. Just as we have been doing since the dawn of time. That’s what makes the web amazing, is that it allows us to do that with the space constraints taken away.

People talk about the web as this game change; it heralds a new paradigm, a new world. I actually think it’s the other way around and what the web does is brings us back to what it used to be like when we would sit around the fire and tell stories and interact with one another.

Now that changed briefly. If you look at the history of the human race, there was a blip for the period of approximately the twentieth century, where interaction changed from being this interaction between people to being a producer and consumer-type interaction. The record industry and the film industry would try and have you believe that that is the norm, but that is the exception, if you look at the history of mankind. What the web has done, it’s managed to bring us back to being able to connect to one another. It’s the biggest campfire in the world; we can all sit around, I can connect with anyone.

This idea that the web is bringing us back to what interaction really is, that was an idea that was beautifully encapsulated at the end of the twentieth century—at the end of this blip in the history of mankind—and it was encapsulated by Douglas Adams. He was writing an essay in 1999 and he described this idea of interactivity and interaction on the web thusly. He said:

The reason we suddenly need such a word, interactivity, is that during this century, we have for the first time been dominated by non-interactive forms of entertainment cinema, radio, recorded music and television. Before they came along all entertainment was interactive: theatre, music, sport. We didn’t need a special word for interactivity in the same way that we don’t (yet) need a special word for people with only one head.

I think there’s something to that; that what the web is doing is not actually heralding something brand new, but is bringing us back to the interactions that we were evolved to do, and what we do when we make websites is we allow that kind of interaction to happen. We are contributing to that wonderful global network of hypertext documents.

That’s what you do. When you make websites, you are contributing to the most amazing experiment in interactivity in the history of mankind, and for that, I thank you.

Licence

This presentation is licenced under a Creative Commons attribution licence. You are free to:

Share

Copy, distribute and transmit this presentation.

Remix

Adapt the presentation.

Under the following conditions:

Attribution

You must attribute the presentation to Jeremy Keith.

Jeremy Keith: Paranormal Interactivity on Vimeo

This is the talk I gave at An Event Apart through 2010. It’s all about interaction design with some examples from Huffduffer.