Tags: tap

73

sparkline

Styling the Patterns Day site

Once I had a design direction for the Patterns Day site, I started combining my marked-up content with some CSS. Ironically for an event that’s all about maintainability and reusability, I wrote the styles for this one-page site with no mind for future use. I treated the page as a one-shot document. I even used ID selectors—gasp! (the IDs were in the HTML anyway as fragment identifiers).

The truth is I didn’t have much of a plan. I just started hacking away in a style element in the head of the document, playing around with colour, typography, and layout.

I started with the small-screen styles. That wasn’t a conscious decision so much as just the way I do things automatically now. When it came time to add some layout for wider viewports, I used a sprinkling of old-fashioned display: inline-block so that things looked so-so. I knew I wanted to play around with Grid layout so the inline-block styles were there as fallback for non-supporting browsers. Once things looked good enough, the fun really started.

I was building the site while I was in Seattle for An Event Apart. CSS Grid layout was definitely a hot topic there. Best of all, I was surrounded by experts: Jen, Rachel, and Eric. It was the perfect environment for me to dip my toes into the waters of grid.

Jen was very patient in talking me through the concepts, syntax, and tools for using CSS grids. Top tip: open Firefox’s inspector, select the element with the display:grid declaration, and click the “waffle” icon—instant grid overlay!

For the header of the Patterns Day site, I started by using named areas. That’s the ASCII-art approach. I got my head around it and it worked okay, but it didn’t give me quite the precision I wanted. I switched over to using explicit grid-row and grid-column declarations.

It’s definitely a new way of thinking about layout: first you define the grid, then you place the items on it (rather than previous CSS layout systems where each element interacted with the elements before and after). It was fun to move things around and not have to worry about the source order of the elements …as long as they were direct children of the element with display:grid applied.

Without any support for sub-grids, I ended up having to nest two separate grids within one another. The logo is a grid parent, which is inside the header, also a grid parent. I managed to get things to line up okay, but I think this might be a good use case for sub-grids.

The logo grid threw up some interesting challenges. I wanted each letter of the words “Patterns Day” to be styleable, but CSS doesn’t give us any way to target individual letters other than :first-letter. I wrapped each letter in a b element, made sure that they were all wrapped in an element with an aria-hidden attribute (so that the letters wouldn’t be spelled out), and then wrapped that in an element with an aria-label of “Patterns Day.” Now I could target those b elements.

For a while, I also had a br element (between “Patterns” and “Day”). That created some interesting side effects. If a br element becomes a grid item, it starts to behave very oddly: you can apply certain styles but not others. Jen and Eric then started to test other interesting elements, like hr. There was much funkiness and gnashing of specs.

It was a total nerdfest, and I loved every minute of it. This is definitely the most excitement I’ve felt around CSS for a while. It feels like a renaissance of zen gardens and layout reservoirs (kids, ask your parents).

After a couple of days playing around with grid, I had the Patterns Day site looking decent enough to launch. I dabbled with some other fun CSS stuff in there too, like gratuitous clip paths and filters when hovering over the speaker images, and applying shape-outside with an image mask.

Go ahead and view source on the Patterns Day page if you want—I ended up keeping all the CSS in the head of the document. That turned out to be pretty good for performance …for first-time visits anyway. But after launching the site, I couldn’t resist applying some more performance tweaks.

Getting griddy with it

I had the great pleasure of attending An Event Apart Seattle last week. It was, as always, excellent.

It’s always interesting to see themes emerge during an event, especially when those thematic overlaps haven’t been planned in advance. Jen noticed this one:

I remember that being a theme at An Event Apart San Francisco too, when it seemed like every speaker had words to say about ill-judged use of Bootstrap. That theme was certainly in my presentation when I talked about “the fallacy of assumed competency”:

  1. large company X uses technology Y,
  2. company X must know what they are doing because they are large,
  3. therefore technology Y must be good.

Perhaps “the fallacy of assumed suitability” would be a better term. Heydon calls it “the ‘made at Facebook’ fallacy.” But I also made sure to contrast it with the opposite extreme: “Not Invented Here syndrome”.

As well as over-arching themes, it was also interesting to see which technologies were hot topics at An Event Apart. There was one clear winner here—CSS Grid Layout.

Microsoft—a sponsor of the event—used An Event Apart as the place to announce that Grid is officially moving into development for Edge. Jen talked about Grid (of course). Rachel talked about Grid (of course). And while Eric and Una didn’t talk about it on stage, they’ve both been writing about the fun they’ve been having having with Grid. Una wrote about 3 CSS Grid Features That Make My Heart Flutter. Eric is documenting the overall of his site with Grid. So when we were all gathered together, that’s what we were nerding out about.

The CSS Squad.

There are some great resources out there for levelling up in Grid-fu:

With Jen’s help, I’ve been playing with CSS Grid on a little site that I’m planning to launch tomorrow (he said, foreshadowingly). I took me a while to get my head around it, but once it clicked I started to have a lot of fun. “Fun” seems to be the overall feeling around this technology. There’s something infectious about the excitement and enthusiasm that’s returning to the world of layout on the web. And now that the browser support is great pretty much across the board, we can start putting that fun into production.

Research on evaluating technology

I’ve spent the past few months preparing a new talk for An Event Apart San Francisco (and hopefully some more AEAs after that). As always happens, I spent the whole time vacillating between thinking “this is good!” and thinking “this is awful!” I’m still bouncing between those poles. I won’t really know whether the talk is up to snuff until I actually give it to a live audience.

Over the past few years, my presentations have built upon one another. Two years ago, my talk was called Enhance! and it set the groundwork for using a layered approach to web design and development. My 2016 talk, Resilience, follows on with a process and examples for that approach (I also set myself the challenge of delivering a talk about progressive enhancement without ever using the phrase “progressive enhancement”).

My new talk goes a bit meta, but in my mind, it’s very much building on the previous talks. The talk is all about evaluating technology. I haven’t settled on a final title, but I was thinking about something obtuse, like …Evaluating Technology.

Here’s my hastily scribbled description:

We work with technology every day. And every day it seems like there’s more and more technology to understand: graphic design tools, build tools, frameworks and libraries, not to mention new HTML, CSS and JavaScript features landing in browsers. How should we best choose which technologies to invest our time in? When we decide to weigh up the technology choices that confront us, what are the best criteria for doing that? This talk will help you evaluate tools and technologies in a way that best benefits the people who use the websites that we are designing and developing. Let’s take a look at some of the hottest new web technologies like service workers and web components. Together we will dig beneath the hype to find out whether they will really change life on the web for the better.

As ever, I’ll begin and end with a long-zoom pretentious arc of history, but I’ll dive into practical stuff in the middle. That’s become a bit of a cliché for my presentations, but the formula works as a sort of microcosm of a good conference—a mixture of the inspirational and the practical, trying to keep a good balance of both.

For this new talk, the practical focus will be on some web technologies that are riding high on the hype cycle right now: service workers, web components, progressive web apps. I’ll use them as a lens for applying broader questions about how we make decisions about the technologies we embrace, and the technologies we reject.

Technology. Now there’s a big subject. It’s literally the entirety of human history. I had to be careful not to go down too many rabbit holes. I’m still not sure if I’ve succeeded, but I’ve already had to ruthlessly cull some darlings.

One of the nice things that the An Event Apart crew started doing was to provide link lists for each talk to attendees. That gives me an opportunity to touch briefly on a topic in the talk itself, but allow any interested attendees to dive deeper at their leisure.

For this talk on evaluating technology, I’ve put together this list of hyperlinks for further reading, watching, listening, and researching…

People

Papers

Presentations

Books

Bookmarklets

Someone at Clearleft asked me a question recently about making bookmarklets. I have a bit of experience in that department. As well as making a bookmarklet for adding links to my own site, there’s the Huffduffer bookmarklet that’s been chugging away since 2008.

I told them that there are basically two approaches:

  1. Have the bookmarklet pop open a new browser window at your service, passing in the URL of the current page. Then do all the heavy lifting on your server.
  2. Have the bookmarklet inject JavaScript to analyse and edit the DOM of the document in the current browser window. All the heavy lifting is done directly in client-side JavaScript.

I favour the first approach. Partly that’s because it makes it easier to update the functionality. As you improve your server-side script, the bookmarklet functionality gets better automatically. But also, if your server-side script doesn’t do its magic, you can always fall back to letting the end user fill in the details.

Here’s an example…

When you click the Huffduffer bookmarklet, it pops open this URL:

https://huffduffer.com/add?page=…

…with that page parameter filled in with whatever page you currently have open. Let’s say I’ve got this page currently open in my browser:

https://adactio.com/journal/6786

If I press the Huffduffer bookmarklet, that will spawn a new window with this URL:

https://huffduffer.com/add?page=https://adactio.com/journal/6786

And that’s all it does. Now it’s up to that page on Huffduffer to figure out what to do with the URL it has been given. In this case, it makes a CURL request to figure out what to use as a title, what to use as a description, what audio file to use, etc. If it can’t figure that out, I can always fill in those fields myself by hand.

I could’ve chosen to get at that information by injecting JavaScript directly into the page open in the browser. But that’s somewhat invasive.

Brian Donohue wrote on Ev’s blog a while back about one of the problems with that approach. Sites that—quite correctly—have a strict Content Security Policy will object to having arbitrary JavaScript injected into their documents.

But remember this only applies to some bookmarklets. If a bookmarklet just spawns a new window—like Huffduffer’s—then there’s no problem. That approach to bookmarklets was dismissed with this justification:

The crux of the issue for bookmarklets is that web authors can control the origin of the JavaScript, network calls, and CSS, all of which are necessary for any non-trivial bookmarklet.

Citation needed. I submit that Huffduffer and Instapaper provide very similar services: “listen later” and “read later”. Both use cases could be described as “non-trivial”. But only one of the bookmarklets works on sites with strict CSPs.

Time and time again, I see over-engineered technical solutions that are built with the justification that “this problem is very complex therefore the solution needs to be complex” (yes, I am talking about web thangs that rely on complex JavaScript). In my experience, it’s exactly the opposite way around. The more complex the problem, the more important it is to solve it in the simplest way possible. It’s the only way of making sure the solution is resilient to unexpected scenarios.

The situation with bookmarklets is a perfect example. It’s not just an issue with strict Content Security Policies either. I’ve seen JavaScript-injecting bookmarklets fail because someone has set their browser cookie preferences to only accept cookies from the originating server.

Bookmarklets are not dead. They may, however, be pining for the fjords. Nobody has a figured out a way to get bookmarklets to work on mobile. Now that might well be a death sentence.

Without delay

When I wrote about mobile Safari adding support for touch-action: manipulation, I finished with this snarky observation:

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Historically, Apple have tied mobile Safari updates to iOS version number increments, and they happen about once a year. But this time, it looks like my snark was unfounded:

On Safari for iOS, the 350 ms wait time to detect a second tap has been removed to create a “fast-tap” response. This is enabled for pages that declare a viewport with either width=device-width or user-scalable=no. Authors can also opt in to fast-tap behavior on specific elements by using the CSS touch-action property, using the manipulation value.

That’s from the release notes for Safari 9.1—a point release.

I’m very pleased to have been absolutely wrong with my prediction of Apple’s timing.

Delay

Mobile browser vendors have faced a dilemma for quite a while. They’ve got this double-tap gesture that allows users to zoom in on part of a page (particularly handy on non-responsive sites). But that means that every time a user makes a single tap, the browser has to wait for just a moment to see if it’s followed by another tap. “Just a moment” in this case works out to be somewhere between 300 and 350 milliseconds. So every time a user is trying to click a link or press a button on a web page, there’s a slight but noticeable delay.

For a while, mobile browsers tried to “solve” the problem by removing the delay if the viewport size had been set to non-scalable using a meta viewport declaration of user-scalable="no". In other words, the browser was rewarding bad behaviour: sites that deliberately broke accessibility by removing the ability to zoom were the ones that felt snappier than their accessible counterparts.

Fortunately Android changed their default behaviour. They decided to remove the tap delay for any site that had a meta viewport declaration of width=device-width (which is pretty much every responsive website). That still left Apple.

I discussed this a couple of years ago with Ted (my go-to guy on the inside of the infinite loop):

He’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.

Well, the Webkit team have announced their solution. As well as following Android’s lead and removing the delay for responsive sites, they’ve also provided a way for authors to declare which elements should have the delay removed using the CSS property touch-action:

Putting touch-action: manipulation; on a clickable element makes WebKit consider touches that begin on the element only for the purposes of panning and pinching to zoom. This means WebKit does not consider double-tap gestures on the element, so single taps are dispatched immediately.

So to get the behaviour I was hoping for—no delay on focusable elements—I can add this line to my CSS:

a, button, input, select, textarea, label, summary {
  touch-action: manipulation;
}

That ought to do it. I suppose I could also throw [tabindex]:not([tabindex="-1"]) into that list of selectors.

It probably goes without saying, but you shouldn’t do:

* { touch-action: manipulation; }

or:

body { touch-action: manipulation; }

That default behaviour of touch-action: auto is still what you want on most elements.

Anyway, I’m off to update my CSS even though this latest fix probably won’t land in mobile Safari until, oh ….probably next October.

Links from a talk

I’m coming to a rest after a busy period of travelling and speaking. In the last five or six weeks I’ve been to Copenhagen, Freiburg, Prague, Portland, Seattle, and Austin.

The trip to Austin was lovely. It was so nice to be there when it wasn’t South by Southwest (the infrastructure of the whole town creaks under the sheer weight of the event). I wasn’t just there to eat tacos and drink beer in the sunshine. I was there to talk at An Event Apart.

Like I said months before the event:

Everyone in the line up is one of my heroes.

It was, as always, a great event. A personal highlight for me was getting to meet Lara Hogan for the first time. She was kind enough to sign my copy of her fantastic book. She gave an equally fantastic talk at the conference, featuring some of the most deftly-handled Q&A I’ve ever seen.

I spoke at the end of the conference (no pressure!), giving a brand new talk called Resilience—I gave a shortened version at Coldfront and Smashing Conference but this was my first chance to go all out with an hour long talk. It was my chance to go full James Burke.

I assembled some related links for the attendees. Here they are…

Books

References

Resources

Related posts on adactio.com

Here’s a readlist of those links.

Further reading

Here’s a readlist of those links.

See also: other links tagged with “progressive enhancement” on adactio.com

100 words 016

A Dao of Web Design by John Allsopp is a document that stands outside of time. It was a perfectly crafted message for its own era, and amazingly it’s even more relevant now, a full fathom fifteen years later.

We once took on the tropes of print design and tried to apply them to the web. I fear that today we run the risk of treating web development no different to other kinds of software development, ignoring the strengths of the web that John highlighted for us. Flexibility, ubiquity, and uncertainty: don’t fight them as bugs; embrace them as features.

100 words 011

The time had come for Jeremy to leave Brighton. He was being called away to the far shores of the Pacific Northwest. What would have once been a sea voyage and overland trek lasting for weeks and months took him just nine hours in the belly of a flying machine. Having made landfall in Seattle he then had to stand in front of a room full of his peers at An Event Apart and speak to them about progressive enhancement. Jeremy tries to remain humble but as he stepped off that stage, two words went through his mind: “Nailed. It!”

100 words 009

Last year at An Event Apart in Seattle I was giving a talk about long-term thinking on the web, using The Session as a case study. As a cheap gimmick, I played a tune on my mandolin during the talk.

Chris Coyier was also speaking. He plays mandolin too. Barry—one of the conference attendees—also plays mandolin. So we sat outside, passing my mandolin around.

Barry is back this year and he brought his mandolin with him. I showed him an Irish jig. He showed me a bluegrass tune. Together we played a reel that crossed the Atlantic ocean.

Talking and travelling

I’m in America. This is a three-week trip and in those three weeks, I’m speaking at four conferences.

That might sound like a fairly hectic schedule but it’s really not that bad at all. In each place I’m travelling to, travel takes up a day, the conference portion takes up a couple of days, but I still get a day or two to just hang out and be a tourist, which is jolly nice.

This sojourn began in Boston where I was speaking at An Event Apart. It was—as ever—an excellent event and even though I was just speaking at An Event Apart in Seattle just a few weeks ago, there were still plenty of fresh talks for me to enjoy in Boston: Paul talking about performance, Lea talking about colour in CSS, Dan talking about process, and a barnstorming talk from Bruce on everything that makes the web great (although I respectfully disagree with his stance on DRM/EME).

My own talk was called The Long Web and An Event Apart Boston was its final outing. I first gave it at An Event Apart DC back in August—it’s had a good nine-month run.

My next appearance at An Event Apart will be at the end of this American trip in San Diego. I’ll be presenting a new talk there. Whereas my previous talk was a rambling affair about progressive enhancement, responsive design, and long-term thinking, my new talk will be a rambling affair about progressive enhancement, responsive design, and long-term thinking.

Sooner or later people are going to realise that I keep hammering home the same message in all my talks and this whole speaking-at-conferences gig will dry up. Until then, I’ll keep hammering home that same old message.

I have two opportunities to road-test this new talk before An Event Apart San Diego (for which, by the way, tickets still remain: use the code AEAKEITH when you’re booking to get $100 off).

I’ll be speaking at Bmoresponsive in Baltimore at the end of this week. Before that, I have the great pleasure (and pressure) of opening the show tomorrow at the Artifact conference here in good ol’ Austin, Texas (and believe it or not, you can still get a ticket: this time use the code ADACTIO100 when you’re booking to get $100 off).

Until then, I have some time to wander around and be a tourist. It is so nice to be here in Austin when it’s not South by Southwest. I should probably fretting over this talk but instead I’m spending my time sampling tacos and beers in the sunshine.

America

I’ve just come back from a multi-hop trip to the States, spanning three cities in just over two weeks.

It started with an all-too-brief trip to San Francisco for Science Hack Day, which—as I’ve already described—was excellent. It was a shame that it was such a flying visit and I didn’t get to see many people. But then again, I’ll be back in December for An Event Apart San Francisco.

It was An Event Apart that took me to my second destination: Austin, Texas. The conference was great, as always. But was really nice was having some time afterwards to explore the town. Being in Austin when it’s not South by Southwest is an enjoyable experience that I can heartily recommend.

Christopher and Ari took me out to Lockhart to experience Smitty’s barbecue—a place with a convoluted family drama and really, really excellent smoked meat. I never really “got” Texas BBQ until now. I always thought I liked the sauced-based variety, but now I understand: if the BBQ is good enough, you don’t need the sauce.

For the rest of my stay, Sam was an excellent host, showing me around her town until it was time for me to take off for New York city.

To start with, I was in Manhattan. I was going to be speaking at Future Of Web Design right downtown on 42nd street, and I showed up a few days early to rendezvous with Jessica and do some touristing.

We perfected the cheapskate’s guide to Manhattan, exploring the New York Public Library, having Tiff show us around the New York Times, and wrangling a tour of the MoMA from Ben Fino-Radin, who’s doing some fascinating work with the digital collection.

I gave my FOWD talk, which went fine once the technical glitches were sorted out (I went through three microphones in five minutes). The conference was in a cinema, which meant my slides were giganormous. That was nice, but the event had an odd kind of vibe. Maybe it was the venue, or maybe it was the two-track format …I really don’t like two-track conferences; I constantly feel like I’m missing out on something.

I skipped out on the second day of the conference to make my way over the bridge to Brooklyn in time for my third trip to Brooklyn Beta.

This year, they tried something quite different. For the first two days, there was a regular Brooklyn Beta: 300 lovely people gathered together at the Invisible Dog, ostensibly to listen to talks but in reality to hang out and chat. It was joyous.

Then on the third and final day, those 300 people decamped to Brooklyn’s Navy Yard to join a further 1000 people. There we heard more talks and had more chats.

Alas, the acoustics in the hangar-like space battled against the speakers. That’s why I made sure to grab a seat near the front for the afternoon talks. I found myself with a front-row seat for a series of startup stories and app tales. Then, without warning, the tech talks were replaced with stand-up comics. The comedians were very, very good (Reggie Watts!) …but I found it hard to pay attention because I realised I was in a living nightmare: somehow I was in the front-row seat of a stand-up comedy show. I spent the entire time thinking “Please don’t pick on me, please don’t pick on me, please don’t…” I couldn’t sneak out either, because that would’ve only drawn attention to myself.

But apart from confronting me with my worst fears, Brooklyn Beta was great …I’m just not sure it scales well from 300 to 1300.

And with that, my American sojourn came to an end. I’m glad that the stars aligned in such a way that I was able to hit up four events in my 16 day trip:

August in America, day twenty-five

Today was the second day of An Event Apart Chicago and I kicked things off with my talk The Long Web. But this time I introduced a new variable into the mix—I played a bit of mandolin.

A Man and His Music: Jeremy Keith at An Event Apart Chicago 2013

It was relevant …honest. I was talking about the redesign and relaunch of The Session, which involved giving a bit of background on traditional Irish music, so it seemed appropriate to demonstrate with a hornpipe. I screwed it up a little bit, but people didn’t seem to mind.

Jeremy Keith at An Event Apart Chicago 2013

Once I was done with my talk, I was able to relax and enjoy an excellent presentation by Adrian on interface details; lots of great food for thought in there.

Once the day was done, myself, Jessica, Jason, Ethan, Brad, Kristina, and Karen made our way to The Purple Pig, where we proceeded to eat all the food. Excellent food and excellent company; a good way to spend my last night in Chicago …and indeed, the United States.

Tomorrow I begin the journey home.

August in America, day twenty-four

Today was the opening day of An Event Apart Chicago so I spent the whole day at the back of the room absorbing the knowledge bombs being dropped.

As usual, the quality of the talks was excellent, and quite a few of them set me up nicely for my talk tomorrow. I’ll be reiterating a lot of what Ethan said about progressive enhancement—no surprise there.

I’m on first thing tomorrow. That’s the hangover slot (thanks for booze, Media Temple). I’m kind of nervous about the talk. Now that I’ve given it once already—at An Event Apart DC earlier this month—I shouldn’t be worried, but I’m going to attempt something a bit new tomorrow. If it doesn’t work, I’ll be left with egg on my face.

Wish me luck.

Double tap delay

Even though my encounter with Ted 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 Ted says that he sometimes still likes to double tap to zoom even in responsive designs. He’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?

August in America, day four

Today was day two of An Event Apart DC and I opened up the show. I was very nervous because this was a brand new talk. I wasn’t sure whether I would come in way under time, or way over time, or whether anybody would be interested in the subject matter.

As it turned out, the timing was okay. I got through a lot of stuff faster than I was expecting, so that left me time for a good ol’ rant towards the end of the talk. I ranted about progressive enhancement. I ranted about digital preservation. I ranted about “the cloud”. I guess I shouldn’t be surprised that people think I’m an angry person (I’m really not; honest).

It seemed like people really enjoyed the talk. There were lots of positive tweets and lots of people came up to me to tell me how much they enjoyed the “big picture” nature of my talk. But I’m not going to be complacent about it: a few years ago at An Event Apart in Boston I gave a less technical talk than usual and it seemed like people really liked it (positive tweets, kind words, etc.) …but then when the feedback surveys were totted up, I ended up getting the lowest rank I had ever received. So time will tell what the audience really thought of my talk today.

In any case, I enjoyed it. As usual, I just got up on stage and geeked out for an hour to a captive audience about stuff that really excites me. How cool is that?

I was glad to have the talk done. Afterwards I could relax and enjoy all the other talks, and have a bit of a chat with some of the smart and friendly attendees.

Now that the conference is over, it’s time for me to depart Alexandria. Next stop: Philadelphia.

August in America, day three

It was a beautiful day today but I spent most of it indoors. Today was the first day of An Event Apart DC here in Alexandria. As usual, the standard of talks was ludicrously high.

An Event Apart often feels like getting a snapshot of the current state of web technologies and best practices. I really like it when themes emerge from multiple talks—those emergent themes are usually the hot topics of modern web design and development. Today I felt like there were two prominent themes:

  1. process and
  2. devices.

Both Samantha and Jason talked about process and workflow from different perspectives. I had seen Jason’s talk at New Adventures in Nottingham but he’s such a joy to listen to, I gladly soaked it up again. Listening to Samantha reinforced my opinion that she’s one of the smartest designers working today. I found myself nodding my head enthusiastically during both talks.

Luke and Grigs both showed us what an amazingly diverse set of devices we have to deal with these days. I know that some people find this situation depressing, but I find it quite energising. Let’s face it, the web was getting pretty boring there for a while a few years back. You certainly can’t say that about the current browser/device landscape.

Rounded out with Jeffrey and Karen’s content-focused calls-to-arms—one at the start of the day and the other at the end—it was a great day one.

I’m speaking first thing tomorrow. That’s right; I’ve got the hangover slot.

This is a brand new untested talk. I had planned to give a run-through to the guys at Clearleft but somehow that never happened, so tomorrow will literally be the very first time I’m giving this talk. That gives it a certain frisson and adds an air of excitement and tension. It also means I’m very, very nervous.

I think it’s a good talk …but I’m not sure how it’s going to go down with this crowd. While it will have some practical tips scattered throughout, it’s mostly going to be a fairly personal talk about a personal project that I’m using as a lens to look at long-term web design and development. That might put some people off, who would rightly argue that it isn’t directly applicable to their day-to-day work, but I’m just going to have to accept that. It’s going to be interesting to see what people make of it.

I’m excited and nervous. I probably won’t get much sleep tonight.

An Event Alarm

I’m at An Event Apart. Somewhere. It’s in a room in a hotel. The room is smaller than the usual ballroom-sized venue, but I know it’s An Event Apart because Luke Wroblewski is giving a talk. I think it’s a talk about how he led a group of people who were trapped in the desert to safety. Somehow he saved them with data.

I’m speaking next. But there’s a pressure on my bladder that I need to relieve. I’ve got another ten or fifteen minutes ‘till my talk so I reckon I have enough time. I go out into the corridor in search of a toilet. I find one and do what I need to do.

But when I go back out into the corridor, I can’t immediately find the room that the conference is in. That’s okay, I think. I’ve still got time. But as I wander the corridor more and more, I start to panic. I’m supposed to be on in five minutes! Now the hotel building seems to be cavernous, like one of those Las Vegas hotel-casino hybrids that contain a labyrinthine mini-city. I’m supposed to be on stage now! Up escalators, down stairs …I can’t find the room. I’m really panicking now. I was supposed to be on stage five ago …Jeffrey’s going to kill me. I grab someone who looks like a hotel employee and beg him to help me: I was supposed to be on stage ten minutes ago! But he can’t help me. I’m really freaking out.

Then I woke up. I don’t think if I’ve ever had the classic “final exam” dream, but I think this is the closest equivalent.

An Event Apart DC is ten days away. I’m giving a new talk. I thought I was prepared for it. My subconscious begs to differ.

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?

Phones

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.

Tablets

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.

Hybrid

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?

Desktop

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.

Responsive and Responsible by Scott Jehl

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.