Tags: table



Talking with the tall man about poetry

When I started making websites in the 1990s, I had plenty of help. The biggest help came from the ability to view source on any web page—the web was a teacher of itself. I also got plenty of help from people who generously shared their knowledge and experience. There was Jeffrey’s Ask Dr. Web, Steve Champeon’s WebDesign-L mailing list, and Jeff Veen’s articles on Webmonkey. Years later, I was able to meet those people. That was a real privilege.

I’ve known Jeff for over a decade now. He’s gone from Adaptive Path to Google to TypeKit to Adobe to True Ventures, and it’s always fascinating to catch up with him and get his perspective on life, the universe, and everything.

He started up a podcast called Presentable about a year ago. It’s worth having a dig through the archives to have a listen to his chats with people like Andy, Jason, Anna, and Jessica. I was honoured when Jeff asked me to be on the show.

We ended up having a really good chat. It’s out now as Episode 25: The Tenuous Resilience of the Open Web. I really enjoyed having a good ol’ natter, and I hope you might enjoy listening to it.

‘Sfunny, but I feel like a few unplanned themes came up a few times. We ended up talking about art, but also about the scientific aspects of design. I couldn’t help but be reminded of the title of Jeff’s classic book, The Art and Science of Web Design.

We also talked about my most recent book, Resilient Web Design, and that’s when I noticed another theme. When discussing the web-first nature of publishing the book, I described the web version as the canonical version and all the other formats as copies that were generated from that. That sounds a lot like how I describe the indie web—something else we discussed—where you have the canonical instance on your own site but share copies on social networks: Publish on Own Site, Syndicate Elsewhere—POSSE.

We also talked about technologies, and it’s entirely possible that we sound like two old codgers on the front porch haranguing those damn kids on the lawn. You can be the judge of that. The audio is available for your huffduffing pleasure. If you enjoy listening to it half as much as I enjoyed doing it, then I enjoyed it twice as much as you.

Month maps

One of the topics I enjoy discussing at Indie Web Camps is how we can use design to display activity over time on personal websites. That’s how I ended up with sparklines on my site—it was the a direct result of a discussion at Indie Web Camp Nuremberg a year ago:

During the discussion at Indie Web Camp, we started looking at how silos design their profile pages to see what we could learn from them. Looking at my Twitter profile, my Instagram profile, my Untappd profile, or just about any other profile, it’s a mixture of bio and stream, with the addition of stats showing activity on the site—signs of life.

Perhaps the most interesting visual example of my activity over time is on my Github profile. Halfway down the page there’s a calendar heatmap that uses colour to indicate the amount of activity. What I find interesting is that it’s using two axes of time over a year: days of the month across the X axis and days of the week down the Y axis.

I wanted to try something similar, but showing activity by time of day down the Y axis. A month of activity feels like the right range to display, so I set about adding a calendar heatmap to monthly archives. I already had the data I needed—timestamps of posts. That’s what I was already using to display sparklines. I wrote some code to loop over those timestamps and organise them by day and by hour. Then I spit out a table with days for the columns and clumps of hours for the rows.

Calendar heatmap on Dribbble

I’m using colour (well, different shades of grey) to indicate the relative amounts of activity, but I decided to use size as well. So it’s also a bubble chart.

It doesn’t work very elegantly on small screens: the table is clipped horizontally and can be swiped left and right. Ideally the visualisation itself would change to accommodate smaller screens.

Still, I kind of like the end result. Here’s last month’s activity on my site. Here’s the same time period ten years ago. I’ve also added month heatmaps to the monthly archives for my journal, links, and notes. They’re kind of like an expanded view of the sparklines that are shown with each month.

From one year ago, here’s the daily distribution of

And then here’s the the daily distribution of everything in that month all together.

I realise that the data being displayed is probably only of interest to me, but then, that’s one of the perks of having your own website—you can do whatever you feel like.

One day in London

I don’t get up to London all that often—maybe once every few weeks; just long enough for the city’s skyline to have changed again. Yesterday was one of those days out in the big smoke.

I started with a visit to the Royal College of Art to see the work in progress exhibition that’s running until Sunday. Specifically, I wanted to see the project by Monika, who was one third of the immensely talented internship collaboration at Clearleft that produced notice.city. Her current project is called Watching the Watchers, all about undersea cables, surveillance, and audio—right up my alley. I think Ingrid, James, Dan, and Georgina would like it.

Checking out Monika’s work in progress at the RCA. Watching the watchers

After that, I entered a metal tube to be whisked across the city to the Hospital Club, where a room had been booked for a most enjoyable Clearleft event. Anna had organised a second of her roundtable gatherings. This time the theme was “going responsive.”

The idea is to gather people together for one afternoon to share experiences and challenges. Anna invited people from all sorts of organisations, from newspapers to e-commerce and everything in between. Some of them were people we already knew, but most of them had no connection to Clearleft at all.

Everything happened the Chatham House Rule so I can’t tell you the details of who said what, but I can tell you that it was very productive afternoon. Some of the companies represented were in the process of switching to responsive, some had already done it, and some were planning it, so it was a perfect mix.

We began with a variation on the lean coffee technique. Splitting into groups, everyone jotted down some topics that they wanted to discuss. We shared those, grouped them, and voted on which order we would discuss them. Each topic got 5 to 10 minutes of discussion. In my group, we discussed strategy, workflow, tools, and more. We could’ve easily talked for longer. Some outcomes (very badly summarised):

  • The vision and strategy for a responsive redesign needs to be communicated (and sold) up the chain to stakeholders as well as to the designers and developers in the trenches.
  • “Mobile-first” For The Win! Solve the harder problems first.
  • Multi-disciplinary teams For The Win! Works well with Agile too.
  • A pattern libraries is probably the best tool you can have. So pattern libraries For The Win too!

After a break, we switched over in to a sort of open space exercise. Anyone who has a burning question they want answered writes that question down on an oversize post-it and slaps it on the wall. Now we’ve got a room with questions written on different parts of the wall. If you want to take a stab at answering any of those questions, you write it down on a post it note and slap it next to the question. Everyone does this for a while, going from question to question and having lots of good discussion. Then, at the end, we go from question to question, with the person who originally posted the question taking ownership of summarising the answers.

Some of the questions were:

  • How to help people to stop thinking “desktop first”?
  • Should designers code? Should developers design? Or Both?
  • How do you start to deploy a responsive version of an existing site?
  • How do you do responsive ads?
  • What is the best tool to use to create responsive designs?
  • Would every project benefit from a design system? Is it always worth the investment?

You get the idea. The format worked really well; it was the first time any of us had tried it. We slightly over-ran the time we had allotted for the afternoon, but that’s mostly because there was so much meaty stuff to discuss.


With that productive afternoon done, I made my way to the Bricklayer’s Arms, where by lucky coincidence, a Pub Standards meet-up was happening. I went along for a pint and a chat while I waited for rush hour to ease off: I wanted to avoid the crush before I started making my way back to Brighton. See you next time, Londinium.

Designing for Touch by Josh Clark

Josh the Touchmaster is here at An Event Apart Atlanta to tell us about Designing for Touch.

Science! Science and web design. As Scott said, a lot of what we’re doing now is checking the nuances of things we’ve been doing all along. We’re testing our assumptions.

We had web standards. Then we had responsive design. Now there’s a new revelation: there is no one true input for the web.

There are lots of new input mechanisms coming down the pipe, but right now the biggest new one is touch. This talk is about designing for touch.

As of last month, 31% of US adults have tablets. A few years ago, it was zero. The iPad is the fastest-growing consumer product in the history of consumer products. But touch isn’t just for mobile phones and tablets. Touch is on the desktop now too. All desktop web designs have to be touch-friendly now.

The ugly truth is that we’ve thought of web design as primarily a visual design medium. But when you add touch into the mix, it gets physical. It’s no longer just about how your pixels look; it’s about how they feel too. You are not “just” a visual designer now. There are portions of industrial design in what you do: honest-to-goodness ergonomics. In a sense, you’re designing a physical device, because it will be explored by hands. Phones and tablets are blank slates. We provide the interface. How will it feel in the user’s hands? More specifically, how will it feel in one hand?


Thumbs are fantastic. The thumb, along with celebrity gossip, is what separates us from the beasts. There’s a natural thumb-resting area on the iPhone (coming from the bottom left to the centre). That’s why positioning conventions have evolved they way have on iOS—very differently to the desktop: navigation at the bottom instead of the top.

There’s an age-old principle in industrial design: content at the top; controls at the bottom. Now we see that in iOS. But in Android there are assistive buttons at the bottom (just as the industrial design maxim suggests). But now if you put your controls at the bottom too, you’ve got too much going on. So on Android you should be putting your controls at the top. But the drawback is that this is no longer in the thumb-sweeping area.

That’s iOS and Android. What about the web?

There are problems with pinning navigation to either the top or bottom. First of all, position: fixed is really screwy on mobile browsers. Secondly, in landscape (or other limited-height environments), the controls take up far too much room compared to the content. The third problem is also related to space: browser chrome.

Instead, a better pattern is to have a menu control that reveals navigation. The simplest version is when this is simply an internal link to navigation at the bottom of the page. As Luke says, forget HTML5: this is HTML1. Best of all, this pattern leads with the content and follows it with the navigation.

So that’s where things stand with touch navigation on phones:

  • iOS: Controls at screen bottom.
  • Android: Controls at screen top.
  • Web: Controls at page bottom.


What about tablets? This is more likely to be a two-handed grip. Now having controls at the bottom would be really hostile to touch. The phone thumb-zone no longer applies, but thumbs still matter because they could be obscuring controls. Your thumbs are more likely to be on the sides, with easy reach to the top. So put controls in those regions where thumbs can come to rest: the side.

There are some cases where bottom navigation is okay: in an ebook where you’re showing a complicated control …or a map with a draggable interface below it. When you need a control to do browsing or preview for the content above it, the bottom is okay.


The unholy alliance: a laptop with a keyboard combined with a touch-enabled screen. There are lots of them coming down the line.

Mouse and trackpad usage drops off a lot on hybrid devices. There was always the fear of “gorilla arms” with hybrid devices but it turns out that people are gripping the sides of the screen (like a tablet) but when people are jabbing the screen, it’s more like a phone. If you overlay the thumb comfort zone of a hybrid laptop with the thumb comfort zone of a tablet, there’s one area that’s left out: the top …exactly where we put our navigation on laptop/desktop screens.

This is a headache for responsive design. We’ve been correlating small screens with touch. It turns out that screen size is a lousy way to detect a touchscreen. And it’s hard to detect support for touch. So, for now, we’re really just guessing.

But we have top men working on the problem. Top. Men. There’s a proposal in CSS4 for a pointer property. But even then, what will a hybrid device report if it supports trackpad, keyboard, mouse and touch?


All desktop designs have to be touch-friendly. This is going to require a big change in our thinking. For a start, it’s time to bid farewell to hover events, certainly for crucial content …maybe it can be used for enhancements.

Given the thumb zones on tablets and hybrids, we can start putting frequent controls down the side—controls that stay in view even when the content is scrolled. Just to be clear: don’t put your main navigation there—put the controls that people actually use. Sorry, but people don’t actually use your main navigation. People use main navigation only as a last resort.

Quartz uses a very thumb-friendly layout. But how big should the touch targets be? It turns out …seven millimeters; the tip of a finger. Use nine millimeters if you really need to be safe.

I don’t know about you, but I’m not using millimeter as a unit in my CSS. But standards can help here. A pixel is defined in CSS2.1 to have a set millimeter size. But that doesn’t factor in the reality of dynamic viewports: zooming, pinching, scaling. Devices still report they’re actual physical size; the hardware pixels, that have nothing to do with the calculated web pixels.

On the iPhone we arrive at this magical 44 pixel number, which is repeated over and over throughout the UI. As long as one dimension is 44 pixels, you can squeeze the other dimension down to 29 pixels: 44x29 or 29x44. On iOS, that unit is repeated for a rhythm that just feels right: 44, 88, etc. The interface is designed not just for the hand, but of the hand. Use that rhythm, even on desktop screens.

That’s lovely and elegant. Digital watches are not. Touch targets need to be a certain size.

Now these optimisations mean there’s inevitably some constraint. But that can be a good thing: you might have to reduce what’s on your screen, and that means that your interface will be more focused. Clarity trumps density.

But simplicity isn’t always a good thing. Complexity has become a dirty word, but sometimes it’s needed. People don’t want a dumbed-down interface that won’t let them do everything.

And when you don’t have space constraints, that doesn’t mean you should fill up the space with crap. Aim for clarity, no matter what the size of the screen. On a smaller screen, that can be a more conversational, back-and-forth interaction, requesting and revealing information; question, answer; ask, receive. This progressive disclosure requires more taps, but that’s okay. Extra taps and clicks aren’t evil. When done right, they can actually be better because they provide clarity and invite conversation. As long as every tap is a quality tap that provides information, and helps complete a task, they are not evil.

But the long scroll …that is evil. That’s how kittens get killed.

Luke has documented the off-canvas pattern as a way of pushing some information off-screen. It’s kind of like a carousel. So instead of everything being stacked vertically, there can be sections that are navigated horizontally. That’s what Josh and Ethan did on the site for People magazine on small screens.

So for desktop interfaces, these are the points to remember:

  • Hover is an enhancement
  • Bottom left for controls.
  • Big touch targets.
  • 44px rhythm.
  • Progressive disclosure.

But even though Josh has been talking all about the touch interface, it’s worth remembering that sometimes the best interface is no interface at all. And we need to stop thinking about input mechanisms as singular things: they can be combined. Think about speech + gesture: it’s literally like magic (think: Harry Potter casting a spell). Aral’s hackday project—where he throws content from the phone to the Kinect—gets a round of applause. Now we’ve got Leap Motion on its way. These things are getting more affordable and available. So we could be bypassing touch completely. We can move the interface off the screen entirely. How can we start replacing clumsy touch with the combination of all these sensors?

Digital is growing more physical. Physical is growing more digital. Our job is becoming less about pixels on screens and more about interacting with the world. We have to be willing to challenge established patterns. We have to think. We have to use our brains.


Right after I wrote about combining flexbox with responsive design—to switch the display of content and navigation based on browser size—I received an email from Raphaël Goetter. He pointed out a really elegant solution to the same use-case that makes use of display:table.

Let’s take the same markup as before:

<div role="main">
<p>This is the main content.</p>
<nav role="navigation">
<p>This is the navigation.</p>
<li><a href="#">foo</a></li>
<li><a href="#">bar</a></li>
<li><a href="#">baz</a></li>

The source order reflects the order I want on small-screen devices (feature phones, smart phones, etc.). Once the viewport allows it, I’d like to put that navigation at the top. I can do this by wrapping some display declarations in a media query:

@media screen and (min-width: 30em) {
    body {
        display: table;
        caption-side: top;
    [role="navigation"] {
        display: table-caption;

That’s it. It works much like box-orient:vertical with box-direction:reverse but because this is good ol’ CSS 2.1, it’s very well supported.

We can solve the other issue too: making those list items display horizontally on larger screens:

[role="navigation"] ol {
    display: table-row;
[role="navigation"] ol li {
    display: table-cell;

Once again, I’ve put a gist up on Github (get me! I’m like a proper computer nerd).

Update: And Remy has put it on JSbin so you can see it in action (resize the live preview pane).

So there you go: we’ve at least two different mechanisms in CSS to re-order the display of content and navigation in response to screen real-estate. The default is content first, navigation second—a pattern that Luke talked about in this interview with Jared:

Yeah, one of the design principles that I’ll be talking on the tour about, for mobile, is content first, navigation second; which is just really putting something up right away that somebody can engage with, and saving the pivoting and the navigating for later.

There’s, basically, UI patterns that you can use to make that happen. I’m still surprised at how many, both mobile websites and applications, the first thing they give you is a menu of choices, instead of content.

Don’t get me wrong, the menu’s important, and you can get to it, but it’s actually the content that the immediacy of mobile, and the fact that you’re probably on a slower network, and in some cases you’re even paying for your data transfers, right? Giving you a list of choices as your first time experience tends not to work so well.

Luke Wroblewski — Designing Mobile Web Experiences » UIE Brain Sparks on Huffduffer


In case you hadn’t noticed, I’ve got a real thing about portable social networks. And I’m not the only one. At a recent meetup in San Francisco a bunch of the Web’s finest minds got together to tackle this issue. You can track the progress (and contribute) on the microformats wiki.

Ever since then, Brian Oberkirch has been doing a sterling job documenting the issues involved:

Head on over there, read what Brian has to say and join in the conversation in the comments.

Lest you think that this is some niche itch that needs to be scratched, I can tell you from personal experience that everybody I’ve spoken to thinks that is a real issue that needs tackling. Heck, even Wired News is getting upset in the article Slap in the Facebook: It’s Time for Social Networks to Open Up:

We would like to place an open call to the web-programming community to solve this problem. We need a new framework based on open standards. Think of it as a structure that links individual sites and makes explicit social relationships, a way of defining micro social networks within the larger network of the web.

Weirdly, the same article then dismisses XFN, saying Trouble is, the data format doesn’t yet offer any tools for managing friends. That’s kind of like dismissing HTML because it doesn’t offer you a way of managing your bookmarks. XFN is a format—a really simply format. Building a tool to manage relationships would be relatively easy. But you have to have the format before you can have the tool.