A lovely bit of data celebration from Ravelry on the occasion of their 4 millionth user.
I’ve said it before and I’ll say it again: if you want to see a successful example of a real social networking site, don’t look at Facebook; look at Ravelry.
A lovely bit of data celebration from Ravelry on the occasion of their 4 millionth user.
I’ve said it before and I’ll say it again: if you want to see a successful example of a real social networking site, don’t look at Facebook; look at Ravelry.
The importance of long-term thinking in web design. I love this description of the web:
a truly fluid, chaotic design medium serving millions of imperfect clients
That attitude infuriates and depresses me. It seems to me that it demonstrates a fundamental mismatch between how that person views the job of web development and the way the web actually works.
It is entirely possible—nay, desirable—to use features long before they are supported in every browser. That’s how we move the web forward. If we waited until there was universal support for a feature before we used it, we’d still be using CSS 1.0 and HTML 2.0.
If you use a CSS feature that isn’t supported in a particular browser—like, say, an older version of Internet Explorer—that browser will simply ignore that CSS rule. So you don’t get that rounded corner, or text shadow, or whatever it was. Browsers have the same error-handling mechanism for HTML: if they see something they don’t understand, they just ignore it. The browser will not throw an error. The browser will not stop rendering the page. Browsers are very liberal in what they accept.
Anyway, my point is—and I can’t believe I still have to repeat this after all these years—websites do not need to look exactly the same in every browser.
“But my client!”, cries the Smashing Magazine commenter, “But my boss!”
If your client or boss expects that a website will look and behave the same in every browser on every device, then where did they get those expectations from? And rather than spending your time trying to meet those impossible expectations, I think your time would be better spent explaining why those expectations don’t match the reality of the web.
It’s like Mike Monteiro says about clients: if they just don’t get something about your design, that’s not their fault; it’s yours. Explaining your design work is part of your design work. It’s the same with web development. It’s our job to explain how the web works …and how the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.
That was true fourteen years ago when John Allsopp wrote A Dao Of Web Design, and it’s still true today. Back then, designers and developers were comparing the web to print and finding it wanting. These days, designers and developers are comparing the web to native and finding it wanting. In both cases, I feel like they’re missing the fundamental point of the web: you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.
Paul Kinlan published a post called This Is the Web Platform where he tabulates the current state of browser support for various features. “Pretty damning” he says:
the feature support that is ubiquitous across the web is actually pretty small especially if you are supporting IE8.
That’s true …from a certain point of view. But it depends on your definition of “support”. If your definition of “support” is “must look and work identically to the latest version of Chrome”, then yes, you’re going to have a smaller set of features you can use (you’re also going to live a miserable existence). But if your definition of “support” is “must be able to access the content and accomplish the task”, then as long as you’re using progressive enhancement, you can use all the features you want and support Internet Explorer 8, 7, 6, 5 …you can support every browser capable of connecting to the internet.
There is a difference between support and optimization.
I think part of the problem may be with the language we use. We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.
It’s a subtle Lakoffian thing, but when we talk about “the browser” as if it were a single entity we might be unconsiously reinforcing the expectation that there is one Platonic ideal of browser rendering and that’s what we’re designing for.
There’s another phrase that bothers me, and it’s the phrase that Paul used in the title of his article: “the web platform”. This is something I talked about back in November in my presentation The Power of Simplicity:
But this idea of the web as a platform, I get why from a marketing perspective, we’d want to use that phrase, because it puts the web on equal footing with genuine platforms.
I would say Flash is a platform, and native: iOS and Android and these things. They are platforms, in that it’s all one bundle. And the web isn’t like that.
What I mean is, if you use the Flash platform, then anyone with the Flash plug-in can get your content. It’s on or off. It’s one or zero; it’s binary. Either they have the platform or they don’t. Either they get all your content, or none of your content.
And it’s similar with native apps. If you’ve got the right phone, you can get my app. All of my app. You don’t get bits of my app, you get all my app. Or you get none of it because you don’t have that particular phone that I’m supporting.
And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.
The web is not a platform. It’s a continuum.
Great suggestions from Dave for podcasters keen on allowing easier sharing.
Oh, how I wish Soundcloud would do this and be less of an audio roach motel!
The Code for America project at Clearleft was fun for everyone involved. And because the code for the site is open to anyone to contribute to, the fun didn’t have to stop when the project officially wrapped up.
Because of her experience with front-end styleguides, we had hired Anna to work as a front-end developer on the Code for America project. But even when she was officially discharged of her duties, she decided to keep contributing to the public codebase.
For this service above and beyond the call of duty, Mike rewarded her in the time-honoured way: cake! In this case, the cake was inspired by the unofficial project theme song we blasted out every morning in the Clearleft HQ.
Mike writes about what it was like being a client for a change. After working with him on the Code for America project, I can personally vouch for him as a dream client:
Clearleft’s pattern deliverables are the special-special that made the final work so strong. Jon Aizlewood’s introduction to the concept convinced me to contact Clearleft. Jeremy Keith’s interest in design systems kicked off the process, and Anna Debenham’s fucking rock star delivery brought it all home.
Some good ideas on the idea of element-level media queries, a feature that developers are crying out for and browser makers are saying is too hard. This post has some thoughts on how to deal with the potential issues.
An interesting pattern for handling complex data tables in responsive designs. It’s a desktop-down approach, but pretty smart.
Great stuff from James Wragg and the gang at Madgex: a way of lazy-loading ads for responsive sites without messing with the ad code.
This may be the only slideshow on a website I’ve ever actually bothered to click all the way through.
This looks like a nifty take on the ol’ using-labels-like-placeholders pattern for forms. I still prefer to have a label visible at all times, but this seems like a nice compromise.
When Clearleft’s part in the project officially wrapped up, I wrote:
It’ll be a while yet before the new site rolls out.
That was exactly one month ago.
I’m impressed! That’s a pretty short timescale to rebuild a fairly large website, not only changing the front-end codebase, but also switching out the back-end stack as well. They must’ve been working flat out.
I’ve worked on projects in the past where my initial excitement at the project’s wrap diminished as the site launch date slipped further and further over the horizon of the future. It isn’t unusual to have a gap of many months between the end of Clearleft’s time on a project and seeing the site go live. I’m really happy that the Code for America project bucks that trend.
Nice! A Yeoman generator for scaffolding your own pattern primer.
(Those are just words, aren’t they? Y’know, as opposed to a sentence that would actually make sense to most right-thinking people.)
Thoughts from Luke Bacon on two topics that fascinate me: archives and design principles.
I’m back from Munich, where I spent three solid days workshopping with AutoScout24. I’m happy to report that it went really, really well. It’s restored my confidence after the negative feedback I got in Tel Aviv.
Three days is quite a long time to spend workshopping, so I was mostly winging it. But that extended period also allowed us to dive deep into specific issues and questions (all the usual suspects: how to handle navigation, images, complex interactions, etc.).
The real issues, however, were much more “bigger picture”—how to handle the transition to responsive of a big desktop-centric site that’s been growing for over a decade. By the end of the three days, we had divided the options into three groups:
There’s no doubt about it: trying to apply responsive design to large-scale existing desktop-centric sites is really, really hard. The message I keep repeating in my workshops is that you can’t expect to just sprinkle on some magic media-query fairydust—it just doesn’t work that way. Instead, you’ve got to figure out a way to reframe all your challenges into a mobile-first way of thinking.
Instead of asking “How can I make these patterns (mega-menus, lightboxes, complex data tables) work when the screen size shrinks?”, you need to ask “What’s the problem they’re supposed to be solving, and how would I design a solution for the small screen to start with?” Once you’ve done that, then it becomes a matter of scaling up to the large screen …which is actually a much simpler problem space.
As is so often the case with web design, it requires the application of progressive enhancement. In the case of responsive design, that means starting with small-screen styles, small-screen images, and small-screen content priority. Then you can progressively enhance with layout styles, larger images, and conditional loading of nice-to-have extra content. Oh, and you absolutely have to accept and embrace the fact that websites do not need to look the same in every browser.
Making that change in thinking can be hugely challenging.
Remember when we were all making websites with tables for layout? Then the web standards movement came along, pushing for the separation of structure and presenation, urging us to use CSS for layout. It took the brain-rewiring power of the CSS Zen Garden to really give people that “A-ha!” moment.
Mobile-first responsive design requires a similar rewiring of the brain. And if you’re used to doing things a certain way, then it’s natural to resist such drastic change—although as Elliot pointed out at the Responsive Day Out, when you first make the switch it might be very tricky, but it gets easier and easier with each project.
Still, it can be a difficult message to hear. I suspect that’s why my workshop in Tel Aviv wasn’t so warmly received—I didn’t provide any easy answers.
The designers and developers at AutoScout24 also didn’t find it easy to accept how much they’d have to rethink their approach, but by the end of the three days they had a much clearer idea of how they could go about making that change. I’m really curious to see where they’ll go from here. Personally, I’m very optimistic about their prospects for successfully pulling off a large-scale responsive relaunch.
There are two main reasons for my optimism:
I can’t emphasise enough how important that kind of collaborative environment is.
I’ve said it before, and I’ll say it again; the biggest challenges of responsive design are not technology problems.:
No, the biggest challenges, in my experience, are to do with people. Specifically, the way that people work together.
I’ve spoken to some companies who were eager to make the switch to responsive design, but who have designers and developers sitting in different rooms, or on different floors, or buildings, or even countries. That’s when my heart sinks. Trying to work in the iterative way that a good responsive project demands is going to be massively difficult—if not downright impossible—in that environment.
So I’m pretty confident that if the designers and developers at AutoScout24 put their minds to it, they can rise to the enormous challenge that lies ahead of them. They’ve got the right working environment, they’ve got a UI library, and they’ve got the option of using their exising mobile subdomain. Most of all, they’ve demonstrated a willingness to accept all the challenges that come with changing from a desktop-centric to a content-first mindset.
All in all, it was a very productive three days in Munich. It was hard work, but then again, I had the option of rewarding myself with some excellent Bavarian food and beer each evening.
But it wasn’t a holiday. Before I could go off exploring Tel Aviv and Jerusalem, I had work to do. I was one of the speakers at the UXI Studio event.
We arrived on Saturday, and I was giving a talk on Sunday evening. At first I thought that was a strange time for a series of talks, ‘till I realised that of course Sunday is just a regular work day like any other.
It was a lot of fun. I was the last of four speakers—all of whom were great—and the audience of about 200 people were really receptive and encouraging. I had fun. They had fun. Everything was just dandy.
Two days later, I gave a full-day workshop on responsive design. That was less than dandy.
I’ve run workshops like this quite a few times, and it has always gone really well, with lots of great discussions and reactions from attendees. The workshop is normally run with anywhere between ten and thirty people. This time, though, there were about 100 people.
Now, I knew in advance that there would be this many people, so I knew I wouldn’t be able to get as hands-on as I’d normally do; going from group to group, chatting and offering advice—it would simply take too long to that. So I still ran the exercises I’d normally do, but there was a lot more of me talking and answering questions.
I thought that was working out quite well—there were plenty of questions, and I was more than happy to answer as many as I could. In retrospect though, it may have been the same few people asking multiple questions. That might not have been the best experience for the people staying quiet.
Sure enough, when the feedback surveys came back, there were some scathing remarks. Now, to be fair, only 31 of the 100 attendees filled out the feedback form at all, and of those, 15 left specific remarks, some of which were quite positive. So I could theoretically reassure myself that only 10% of the attendees had a bad time, but I’m going to assume it was a fairly representative sample.
I could try to blame the failure of my workshop on the sheer size of it, but I did a variation of the same workshop for about the same number of attendees at UX Week last year, and that went pretty great. So I’m not sure exactly what went wrong this time. Maybe I wasn’t communicating as clearly as I hoped, or maybe the attendees had very different expectations about what the workshop would be about. Or maybe it just works better as a half-day workshop (like at UX Week and UX London) than a full day.
Anyway, I’m going to take it as a learning experience. I think from now on, I’m going to keep workshop numbers to a managable level: I think around thirty attendees is a reasonable limit.
I’m about to head over to Munich for three solid days of workshopping and front-end consulting at a fairly large company. Initially there was talk of having about 100 people at the workshop, but given my recent experience in Tel Aviv, I baulked at that. So instead, the compromise we reached was that I’d give a talk to 100 people tomorrow morning, but that the afternoon’s workshop would be limited to about 30 people. Then there’ll be two days of hacking with an even smaller number.
This won’t be the first time I’ve done three solid days of intensive workshopping, but last time I was doing it together with Aaron:
This time I’m on my own. Wish me luck!
Some great thoughts in here about web development workflow and communication between designers and developers.
I believe that the solution is made up of a variety of tools that encourage conversation and improve our shared lexicon. Tools such as styleguides, pattern libraries, elemental and modular systems that encourage access not only by developers, but by designers, shareholders and editors as well.
When I finally unveiled the redesigned and overhauled version of The Session at the end of 2012, it was the culmination of a lot of late nights and weekends. It was also a really great learning experience, one that I subsequently drew on to inform my An Event Apart presentation, The Long Web.
As part of that presentation, I give a little backstory on the ABC format. It’s a way of notating music using nothing more than ASCII text. It begins with some JSON-like metadata about the tune—its title, time signature, and key—followed by the notes of the tune itself—uppercase and lowercase letters denote different octaves, and numbers can be used to denote length:
X: 1 T: Cooley's R: reel M: 4/4 L: 1/8 K: Edor |:D2|EBBA B2 EB|B2 AB dBAG|FDAD BDAD|FDAD dAFD| EBBA B2 EB|B2 AB defg|afec dBAF|DEFD E2:| |:gf|eB B2 efge|eB B2 gedB|A2 FA DAFA|A2 FA defg| eB B2 eBgB|eB B2 defg|afec dBAF|DEFD E2:|
ABC notation dates back to the early nineties, a time of very limited bandwidth. Exchanging audio files or even images would have been prohibitively expensive. Having software installed on your machine that could convert ABC into sheet music or audio meant that people could share and exchange tunes through email, BBS, or even the then-fledgling World Wide Web.
In today’s world of relatively fast connections, ABC’s usefulness might seemed lessened. But in fact, it’s just as popular as it ever was. People have become used to writing (and even sight-reading) the format, and it has all the resilience that comes with being a text format; easily editable, and human-readable. It’s still the format that people use to submit new tune settings to The Session.
A little while back, I came upon another advantage of the ABC format, one that I had never previously thought of…
The Session has a wide range of users, of all ages, from all over the world, from all walks of life, using all sorts of browsers. I do my best to make sure that the site works for just about any kind of user-agent (while still providing plenty of enhancements for the most modern browsers). That includes screen readers. Some active members of The Session happen to be blind.
One of those screen-reader users got in touch with me shortly after joining to ask me to explain what ABC was all about. I pointed them at some explanatory links. Once the format “clicked” with them, they got quite enthused. They pointed out that if the sheet music were only available as an image, it would mean very little to them. But by providing the ABC notation alongside the sheet music, they could read the music note-for-note.
That’s when it struck me that ABC notation is effectively
alt text for sheet music!
There’s one little thing that slightly irks me though. The ABC notation should be read out one letter at a time. But screen readers use a kind of fuzzy logic to figure out whether a set of characters should be spoken as a word:
Screen readers try to pronounce acronyms and nonsensical words if they have sufficient vowels/consonants to be pronounceable; otherwise, they spell out the letters. For example, NASA is pronounced as a word, whereas NSF is pronounced as “N. S. F.” The acronym URL is pronounced “earl,” even though most humans say “U. R. L.” The acronym SQL is not pronounced “sequel” by screen readers even though some humans pronounce it that way; screen readers say “S. Q. L.”
It’s not a big deal, and the screen reader user can explicitly request that a word be spoken letter by letter:
Screen reader users can pause if they didn’t understand a word, and go back to listen to it; they can even have the screen reader read words letter by letter. When reading words letter by letter, JAWS distinguishes between upper case and lower case letters by shouting/emphasizing the upper case letters.
But still …I wish there were some way that I could mark up the ABC notation so that a screen reader would know that it should be read letter by letter. I’ve looked into using
abbr, but that offers no guarantees: if the string looks like a word, it will still be spoken as a word. It doesn’t look there’s any ARIA settings for this use-case either.
So if any accessibility experts out there know of something I’m missing, please let me know.
Update: I’ve added an aural CSS declaration of
speak: spell-out (thanks to Martijn van der Ven for the tip), although I think the browser support is still pretty non-existent. Any other ideas?
A lovely little tour of eleven ubiquitous icons.
A great post from Anna on the front-end styleguides she’s worked on for A List Apart and Code for America. ‘Twas a pleasure working with her on the Code for America project.
A-mer-ica! Fuck yeah!
There was a great turn-out. Normally I’d expect a fairly significant no-show rate for a free event (they’re often oversubscribed to account for this very reason), but I was amazed how many people braved the dreadful weather to come along. We greeted them all with free beer, courtesy of Clearleft.
Honor made plentiful use of sound during her presentation. Or rather, plentiful use of electromagnetic signals converted into sound: asteroseismology from the sun; transient luminous events in the Earth’s upper atmosphere; the hailstorm as Cassini pirouettes through Saturn’s rings; subatomic particle collisions sonified. They all combined to eerie effect.
Justin’s talk was more down to Earth, despite sounding like a near-future science-fiction scenario: individuals and communities harnessing the power of the photovoltaic solar panel to achieve energy-independence.
There was a beer break between the talks and we had a joint discussion afterwards, with questions from the audience. I was leading the discussion, and to a certain extent, I played devil’s advocate to Justin’s ideas, countering his solar energy enthusiasm with nuclear energy enthusiasm—I’m on Team Thorium. (Actually, I wasn’t really playing devil’s advocate. I genuinely believe that nuclear energy is the cleanest, safest source of energy available to us and that an anti-nuclear environmentalist is a contradiction in terms—but that’s a discussion for another day.)
There was a bittersweet tinge to the evening. The first Connections event was also Honor’s last public speaking engagement in Brighton for a while. She is bidding farewell to Lighthouse Arts and winging her way to a new life in Singapore. We wish her well. We will miss her.
The evening finished with a facetious rhetorical question from the audience for Honor. It was related to the sonification of particle collisions like the ones that produced evidence for “the God particle”, the Higgs boson. “Given that the music produced is so unmusical”, went the question, “does that mean it’s proof that God doesn’t exist?”
We all had a laugh and then we all went to the pub. But I’ve been thinking about that question, and while I don’t have an answer, I do have a connection to make between both of the talks and algorithmically-generated music. Here goes…
Justin talked about the photovoltaic work done at Bell Labs. An uncle of Ray Kurzweil worked at Bell Labs and taught the young Kurzweil the basics of computer science. Soon after, Ray Kurzweil wrote his first computer program, one that analysed works of classical music and then generated its own music. Here it is.
This fun-looking short film—funded by Brighton’s Lighthouse Arts—is screening at the Duke Of York’s Cinema on Saturday, March 1st followed by a panel discussion with the director and science-comedienne Helen Keen.
A fascinating look at the early history of HTML, tracing its roots from the dialect of SGML used at CERN.
A great write-up of the design process behind The Guardian’s responsive site. It’s really gratifying to see UX designers talking about performance.
The first time I went to South by Southwest in 2005 it was an amazing experience (this was before it grew so massively large that its gravity well sucked in all the social media marketing biz dudes in the universe):
I’ve never met so many wonderful people gathered together in one place. It was tribal in the true sense of the word (that would be the cool, fun-loving sense as opposed to the hippy-dippy sense).
There was a great sense of openness and sharing. In a way, it was like the web made flesh—a terrific community of enthusiastic people eager and willing to share their knowledge and experience.
Towards the end of the week, there was the annual web awards show. Everything else about South by Southwest had been so great, I figured I’d go along to that too. Also, someone I know had been nominated for an award.
It was like stepping into opposite-web. The mood switched from one of sharing and openness to one of basically not giving a shit. Everyone in the room was there because either they or someone they knew had been nominated for an award, and that’s all they cared about. Everything before and after that point in the awards ceremony was irrelevant.
In retrospect, I should have seen it coming. If the point of the web and community gatherings—like the SxSW of yore—is for individuals to be subsumed into a larger group that is greater than the sum of its parts, then the whole point of an awards ceremony is to do the exact opposite: to single out some individuals in the group.
I made the mistake of going back to the Southby awards ceremony a year or two later, simply because Ze Frank was presenting it. “How bad could it be?” I thought. But even the inimitable Ze couldn’t save the day.
Every so often, some smart, talented web designers will bemoan the lack of recognition afforded to their
craft, industry, . They wish for the same level of respect that architects or film-makers get, or for the iconic status given to the best of the advertising world’s output in decades past.
Be careful what you wish for, I say. Not only are these the same industries that are rife with horrible business practices like spec work, they are notoriously unfair when it comes to praising individual achievement over the efforts of the group. Worst of all, the proliferation of high-profile awards leads to the practice of producing “award-winning work” i.e. work designed purely to win awards.
I’ve spoken before about the spirit of the web; how I believe certain design principles have influenced the creation and growth of the web. I see that same spirit imbued in online communities and tools like Github. I don’t see that same spirit in the awarding of prizes.
I got chatting to Aral about a markup pattern that’s become fairly prevalent since the rise of Github: linking to the source code for a website or project. You know, like when you see “fork me on Github” links.
We were talking about how it would be nice to have some machine-readable way of explicitly marking up those kind of links, whether they’re in the
head of the document, or visible in the
body. Sounds like a job for the
rel attribute, I thought.
rel attribute describes the relationship of the current document to the linked document. You can use it on the
link element (in the
head of your document) and the
a element (in the
body). The example that everyone is familiar with is
linking off to a CSS file—the linked document has the relationship of being a stylesheet for the current document.
rel attribute could theoretically take a space-separated list of any values, just like the
class attribute. In practice, there’s much more value in having everyone agree on which
rel values should be used.
There used to be a page on the WHATWG site for listing
rel values, but it tended to stagnate. So now the official registry for
rel values is on the microformats wiki. That’s where you can see which values are recommended for use today and you can also brainstorm new ideas.
The benefit of having one centralised for this is that you can see if someone else has had the same idea as you. Then you can come to agreement on which value to use, so that everyone’s using the same vocabulary instead of just making stuff up.
It doesn’t look like there’s an existing value for the use case of linking to a document’s (or a project’s) source code so I’ve proposed
Now I should document some use cases of people linking their site to its source code. It might be that wikis qualify as another use case: every “edit” button points to the source of the document in wiki markup.
If you have any thoughts on this pattern, or examples to add, please feel free to add them.
Such a classic game, well worth playing again.
If you picked up the Guardian this weekend, you’ll have seen some brilliant work by Kyle on the cover (and inside) the magazine section.