Journal tags: responsive

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:

1. Start making any new pages and sections of the site responsive. After a while of doing that, the team would develop a pretty good feeling of what it would take to then go back and retrofit what’s already online. The downside of this approach is that would provide an asynchronous user experience: users would be moving from responsive to non-responsive parts of the site, which could be confusing.
2. Leave the current fixed-width grid as it is, but focus on making all the components of the page flexible. Once all the components are fluid, then it should be a matter of switching over to a fluid grid in one fell swoop. On the plus side, this means that the whole site would then be responsive. On the negative side, until all the components have been made flexible—which could take some time—the site remains rigidly fixed-width and desktop-centric.
3. Rebuild the mobile site, using it as a seed from which to grow a new responsive site. On the face of it, having a separate mobile subdomain might seem like a millstone around your neck if your trying to push for a responsive design. In practice though, it can be enormously useful. Mostly it’s a political issue: whereas ripping out the desktop site and starting from scratch is a huge task that would require everyone’s buy-in, nobody gives a shit about the mobile subdomain. Both the BBC news team and The Guardian are having great success with this approach, building mobile-first responsive sites bit-by-bit on the m. subdomain, with the plan to one day flip the switch and make the subdomain the main site. The downside is that until the switch is flipped, you’ve still got to deal with redirecting mobile traffic—probably using some nasty user-agent sniffing—and all the issues that come with having your content appearing at more than one URL.

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:

1. They’ve already put together a front-end styleguide; a UI library of components. The fact that they’re already thinking about breaking things down into their component parts is a terrific approach (and they also said they’re planning to make their UI library public, which makes me very happy indeed).
2. Developers, designers, and information architects work side by side. The web department works in teams, but those teams aren’t organised by job role. Instead each small team of 4 or 5 people has a product manager, a UX designer, visual designer, and a developer or two.

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.

Three weeks ago, myself and Jessica went to Israel. It was a wonderful trip, filled with wonderful food. I took lots of pictures if you don’t believe me.

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:

I’m in Madison, Wisconsin where myself and Aaron are wrapping up three days of workshopping with Shopbop. It’s all going swimmingly.

This last of the three days is being spent sketching, planning and hacking some stuff together based on all the things that Aaron and I have been talking about for the first two days: progressive enhancement, responsive design, HTML5, JavaScript, ARIA …all the good stuff that Aaron packed into Adaptive Web Design.

This time I’m on my own. Wish me luck!

Mike has written about the Code for America alpha website that we collaborated on:

We chose to work with ClearLeft because they develop a pattern portfolio (a pattern/style library) which would allow us to scale our work to our Brigades. This unique approach has aligned perfectly with our work style and decentralized organizational structure.

Thankfully, I think the approach of delivering a pattern portfolio (instead of just pages) isn’t so unique these days. Mind you, it still seems to be more common with in-house teams than agencies. The Mailchimp pattern library is a classic example.

But agencies like Paravel are—like Clearleft—delivering systems, not pages. Dave wrote about providing responsive deliverables:

Responsive deliverables should look a lot like fully-functioning Twitter Bootstrap-style systems custom tailored for your clients’ needs.

I think that’s a good way of looking at it: a Bootstrap for every project.

Here’s the front-end style guide for Code for America.

Usually these front-end deliverables will be password-protected on the Clearleft extranet for the client’s eyes only, but Code for America are all about openness, so they’re more than willing to let us share it with the world. That makes me very happy. I remember encouraging the guys at Starbucks to publish their front-end style guide and I’ve written about this spirit of sharing before:

These style guides and pattern libraries aren’t being published in an attempt to provide ready-made solutions—every project should have its own distinct pattern library. Instead, these pattern libraries are being published in a spirit of openness and sharing …a way of saying “Hey, this is what worked for us in these particular circumstances.”

If you’re poking around the Code for America style guide, you’ll notice that it borrows some ideas from the pattern primer idea I published a while back. But in this iteration, the markup is available via a toggle—a nice variation. There’s also a patchwork page that provides a nice glance-able uninterrupted view of the same patterns.

Every project is a learning experience and each front-end style guide gives us ideas about how to do the next one better. In fact, Mark is busy working on better internal tools for creating these kinds of deliverables—something we’ll definitely be sharing. In the meantime, I’ll be encouraging other clients to be as open as Code for America have been in allowing us to share these deliverables.

For more on the usefulness of front-end style guides, be sure to read Paul’s article on style guides for the web, Anna’s classic 24 Ways article, and of course, Anna’s pocket guide from Five Simple Steps.

As predicted, today’s schedule of two back-to-back half-day workshops at UX Week was indeed quite exhausting. But it was also very rewarding.

Every time I run a workshop, I always end up learning something from the experience and today was no exception. The attendees were a bright bunch with lots of great questions and discussion points.

Once the workshops were done, I felt pretty exhausted. Jessica and I had a quiet night sampling the culinary delights of M.Y. China conveniently located just across the street from our hotel so I could collapse into bed at the end of the day.

Even though my encounter with Tess yesterday was brief, we still managed to turn the conversation to browsers, standards, and all things web in our brief chat.

Specifically, we talked about this proposal in Blink related to the 300 millisecond delay that mobile browsers introduce after a tap event.

Why do browsers have this 300 millisecond delay? Well, you know when you’re looking at fixed-width desktop-based website on a mobile phone, and everything is zoomed out, and one of the ways that you can zoom in to a specific portion of the page is to double tap on that content? A double tap is defined as two taps less than 300 milliseconds apart. So whenever you tap on something in a touch-based browser, it needs to wait for that length of time to see if you’re going to turn that single tap into a double tap.

The overall effect is that tap actions feel a little bit laggy on the web compared to native apps. You can fix this by using the fastclick code from FT Labs, but I always feel weird solving a problem on mobile by throwing more front-end code at it.

Hence the Blink proposal: if the author has used a meta viewport declaration to set width=device-width (effectively saying “hey, I know what I’m doing: this content doesn’t need to be zoomed”), then the 300 millisecond delay could be removed from tap events. Note: this only affects double taps—pinch zoom is unaffected.

This sounds like a sensible idea to me, but Tess says that she sometimes still likes to double tap to zoom even in responsive designs. She’d prefer a per-element solution rather than a per-document meta element. An attribute? Or maybe a CSS declaration similar to pointer events?

I thought for a minute, and then I spitballed this idea: what if the 300 millisecond delay only applied to non-focusable elements?

After all, the tap delay is only noticeable when you’re trying to tap on a focusable element: links, buttons, form fields. Double tapping tends to happen on text content: divs, paragraphs, sections. That’s assuming you are actually using buttons and links for buttons and links—not spans or divs a-la Google.

And if the author decides they want to remove the tap delay on a non-focusable element, they can always make it focusable by adding tabindex=-1 (if that still works …does that still work? I don’t even know any more).

Anyway, that was my not-very-considered idea, but on first pass, it doesn’t strike me as being obviously stupid or crazy.

So, how about it, browser makers? Does removing the 300 millisecond delay on focusable elements—possibly in combination with the meta viewport declaration—make sense?

I got an email recently from the guys at Cyber Duck asking me about the process behind the dConstruct 2012 website, beautifully designed by Bevan. Ethan actually used it as an example in his An Event Apart talk earlier this week. Anyway, here’s what I wrote…

The dConstruct conference takes place on the first Friday of September every year, and every year the conference has a different theme. That theme then influences the visual design of the site. To start with, we throw up a quick holding page and then, once we’ve got our speakers all set, we launch the site proper, usually a month or so before tickets go on sale.

At Clearleft, we believe very strongly in the universality of the web. We wanted the information on the 2012 dConstruct website to be available to anybody with an internet connection, no matter what kind of device or browser they’re using. That does not mean that the site should look and behave exactly the same in every browser or on every device. That isn’t practical. Nor is it desirable, in my opinion. Better browsers should be rewarded with a better experience. But every browser should be able to access the content. The best way to achieve that balance is through progressive enhancement. Responsive web design—when it’s done mobile first—is an excellent example of progressive enhancement in action.

The theme for dConstruct 2012 was “Playing With The Future”. It would be easy to go overboard with a visual design based on that theme, so we made sure to reign things in a bit and keep it fairly subtle. The colour scheme evolved from previous years, going in a more pastel direction. The use of Futura for headline text was the biggest change.

Those colours (muted green, red, and blue) carried through to the imagery. In the case of a conference website, the imagery is primarily photographs of speakers. That usually means JPEGs and sometimes those JPEGs can get pretty weighty. In this case, the monochrome nature of the images meant that we could use PNGs. Not only that, but through a little experimentation, we were able to get away with sometimes using as few as 16 colours for the PNG. That meant the file sizes could be nice and small. The average speaker photo was around 12K in weight.

Each speaker photo is 200x200 pixels in size. Now, you might think that we’d want to make those bigger as we moved up from small screen sizes to larger, desktop sizes. But actually, because the layout changes to put more of the photos side-by-side as the viewport gets larger, there was no need to do any clever responsive image-swapping. Instead, we spent that time getting the images as small in file size as we possibly could. The ImageOptim app for Mac is very handy for helping with this.

There are also some background images (for social media icons, background textures, and the like). These were all Base 64-encoded into the stylesheet to avoid extra HTTP requests.

The priority was very much on keeping things speedy. When talking about responsive design, there’s a lot of emphasis on layout but actually that was a relatively straightforward part of the 2012 dConstruct site: there’s nothing too complicated going on there. Instead, the focus was on performance balanced with a striking visual design.

On the individual speaker pages, there’s a bit of conditional loading going on. For example, most pages include a link to a video on YouTube or Vimeo. On larger screen sizes, there’s a bit of JavaScript to pull in that video and display it right on the page. Crucially, this JavaScript runs after the rest of the document has already loaded so it won’t block the rendering. The end result is that everyone has access to the video: on smaller screens, it’s available by following a link; on larger screens, it’s available in situ.

JavaScript is only ever used to enhance, never as a requirement for core functionality. The navigation, for example, has a nice toggle-to-reveal behaviour on small screens if JavaScript is available. But if JavaScript isn’t available or doesn’t load for some reason, then the navigation is simply visible by default. It’s important to consider safe defaults before adding behavioural enhancements.

In retrospect, it probably would’ve made more sense to simply inline the JavaScript at the bottom of each page: the external file isn’t very big at all, and that extra HTTP request could’ve been saved.

There were some other things that could’ve been done better: some of the images might have been better as SVG (the logo, for example). But all those lessons were carried forward and so the site for dConstruct 2013 is even snappier and more performant.

Brad has done a great job in documenting navigation patterns for responsive designs. More recently I came across Erick Arbé’s similar collection of patterns for responsive navigation. And, of course, at the Responsive Day Out, David gave a presentation on the subject.

As I mentioned in the chat after David’s talk, choosing a pattern doesn’t need to be an either/or decision. You can start with a simple solution and progressively enhance to a more complex navigation pattern.

Take the footer-anchor pattern, for example. I really, really like this pattern. It doesn’t require any JavaScript whatsoever; just a simple hyperlink from the top of the page that links to the fragment identifier of the navigation at the bottom of the page. It works on just about every device.

But you don’t have to stop there. Now that you’ve got a simple solution that works everywhere, you can enhance it for more capable browsers.

Take a look at this example that applies the off-canvas pattern for browsers capable of handling the JavaScript and CSS required.

You can see the two patterns in action by looking at the source in JS Bin. If you toggle the “Auto-run JS” checkbox, you can see both behaviours. Without JavaScript you get the footer-anchor pattern. With JavaScript (and a capable browser) you get the off-canvas pattern.

I haven’t applied any media queries in this instance, but it would be pretty straightforward to apply absolute positioning or the display: table hack to display the navigation by default at wider screen sizes. I’ll leave that as an exercise for the reader (bonus points: apply the off-canvas from the right of the viewport rather than the left).

Feel free to peruse the somewhat simplistic code. I’m doing a bit of feature detection—or cutting the mustard—to test for querySelector and addEventListener. If a browser passes the test, a class is applied to the document root and some JavaScript is executed on page load to toggle the off-canvas behaviour.

On a recent project, I found myself implementing a number of different navigation patterns: off-canvas, overlay, and progressive disclosure. But each one began as an instance of the simple footer-anchor pattern.

Progressive enhancement, baby. Still not dead, still important.

I’ve been doing some workshopping and consultancy at a few different companies recently, mostly about responsive design. I can’t help but feel a little bad about it because, while I think they’re expecting to get a day of CSS, HTML, and JavaScript, what they actually get is the uncomfortable truth that responsive design changes everything …changes that start long before the front-end development phase.

I explain the ramifications of responsive design, hammer on about progressive enhancement like a broken record, extoll the virtues of a content-first approach, exhort them to read A Dao of Web Design, and let them know that, oh, by the way, your entire way of working will probably have to change.

Y’see, it’s my experience that the biggest challenges of responsive design (which, let’s face it, now means web design) are not technology problems. Sure, we’ve got some wicked problems when dealing with non-flexible media like bitmap images, which fight against the flexible nature of the web, but thanks to the work of some very smart and talented people, even those kinds of issues are manageable.

No, the biggest challenges, in my experience, are to do with people. Specifically, the way that people work together.

Old waterfallesque processes where visual designers work entirely in Photoshop before throwing PSDs over the wall to developers just don’t cut it any more. Old QA testing processes that demanded visual consistency across all browsers and platforms are just ludicrous.

The thing is …those old processes were never any good. We fooled ourselves into thinking they worked, but that was only because we were working from some unfounded assumption: that everyone is on broadband, that everyone has a nice big screen, that everyone has a certain level of JavaScript capability. The explosion in diversity of mobile devices (and with it, the rise of responsive design) has shone a light on those assumptions and exposed those old processes for the façades that they always were.

When I’m doing a workshop and I tell that to designers, developers, and project managers, they often respond by going through the five stages of grief. Denial, anger, bargaining, depression …I try to work with them through those reactions until they ultimately get to acceptance.

Somewhere between the “bargaining” and “depression” phase, somebody inevitably passes the buck further up the chain:

“Oh, we’d love to do what you’re saying, but our clients would never go for it.” Or “You’ve convinced me but there’s no way our boss will ever agree to this.”

I’ve got to be honest: sometimes I think we use “the client” and “the boss” as a crutch. I’m also somewhat bemused when people ask me for advice to help them convince their client or their boss. I don’t know your boss—how could I possibly offer any relevant advice?

Still, I’ve written about this question of “How do I convince…?” before:

Something I’ve found useful in the past is the ability to point at trailblazers and say “like that!” Selling the idea of web standards became a whole lot easier after Doug redesigned Wired and Mike redesigned ESPN. It’s a similar situation with responsive design: clients are a lot more receptive to the idea now that The Boston Globe site is live.

When it comes to responsive design, there’s one site that should thoroughly shame anyone who claims that they can’t convince their boss to do the right thing: GOV dot UK.

It’s responsive. It puts user needs first. It’s beautiful. It even won the Design Museum’s design of the year, for crying out loud.

This isn’t some flashy lifestyle business. This isn’t some plucky young disruptive startup. This is the British government, an organisation so stodgy and bureaucratic that there are multiple sitcoms about its stodginess and bureaucracy.

Gov.uk is an inspiration. If the slowest-moving organisation in the country can turn itself around, embrace a whole new way of working, and produce a beautiful, usable, responsive site, then the rest of us really have no excuse.

Pretty much every time I give a talk—be it on progressive enhancement, responsive design, or web development in general—I almost always make reference to John’s A Dao Of Web Design. Invariably, I ask for a show of hands: “Who’s read this article?” I ask. I try not to get too dispirited when only a few hands go up. Instead I encourage everyone—in the strongest possible terms—to seek it out and read it.

It’s not just that I consider A Dao Of Web Design to be part of the canon of great writing and thinking for web designers and developers. I’m also continually amazed by its longevity. Thirteen years is a very, very long time on the web, and yet just last week Richard referenced John’s article when he was describing how best to approach designing for the web today.

The only other article I can think that matches its importance is Ethan’s unveiling of Responsive Web Design three years ago, also on A List Apart. It’s no coincidence that Ethan’s article references John’s article from a decade before. Both pieces are essentially making the same rallying cry: stop fighting the flexible nature of the web. Embrace it.

I think that finally, finally we’re beginning to do just that.

I spent most of last week up in Greenwich for this year’s UX London. ‘Twas a most excellent event. The move to the new venue gave the whole event a much more fun vibe and the format of a morning of talks followed by an afternoon of workshops was perfect.

Andy did a great job curating the line-up. It had a bit of a dConstruct-y feel, and not just because we had old friends like Marty, Peter, and Hannah back: Genevieve Bell, Simone Rebaudengo and Richard Seymour all broke our brains in different wonderful ways.

Hats off to Kate who worked her ass off to make sure that everything ran smoothly. Seriously, you wouldn’t believe the amount of work she did. The change of venue and format for this year resulted in at least twice as much work as usual.

In the middle of UX London’s three days, I ran a workshop called Responsive UX. As I told the audience that morning when I was pitching the workshop, I got the title by taking the term “responsive design” and doing a find-and-replace on the word “design” with the phrase “UX”. After all, what’s the difference? Right, Peter?

Seriously though, this workshop was a little different in that I wasn’t covering any HTML or CSS or JavaScript. It was much more about planning for the unknown and good ol’-fashioned content priority and hierarchy.

I wasn’t entirely pleased with how it went. It was a workshop of two halves. The first half had far too much of me talking (and ranting), probably preaching to the choir. But I felt I had to lay the groundwork first. The second half—when everybody got hands on with paper-based exercises—was much better.

I learned my lesson: show, don’t tell. I’ll be doing a full day responsive workshop at Ampersand in June. I plan to make sure that there’s less of me talking and more making and collaborating. Also, because it’s a full day, I’ll be able to get down to the nitty-gritty of markup and style sheets.

And don’t forget; if you want me to come to your company sometime and do a workshop there, no problemo.

Some people at the workshop asked about me publishing my slides. The slides by themselves really don’t contain much information but I’ve published them on Speakerdeck anyway. But what’s more valuable are the URLs to articles and resources I mentioned along the way. So here’s the structure of the workshop together with links to examples and further reading…

Introduction

• Long Live the Web by Tim Berners-Lee
• A Dao of Web Design by John Allsopp
• Responsive Web Design by Ethan Marcotte
• A Richer Canvas by Mark Boulton
• Fit to Scale by Trent Walton

Myths

• St. Paul’s School
• Huffduffer
• Map Tales
• The Mobile Context by Mark Kirby
• There is no Mobile Web by Stephen Hay
• Noise-to-Noise Ratio by Merlin Mann

Progressive Enhancement

• Responsive By Default by Andy Hume
• Do websites need to look exactly the same in every browser? by Dan Cederholm

Planning

• Mobile First by Luke Wroblewski
• Content First
• APIs First
• The DRY Principle
• URL Design by Kyle Kneath

Conditional Loading

• dConstruct 2012
• Conditional Loading for Responsive Designs

Visual Design

• Time to stop showing clients static design visuals by Andy Clarke
• Style Tiles by Samantha Warren
• Element Collages by Dan Mall
• Matter
• Pattern Primer example
• Pattern Primer source

Navigation

• Clearleft (navigation first)
• The Session (content first, navigation second)
• Fix My Street (display: table)
• Hack Farm (progressive disclosure)
• Wellcome Library (off-canvas)
• Yaron Shoen (separate URL)

There was a repeated rallying cry at the Responsive Day Out. It was the call for more sharing—more sharing of data, more sharing of case studies, more sharing of success stories, but also more sharing of failures.

In that spirit, I thought I’d share a pattern I’ve been working on. It didn’t work, but I’m not going to let that stop me putting it out there.

Here’s what I wanted to do…

Let’s say you’ve got a list of items; modular chunks of markup like an image and a caption, for example. By default these will display linearly on a small screen: a vertical list. I quite like the way that the Flickr iPhone app takes those lists and makes them horizontal—they go off-canvas (to the right), with a little bit of the next item peaking out to give some affordance. It’s like an off-canvas carousel.

I’d quite like to use that interaction in responsive designs. But I don’t want to do it by throwing a lot of JavaScript at the problem. So I thought I’d attempt to achieve it with a little bit of CSS.

So, let’s say I’ve got a list of six items like this:

<div class="items">
    <ul class="item-list">
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
        <li class="item"></li>
    </ul><!-- /.item-list -->
</div><!-- /.items -->

Please pay no mind to the qualities of the class names: this is just a quick proof of concept.

Here’s how that looks. At larger screen sizes, I display the list items in groups of two or three, side by side. At smaller sizes, the items simply linearise vertically.

Okay, now within a small-screen media query I’m going to constrain the width of the container:

.items {
    width: 100%;
}

I’m going to make the list within that element stretch off-canvas for six screens wide (this depends on me knowing that there will be exactly six items in the list):

.items .item-list {
    width: 600%;
}

Now I’ll make each item one sixth of that size, which should be one screen’s worth. Actually, I’m going to make it a bit less than exactly one sixth (which would be 16.6666%) so that a bit of the next item peaks out:

.item-list .item {
    width: 15%;
}

My hope was that to make this crawlable/swipable, all I had to do was apply overflow: scroll to the containing element:

.items {
    width: 100%;
    overflow: scroll;
}

All of that is wrapped up in a small-viewport media query:

@media all and (max-width: 30em) {
    .items {
        width: 100%;
        overflow: scroll;
    }
    .items .item-list {
        width: 600%;
    }
    .items .item {
        width: 15%;
    }
}

It actually works …in some browsers. Alas, support for overflow: scroll doesn’t extend back as far as Android 2, still a very popular flavour of that operating system. That’s quite a showstopper.

There is a polyfill called Overthrow from those mad geniuses at Filament Group. But, as I said, I’d rather not throw more code at the problem. While I can imagine shovelling a polyfill at a desktop browser, I have a lot of qualms about trying to “support” an older mobile browser by giving it a chunk of JavaScript to chew on.

What I really need is a way to detect support for overflow: scroll. Alas, looking at the code for Overthrow, that isn’t so easy. Modernizr cannot help me here. We are in the realm of the undetectables.

My pattern is, alas, a failure.

Or, at least, it’s a failure for now. The @supports rule in CSS is tailor-made for this kind of situation. Basically, I don’t want any those small-screen rules to apply unless the browser supports overflow: scroll. Here’s how I will be able to do that:

@media all and (max-width: 30em) {
  @supports (overflow: scroll) {
    .items {
        width: 100%;
        overflow: scroll;
    }
    .items .item-list {
        width: 600%;
    }
    .items .item {
        width: 15%;
    }
  }
}

This is really, really useful. It means that I can start implementing this pattern now even though very few browsers currently understand @supports. That’s okay. Browsers that don’t understand it will simply ignore the whole block of CSS, leaving the list items to display vertically. But as @support gets more …um, support …then the pattern will kick in for those more capable browsers.

I can see myself adding this pre-emptive pattern for a few different use cases:

• On the home page of Huffduffer, there’s the list of popular items and the list of new tunes.
• On the tunes page of The Session, there’s the list of newest tune settings, newest comments, etc.
• On the Clearleft blog, there’s the list of recent blog entries.

Feel free to poke at the example code. Perhaps you can find a way to succeed where I have failed.

One of the recurring themes at the Responsive Day Out was how much of a sea change responsive design is. More than once, it was compared to the change we went through going from table layouts to CSS …but on a much bigger scale.

Mark made the point that designing in a liquid way, rather than using media queries, is the real challenge for most people. I think he’s right. I think there’s an over-emphasis on media queries and breakpoints when we talk about responsive design. Frankly, media queries are, for me, the least interesting aspect. And yet, I often hear “media queries” and “responsive design” used interchangeably, as if they were synonyms.

Embracing the fluidity of the medium: that’s the really important bit. I agree with Mark’s assessment that the reason why designers and developers are latching on to media queries and breakpoints is a desire to return to designing for fixed canvases:

What started out as a method to optimise your designs for various screen widths has turned, ever so slowly, into multiple canvas design.

If you’re used to designing fixed-width layouts, it’s going to be really, really hard to get your head around designing and building in a fluid way …at first. In his talk, Elliot made the point that it will get easier once you get the hang of it:

Once you overcome that initial struggle of adapting to a new process, designing and building responsive sites needn’t take any longer, or cost any more money. The real obstacle is designers and developers being set in their ways. I know this because I was one of those people, and to those of you who’ve now fully embraced RWD, you may well be nodding in agreement: we all struggled with it to begin with, just like we did when we moved from table-based layout to CSS.

This is something I’ve been repeating again and again: we’re the ones who imposed the fixed-width constraint onto the medium. If we had listened to John Allsopp and embraced the web for the inherently fluid medium it is, we wouldn’t be having such a hard time getting our heads around responsive design.

But I feel I should clarify something. I’ve been saying “we” have been building fixed-width sites. That isn’t strictly true. I’ve never built a fixed-width website in my life.

Some people find this literally unbelievable. On the most recent Happy Mondays podcast, Sarah said:

I doubt anyone can hold their hands up and say they’ve exclusively worked in fluid layouts since we moved from tables.

Well, my hand is up. And actually, I was working with fluid layouts even when we were still using tables for layout: you can apply percentages to tables too.

Throughout my career, even if the final site was going to be fixed width, I’d still build it in a fluid way, using percentages for widths. At the very end, I’d slap on one CSS declaration on the body to fix the width to whatever size was fashionable at the time: 760px, 960px, whatever …that declaration could always be commented out later if the client saw the light.

Actually, I remember losing work back when I was a freelancer because I was so adamant that a site should be fluid rather than fixed. I was quite opinionated and stubborn on that point.

A search through the archives of my journal attests to that:

• 2003: The long debate
• 2004: Regurgitating the chestnut
• 2004: Fixed vs. Liquid… yet again
• 2005: Fixed Fashion
• 2005: Transparent liquid
• 2005: A List Too Far Apart
• 2006: Fixtorati
• 2007: New Year’s Resolution
• 2009: Zoomfusion

Way back in 2003, I wrote:

It seems to me that, all too often, designers make the decision to go with a fixed width design because it is the easier path to tread. I don’t deny that liquid design can be hard. To make a site that scales equally well to very wide as well as very narrow resolutions is quite a challenge.

In 2004, I wrote:

Cast off your fixed-width layouts; you have nothing to lose but your WYSIWYG mentality!

I just wouldn’t let it go. I said:

So maybe I should be making more noise. I could become the web standards equivalent of those loonies with the sandwich boards, declaiming loudly that the end is nigh.

At my very first South by Southwest in 2005, in a hotel room at 5am, when I should’ve been partying, I was explaining to Keith why liquid layouts were the way to go.

That’s just sad.

So you’ll forgive me if I feel a certain sense of vindication now that everyone is finally doing what I’ve been banging on about for years.

I know that it’s very unbecoming of me to gloat. But if you would indulge me for a moment…

I TOLD YOU! YOU DIDN’T LISTEN BUT I TOLD YOU! LIQUID LAYOUTS, I SAID. BUT, OH NO, YOU INSISTED ON CLINGING TO YOUR FIXED WIDTH WAYS LIKE A BUNCH OF BLOODY SHEEP. WELL, YOU’RE LISTENING NOW, AREN’T YOU? HAH!

Ahem.

I’m sorry. That was very undignified. It’s just that, after TEN BLOODY YEARS, I just had to let it out. It’s not often I get to do that.

Now, does anyone want to revisit the discussion about having comments on blogs?

Thanks to Drew’s tireless work over the weekend, all the audio from the Responsive Day Out is available for your aural pleasure.

I’ve added them on Huffduffer. Subscribe to the RSS feed in the podcast-listening application of your choice. Or feel free to cherry-pick from the day’s snappy, quick-fire talks:

1. Sarah Parmenter: The Responsive Workflow
2. David Bushell: Responsive Navigation
3. Tom Maslen: Cutting the Mustard
4. Jeremy chatting with Sarah, David, and Tom
5. Richard Rutter: Responsive Web Fonts
6. Josh Emerson: Asset Fonts
7. Laura Kalbag: Design Systems
8. Elliot Jay Stocks: RWD — The War Has Not Yet Been Won
9. Jeremy chatting with Richard, Josh, Laura, and Elliot
10. Anna Debenham: Playing with Game Console Browsers
11. Andy Hume: The Anatomy of a Responsive Page Load
12. Bruce Lawson: What’€™s Next in StandardsLand
13. Jeremy chatting with Anna, Andy, and Bruce
14. Owen Gregory: Antiphonal Geometry
15. Paul Lloyd: The Edge of the Web
16. Mark Boulton: In Between
17. Jeremy chatting with Owen, Paul, and Mark

Share and enjoy!

When I announced the Responsive Day Out just three months ago, I was at pains to point out that it wouldn’t be a typical Clearleft event:

It’s a kind of conference, I guess, but I think of it as more like a gathering of like-minded people getting together to share what they’ve learned, show some examples, swap techniques, and discuss problems. And all of it will be related to responsive web design.

Well, it all went according to plan. In fact, it surpassed all expectations. It was really, really, really good, thanks to the unstoppable quick-fire knowledge bombs being dropped by each and every amazing speaker.

In the run-up to the event, I kept telling the speakers not to prepare too much; after all, these would just be quick 20 minute talks, and they were all donating their time and expertise …but clearly they didn’t listen to me. Everyone brought their A-game.

At the excellent after-party, courtesy of the kind people of Gridset, lots of people said how much they liked the format. It’s one I shamelessly ripped off from Honor’s Improving Reality event—a batch of three quick, focused talks back-to-back, followed by a joint discussion with all three speakers, and some questions from the audience. I was playing host for the day, and I tried my best to keep things lighthearted and irreverent. From the comments I heard, I think I succeeded in bringing the tone down.

Despite the barebones, stripped-down nature of the event, there was good coffee on hand throughout, thanks to A Book Apart and Shopify.

There will be audio, thanks to Drew. There will be video, thanks to Besquare and Mailchimp.

In the meantime, Marc has posted a bunch of pictures on Flickr and Orde Saunders liveblogged the whole day.

If you came along, thank you. I hope you had a good time and enjoyed a day out at the seaside. Special thanks to the people who came from afar afield as Italy, Spain, and Belgium. I really appreciate it.

I really enjoyed myself, and I was relieved that the somewhat unorthodox gathering worked so well. But really, yesterday was a smash hit because of the speakers. Sarah, David, Tom, Richard, Josh, Laura, Elliot, Anna, Bruce, Andy, Owen, Paul, and Mark …you were all magnificent. Thank you, thank you, thank you!

This is shaping up to be a fun week. I’m off to Altitude down the coast in Portsmouth tomorrow. If you’re going to be there, come and say hello. Then just two days after that it’ll be the Responsive Day Out here in Brighton. Squee!

If you’re coming to Brighton the day before the conference, I recommend heading along to Thursday’s Async event on building HTML5 games. I won’t be able to make it, alas—I’ll be whisking the speakers off to an undisclosed location for a nice evening out.

I have a favour to ask of you if you’re coming along to the Responsive Day Out on Friday. If you have any web-related books that you no longer need, please bring them along with you. I want to support Scrunchup’s initiative to distribute materials to schools.

I’ll also be bringing some books along, thanks to sponsors A Book Apart. If you ask a question during the discussion portions of the day, you can claim a book: either Ethan’s, or Luke’s, or Karen’s.

If you’re coming along to the Responsive Day Out, please get there nice and early for registration. Doors open at 9am and everything kicks off at 10am. There will be coffee. Good coffee.

Here’s the plan. It may change…

9:00 – 10:00	Registration
10:00 – 10:20	Sarah Parmenter
10:20 – 10:40	David Bushell
10:40 – 11:00	Tom Maslen
11:00 – 11:15	Chat with Sarah, David, and Tom
11:15 – 11:45	Break
11:45 – 12:05	Richard Rutter and Josh Emerson
12:05 – 12:25	Laura Kalbag
12:25 – 12:45	Elliot Jay Stocks
12:45 – 13:00	Chat with Richard, Josh, Laura, and Elliot
13:00 – 14:30	Lunch break
14:30 – 14:50	Anna Debenham
14:50 – 15:10	Andy Hume
15:10 – 15:30	Bruce Lawson
15:30 – 15:45	Chat with Anna, Andy, and Bruce
15:45 – 16:15	Break
16:15 – 16:35	Owen Gregory
16:35 – 16:55	Paul Lloyd
16:55 – 17:15	Mark Boulton
17:15 – 17:30	Chat with Owen, Paul, and Mark

Scott is here at An Event Apart in Atlanta to talk to us about being responsibly responsive. Scott works with Filament Group on large-scale responsive designs like the Boston Globe. They’ve always focused on progressive enhancement and responsive design feels like a natural evolution of that.

But responsive design is just a small part of what goes into responsible design. Responsible design isn’t just about layout, it’s about making sure that adding advanced features doesn’t inconvenience anyone. Mostly, we need to care; we need to care about people in situations other than our own.

This became very clear to Scott when he was travelling in southeast Asia, working remotely with his colleagues back in Boston. Most of the time he was accessing the web through a USB dongle over a cellular network. That’s how most people get online there. So don’t make assumptions about screen size and bandwidth.

Browsing via this dongle was frustrating. It was frustrating for Scott because, as a developer, he knew that there was no reason for the web to be so difficult to use on this connection.

It’s our fault. The average web page is over a megabyte in size. A megabyte! That breaks down to a lot of images, plenty of JavaScript, some HTML, and “other” …which means cat pictures. Sending 800K of images is a lot for any kind of device. Same with JavaScript: 200K is a lot. The benefits that we as developers get from that JavaScript is burdening our users.

When you prototype interactions, are you thinking about your own clock …or the user’s?

The average load time for the top 200 websites is between 6 and 10 seconds on a good connection.

Good performance is good design. Scott shows a graph of “webpage loading time” on one axis against “swear words” on the other. The graph trends upwards.

Now those 1MB webpages were probably desktop-specific sites, not responsive sites. But 86% of responsive sites send the same assets to all devices.

We have to design for new sizes and new input methods, but at the same time, the old contexts aren’t going away.

We’re moving from normalisation to customisation. We used to try to make things look and work the same in every browser. It was always a silly goal, but now it seems totally ridiculous. But content parity does not require experience parity. In fact, if things look and act the same across all devices, that might mean that we’ve missed a lot of opportunities.

We should avoid presumptions. We might be able to get the dimensions of a screen, but that could be different to the dimensions of the viewport. Instead of using pixels for breakpoints, we can use ems so that the user’s font size determines the layout changes.

Before we look at some responsible techniques, let’s look at the anatomy of a page load.

HTTP

We begin with typing a URL. That request goes to a DNS server. Then the request is sent to the right host. Then the host sends a response. But on a mobile device, there’s an extra step. You have to go through a tower first, before reaching the DNS server. That connection to the tower takes two seconds (for radio). That two-second delay only happens once, thankfully.

Once the connection is made, the HTML response sends more requests: CSS, JavaScript, pictures of cats. During this time, the browser holds off on rendering. This is the critical path.

After about eight seconds, the carrier drops the connection. That two-second connection needs to be made again. So we should try to get everything during that initial eight second period.

HTML

Network conditions can change. Every HTTP request is a gamble. Say you’ve embedded a third-party widget, like Twitter’s. If you’re in a country like China that blocks Twitter, the page will never load. Chrome will hang for thirty seconds.

We need to ensure that we’re delivering assets responsibly. Consider using conditional loading. On the Boston Globe, the home page has a lot of content. The headlines certainly belong there. But content from individual sections (that you can get to from the top navigation) is also being pulled into the homepage. We definitely want to provide the link to, for example, the sports section, but the latest content from the sports section could be conditionally loaded.

Scott mentions my 24 Ways article on conditional loading for responsive designs. At Filament Group, they abstracted this “link/conditional load” into a pattern. It uses HTML5 data attributes to indicate what should be pulled in via Ajax and where it should go.

CSS

Let’s look at how we deliver CSS. The way that we load CSS today is going to catch up with us. According to the HTTP Archive, the transfer size of CSS has the highest correlation to render time.

As a start, we should be using mobile-first media queries. That means starting with the styles for absolutely every device. Then we start adding our media queries for wider and wider viewport widths. This gives you a broadly-usable default. Those initial styles should go to everyone, but Scott likes to qualify them with an only all media query for some enhanced small-screen layout declarations. That makes sure that really old browsers won’t mess it up.

Generally mobile-first media queries work pretty well. But there’s a problem. We’re sending all the CSS to all the devices, even if they’ll never use half of it.

Would it be better to use multiple link elements with different media types? Alas, no. Browsers will download all stylesheets (even if the media type is set to “nonsense”) just in case they’ll need ‘em later. And unfortunately those requests are blocking. Modern WebKit browsers do a bit better. It still downloads all the stylesheets but it will render once it has the small-screen CSS.

The best approach is, unfortunately, to send just one CSS file but minify, compress, gzip and cache the shit out of it. CSS compresses really well. Gzip works by spotting redundant data—as soon as it notices a repeating segment, you get a gain. And CSS is full of repeated properties and declarations.

Images

Images are an interesting problem. Remember they were the worst offenders in page bloat. Fortunately they don’t block, but still—this problem will only get worse.

There are background images. They’re easy. Browsers have gotten very smart about only downloading the background images they need.

Foreground images aren’t so easy. There’s the compressive image technique that Luke mentioned. Make the JPEG bigger in size, but lower in quality. When it’s scaled down in the browser, it looks perfectly fine. A 1x image saved at 90% quality, it’s 95K. The same image at 2x with 0% quality is 44K.

But there’s a concern about the memory footprint of doing this on some devices. Filament Group are looking into this but it’s very hard to test.

With compressive images, you just have to point to them in one img element using the src attribute.

Responsive images are much trickier. There are two proposals.

The first is the picture element, which uses multiple source elements to specify different images for different breakpoints. There’s also a fallback image as a last resort for older browsers.

The second proposal is the srcset attribute. It’s particularly well-suited to different pixel densities. The advantage of this one is that the browser, rather than the author, gets the last say about which image should be displayed. There’s also talk about merging both proposals.

Neither proposal works today so Scott created Picturefill, a polyfill for the picture proposal, although it uses divs. The fallback image goes in a noscript element to prevent browsers from pre-fetching it.

Since picture and Picturefill work with media queries, perhaps you can default to standard definition but allow users to opt in to high definition versions.

Managing different images for different resolutions and pixel densities gets very tedious. Maybe we should abandon the pixel. Certainly for icons, SVG can be really useful. It’s well-supported today. It also compresses well, because it is text: it’s a markup language, like HTML. That means you can also edit the source of an SVG image in a text editor.

You can reference the SVG file directly in the src attribute of an img element. For older browsers, you could use onerror to replace it with a different image format.

You can also put SVG as a background image. And you use them as data-URLs and just write out the SVG in your stylesheet.

Building on that, there’s a tool called Grunticon that generates and regenerates CSS whenever you make changes to an image. It also generates a preview document for you.

JavaScript

Lastly, there’s JavaScript. The trick is to stay off the critical path. Load just as much as you need up front, so you can load more later on.

Scott uses a handful of variables to determine what needs to be loaded or not:

1. Broad qualification. Does the browser support “only all”? Scott uses YepNope to test and if the test comes back positive, he loads in his global JavaScript.
2. Browser features. Are touch events supported? Again, Scott uses YepNope to test before loading JavaScript that uses touch.
3. Environmental conditions. Media queries, basically.
4. Template type. Define in your markup what kind of page this is (using a meta element e.g. “shoppingcart”. Then test whether we need shoppingcart.js.

You can even load CSS with YepNope but be careful. You could use it for fonts, for example, after you’ve tested that @font-face is supported.

Dealing with third-party content is tricky—it’s blocking. The Twitter embed code for tweets now includes an async attribute. It’s pretty well supported in modern browsers.

On the Boston Globe, they had to deal with ads. Nightmare! They used iframes.

But the main idea here is: defend the critical path. Develop responsively and responsibly. Today we have the tools to build rich experiences without excluding anyone.

The Responsive Day Out is only two weeks away. Exciting!

If you have a ticket, just print it out (or bring along an electronic version on some kind of screen) and you’re good to go. If you didn’t get your Eventbrite ticket, let me know and I can resend it.

If didn’t get a ticket, sorry. But all is not lost. In my experience, it’s at this time—in the final run-up to the event—that ticket-holders start to bail, for whatever reasons: clashing events, work duties, illness, or whatever. We’re not offering any refunds, but people can swap tickets. So if you can’t make it, give a shout-out on Twitter: I can guarantee that there are plenty of people willing to take that ticket off your hands.

Remember, this isn’t going to be a typical Clearleft conference: a lot of the things that you would expect to get as standard at a conference won’t be on offer. No badges. No lanyards. No banners. No sponsor stands. And if you want to get a tea or coffee from the bar in the Brighton Dome, you’ll have to pay for it (although we will have coffee cart from Small Batch Coffee on hand to dish out free flat whites).

Here’s how I’ve got the day planned:

9:00 – 10:00	Registration
10:00 – 10:20	Sarah Parmenter
10:20 – 10:40	David Bushell
10:40 – 11:00	Tom Maslen
11:00 – 11:15	Chat with Sarah, David, and Tom
11:15 – 11:45	Break
11:45 – 12:05	Richard Rutter and Josh Emerson
12:05 – 12:25	Laura Kalbag
12:25 – 12:45	Elliot Jay Stocks
12:45 – 13:00	Chat with Richard, Josh, Laura, and Elliot
13:00 – 14:30	Lunch break
14:30 – 14:50	Anna Debenham
14:50 – 15:10	Andy Hume
15:10 – 15:30	Bruce Lawson
15:30 – 15:45	Chat with Anna, Andy, and Bruce
15:45 – 16:15	Break
16:15 – 16:35	Owen Gregory
16:35 – 16:55	Paul Lloyd
16:55 – 17:15	Mark Boulton
17:15 – 17:30	Chat with Owen, Paul, and Mark

It’s going to be a frenetic action-packed day! Then (after a suitable interval to grab some fish’n’chips or a curry or something) we can head on over to The Loft on Ship Street for the after-party from 7:30pm.

If the Responsive Day Out isn’t enough brain food for you, you might like to know that Remy is running a workshop the day before on mobile web apps. So if you’re coming down to Brighton anyway, you can kill two web technology birds with one stone.

Mark has written down some thoughts on breakpoints in responsive designs. I share his concern that by settling on just a few breakpoints, there’s a danger of returning to the process of simply designing for some set canvases: here’s my “mobile” layout, here’s my “tablet” layout, here’s my “desktop” layout.

In my experience, not all breakpoints are created equal. Sure, there are the points at which the layout needs to change drastically in order for the content not to look like crap—those media queries can legitimately be called breakpoints. But then there are the media queries that are used to finesse page elements without making any major changes to the layout.

When I was working on Matter, for example, there was really only one major breakpoint, where the layout shifts from one column to two. That’s the kind of breakpoint that you can figure out pretty easily from the flow of your content; just resizing your browser window is usually enough to settle on the point that feels right. But there are lots of other media queries in the Matter stylesheet. Those are there to make smaller adjustments to margins, font sizes …the kind of changes that came about from testing on phones and tablets in the device lab.

It feels a bit odd to call them breakpoints, as though the layout would “break” without them. Those media queries are there to tweak the layout. They’re not breakpoints; they’re tweakpoints.

There was once a time when the first thing you would do when you went to visit a newly-launched website was to run its markup through a validator.

Later on that was replaced by the action of bumping up the font size by a few notches—what Dan called the Dig Dug test.

Thanks to Ethan, we all started to make our browser windows smaller and bigger as soon as we visited a newly-launched site.

Open link to post on cool new site. Resize browser window—tiny, huge, tiny. Don’t read essay. Realize. Hang head in shame.I blame @beep.

— Frank Chimero (@fchimero) January 29, 2013

Now when I go to a brand new site I find myself opening up the “Network” tab in my browser’s developer tools to count the HTTP requests and measure the page weight.

Just like old times.

The Responsive Day Out is just seven weeks away. That’s only 49 sleeps!

Alas, Malarkey has had to drop out. Sad face. But, I’ve managed to find another talented web geek from Corby: Tom Maslen of Responsive News fame. Happy face!

Here’s another bit of news: there will be an after-party. Rejoice! Thanks to the generosity of the fine people behind Gridset—that would be Mark Boulton Design then—we’ll be heading to The Loft on Ship Street in the evening to have a few drinks and a good ol’ chinwag. That’s where Remy had the Full Frontal after-party and I thought it worked really, really well. Instead of shouting over blaring music, you could actually have a natter with people.

Many, many thanks to Gridset for making this possible.

In other news of generosity, Drew has offered to work his podcasting magic. Thank you, Drew! And Craig has very kindly offered to record and host video of the event, made possible with sponsorship from Mailchimp. Thank you, Craig! Thank you, Mailchimp!

And get this: A Book Apart are also getting behind the day and they’ll be sending on some books that I plan to give away to attendees who ask questions during the discussiony bits. Thank you, my friends apart!

I could still do with just one more sponsor: I’d really like to hire out the Small Batch coffee cart for the day, like we did at dConstruct. There will be coffee and tea available from the Dome bar anyway, but the coffee is pretty awful. Even though the Responsive Day Out is going to be a very shoestring, grassroots affair, I’d still like to maintain some standards. So if you know of a company that might be interested in earning the gratitude of a few hundred web geeks, let them know about this (it’s around a grand to caffeinate a conference worth of geeks for a day).

If you’ve got your ticket, great; I look forward to seeing you on March 1st. If you don’t; sorry. And before you ask, no, I’m afraid there is no waiting list. We’re not doing any refunds or transfers—if someone with a ticket can’t make it, they can simply give (or sell) their ticket to someone else. We won’t be making any lanyards so we don’t need to match up people to name badges.

So keep an eye on Twitter (especially closer to the day) in case anyone with a ticket is planning to bail.