Magic Torch

I was in the cinema when all the announcing was going on, but I’ve had a wee look just now.

The thing that struck me immediately is that the UI design has this deadly confidence about it. The Mail app, the Calendar, the whole thing. No hesitation, no glancing sideways at what other people are doing, certainly nothing left half-done.

You notice the same calmness and polish on the iPhone, but here it really gets a chance to stretch its legs.

Lovely.

I didn’t think I’d want one, but I really do.

Not been here in a while. I’m a classic short attention span creature. It’s genetic. I’ve had conversations about this.

But I’ve decided to attempt to adhere to a “once a day” discipline for a few things I should be doing more of. One of which is a bit writing. Specifically, writing here. The act being more important than the outcome.

So… today…

Oh yeah. I heard about and then listened to this, this afternoon (I can totally multi-task. Don’t worry). It’s a short and snappy podcast called The Dev Show, hosted by Dan Benjamin and Jason Seifer, two fine developing and podcasting fellows, and covers topics from all over the Development spectrum, from UI and front-end scripting to CMS and Database voodoo. There were 3 or 4 items (and they rip through them pretty sharpish) that I personally found useful to know about.

Give it a go.

“Yeah, but your scientists were so preoccupied with whether or not they could, they didn’t stop to think if they should.”

So said Jeff Goldblum, wisest of all Jeffs (with the possible exception of Zeldman) to safari suit-crazed boffin Richard Attenborough in cinema’s “Jurassic Park”.

Jeff knew what he was talking about, too. We all remember the thing with Samuel L. Jackson’s arm, don’t we?

Jeff’s profundity with regard to meddling in Nature’s Ways has been on my mind for a couple of weeks now. But instead of DNA, I’ve been humming and hawing about jQuery.

jQuery has become our go-to JavaScript framework foundation for the scripting we do here at Equator. And we do a fair amount. Nothing like a Google Docs or anything, but we can bring it when required. And it’s great to have jQuery for the heavy lifting. However…

Back to Jeff.

While Dickie was spluttering into his Chilean Sea Bass, Jeff followed up with some extra ‘blum-zen:

“I’ll tell you the problem with the scientific power that you’re using here: it didn’t require any discipline to attain it.”

Are you beginning to see the connection?

Yeah, okay, we’re talking a JavaScript library here, and not Velociraptors in your kitchen, but I think Jeff would recognise what is going on.

jQuery requires very little discipline to produce startling effects. And while that is great for deadlines, I can’t help thinking that proper design thought is being short-circuited a bit. At least with one particular jQuery-enabled bit of magic: the Show/Hide widget, whereby clicking a button shows or hides a bit of content via a smooth half-secondish transition.

It’s very nice. Much less jarring than instantly disappearing or appearing the content and it looks snazzy (there’s a lot to be said for a bit of snazzy). With traditional JavaScript you’d be looking at a fair bit of work to realise it. With jQuery it literally takes a few minutes. There is a one function call (slideToggle) in jQuery that automatically controls the animation in either direction.

What was once expensive is now essentially free. And so it starts getting used all over the place. It’s seductive as hell. Section of content getting a bit big? Stick a show/hide on it. Too many sections making the page a bit long? Stick show/hides on all of them. FAQ page? Do you really need to ask?

I’m beginning to think this is a real problem. I think we have become a bit too enamoured and let clients become far too enamoured of this little warlock’s trick we can do just-like-that.

Hiding things that are sort of in the way or don’t quite fit isn’t any kind of substitute for showing the correct things in the first place. It’s too easy, if the page is proving tricky to get right, to just hide the rough edges.

There’s also a hint of “we know what’s best for you with regard to this inter-net page” about it. If people consume the content in this particular way they will be fitter, healthier, more productive, etc.

It has reached an absurd degree in some particular cases I’ve seen recently (naming no names). Where there seems to be an actual fear of showing the user too much content. And by too much I’m not talking about one of the chunkier Harry Potters. I’m talking about anything that might force its way beneath the page fold (these still exist, apparently). Four or five hundred pixels’ worth of nicely-set copy.

So you end up with FAQ pages where every section and every question/answer within that section is subject to a show/hide widget. Even if the answer is two sentences. Even if the answer is shorter than the question. Seriously.

Why is scrolling such a nightmarish proposition, but clicking one of half a dozen or more non-standard controls to display content that may only be relevant once revealed is the future of the human-computer interface? Just because you’d like your user to grok your UI the way Lobot might, it isn’t going to make it so.

People had been navigating newspapers, magazines, books, parchments and… errrr… scrolls for thousands of years before the Internet turned up, but somehow putting it on a screen means that more than a couple of paragraphs and people are going to be jumping out of windows?

Really?

Come on. What would Jeff do?

In between doing actual work this afternoon, my brain was wrestling with the idea that clients could use Twitter as some kind of marketing channel (or not, or… something). There was a PDF floating, which purported to offer detailed insight into how to do this, and it was pretty funny stuff.

The amount of effort that was required to interface Twitter with a coherent corporate marketing message was scarily large (“Have two people reponsible for posting, so one of them can always be “on call” to deal with issues!”).

It made me wonder if Twitter, by its very nature, resists this kind of use.

I think it might mimic some specific way in which we, as humans, think. The little moments of existential sparkle when we notice stuff about what we are doing and how we are doing it. The honest or not-so-honest internal monologue. The Head fluff we all share, and thus can appreciate in others.

The best of it is instinctive and authentic and even in 140 characters it will often result in a large amount of insight or humour or experience. And if there is any marketing value to be had from that it isn’t something you can work out before you start. That human fluff is required as tinder or else you just get a damp and embarrassing squib. The value emerges in an unpredictable and second-hand kind of way. And it’s fluffy human value.

I’m not sure a direct corporate marketing message can replicate that.

I gave a talk at the end of April, as part of the Equator Academy lunchtime seminar series. Went pretty well, by all accounts. My own memories are a bit vague. But a few technical and presentational lessons were learned, and it was definitely enjoyable (yes, really) once I got going. The more conversational Q&A at the end was something I could have done all afternoon.

It was a bit rapid-fire though, so I thought I’d put together a bit of extra info about the things I touched on.

First off, here are the slides that I used. There are a few more involved ones, but mostly I wanted sign-posts for the talk, rather than putting it all up there to read. I was definitely conscious of avoiding the turning-to-the-screen-and-just-reading-what-is-there syndrome.

Mostly worked.

Anway. Here’s some notes and links for stuff I found useful when I was putting the talk together.

The Front-End as Abstract Information

This more abstract perspective of the front-end is normally something that sits at the back of my head when I’m working. It’s good to periodically evaluate what I’m doing in these terms, to keep me right and help me plan what’s going where.

The Early Web

I had a look at the Internet Archive, which archives pages and sites going back to the mid ’90s, and went over some very early websites. It’s amazing to see this stuff and realise it is only ten, fifteen years old. It can be a little scary looking back at what was considered cutting edge, or at least acceptable enough back then. Especially the early iterations of big corporate sites. The impression you get is that no-one really had any idea what was about to happen.

Can’t help but make you think if the stuff we are producing today will be regarded in the same way a decade from now.

“Web 2.0? Aww, they really didn’t have a clue, did they?”

Tower Of Babel (to) Present Day

Here’s the article from A List Apart that I mentioned: To Hell With Bad Browsers. Today, supporting the latest browsers is the sexy, but 8 years ago making that choice must have been tricky and at odds with what everyone else was doing. Again, worth noting how much things have changed in a very short period.

Two other site I mentioned briefly were the Web Standards Project and the CSS Zen Garden:

The Web Standards Project did a lot of behind-the-scenes, non-sexy work in the early (and later) days of Standards awareness. Their site is still a good place to read about the basic reasons for embracing standards, as well as that historical perspective.

CSS Zen Garden started as a more design-focused attempt to encourage standards-based design and using CSS for presentation in particular. It has used the same markup since then, which contributors then transform by adding CSS and image to this.

And obviously, there is a ton of technical documentation at the W3C. The basic definitions of the technologies, but also a lot of learning material.

Modern Web Standards

I used Andy Rutledge’s Bullet List Only page to illustrate both how powerful CSS now is at laying out page and also that this power can often hide bad markup that could create issues in other situations, where the primary stylesheet isn’t being used. With standards both HTML and CSS can really do what they were designed for, and as a result both can step up a gear.

There’s a ton of stuff to read about where Web Standards are these days. Lots of newer topics too, as the ideas and insights have developed and multiplied. Here are a few more things to get started with:

How To Grok Web Standards – A great piece that explores the basic ideas of standards and semantics from different, non-webby perspectives.

Understanding Progressive Enhancement – Progressive enhancement takes the tools we have in Web Standards and think about using them more effectively, with a eye on both the present and the future. Definitely the way forward as the browser market gets more crowded and something we’ve embracing at Equator.

The project is approaching some kind of conclusion. 85% seems like a decent number. For it. Certainly not for the theoretical site that is still sitting amongst the pages of the various bits of project documentation. That has been replaced with something crunchier, trickier and yet more nutritious. 85% sounds decent and reassuring.

Things are still a bit rough round the edges, but also coming together. It starts feeling like a site, despite the placeholder content and the same image on 147 of the pages. The cracks are starting to close up. At least the ones I’m deciding to notice.

Unfortunately 85% means what’s left is all that stuff that I’ve forgotten about or overlooked or ignored. The unknown bits and pieces that’ll only start making noises once the site gets properly used by actual admins and users.

Bloody 15%.

Oh well.

I find the fact that the web is barely more than a dozen years old mind-bogglingly exciting. So much to figure out, try out, fail and succeed at. An extremely addictive mix of abstract concepting and carving logic and method directly out of plain-text. At least where I live in the process. It’s great. You get a real sense of putting the tracks down in front of you as you are barreling along.

At least when everyone involved gets it.

When they don’t, the newness and comparative strangeness of the medium (at least when compared to anything else, ever) doesn’t give you much of a foundation from which to mount a forceful and authoritative argument about how things need to work. Particularly when counter-arguments are being mounted from things like printed paper. Everyone groks paper, or at least they’ll have a good go at kidding themselves they do. It’s safe, barring the occasional cut. It doesn’t do much at all, except lie there and be looked at. Stupid, but comprehensible because of it. And it isn’t the only one. Film and video is possible more stupid.

The web, by comparison, isn’t stupid. It isn’t stupid in about a thousand different directions at once. And that makes it very hard to define. Maybe even impossible to define in terms that’ll line it up nicely with the old media.

I can kind of see why the way the world operates being taken over by this thing that no-one seems to fully understand, and which in 5-10 years is probably going to be unrecognisable, can be scary. And why the people hawking it might be intimidating and make you push things back to places you understand.

I can kind of see that. I can be sympathetic. Honest.

Most days.

Not today, though.

Today was full of people literally waving paper with comfortable and stupid things written on it. Things like “consistent brand colour” and “look at this, then look at this, now stop”.

But today is done. Next?

I spent the last couple of days of last week working on a new website, where we are taking a fully progressively enhanced approach to the user interface. It really did feel good to be working this way. Not having to worry about things like non-CSS drop shadows or corners freed up my head to more carefully consider other choices. Like laying out quite a bit of a busy header using absolute positioning. Not something I’d done before. But starting with markup that is just the way you want it makes you more inventive about keeping it that way.

The other thing I noticed is that the details still remained and demanded attention. I’m not sure I was expecting this. Buttons, clean and simple though they were, still needed to be teased into the correct vertical alignment. CSS still needed to anticipate a change in text-size that would start shifting elements out of their original positions. It was still as tricky as ever. IE6 was still a pain, although not, it turned out, as much as Firefox 2, which has quickly become a persona non grata around here, due to its lack of display:inline-block. Who’d have thought?

Anyway. The process was initially frustrating because I thought I should be making faster progress than I was, but it ended up being kind of a relief. It’s good to know that thought, consideration and creativity are still as necessary as ever. Just used more in the right places.

This article on northtemple says a lot of what I was trying to say in the previous post, except a lot better. And it hits the most important point, which I totally missed.

Accessibility starts with empathy. As just about everything in web design and development starts with empathy. If you have no empathy for your users, you are going to fail. You are particularly going to fail if, at the first sign of things getting tricky (“we need to think about accessibility”), you switch off your empathy for a user and reduce them to someone you can afford to have not use your site. Not least because it is never “a user”. It is the user you thought of and the literally tons of users, doing things almost the same way, who you have no idea about, because you really aren’t that clever.

Note: This entry was originally published on the mother-blog of EquatorLive. And when I say “originally”, I mean about 5 minutes before I put it up here.

Accessibility on the web has always had a bit of an image problem. Being sensible at the cost of interesting. You could be one or the other and most people went with interesting. And even when it was taken seriously, it was always presented in the same way as accessibility is presented in the real world: As an add-on that sat on top of the original and ruined its lines. If you didn’t want to compromise on your main site experience, you would have to go to the trouble of creating a “text-only” version that you could divert disabled people (because who else needs special access?) towards.

That was then. And in between then and now things have definitely improved, but the feeling remains. That in properly addressing accessibility you have to compromise the user experience.

“How to increase the text size on your browser!”

At Equator we take accessibility seriously. It’s something clients almost always ask for and something we deliver. We have the checklist and we tick all the boxes on it. Alt tags on images and other non-text media (at least most of the time). Well-ordered content, arranged by importance and priority on the page (almost always). Semantic, structural markup (apart from the markup that isn’t, but there really isn’t much of that). Good job, pat on the back.

I imagine this way of looking at accessibility isn’t too different from the way most other people (who care) think about it. It’s all about compliance. You’ve got to be compliant! It’s a pain, especially when you forget about it until the last minute (Yes, hands up who has been to that special place). But you do it, write the blurb for the accessibility policy page and maybe even put some kind of tick-based logo in the footer.

Meanwhile, in the 21st century

This attitude is missing the point entirely. Accessibility is not a checklist or a chore. It’s not washing your hands before you eat dinner. It’s a fundamental part of how you make the web work.

Accessibility is about letting as many people as possible experience as much of the web as possible. Even the useful and complicated parts. Especially the useful and complicated parts.

It’s simple: If you don’t consider accessibility as a fundamental part of your design and development process, you are making bad websites. Not just inaccessible websites. But straight-out crap websites.

Compromised websites, most importantly. Long gone are the days when the only way to build interesting websites, using tables to lay out and presentational markup to style content, was at odds with the principles of accessibility. We can do both now. We have to do both now.

The web is not novel anymore. It has matured at a tremendous speed and users no longer expect to be passive consumers of what it has to offer. It is a massive toolbox of stuff that helps them get things done. We’ve noticed it ourselves. We don’t really create websites anymore. We develop web applications. Hopefully for as many people as possible. If we leave out a group of users because it was too much bother or we forgot, then someone will take the time and take those users. A compromised website nowadays is one that isn’t accessible.

Everybody needs an accessible web

Today, the way to creating an accessible web experience is actually pretty straightforward: Get out of the way. If people have a need for web content to be presented in a certain format, they will generally handle that certain format themselves. What they need from you is content and functionality without any conflicting formatting from you.

This is where Web Standards comes into play in a big way, and also why accessibility is a fundamental effect of a well-built web experience, as well as an important feature.

Web Standards treat content, presentation and behaviour as separate pieces of an overall experience. Therefore, a user can pick and choose which of these elements they require and which they can replace with their own, custom versions. Such as converting text content to audio, instead of applying all that carefully crafted CSS to it.

You keep the content and presentation separate and you really don’t have to do much more to make it all accessible. It’s all about giving the user control. The trick is that if you understand how the web is meant to work, which is what the Standards are all about, that is exactly what you are doing.

Growing your own guidelines

It’s always a bit more complicated than that, of course, but luckily the experts at the WAI have done the hard work for you, in producing the guidelines for achieving good accessibility. Sort of.

At the beginning of the year, the working draft of version 2 of the guidelines was published after approximately a lot of years in development. And they were certainly different from version 1. The original guidelines focused on the technologies that the W3C set the standards for, HTML and CSS being the main ones. So there was a fairly well-defined list of things to tick to achieve a certain rating.

The new guidelines are bit more general purpose. They don’t deal in specific technologies, but are rather focused around a set of 4 principles. An accessible website or application, built using any technology, should be: Perceivable, Operable, Understandable and Robust.

How you achieve these principles is trickier to nail down. What you have to do, to some extent, is create your own set of guidelines based on the what you use and how you use it. There is plenty of content provided by the WAI, covering the kind of things that the 1.0 guidelines talked about, but it’s just a stepping off point. You need to understand and fill in the blanks yourself.

This is pretty daunting, but doing it will give you a deep understanding of how to create better solutions to complex accessibility problems, not just complying with a list that someone else cooked up.

Show me the money (or nearest equivalent)

This is all very interesting, I’m sure you’ll agree, but how about an example of how accessibility really matters in one of the most important ways people use the web. It’s to do with the web’s biggest user and the fact that they are disabled.

Picture a typical web user for whom accessibility is an issue. Of course, there isn’t a typical one, but try anyway. If you are like me you are maybe picturing somebody blind, using a screen reader to browse the web? The biggest user of the web isn’t too different from that stereotype. They are called Google and they really appreciate accessibility.

Google browses more sites and more content than any of us will ever find in our whole lives. It notices when it can understand a site because the content is presented in an accessible way and when it can’t because the content is dependent on JavaScript (which it doesn’t run) or lacks alternative descriptions for non-text media or is just badly organised. It has an opinion about this, too. This opinion affects where your site ends up in a Google search. And it’s only going to matter more in the future.

In the future there will be robots

Google is an extreme example of how the web is going to work more and more in the future: most of the actual surfing isn’t going to be done by people at all, but by software acting for people. There’s already too much content out there for us to deal with. We already need RSS-based aggregators and software agents to pull content to us in a form that we can digest more easily. We are all becoming, more and more, disabled users. Our disability is a lack of attention and time. The result will be simple. Accessible content and functionality will eventually be all we have time for.