Promo

The lovely and talented Paul and Kelly from Maxine Denver were in the Clearleft office to do some video work last week. After finishing a piece I was in, I suggested they keep “rolling” (to use an anachronistic term) so I could do a little tongue-in-cheek piece about the Clearleft device lab, a la Winnebago Man.

Here’s the result.

It reminded me of something, but I couldn’t figure out what. Then I remembered.

Not tumbling, but spiralling

Tumblr is traditionally the home of fun and frivolous blogs: Moustair, Kim Jong-Ill Looking At Things, Missed High Fives, Selleck Waterfall Sandwich, and the weird but wonderful Consume Consume (warning: you may lose an entire day in there).

But there are also some more thoughtful collections on Tumblr:

• Abondonedography documents the strangely hypnotic lure of abandoned man-made structures, as does Abandoned Playgrounds.
• Adiphany shows some of the cleverer pieces from the world of advertising.
• Histories Past is a collection of fascinating historical photographs.
• Found is also a collection of photographs, all of them from the archives of National Geographic, many of them hitherto-unpublished.

It’s going to be real shame when Tumblr shuts down and deletes all that content.

Of course that will never happen. Just like that never would’ve happened to Posterous or Pownce or Vox or GeoCities — publishing platforms where millions of people published a panoply of posts from the frivolous to the sublime, all of them now destroyed, their URLs purged from the web.

That reminds me: there’s one other Tumblr-hosted blog I came across recently: Our Incredible Journey documents those vile and disgusting announcements that start-ups make when they get acquired by a larger company, right before they flush their user’s content (and trust) down the toilet.

Oh, and I’ve got a Tumblr blog too. I just use it for silly pictures, YouTube videos, and quotes. I don’t want it to hurt too much when it gets destroyed.

Placehold on tight

I’m a big fan of the placeholder attribute introduced in HTML5. In my book, I described the cowpath it was paving:

1. When a form field has no value, insert some placeholder text into it.
2. When the user focuses on that field, remove the placeholder text.
3. If the user leaves the field and the field still has no value, reinstate the placeholder text.

That’s the behaviour that browsers mimicked when they began implementing the native placeholder functionality. I think Opera was first. Now all the major browsers support it.

But in some browsers, the details of that behaviour have changed slightly. In Chrome and Safari, when the user focuses on the field, the placeholder text remains. It’s not until the user actually begins to type that the placeholder text is removed.

Now, personally speaking, I’m not keen on this variation. It seems that I’m not alone. In an email to the WHATWG, Markus Ernst describes the problems that he’s noticed in user-testing where users are trying (and, of course, failing) to select the placeholder text in order to delete it before they begin typing.

It seems that a relevant number of users do not even try to start typing as long as the placeholder text remains visible.

But this isn’t so clear-cut. A quick straw poll at the Clearleft showed that opinions were divided on this. Some people prefer the newer behaviour …however it quickly became apparent that the situations they were thinking of were examples of where placeholder has been abused i.e. attempt to act as a label for the form field. In that situation, I agree, it would definitely be more useful for the labelling text to remain visible for as long as possible. But that’s not what placeholder is for. The placeholder attribute is intended to show a short hint (such as an example value)—it should be used in addition to a label; not instead of a label. I tend to use example content in my placeholder value and I nearly always begin with “e.g.”:

<label for="fn">Your Name</label>
<input id="fn" name="fn" type="text" placeholder="e.g. Joe Bloggs">

(Don’t forget: generating placeholders from datalists can be a handy little pattern.)

So if you’re using placeholder incorrectly as a label, then the WebKit behaviour is probably what you want. But if you’re using placeholder as intended, then the behaviour in the other browsers is probably more desirable. If you want to get Safari and Chrome to mimic the behaviour of the other browsers, here’s a handy bit of CSS (from that same thread on the WHATWG mailing list):

[placeholder]:focus::-webkit-input-placeholder {
  color: transparent;
}

You can see that in action on search forms at The Session for recordings, events, discussions, etc.

Now, if you do want your label—or input mask—to appear within your form field and remain even when the user focuses on the field, go ahead and do that. Use a label element with some CSS and JavaScript trickery to get the effect you want. But don’t use the placeholder attribute.

Off-canvas horizontal lists

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.

Slow glass

The day that Opera announced that it was changing its browser to use the WebKit rendering engine, I was contacted by .net magazine for my opinion on the move. My response was:

I have no opinion on this right now.

Frankly, I’m always quite amazed at how others can form opinions so quickly. Sometimes opinions are formed and set on technologies before they’re even out and about in the world: little printers, Apple watches, Google glasses…

The case against Google Glass seemed to be a done deal after Mark Hurst published The Google Glass feature no one is talking about:

The key experiential question of Google Glass isn’t what it’s like to wear them, it’s what it’s like to be around someone else who’s wearing them.

It’s a very persuasive piece of writing and it certainly gave me food for thought. Then Eric wrote Glasshouse:

Our youngest tends to wake up fairly early in the morning, at least as compared to his sisters, and since I need less sleep than Kat I’m usually the one who gets up with him. This morning, he put away a box he’d just emptied of toys and I told him, “Well done!” He turned to me, stuck his hand up in the air, and said with glee, “Hive!”

I gave him the requested high-five, of course, and then another for being proactive. It was the first time he’d ever asked for one. He could not have looked more pleased with himself.

And I suddenly realized that I wanted to be able to say to my glasses, “Okay, dump the last 30 seconds of livestream to permanent storage.”

Now I’ve got another interesting, persuasive perspective on the yet-to-be-released product.

Just as we can be very quick to label websites and social networks as dead (see Flickr), I worry if we’re often too quick to look for the worst aspects in any new technology.

Natalia has written a great piece called No, let’s not stop the cyborgs in reaction to the over-the-top Luddism of the Stop The Cyborgs movement:

Healthy criticism and skepticism towards technologies and their impact on society is necessary, but framing it in a way that discredits all people with body and sense enhancing technologies is othering.

Now we get in to the question of whether technology can be inherently “good” or “bad.” Kevin Kelly avoids such loaded terms, but he does ascribe some kind of biased trajectory to our tools in his book What Technology Wants.

Natalia writes:

It’s also important to remember that technologies themselves aren’t always ethically questionable. It’s what we do with them that can be positive or contribute to suffering and misery. Sometimes the same technology can be used to help people and to simultaneously ruin lives for profit.

A fair point, but one that is most commonly used by the pro-gun lobby—proponents of a technology that I personally find very hard to view as neutral.

But the point remains: we seem to have a natural impulse to immediately think of the worst that could happen with any new technology (though I’m just as impatient with techno-utopians as I am with techno-dystopians). I really enjoy watching Black Mirror but its central question grows wearisome after a while. That question is “What’s the worst that could happen?”

I am, once more, reminded of the danger of self-fulfilling prophesies when it comes to seeing the worst in technologies like Google Glass. As Matt Webb’s algorithm puts it:

It’s not the end of privacy because it’s all newly visible, it’s the end of privacy because it looks like it’s the end of privacy because it’s all newly visible.

I was chatting with fellow sci-fi fan Jon Tan about Kim Stanley Robinson, whose work I (shamefully) haven’t dived into yet. Jon told me that a good starting point would be the Three Californias trilogy. It consists of one utopia, one dystopia, and one apocalypse. I like the sound of that.

Those who take an anti-technology stance, or at least an overly-negative stance on technology, are often compared to the Amish. But as Stewart Brand is quick to point out, the Amish don’t reject technology—instead, they take their time in deciding whether a new technology will, on balance, be better or worse for their society in the long term:

The Amish seek to master technology rather than become its slave.

I think that techno-utopians and -dystopians alike can appreciate that.

Told you so

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?

Tools of the trade

I remember when Rebecca wrote about A Baseline for Front-End Developers:

I think we’re seeing the emphasis shift from valuing trivia to valuing tools.

I know that Paul places a similar emphasis on the value of front-end development tools. Personally, I’ve always been lax with keeping up to date with start-of-the-art tools. I’ve been working on the web long enough to see yesterday’s cutting-edge tools stagnate or fall out of favour.

Still, I should really do more to keep up. There are a few design tools cropping up that I should really investigate.

LayerVault and Pixelapse both offer git-style version control for Photoshop, Fireworks, and Illustrator files. Sounds useful.

Then there are the tools that I think could be really useful for making HTML prototypes: Easel is browser-based, while Hammer and Mixture are OS X apps. They’ve all got enough time-saving shortcuts to make them worth investigating further. I wouldn’t use them for production code, but like I said, handy for prototyping.

Responsive audio out

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!

Oh, what a Responsive Day Out that was!

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!

Responsive day soon

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…