Tags: blogging

62

sparkline

Fifteen

My site has been behaving strangely recently. It was nothing that I could put my finger on—it just seemed to be acting oddly. When I checked to see if everything was okay, I was told that everything was fine, but still, I sensed something that was amiss.

I’ve just realised what it was. Last week on the 30th of September, I didn’t do or say anything special. That was the problem. I had forgotten my blog’s anniversary.

I’m so sorry, adactio.com! Honestly, I had been thinking about it for all of September but then on the day, one thing led to another, I was busy, and it just completely slipped my mind.

So this is a bit late, but anyway …happy fifteenth anniversary to this journal!

We’ve been through a lot together in those fifteen years, haven’t we, /journal? Oh, the places we’ve been and the things we’ve seen!

I remember where we were on our tenth anniversary: Bologna. Remember we were there for the first edition of the From The Front conference? Now, five years on, we’ve just been to the final edition of that same event—a bittersweet occasion.

Like I said five years ago:

It has been a very rewarding, often cathartic experience so far. I know that blogging has become somewhat passé in this age of Twitter and Facebook but I plan to keep on keeping on right here in my own little corner of the web.

I should plan something special for September 30th, 2021 …just to make sure I don’t forget.

Someone will read this

After Responsive Field Day I had the chance to spend some extra time in Portland. I was staying with one Andy, with occasional welcome opportunities to hang out with the other Andy.

Over an artisanal, hand-crafted, free-range lunch one day, I took a moment to thank Andy B. I thanked him for a link. Links are very much his stock-in-trade, but there was one in particular that he had shared which stuck in my soul.

It started when he offered a bribe for a good link:

Paul Thompson won the bounty:

The link was to a page on Tilde Town, one of the many old-school web rings set up in the spirit of Paul Ford’s Tilde Club. The owner of this page had taken it upon himself to perform a really interesting—and surprisingly moving—experiment:

  1. Find blog posts where people have written “no one will ever read this”, and
  2. Read them aloud.

I’ve written before about how powerful the sound of a human voice can be. There was something about hearing these posts—which were written with a resigned acceptance of indifference—being given the time and respect to be read aloud. I listened to every single one, sometimes bemused, sometimes horrified, always fascinated.

You should listen to all of them too. They deserve it.

One in particular haunted me. It was written in 2008. After listening to it, I had to know more. I felt creepy and voyeuristic, but I transcribed a sentence from the audio file and pasted it in to Google.

I found her blog on the old my-diary.org domain. She only wrote nine entries in total. Her last one was in November 2009.

That was six years ago. I wonder how things turned out for her. I wonder if life got better for her when she left her teenage years behind. I wonder if she ever found peace.

I hope she’s okay.

Home

There’s nothing quite so tedious as blogging about blogging, but I came across a few heart-warming thoughts recently that it would be remiss of me to let go unremarked, so please indulge me for a moment as I wallow in some meta-blogging.

Marco Arment talks about the trend that many others have noticed, of personal publishing dying out in favour of tweeting:

Too much of my writing in the last few years has gone exclusively into Twitter. I need to find a better balance.

As he rightly points out:

Twitter is a complementary medium to blogging, but it’s not a replacement.

Andy noticed a similar trend in his own writing:

Twitter and Waxy Links cannibalized all the smaller posts, and as my reach grew, I started reserving blogging for more “serious” stuff — mostly longer-form research and investigative writing.

Well, fuck that.

Amber Hewitt also talks about reviving the personal blog:

Someone made an analogy that describes social networks very well. Facebook is your neighborhood, Twitter is your local bar, and your blog is your home. (I guess Instagram is the cafe? “Look what I’m eating!”)

This made me realized I’m neglecting my home. My posts and photos are spread out on different networks and there is no centralized hub.

That reminds me of what Frank said about his site:

In light of the noisy, fragmented internet, I want a unified place for myself—the internet version of a quiet, cluttered cottage in the country.

The wonderful Gina Trapani—who has has publishing on her own site for years now—follows Andy’s lead with some guidelines for short-form blogging:

  • If it’s a paragraph, it’s a post.
  • Negotiate a comfort zone.
  • Traffic is irrelevant.
  • Simplify, simplify.
  • Ask for trusted collaborator feedback.
  • Have fun.

Good advice.

Writing from home

I’m not saying that this is a trend (the sample size is far too small to draw any general conclusions), but I’ve noticed some people make a gratifying return to publishing on their own websites.

Phil Coffman writes about being home again:

I wasn’t short on ideas or thoughts, but I had no real place to express them outside of Twitter.

I struggled to express my convictions on design and felt stifled in my desire to share my interests like I once had. I needed an online home again. And this is it.

Tim Kadlec echoes the importance of writing:

Someone recently emailed me asking for what advice I would give to someone new to web development. My answer was to get a blog and write. Write about everything. It doesn’t have to be some revolutionary technique or idea. It doesn’t matter if someone else has already talked aobut it. It doesn’t matter if you might be wrong—there are plenty of posts I look back on now and cringe. You don’t have to be a so called “expert”—if that sort of label even applies anymore to an industry that moves so rapidly. You don’t even have to be a good writer!

Writer Neil Gaiman is taking a hiatus from Twitter, but not from blogging:

I’m planning a social media sabbatical for the first 6 months … It’s about writing more and talking to the world less. It’s time. I plan to blog here MUCH more, as a way of warming up my fingers and my mind, and as a way of getting important information out into the world. I’m planning to be on Tumblr and Twitter and Facebook MUCH less.

If you are used to hanging out with me on Tumblr or Twitter or Facebook, you are very welcome here. Same me, only with more than 140 characters. It’ll be fun.

Joschi has been making websites for 14 years, and just started writing on his own website, kicking things off with an epic post:

I know that there will be a lot of work left when I’m going to publish this tomorrow. But in this case, I believe that even doing it imperfectly is still better than just talking about it.

That’s an important point. I’ve watched as talented, articulate designers and developers put off writing on their own website because they feel that it needs to be perfect (we are own worst clients sometimes). That’s something that Greg talks about over on the Happy Cog blog:

The pursuit of perfection must be countered by the very practical need to move forward. Our world seems to be spinning faster and faster, leaving less and less time to fret over every detail. “Make, do” doesn’t give any of us license to create crap. The quality still needs to be there but within reason, within the context of priorities.

And finally, I’ll repeat what Frank wrote at the cusp of the year:

I’m doubling down on my personal site in 2014. In light of the noisy, fragmented internet, I want a unified place for myself—the internet version of a quiet, cluttered cottage in the country. I’ll have you over for a visit when it’s finished.

In dependence

Jason Kottke wrote an end-of-the-year piece for the Nieman Journalism Lab called The blog is dead, long live the blog:

Sometime in the past few years, the blog died. In 2014, people will finally notice.

But the second part of the article’s title is as important as the first:

Over the past 16 years, the blog format has evolved, had social grafted onto it, and mutated into Facebook, Twitter, and Pinterest and those new species have now taken over.

Jason’s piece prompted some soul-searching. John Scalzi wrote The Death of the Blog, Again, Again. Colin Devroe wrote The blog isn’t dead. It is just sleeping.:

The advantages to using Facebook should be brought out onto the web. There should be no real disadvantage to using one platform or another. In fact, there should be an advantage to using your own platform rather than those of a startup that could go out of business at any moment.

That’s a common thread in amongst a number of the responses: the specific medium of the blog may certainly be waning, but the idea of independent publishing still burns brightly. Ben Werdmuller sums that feeling up, saying the blog might be dying, but the web’s about to fight back:

If you buy the idea that articles aren’t dying - and anecdotally, I know I read as much as I ever did online - then a blog is simply the delivery mechanism. It’s fine for that to die. Even welcome. In some ways, that death is due to the ease of use of the newer, siloed sites, and makes the way for new, different kinds of content consumption; innovation in delivery.

Kartik Prabhu writes about The Blogging Dead:

In any case, let’s not ‘blog’, let’s just write—on our own personal place on the Web.

In fact, Jason’s article was preceded by a lovely post from Jeffrey called simply This is a website:

Me, I regret the day I started calling what I do here “blogging.”

I know how he feels. I still call what I write here my “journal” rather than my “blog”. Call it what you like, publishing on your own website can be a very powerful move, now more than ever:

Blogging may have been a fad, a semi-comic emblem of a time, like CB Radio and disco dancing, but independent writing and publishing is not. Sharing ideas and passions on the only free medium the world has known is not a fad or joke.

One of the most overused buzzwords of today’s startup scene is the word “disruption”. Young tech upstarts like to proclaim how they’re going to “disrupt” some incumbent industry of the old world and sweep it away in a bright new networked way. But on today’s web of monolithic roach-motel silos like Facebook and Twitter, I can’t imagine a more disruptive act than choosing to publish on your own website.

It’s not a new idea. Far from it. Jeffrey launched a project called Independent’s Day in 2001:

No one is in control of this space. No one can tell you how to design it, how much to design it, when to “dial it down.” No one will hold your hand and structure it for you. No one will create the content for you.

Those words are twelve years old, but they sound pretty damn disruptive to me today.

Frank is planting his flag in his own sand with his minifesto Homesteading 2014

I’m returning to a personal site, which flips everything on its head. Rather than teasing things apart into silos, I can fuse together different kinds of content.

So, I’m doubling down on my personal site in 2014.

He is not alone. Many of us are feeling an increasing unease, even disgust, with the sanitised, shrink-wrapped, handholding platforms that make it oh-so-easy to get your thoughts out there …on their terms …for their profit.

Of course independent publishing won’t be easy. Facebook, Pinterest, Medium, Twitter, and Tumblr are all quicker, easier, more seductive. But I take great inspiration from the work being done at Indie Web Camp. Little, simple formats and protocols—like webmentions—can have a powerful effect in aggregate. Small pieces, loosely joined.

Mind you, it’s worth remembering that not everybody wants to be independent. Tyler Fisher wrote about this on Medium—“because it is easier and hopefully more people will see it”— in a piece called I’m 22 years old and what is this. :

Fighting to get the open web back sounds great. But I don’t know what that means.

If we don’t care about how the web works, how can we understand why it is important to own our data? Why would we try if what we can do now is so easy?

Therein lies the rub. Publishing on your own website is still just too damn geeky. The siren-call of the silos is backed up with genuinely powerful, easy to use, well-designed tools. I don’t know if independent publishing can ever compete with that.

In all likelihood, the independent web will never be able to match the power and reach of the silos. But that won’t stop me (and others) from owning our own words. If nothing else, we can at least demonstrate that the independent path is an option—even if that option requires more effort.

Like Tyler Fisher, Josh Miller describes his experience with a web of silos—the only web he has ever known:

Some folks are adamant that you should own your own words when you publish online. For example, to explain why he doesn’t use services like Quora, Branch, and Google-Plus, Dave Winer says: “I’m not going to put my writing in spaces that I have no control over. I’m tired of playing the hamster.”

As someone who went through puberty with social media, it is hard to relate to this sentiment. I have only ever “leased,” from the likes of LiveJournal (middle school), Myspace (middle school), Facebook (high school), and Twitter (college).

There’s a wonderful response from Gina Trapani:

For me, publishing on a platform I have some ownership and control over is a matter of future-proofing my work. If I’m going to spend time making something I really care about on the web—even if it’s a tweet, brevity doesn’t mean it’s not meaningful—I don’t want to do it somewhere that will make it inaccessible after a certain amount of time, or somewhere that might go away, get acquired, or change unrecognizably.

This! This is why owning your own words matters.

I have a horrible feeling that many of the people publishing with the easy-to-use tools of today’s social networks don’t realise how fragile their repository is, not least because everyone keeps repeating the lie that “the internet never forgets.”

Stephanie Georgopulos wrote a beautiful piece called Blogging Ourselves to Live—published on Medium, alas—describing the power of that lie:

We were told — warned, even — that what we put on the internet would be forever; that we should think very carefully about what we commit to the digital page. And a lot of us did. We put thought into it, we put heart into, we wrote our truths. We let our real lives bleed onto the page, onto the internet, onto the blog. We were told, “Once you put this here, it will remain forever.” And we acted accordingly.

Sadly, when you uncover the deceit of that lie, it is usually through bitter experience:

Occasionally I become consumed by the idea that I can somehow find — somehow restore — all the droppings I’ve left on the internet over the last two decades. I want back the IMed conversations that caused tears to roll from my eyes, I want back the alt girl e-zines I subscribed to, wrote poetry for. I fill out AOL’s Reset Password form and send new passwords to email addresses I don’t own anymore; I use the Way Back Machine to search for the diary I kept in 1999. I am hunting for tracks of my former self so I can take a glimpse or kill it or I don’t know what. The end result is always the same, of course; these things are gone, they have been wiped away, they do not exist.

I’m going to continue to publish here on my own website, journal, blog, or whatever you want to call it. It’s still possible that I might lose everything but I’d rather take the responsibility for that, rather than placing my trust in ”the cloud” someone else’s server. I’m owning my own words.

The problem is …I publish more than words. I publish pictures too, even the occasional video. I have the originals on my hard drive, but I’m very, very uncomfortable with the online home for my photos being in the hands of Yahoo, the same company that felt no compunction about destroying the cultural wealth of GeoCities.

Flickr has been a magnificent shining example of the web done right, but it is in an inevitable downward spiral. There are some good people still left there, but they are in the minority and I fear that they cannot fight off the douchtastic consultants of growth-hacking that have been called in to save the patient by killing it.

I’ve noticed that I’m taking fewer and fewer photos these days. I think that subconsciously, I’ve started the feel that publishing my photos to a third-party site—even one as historically excellent as Flickr—is a fragile, hollow experience.

In 2014, I hope to figure out a straightforward way to publish my own photos to my own website …while still allowing third-party sites to have a copy. It won’t be easy—binary formats are trickier to work with than text—but I want that feeling of independence.

I hope that you too will be publishing on your own website in 2014.

Parsing webmentions

Thanks to everyone who helped me test webmentions that I hacked together at Indie Web Camp last weekend.

Let me explain what web mentions are all about…

Basically, it’s an equivalent to pingback. Let’s say I write something here on adactio.com. Suppose that prompts you to write something in response on your own site. A web mention is a way for you to let me know that your response exists.

If you look in the head of any of my journal posts, you’ll see this link element:

<link rel="webmention" href="http://adactio.com/webmention.php" />

That’s my web mention endpoint: http://adactio.com/webmention.php …it’s kind of like a webhook: a URL that’s intended to be hit by machines rather than people. So when you publish your response to my post, you ping that URL with a POST request that sends two parameters:

  1. target: the URL of my post and
  2. source: the URL of your response.

Ideally your own CMS or blogging system would take care of doing the pinging, but until that’s more widely implemented, I’m providing this form at the end of each of my posts:

Either way, once you ping my web mention endpoint—discoverable through that link rel="webmention"—with those two parameters, I just need to confirm that your post does indeed contain a link to my post—by making a cURL request and parsing your source—and then I return a server response of 202 (Accepted).

Here’s the code for a minimum viable web mention in PHP.

That’s as far as I got at Indie Web Camp but it was enough for me to start collecting responses to posts.

Webmentions as links

The next step is to do something with the responses. After all, I’ve already got the source of each response from those cURL requests.

Barnaby has a written a nice straightforward microformats parser in PHP. I’m using that to check the cURLed source for any responses that have been marked up using h-entry. That’s one of the microformats 2 vocabularies—a much simpler way of writing structured content with microformats.

Aaron, Amber, and Barnaby all sent responses that were marked up with h-entry so now their responses appear in full.

Webmentions as comments

So there you have it. Comments are now open on every journal post on adactio.com …the only catch is that you have to write the comment on your own site. And if you want the content of your post to appear here (instead of just a link) then update your blog post template to include a handful of h-entry classes.

Feel free to use this post as a test. Mark up your blog with h-entry, write a post that links to this URL, and enter the URL of your post in the form below.

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.

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.

It’s a Write/Read Mobile Web by Luke Wroblewski

Luke is at An Event Apart in Atlanta to give his presentation: It’s a Write/Read Mobile Web. He begins by showing us where he lives in Los Gatos in Silicon Valley. Facebook is up the road in Palo Alto. Yahoo is down the road in Sunnyvale, next to a landfill. In between, there’s a little company called AOL. Then there’s Google and YouTube just off Highway One.

So you have a bunch of internet companies in close physical proximity. They are also the top sites in the US when it comes to time spent on the web, by a very wide margin. You would think that the similarities would end there, because they all provide very different services: social networking, email, messaging, search, and video. But they have something in common. They are all write/read experience. They don’t work unless people contribute content to them. You post updates, you send emails, you type in searches, you upload videos.

Tim Berners-Lee said that his original vision for the web was a place where we could all meet and read and write.

This isn’t just a US-centric thing. Looking at the worldwide list of most popular sites, you’ve got the ones mentioned already but also Twitter and Wikipedia, where all the content is contributed by their users. Even Amazon is powered by reviews. This is what makes the web so awesome. It’s not a broadcast medium. It’s a two-way street. It’s interactive.

So what’s the biggest factor that’s changing for all of these sites? Mobile. 67% of Facebook users and 60% of Twitter users are on mobile. If you look at the stats for Facebook, you can see that their growth is coming from mobile. Desktop usage is pretty flat: mobile usage is soaring. Facebook also has a growing segment of mobile-only users. Zuck has defined Facebook now as a mobile company.

When people hear about the growth in mobile, they assume it’s all about content consumption: reading status updates, watching videos, and so on. There’s a myth that small devices are not good for content creation. But if that were true, then wouldn’t that be a huge problem, given the statistics for growth? Facebook and Twitter would have almost no content. But it’s simply not true. Three hours worth of video are uploaded to YouTube every second from mobile devices.

People think that mobile devices are for games, social networking, and entertainment. And it’s true that those are popular activities. But that kind of usage is actually going down. Where is that time going? The fastest growing category is utilities: finding and buying things, financial management, health services, travel planning, etc. Basically, mobile is anything. So if mobile hasn’t effected you yet, it will.

How do we think about this write/read experience? We imagine that 100% of people are consumers: reading, browsing, etc. Then 10% are curators: liking, faving, etc. Finally there’s the 1% that actually create stuff. 1.8% of users provide almost all of Wikipedia’s content. So we naturally focus on the content consumption in our designs, because that’s the biggest number. But Luke thinks it makes sense to flip that on its head. That 1% are your most important users.

Facebook redesigned their content creation flow multiple times, trying to make that “write” experience as good as possible. Same with YouTube’s uploading interface. They both focused relentlessly on the content creation.

So as we shift our attention to mobile, we should be asking: how do we design for mobile creation?

1. One-handed use

Like Luke’s old adage about “one thumb, one eyeball”, this is literally about testing content creation with one thumb. For his startup, Polar, Luke tested the interface with one thumb and timed how long it took. It was tested and designed for a thumb.

“But Luke”, you cry, “Not everyone just uses their thumb on their mobile device screens!” Well, observing 1,333 people using mobiles on the street showed that they pretty much do.

Dan Formosa says we should design for extremes. In Objectified he talked about designing garden shears for someone with arthritis. If it works for that user, it will work well for everyone.

“But Luke”, you cry, “Aren’t you falling prey to the myth of the ‘mobile context’ where the user is in a hurry, using just one hand?” Well, it is true that lots of people use their devices in the home. But even when you’re not out on the street, you’re still using your thumb: using your phone while watching TV.

Focusing on this use case means you can rethink a lot of interactions. As a general principle, Luke advises “don’t let the keyboard come up.” That is, only provide a virtual keyboard as a last resort. Use smart defaults. Let people tap on links or checkboxes instead of typing. If the user needs to enter a location, they could do so by tapping on a map instead of typing in a place name. Provide a date-picker instead of making people type out dates. Let people use sliders for setting values.

When you design for one-handed use, you’re designing for an extreme case. It also forces you to challenge your assumptions.

2. Visually engaging

When you aim to avoid the keyboard, you often come up with more visual solutions, which can be a great opportunity.

Take Snapchat. People express themselves through photos. The Line app is chat, but with a huge amount of emoticons. Chat becomes visual.

The lesson here is not that society is collapsing into sexting, but that images are very powerful on mobile.

Hotel Tonight’s mobile experience is based around big beautiful images.

“But Luke”, you cry “Why are you advocating big images? Isn’t performance the most important thing on mobile?” Well, yes. But instead of just abandoning images, let’s get really creative about how we serve up images. Take, for example, the experimentation around increasing image dimensions while reducing quality, which results in much smaller files with no noticable loss of fidelity.

3. Focused flows

Dwelling on one-handed use and visually engaging imagery are techniques you can use, but you should really focus on simplifying the processes you put people through. Foursquare have drastically simplified their check-in process.

Creativity is all about focusing on something until you find the simplest way to do it.

The Boingo wireless service used to require 23 inputs. They got rid of 11 of them and increased conversion by 34%. That’s great, but they didn’t go far enough. You can always simplify even more.

Hotel Tonight got their flow down to three taps and a swipe. The CEO says that’s a competitive advantage. Just compare how long it takes to book a hotel with their competitors.

It takes big changes to go small.

When taking about forms and input, this might seem like standard design advice: focus and simplify. But keep focusing and simplifying even more.

4. Just-in-time actions

So we’ve seen three different ways to make things simpler, faster, and more focused. But isn’t that really hard on a small screen, with so little real estate?

Instead of providing intro tours (which are more like intro tests), why not provide introductory information only when it’s needed? Apply the same approach to actions. On Polar, there’s an option to hide the keyboard, but that action is only visible when the keyboard appears.

On long pages on Polar, people wanted a way to get back to the top. If you start scrolling upwards, the navbar from the top is overlaid. It detects that you might be trying to get back to the top, and provides the actions you want.

5. Cross-device usage

Everything Luke has talked about so far has been specifically focused on one kind of device: mobile. But we need to keep our eyes on the multi-device write/read web that is emerging. Creation is happening across devices …sequentially and simultaneously.

The simplest example is access. If you’re on a desktop browsing Luke’s site on Chrome, and then you move to Chrome on the iPhone, there’s Luke’s site.

The next cross-device pattern is flow. We want our processes to work across devices. So if I’m on my laptop and I do a search, then I pick up my phone, I want that last input to carry over. On Ebay, you can save a draft listing on the desktop and pick it up later on mobile. On Google Drive, editing is synced simultaneously between all your devices.

Control is another pattern: using one device to tell another device what to do.

Luke hates log-in forms; that’s no secret. Five years ago, he worked on Yahoo Projector which used a scanned barcode to take control of a TV screen with a phone. He wanted to use this to replace log in, but that never happened. But there’s a service called OneID which is tackling the same use case: you can control log-in across devices.

The last example of cross-device usage is push. Going back to that draft listing on Ebay: take a picture on your phone and have that picture show up on the desktop browser view.

People talk about mobile versus desktop, but these are all examples of these different devices working together.

This was just a taster. We’re just getting started with this stuff.

Billboards and Novels by Jon Tan

Jon is at An Event Apart in Atlanta to talk about Billboards and Novels. That means: impact vs. immersion.

Who in the audience has ever had to explain layout and design decisions? And who has struggled to do that? Jon has. That’s why he wants to talk about the differences between designing for impact—to grab attention—and immersion—to get out of the way and allow for absorbing involvement.

Jon examines the difference between interruption and disruption. You want to grab attention, but the tone has to be right. This is how good advertising works. So sometimes impact is a good thing, but not if you’re trying to read.

The web is reading.

Understanding how people read is a core skill for anyone designing and developing for the web. First, you must understand language. There’s a great book by Robert Bringhurst called What Is Reading For?, the summation of a symposium. Paraphrasing Eric Gill, he says that words are neither things, nor pictures of things; they are gestures.

Words as gestures …there are #vss (very short stories) on Twitter that manage to create entire backstories in your mind using the gestures of words.

A study has shown that aesthetics does not affect perceived usability, but it does have an effect on post-use perceived aesthetics. Even though a “designed” and “undesigned” thing might work equally well, our memory the the designed thing is more positive.

Good typography and poor typography appear to have no affect on reading comprehension. This was tested with a New Yorker article that was typeset well, and the same article typeset badly. The people who had the nicely typeset article underestimated how long it had taken them to read it. Objectively it had taken just as long as reading the poorly-typeset version, but because it was more pleasing, it put them in a good mood.

Good typography induces a good mood. And if you are in a good mood, you perform tasks better …and you will think that the tasks took less time. Time flies when you’re having fun.

What about type on screens?

  • David Berlow describes the web as “crude media.”
  • Jonathan Hoefler describes how he produces fonts differently for different media: the idea (behind the typeface) gives rise to a variety of forms.
  • Matthew Carter designed Bell Centennial to work at one size in one environment: the crappy paper of the telephone book. He left gaps in the letterforms for the ink to spread into.
  • The Siri typeface was redrawn anew as SiriCore specifically for the screen.

When Jon is evaluating typefaces, he is aware that some fonts are more optimised for the screen than others. He tests the smallest text first, in the most adverse environment: a really old HP machine running Windows XP. He also looks at language support, and features and variants like lining numerals: what are the mechanics of the font?

We take quiet delight in the smallest details of a typeface.

Legibility is so important. Kevin Larson analysed how we read. We take a snapshot of a bunch of letters, and our brains rearrange them into a word. We read by skipping along lines in “saccades” with pauses or “fixations” that allow us to understand a group of letters before reading on.

Jon tells the story of how Seb was fooled by a spoof Twitter account for the London Olympics. The account name was London20l2 (with a letter L), not London2012 (with the letter one). Depending on the typeface, that difference can be very hard to spot. Here’s a handy string:

agh! iIl1 o0

Stick that into Fontdeck and you’ll get a good idea of the mechanics of the font you’re looking at. You’re looking out for ambiguities that would interrupt the reader.

The same goes for typesetting: use the right quotes and apostrophes; not primes. Use ligatures when they help. But some ligatures are just showing off and they interrupt your reading. Typesetting should help reading, not interrupt or disrupt.

You can use text-rendering: optimizeLegibility but test it. You can use hyphens: auto but test it. You can add a non-breaking space before the last two words in a paragraph to prevent orphans. It will improve the mood.

A good example of interruption is the Ampersand 2012 website. There’s a span on the letter that should receive a flourish. But you can also use expert subsets. You can use Opentype features. There are common and discretionary ligatures. Implement them wisely. Use discretionary ligatures when you want to draw attention, like in a headline.

Scantastic readability. We wander around the page or screen in the same way as we read with saccades: our eyes jump around the place. Our scan path is a roughly Z-shaped pattern. You can design for this scan path: deliberately interrupt …but not disrupt. Jon uses the squint test when he is designing, to see what jumps out and interrupts.

Measure (line-length) is really important. Long lines tire us out. Bringhurst mentioned 45-75 character measures. But the measure is also bound to the prose: the content might be very short and snappy.

Contrast can give you careful, deliberate interruptions. Position, density, size …these are all tools we can use to interrupt without disrupting. The I Love Typography article on The Origins of ABC is a beautiful example of this. Compare it to the disruption of faddish parallax sites.

But there are no rules, just good decisions.

It’s all so emotional. Sometimes there are no words. Think of the masterful storytelling of the first twenty minutes of Wall-E.

We react incredibly quickly to faces. We can see and recognise a human face in 40 milliseconds, before we even consciously process that we’ve seen a face.

When we try to write about music, the result can be some really purple prose.

We have an emotional reaction to faces, colour, music …and type.

Jon demonstrates the effect on us that a friendly typeface has compared to a harsh typeface …even though the friendly typeface is used for the Malay word for “hate” and the harsh typeface is used for the Malay word for “love.” Our amygdala is reacting directly. It’s a physiological, visceral reaction we have before we even understand what we’re looking at.

Fonts are wayfinding apps for emotions. There’s a difference between designing places and designing postcards of places.

The Milwaukee Police News website is very impactful …but there’s no immersion. It doesn’t communicate beyond the initial reaction.

Places are defined by type and form: New York, London, Paris. A website for Barcelona or Brooklyn should reflect the flavour of those places.

All these things combine: impact, immersion, contrast, colour, type. We can affect people’s experiences. We can put them in a better mood.

Type shapes our experience. It paints pictures that echo in our memory long after we’ve left.

Eric Spiekermann said:

Details in typefaces are not to be seen, but felt.

Those details have to work in the greater context (of colour, contrast, layout).

Bruce Lee said:

Don’t think; feel.

Strong Layout Systems by Eric Meyer

Eric is at An Event Apart in Atlanta talking about Strong Layout Systems. Following on from Brother Jeffrey’s presentation, he begins with a reading…

In the beginning Sir Tim created the server and the browser. And the web was without form. And the face of Tim moved over the web. Tim said “Let there be markup.” And there was markup. And he saw that it was good. And he divided structure from appearance.

That decision is quite striking. Think about other mediums. The structure of a book is bound to its appearance.

Here’s a screenshot, courtesy of Grant Hutchinson, of the preferences in the original Mosaic browser. You could define the appearance of any HTML element …as a user. As an author, you couldn’t do that. HTML didn’t support that: it created structure.

As with all creations, there was a fall. As usual, a reptile was involved. In this case it was Mozilla, known by its ancient name of Netscape. They added presentational elements like prompt and presentational attributes e.g. on the hr element. And then there was the table element. Inevitably, it was used for layout. David Siegel wrote the book on this, Creating Killer Websites. It was tables all the way down: tables inside of tables inside of tables, all to create visual appearance.

The backlash came from the Web Standards Project. It got dogmatic there for a while. But we got past that, and we started using CSS. The promise of CSS was visual presentation, for authors and users. We talk about “controlling” presentation with CSS, but remember that theoretically that can be over-ridden by user styles.

But CSS was an appearance system; not a layout system. It wasn’t that complex. You could print out all of CSS1. The only thing in it in any way suited for layout was floats …and that’s not what they were created for: it was basically the CSS equivalent of the align attribute that Netscape had introduced to HTML. So we used floats because that’s all we had. It wasn’t a layout system but we made it one anyway. There were a lot of bugs, but we dealt them in clever—sometimes deranged—ways.

For CSS2, they realised that designers really liked to lay things out (who knew?) so they introduced positioning. But you have to be careful with positioning. It was great …sort of. You can indeed position an element wherever you want …and overlap them.

The first major site to launch with CSS for positioning was Doug’s redesign of Wired.com (it didn’t use floats). The limitations of positioning forced us into certain design patterns. Note the footer on the old Wired site: it sits at the bottom of the central column, not the whole page. That was to avoid overlap. But Eric remembers talking to Doug and it turns out they actually wanted a full-width footer, but they had to work with the tools they had. Positioning lacked the equivalent of clear that you get with floats.

These were hacks. Hacks aren’t a bad thing; they’re often very clever. But hacks limit us. Neither floats nor positioning had the concept of equal height (but tables did).

We’re now getting to the point where can start to revisit our assumptions about what is and isn’t possible with CSS.

We’ve got viewport units: vh and vw—viewport height and viewport width (in percentages relative to the viewport, not the parent element). This is really useful for handheld devices. There’s also the vmin unit that you can use on font sizes so that text scales in relation to viewport size.

Flexible boxes is more commonly called flexbox. Take a horizontal navigation (in an unordered list) and declare it as a flexible box. Then declare that the elements within should “flex” to each use an equal amount of space. There’s a variant justify-content: space-around which will share out the space between the elements equally.

Flexbox comes out of XUL, Gecko’s layout language for browser chrome. This is real layout. It’s not a hack. As an author, you’re declaring how you want things to be laid out, and the browser does it. It’s a good feeling.

You can also use flexbox to make sure that elements within a shared parent have the same height. In fact, that’s the default behaviour. You can also get your flexible boxes to reflow instead of being trapped on the same line. The new “line” will also share out space for the elements equally.

You can set your flexible boxes with whatever units you want, and mix and match them: percentages and ems, for example. You can have flexible and fixed elements together.

Remember The Holy Grail of Layout on A List Apart? It followed soon after the One True Layout. Now you could do it with just a few quick flexbox declarations.

<header></header>
<main>
 <nav></nav>
 <article></article>
 <aside></aside>
</main>
<footer></footer>

main { display: flex; }
nav { width: 13em; flex: none; }
article { width: auto; flex: none; }
aside { width: 20%; flex: none; }

You can also rearrange the visual ordering (using order). You could make the article appear as the third column within main even though it appears second in the markup. The structure is truly separated from the layout.

Flexbox alignments are really interesting, especially baseline, which will vertically align columns according to the first baseline in each column — very handy.

You aren’t restricted to horizontal layout: you can arrange things vertically. We finally get vertical centring.

Beyond flexbox, we have grids. They’re not quite as stable right now, but the basic idea is that you can set up grid lines to “control” page elements and the space between them: grid-definition-columns: (4em) gives you a repeating grid with a grid unit of four ems.

You can have flexbox inside grids and visa-versa: within a grid unit, you can still display: flex. Within a flexible box, you can define grid lines.

But please don’t go and read the grids specification right now. It’s an amalgamation of three different authors’ texts, one of whom has never written a spec before, and one of the examples is completely misleading about how grids work.

There’s a fraction unit—fr—that you can use to define widths, but you can also use it in combination with min-content which is based on the longest piece of content in a unit. This is complicated stuff and even Eric doesn’t quite get it completely. Maybe min-content is better for non-text content.

And remember you can mix and match these modules. Same with CSS regions. Regions aren’t here yet, but they will completely up-end the way we think about document structure: you put all of your content in one element, and you have some empty elements as well. Then you use CSS regions to define how the content from the first element flows into the others. Effectively your document has a structural portion and a skeleton layout portion.

These layout modules are truly new. You might think that we’re familiar with using CSS for layout, but that was always hacking: using tools for a purpose other than that for which they were created. This new modules were created specifically to allow us to create layouts. That really is new. And Eric can’t wait to see what we do with these new tools.

Your own words

There has been a minor outbreak of handwringing and soul-searching amongst bloggers recently. Jon Udell asked Where have all the bloggers gone? Tim Bray responded with his own thoughts on the Blogodammerung. Paul Ford rallied with some straight-up old-fashioned blogging about the rotary dial.

For quite a while now, people have been pointing the finger at Twitter and Facebook, lamenting that these short-form services are time-sucking all their writing energy. There’s probably some truth to that but as harbingers of blogging doom go, they’re pretty weak. Some of us manage to both blog and tweet (I know, right‽).

If your craving to write is satiated by a service that limits you to 140 characters, then maybe blogging was never the right medium for you in the first place. Although, that said, most of the early blogs (or link-logs) tended to have short, snappy updates.

But there’s a more fundamental difference between posting to Twitter, Facebook, Tumblr, or Google+, and posting to your own blog. Unless you’re using a hosted service, your blog belongs to you. I’m not talking about ownership in the sense of copyright—I’m sure all those other services have T and Cs that make sure you retain to the rights to what you write. I’m talking about owning the URLs.

Scott puts it best when he writes Your words are wasted:

You are pouring your words into increasingly closed and often walled gardens. You are giving control - and sometimes ownership - of your content to social media companies that will SURELY fail.

He’s absolutely right. Over a long enough time period, all third-party services will let you down. There was a time when Friendster was too big to fail. There was a time when it wasn’t possible to imagine a web without Geocities. I’ve been burned by Pownce. Magnolia.

When Delicious was going to be “sunsetted” by Yahoo, a lot of people moved to Pinboard, a service that distinguishes itself by having the shocking business model of actually charging for use. That’s good, and it certainly increases its longevity, but it’s still somebody else’s domain. I decided to move my bookmarks over to my own site.

Now that there is much discontent around Twitter’s ongoing metamorphosis into yet another ad-driven media company, people are moving to App.net, a platform that you pay for and whose Alpha service looks a lot like Twitter without the bad parts. But it’s. Still. Somebody. Else’s. Domain.

I suspect that some of the recent blog-handwringing and blog-soul-searching was prompted by the launch of Medium, an intriguing service that seems to be making lack of ownership into a feature rather than a bug. Instead of your words being defined by you, the author, they are subsumed into the collective and defined by their subject matter instead.

That doesn’t appeal to me, but if this feature request from Dave Winer were implemented, I could get behind Medium 100%:

Let me enter the URL of something I write in my own space, and have it appear here as a first class citizen. Indistinguishable to readers from something written here.

I’m a card-carrying Pembertonian. I have no problem with other services syndicating my words but I want to host the canonical copy. That’s what I’m doing with my journal. That’s I’m doing with my links. I’m not doing it with my tweets (unlike Tantek). I’m not doing it with my photos.

That’s the one that worries me the most. I have over 14,000 pictures on Flickr (I keep offline backups, of course). I pay Flickr and that’s a good thing. But it’s still only a matter of time before Flickr goes the way of other Yahoo properties.

Last year I went to IndieWebCamp in Portland to brainstorm and hack with like-minded people who want to be homesteaders instead of sharecroppers. It was an excellent gathering. And now it’s going to happen again, but this time it’s happening in Brighton.

Two days after dConstruct—and one day after Brighton Mini Maker Faire—we’ll gather at The Skiff for a mishmash of BarCamping and Hackdaying.

You should come. Add yourself to the guest list and the Lanyrd page.

I’ll see you there.

Pepys out

Phil Gyford was down in Brighton visiting the Clearleft HQ today. We’re working with him on Matter, which I’m very excited about.

Today wasn’t just any ol’ day for Phil. Today marks the end of a project of his that has been running for nine years and five months: Pepys’ Diary:

This site is a presentation of the diaries of Samuel Pepys, the renowned 17th century diarist who lived in London, England. A new entry written by Pepys will be published each day over the course of several years; 1 January 1660 was published on 1 January 2003.

We invited Phil down to Brighton last year to talk about Pepys’ Diary at a Skillswap event. You can listen to the audio on Huffduffer.

The diary of Samuel Pepys: Telling a complex story online on Huffduffer

I’m a big fan of long-term thinking and—in web terms—this project is as old as Methuselah. It’s refreshing. In an industry so caught up in the churn and grind of the new and the shiny, I think it’s wonderful that Phil dedicated himself to a project that he knew would require a long-term investment of his time. Russell wrote about it in Wired recently:

In some worlds ten years isn’t very long: it’s not if you’re digging an undersea tunnel or discovering a cure for disease. But in the busy, silly world of early 21st-century media, making a ten-year assertion was a big deal — something akin to the Clock of the Long Now.

I’ll be sorry to see you go, Mister time-shifted Pepys. But I understand that it’s hard for you to keep writing a diary when your eyesight is failing.

Eighteen

On Twitter the other day, Justin Hall wrote:

hah! 18 years ago today, I posted my home page on the public web; here’s a 27 January 1994 version bit.ly/AraMW0

Eighteen years! That’s quite something. For reference, Justin’s site links.net is generally acknowledged to be the web’s first blog, before John Barger coined the term “weblog” (or Peter coined the more common contraction).

If you go right back to the start of links.net, Justin explains that he was inspired to start publishing online by a 1993 article in the New York Times—he has kept a copy on his site. What’s fascinating about the article is that, although it’s talking about the growth of the World Wide Web, it focuses on the rising popularity of Mosaic:

A new software program available free to companies and individuals is helping even novice computer users find their way around the global Internet, the network of networks that is rich in information but can be baffling to navigate.

From a journalistic point of view, this makes a lot of sense: focusing on the interface to the web, rather than trying to explain the more abstract nature of the web itself is a good human-centric approach. When the author does get around to writing about the web, there’s a lot that must be explained for the audience of the time:

With hypertext, highlighted key words and images are employed to point a user to related sources of information.

“I realized that if everyone had the same information as me, my life would be easier,” Mr. Berners-Lee said.

From a small electronic community of physicists, the World-Wide Web has grown into an international system of data base “server” computers offering diverse information.

Links, servers, the World Wide Web …these were actually pretty tricky concepts to explain, and unlikely to elicit excitement. But explaining the browser gets straight to the heart of how it felt to surf the web:

Mosaic lets computer users simply click a mouse on words or images on their computer screens to summon text, sound and images from many of the hundreds of data bases on the Internet that have been configured to work with Mosaic.

Click the mouse: there’s a NASA weather movie taken from a satellite high over the Pacific Ocean. A few more clicks, and one is reading a speech by President Clinton, as digitally stored at the University of Missouri. Click-click: a sampler of digital music recordings as compiled by MTV. Click again, et voila: a small digital snapshot reveals whether a certain coffee pot in a computer science laboratory at Cambridge University in England is empty or full.

These days we take it for granted that we have the ability to surf around from website to website (and these days we do so on many more devices). I think it’s good to remember just how remarkable that ability is.

Thanks, Tim Berners-Lee for dreaming up the web. Thanks, Marc Andreessen for giving us to navigate the web. Thanks, Justin Hall for publishing on the web.

Ten

On this day ten years ago I started this journal. There had been a site at adactio.com before that but it was a silly DHTML brochureware thing. That changed when I wrote my first blog post:

I’m not quite sure what I will be saying here over the coming days, weeks, months and years.

Ten years later this journal contains a decade’s worth of notes-to-self. When somebody else finds what I’ve written to be interesting, that’s a bonus …but I’m writing for myself (or, if I do ever imagine somebody else reading this, I imagine someone just like me—a frightening thought).

It has been a very rewarding, often cathartic experience so far. I know that blogging has become somewhat passé in this age of Twitter and Facebook but I plan to keep on keeping on right here in my own little corner of the web. I’ve been blogging now for 25% of my life.

This journal is one quarter as old as I am.

This journal is half as old the web itself.

Here’s to the next ten years.

Jared Spool: The Secret Lives of Links

The final speaker of the first day of An Event Apart in Boston is Jared Spool. Now, when Jared gives a talk …well, you really have to be there. So I don’t know how well liveblogging is going to work but here goes anyway.

The talk is called The Secret Lives of Links. He starts by talking about one of the pre-eminent young scientists in the USA: Lisa Simpson. One day, she lost a tooth, put it in a bowl and when she later examined it under a microscope, she discovered a civilisation going about its business, all the citizens with their secret lives.

The web is like that.

Right before the threatened government shutdown, Jared was looking at news sites and how they were updating their links. Jared suggests that CNN redesign its site to simply have this list of links:

  1. The most important story.
  2. The second most important story.
  3. The third most important story.
  4. An unimportant, yet entertaining story.
  5. The Charlie Sheen story.

But of course it doesn’t work like that. The content of the links tells the importance. Links secretly live to drive the user to their content.

Compare the old CNN design to the current one. The visual design is different but the underlying essence is the same. The links work the same way.

All the news sites were reporting the imminent government shutdown with links that had different text but were all doing the same thing.

Jared has been working on the web since 1995. That whole time, he’s been watching users use websites. The pattern he has seen is that the content speaks to the user through the links. Everything hinges on the links. They provide the scent of information.

This goes back to a theory at Xerox PARC: if you modelled user behaviour when searching for information, it’s very much like a fox sniffing a trail. The users are informavores.

We can see this in educational websites. The designs may change but links are the constant.

http://xkcd.com/773/

We’ve all felt the pain of battling the site owner who wants to prioritise content that the users aren’t that interested in.

The Walgreens site is an interesting example. One fifth of the visitors follow the “photo” link. 16% go to search. The third most important link is about refilling prescriptions. The fourth is the pharmacy link. The fifth most used links is finding the physical stores. Those five links add up to 59% of the total traffic …but those links take up just 3.8% of the page.

This violates Fitts’s Law:

The speed that a user can acquire a target is proportional to the size of the target and indirectly proportional to the distance from the target.

Basically, the bigger and closer, the easier to hit. The Walgreens site violates that. Now, it would look ugly if the “photo” link was one fifth of the whole page, but the point remains: there’s a lot of stuff being foisted on the user by the business.

Another example of Fitts’s Law are those annoying giant interstitial ads that have tiny “close” links.

Deliver users to their desired objective. Give them links that communicate scent in a meaningful way. Make the real estate reflect the user’s desires.

Let’s go back to an educational web site: Ohio State. People come to websites for all sorts of reasons. Most people don’t just go to a website just to see how it looks (except for us). People go to the Ohio State website to get information about grades and schedules. The text of these links are called trigger words: the trigger an action from the user. When done correctly, trigger words lead the user to their desired goal.

It’s hard to know when your information scent is good, but it’s easy to know when your information scent is bad. User behaviour will let you know: using the back button, pogo-sticking, and using search.

Jared has seen the same patterns across hundreds of sites that he’s watched people using. They could take all the clickstreams that succeeded and all the clickstreams that failed. For 15 years there’s a consistent 58% failure rate. That’s quite shocking.

One pattern that emerges in the failed clickstreams is the presence of the back button. If a user hits the back button, the failure rate of those clickstreams rises to above 80%. If a user hits the back button twice, the failure rate rises to 98%.

The back button is the button of doom.

The user clicks the back button when they run out of scent, just like a fox circling back. But foxes succeed ‘cause rabbits are stupid and they go back to where they live and eat, so the fox can go back there and wait. Users hit the back button hoping that the page will somehow have changed when they get back.

Pay attention to the back button. The user is telling you they’ve lost the scent.

Another behaviour is pogo-sticking, hopping back and forward from a “gallery” page with a list of links to the linked pages. Pogo-sticking results in a failure rate of 89%. There’s a myth with e-commerce sites that users want to pogo-stick between product pages to compare product pages but it’s not true: the more a user pogo-sticks, the less likely they are to find what they want and make a purchase.

Users scan a page looking for trigger words. If they find a trigger word, they click on it but if they don’t find it, they go to search. That’s the way it works on 99% of sites, although Amazon is an exception. That’s because Amazon has done a great job of training users to know that absolutely nothing on the home page is of any use.

Some sites try to imitate Google and just have a search box. Don’t to that.

A more accurate name for the search box would be B.Y.O.L.: Bring Your Own Link. What do people type into this box: trigger words!

Pro tip: your search logs are completely filled with trigger words. Have you looked there lately? Your users are telling you what your trigger words should be. If you’re tracking where searches come from, you even know on what pages you should be putting those trigger words.

The key thing to understand is that people don’t want to search. There’s a myth that some people prefer to search. It’s the design of the site that forces them to search. The failure rate for search is 70%.

Jared imagines an experiment called the 7-11 milk experiment. Imagine that someone has run out of milk. We take them to the nearest 7-11. We give them the cash to buy milk. There should be a 100% milk-purchasing result.

That’s what Jared does with websites. He gives people the cash to buy a product, brings them to the website and asks them to purchase the product. Ideally you should see a 100% spending rate. But the best performing site—The Gap—got a 66% spending. The worst site got 6%.

The top variables that contributed to this pattern are: the ratio of number of pages to purchase. Purchases were made at Gap.com in 11.9 pages. On the worst performers, the ratio was 51 pages per purchase. You know what patterns they saw in the worst performers: back button usage, pogo-sticking and search.

Give users information they want. Pages that we would describe as “cluttered” don’t appear that way to a user if the content is what the user wants. Clutter is a relative term based on how much you are interested in the content.

It’s hard to show you good examples of information scent because you’re not the user looking for something specific. Good design is invisible. You don’t notice air conditioning when it’s set just right, only when it’s too hot or too cold. We don’t notice good design.

Links secretly live to look good …while still looking like links. There was a time when the prevailing belief was that links are supposed to be blue and underlined. We couldn’t have made a worse choice. Who decided that? Not designers. Astrophysicists at CERN decided. As it turns, blue is the hardest colour to perceive. Men start to lose the ability to perceive blue at 40. Women start to lose the ability at 55 …because they’re better. Underlines change the geometry of a word, slowing down reading speed.

Thankfully we’ve moved on and we can have “links of colour.” But sometimes we take it far, like the LA Times, where it’s hard to figure out what is and isn’t a link. Users have to wave their mouse around on the page hoping that the browser will give them the finger.

Have a consistent vocabulary. Try to make it clear which links leads to a different page and which links perform on action on the current page.

We confuse users with things that look like links, but aren’t.

Links secretly live to do what the user expects.

Place your links wisely. Don’t put links to related articles in the middle of an article that someone is reading.

Don’t use mystery meat navigation. Users don’t move their mouse until they know what they’re going to click on so don’t hide links behind a mouseover: by the time those links are revealed, it’s too late: users have already made a decision on what they’re going to click. Flyout menus are the worst.

Some of Jared’s favourite links are “Stuff our lawyers made us put here”, “Fewer choices” and “Everything else.”

In summary, this is what links secretly want to do:

  • Deliver users to their desired objective.
  • Emit the right scent.
  • Look good, while still looking like a link.
  • Do what the user expects.

Ethan Marcotte: The Responsive Designer’s Workflow

The next talk here at An Event Apart in Boston is one I’ve really, really, really been looking forward to: it’s a presentation by my hero Ethan Marcotte. I’ll try to liveblog it here…

The talk is called The Responsive Web Designer’s Workflow but Ethan begins by talking about his grandmother. She was born in 1910 and she’s still in great shape. This past Christmas she gave Ethan a gift of three battered and worn books that were her father’s diaries from the 1880s. They’re beautiful. The front is filled with almanac data but the most fascinating part is the short updates, mostly about the weather. They’re imperfect with crossing out and misspelling but they’re very visceral.

Stories are important. Passing on stories is an important part of what makes us human. Ethan illustrates this by showing some of my tweets about eating toast.

Newspapers are an odd paradox. For one day they are filled with the most important stories but just a day later they lose that immediate value. Take the Boston Globe, for example. It has a long history. Looking at old copies, the artefact itself is quite lovely.

But it’s a changing industry. This year nearly half of American adults will receive their news through mobile devices. The industry is trying to catch up with various strategies: separate mobile sites, iPad apps, and so on.

Ethan’s response last year was to talk about Responsive Web Design, which breaks down into three parts:

  • flexible grids,
  • flexible images and media and
  • media queries.

The idea has taken hold and lots of very talented designers have adopted a responsive approach.

Well, today you can add one more site to the list: The Boston Globe, relaunching with a responsive design this Summer.

Up ‘till now, responsiveness has been about layout—that’s different to design. As Paul Rand wrote:

Design is the method of putting form and content together.

There were three firms involved in the Globe redesign: The Boston Globe itself, Upstatement, and Filament Group. Ethan was in that third group. Everyone’s got a wide range of skills. It’s tempting to divide skills into visual design and interaction design. But that distinction is often a reflection of the job roles at design agencies.

Is the traditional design agency process part of the problem? We have this linear approach: discover, design, develop, deliver—like a relay race. But for a responsive site, you can never really say what the final deliverable is. You could try to come up with Photoshop comps for all possible layouts but that just doesn’t scale.

Then there’s the tools. The first thing you do when you open up Photoshop is to create a fixed canvas size in pixels. This is what Jason was railing against in his quest for a real web design application.

For the responsive workflow, what’s needed is …design-o-velopment (no, not really).

The group convenes. The designers introduce the comp, explaining their decisions. The developers ask lots of questions. Where does content come from? How does the user interact with it? And the important one: how is going to look on a smaller screen? How should it adapt? They discuss the various input modes: mouse, touch, keyboard, voice. The questions are more important than any particular answers at this point.

“What value does this content have for our mobile users?” That question can be best answered by adopting Luke’s Mobile First approach. Narrow screens force us to focus.

Look at an article on AOL. The mobile version is great. The desktop version is cluttered. We drown the content. “Mobile” has become a synonym for “Less” and “Desktop” has become a synonym for “More.”

If you were asked to describe a mobie user, you might think of someone on the go, easily distracted. Whereas you may imagine a desktop user as sitting comfortably with plenty of screen size and attention. But it’s not that simple. People use their mobile devices in all sorts of environments at all sorts of times.

Making decisions about what people want based simply on the device they are using is a little bit like telepathy. Context doesn’t necessarily determine the user’s intent.

Even a good mobile experience, like Flickr’s, gets things wrong. Content is withheld from visitors with mobile devices. Lots of people click on that “desktop version” link because they feel they are missing out.

When you practice Mobile First, you’re making a commitment to the content. Everything that’s displayed on the page deserves to be there. Mobile First really means Content First.

Now you prototype like wild. A pixel-based tool like Photoshop is limited in what it can convey so you need to start making prototypes from the outset.

Figuring out the proportions for a flexible grid is fairly straightforward: target divided by context equals result. Slot in your pixel values to that equation and you get a percentage that you can declare in your stylesheet. Now you’ve got a liquid layout.

Resizing images is simple:

img { max-width: 100%; }

For important large images you can use Scott Jehl’s script to swap out the image src attribute based on the viewport size. It defaults to the smaller-sized image.

Finally, there’s the media queries. There’s a lot of devices to test on. Fortunately the Filament Group are involved with jQuery Mobile so they’ve already got a lot of devices. But rather than designing for specific devices, they searched instead for commonalities, like screen sizes. These are common breakpoints so they are what’s used in the media queries.

There’s very good browser support for media queries but there are still some laggards. Scott Jehl’s other script, Respond, bootstraps media query support using JavaScript.

It’s worth pointing out that they don’t have comps for all these breakpoints: they’re designing in the browser at this point. But they take these prototypes back to the designers so that they can vet them. They ask more questions. How well does the layout adapt? Do individual elements still feel usable? Most importantly, do any page elements need additional design work?

The masthead of the Boston Globe was a tricky problem. The result from prototyping wasn’t satisfactory so the designers came up with a different solution. As the layout shrinks, the masthead functionality changes. This solution wouldn’t have been possible without reconvening to review the prototype. So they’re designing in the browser but what they’re designing are design recommendations.

A responsive site isn’t flipping between a set of fixed layouts. It’s liquid. Breakpoints that you haven’t thought of will still work.

You have to figure out what is the most appropriate experience for what device. Stephen Hay wrote a great post called There Is No Mobile Web. His point is that the rise of mobile should encourage to revisit our principles of accessibility and progressive enhancement for everyone.

When responsive design meets Mobile First—starting with the narrowest width and building up from there—what you’re doing is progressive enhancement. You’ll even see this layering in the way that the stylesheets are structured.

The basic experience is still very attractive. The next step is enhancing for browsers that support media queries …and Internet Explorer. They get an enhanced stylesheet.

There are other things you can test for: are touch events supported, for example. So an iPad has the screen size of a laptop but it also supports touch events. They get some enhanced JavaScript functionality.

A really tricky question is “is this key content, or is it simply an enhancement for some users?” Web fonts are good example of this grey area. For the Boston Globe, they decided to make a hard cut-off point and only serve up web fonts to viewports above a certain size.

Conditional loading in JavaScript is very useful for serving up the right functionality to the right devices.

Let’s pull back a bit before we wrap up.

Just as there has been discussion “Mobile” and “Desktop”, there has also been discussion of “Mobile” and “Responsiveness.” A lot of the discussion is around butting heads between idealism and realism. Ultimately the decision about whether to make “Mobile” site or a “Responsive” site is more about the designer’s philosophy than about devices.

This has been quite a day for announcements. As well as the forthcoming Boston Globe redesign, Ethan also has a publishing date for his book: Responsive Web Design will be published by A Book Apart on June 7th.

Luke Wroblewski: Mobile Web Design Moves

Next up at An Event Apart in Boston is Luke Wroblewski. Let’s see if I can liveblog just some his awesomeness.

Luke begins with some audience interactivity. We’ve all got to stand up. Now we learn a few small moves. Put them all together and what have you got? The Thriller dance!

There’s a point to this: his talk is called Mobile Web Design Moves. Small moves can add up to very big things.

But why learn new moves? Well, Mobile changes things:

  • Mobile web growth and
  • Mobile is different.

Mobile web growth

A few years ago, Morgan Stanley published a report in which they predicted that somewhere in 2012 more mobile devices would be shipped than PCs. Well, it happened two years earlier than predicted. As Eric Schmitt has said, everything to do with mobile happens faster. There’s been a 20% drop in PC usage, with the slack taken up by tablets and smartphones. But as Luke points out, the term PC—Personal Computer—is actually better suited to a mobile device; the device you have with you on your person. The way we interact online, email, etc., is shifting to mobile devices.

But is all this usage happening in native apps? No, as it turns out. 40% of Twitter’s traffic comes from mobile, of which 78% is from the mobile website. Mobile browser users increased over 300%. What people forget is that growth of native apps also drives growth of mobile web use.

In a nutshell, more people are going to be accessing your websites with a mobile device than with a desktop device. Find one study of mobile usage that doesn’t show exponential growth.

Even if you have native apps, like Gowalla with a client for iOS, Android, Blackbery, etc., people will still post links in your native app and where does that take you? To a browser.

Anyway, it doesn’t have to be either a native app or a mobile web site. You can hedge your bets and do both …so you’re protected if Steve Jobs pulls the rug out from under you.

Mobile is different

When you’re sitting at a computer at home, you’re sitting comfortably with a keyboard, mouse, chair and coffee mug. The mobile experience involves a small screen, short battery life, an inconsistent network, fingers and sensors. This tactile experience makes it intensely personal.

Where do people use these devices? There’s the sterotypical picture of the businessman on the move, walking down the street. But 84% of mobile usage happens at home; watching TV, for example. 74% of people use them standing in line. People use them in the toilet.

What about when people use these devices? All throughout the day, as it happens. That’s quite different to desktop use. iPad users do a lot of reading on the couch in the evening and in bed at night.

Mobile devices have different technical capabilities and limitations and there are also some distinct times and behaviours associated with their usage.

By now you should be convinced: I need new moves!

Organise yourself

Try to understand why someone would pull out their mobile device. What is that device good at? Try to marry that up with your content. Luke breaks down mobile behaviours into these categories:

  • Lookup/Find — usually location-related.
  • Explore/Play — often related to reading.
  • Check in/Status
  • Edit/Create — email, for example.

Think about organising your structure to fit these tasks. Luke shows a college site that prioritises campus information less than marketing fluff. But you know, this isn’t just about mobile users. That useful information—like a campus map—is useful for everyone, regardless of their device. So if you go through this process of prioritising for mobile, you will also be prioritising for desktop.

Mobile forces you to prioritise. Screen space is tight. Attention is short. Apply the same prioritisation to desktop users.

Here’s a good rule of thumb: content first, navigation second. Give people what they’re looking for first.

Don’t try to port all of your content to mobile. Instead use this as an opportunity to prune your content and get rid of the crap that people aren’t interested in.

What people want to do on mobile is the same as what people want to do on the desktop. For some reason, Yelp only allowed mobile users to point “mini” reviews …at the very time when people are in the place they are reviewing!

Don’t dumb it down for mobile.

Use your head

Content first, navigation second; yes, but navigation is still important. Facebook’s mobile version originally had 13 navigation elements, which is a bit much. YouTube puts the navigation on a different screen. The pro is that this saves screen estate. The con is that you lose context. ESPN’s mobile site has a navigation that you pull down. There’s also navigation at the end of the page. That’s better than what YouTube does: when you get to the end of the page on YouTube, it’s a dead end. One of the challenges with the ESPN site is that the navigation is duplicated (the pull-down nav and the footer nav). A potential solution is to have that nav link at the top point to the navigation at the bottom of the page.

What about fixed position menus? The iPhone has permanent software buttons on screen in the browser, right? But to do fixed positioning on mobile you have to use some hacky JavScript. And even if you get it working, it’s eating up valuable screen real estate. On the Android device, there’s the problem of the proximity to hardware buttons: people will accidentally mis-tap the hardware controls trying to use on-screen navigation anchored to the bottom of the screen.

So don’t just slavishly copy iOS conventions. Don’t put a back button in your site. It makes sense in an app but on a website, the browser provides a back button already.

Take it in

Input is interesting topic on mobile. The traditional advice is to avoid text input on mobile ….and yet billions of text messages are sent every day. So let’s reverse the traditional advice. Let’s encourage people to input on mobile.

The workhorses of input on the web have been checkboxes, radio buttons, drop-down lists, etc. Using these standards on mobile means you can type into the device interface features, like the select UI on the iPhone. But the constraints of the smaller screen on a mobile device introduces some challenges even if you use these standard controls. If you make your own interface elements, you can given them touch target sizes.

The stuff that we have to programme for ourselves today will become standard declarative features in the future. That’s already happening with HTML5 input types like date. But even small things can make a big difference. Use input types like url, number, email, etc. to get an appropriate on-screen keyboard on iOS. Make use of new input types and attributes. Every little bit helps.

Input masks—confining what’s allowed in a form field—can be very useful on mobile devices. Right now we have to do it programmatically but again, it should become declarative in the future.

Avoid the gradual reveal, where you format as people are typing but in a different format to what the placeholder text displayed. Beware with placeholder text: people can interpret it as the form field already being filled in. Phrase them as questions if you can.

There’s a lot of really exciting things happening on the input side of things with mobile devices. More and more device APIs and sensors are being exposed.

Ask for it

Input is the way we gather answers from people but we also have to think about how we ask the questions.

Many mobile browsers try to optimise desktop-specific sites to help mobile users by using zoom. In that situation, right-aligned form field labels are problematic: when you zoom in on the form field, you can’t see the label. Top-aligned labels work better …and there are many other advantages to top-aligned labels that Luke has talked about in the past.

Some people are trying to use placeholder text as labels. But the problem there is that as soon as you tap in there, it disappears. Again, watch out when putting labels within input fields: it’s not clear if the form field is already filled in or not.

Make your moves

Here’s an opportunity. Mobile is growing so quickly and it’s all new. Now is our chance to come up with new innovative stuff. This stuff hasn’t been figured out yet. More and more devices are coming online every day and they’ve all got web browsers.

We can push towards natural user interfaces where the content is the user interface. Minor rant: our design processes are more about designing navigation instead of focusing on the content and designing that. It’s a challenge. As Josh Clark put it:

Buttons are a hack.

So make your own moves. Yes, it’s a scary time; there’s so much to learn about, but also also a huge opportunity.

Keep an eye out for Luke’s book from A Book Apart called Mobile First coming out in Summer 2011.

Veerle Pieters: The Experimental Zone

The next speaker at An Event Apart in Boston is Veerle Pieters. I’m going to try liveblogging some of what she’s got to say.

Veerle’s talk is called The Experimental Zone and it’s all about experimentation in web design. People often ask her how she comes up with, say, certain colour combinations but she doesn’t really have a straightforward answer—a lot of it is down to experimentation. So it’s good to learn how to experiment better. Pablo Picasso said:

Inspiration exists, but it has to find you working.

Spirographs seem complex but they are a perfect example of how experimenting with really simple fundamental rules and shapes can lead to a beautiful result: start with a simple, translucent square and start applying the same transform multiple times e.g. scaling 85% and rotate -10 degrees. Object: transform: transform again.

You can also experiment with colours in spirographs. Start with a translucent triangular shape, copy and rotate it by 18 degrees but before that, change the colour values. Try different blending modes and see what comes out. Combine different layer modes with different scaling values e.g. 115%. Try different rotation angles to see how they turn out. An extreme value like 48 degrees applied to translucent circular shapes of different colours leads to some interesting results.

Transparency. Blending. Scale. Rotation. Colour. Experiment with those combinations.

But why play around with this stuff? Well, Veerle used some of the results in client work for some background images on sites and on physical credit card designs.

Start with some circles in the colours defined by the client’s in-house style guide and start experimenting with combinations. It’s okay to try out a dozen versions. When you really need to have control, you can get in there and change the overlapping colour combinations manually.

Veerle also does small experiments not related to work; a little every day. She’s got a folder full of patterns and experiments that she hasn’t used yet but they might come in handy later on. Another example of experimentation was the Duoh Christmas card. She began with a star and started experimenting with repeating patterns. Those experimentations didn’t lead anywhere so she went back to the star and tried a different approach. That’s often the way things work out: you have a starting point, you experiment from there and if it doesn’t work out, return to the starting point and try a different direction. For the Christmas card, scaling the star to different sizes with different colours and opacity lead to the final result.

Logo design works in a similar way. The typeface is the starting point (in this example, Dessau Pro Regular). Veerle tweaked the letter shapes and started experimenting with shapes within the shapes. In this example, Veerle took the bowl of the letter A and starting duplicating and rotating, getting some really nice results. You’re playing around and then suddenly you go “Oh, that’s it: that’s what I was looking for.”

Veerle sketches her ideas down. For her own blog, she started sketching variations based around the letter V but she didn’t like any of the results so she left the sketchbook and jumped into Illustrator. Sometimes it’s a bit of both that works: experiments in a sketchbook and in Illustrator.

If time permits, Veerle likes to leave a design (like a logo) alone for a while. Then come back to it and see if you still like it. For her blog, the initial logo she created didn’t stand up to this test. So she went back to the starting point, the letter V, and went in a different direction, keeping the elements she liked from the previous attempt—like the colours—but experimenting with shapes.

Mood boards can be useful for getting started. For the book cover of Aaron’s forthcoming book Adaptive Web Design, she began with her scrapbook-like collection of images and started putting some together into a mood board, trying to visualise the concept of progressive enhancement. The first design direction was ruled to be a bit too abstract. So the simple cubes were ditched in favour of something more sophisticated. The end result is the chameleon on the cover—it’s built of abstract shapes and many colours, but the result is something recognisable.

“Let’s experiment,” says Veerle.

As Erik Spiekermann has said, you can be inspired by something but you can’t just copy it wholesale. But Veerle likes to begin by reproducing something side-by-side and then, maybe a few days later, try to reproduce it without the original. The result is stamped with your own take on the original. She did this with the book cover for Imaginary Cities.

She started sketching it from memory. Her version turned out different; more cube-based. She imported that sketch into illustrator and started making outlines with the pen tool. Once the tracing is done, she started filling in shapes with translucent colours. She used the colour picker to take colours from some of the overlapping shapes for use in a different layer with a different mode: the resulting colour fill is very different. She didn’t know what the end result would be but she just tried things out. Once the colours have been gathered together, she created some gradients with them and applied them to some of the cubes. Then she added some dashed lines that she recalled from original cover. Finally, she upped the contrast.

But let’s go a step further. Let’s try to do this with CSS.

Alex Walker’s article The Cicada Principle is all about introducing pseudo-randomness into tiled multiple background images: the image sizes are all based on different prime numbers. The result looks random. For the curtain example, a ruffle is the base unit: the first image has 1 unit, the second image has 3 units, the third has 7 units.

Veerle takes this idea and applies to her cube-based design. She went with multiples of 3: 300 pixels, 600 pixels, 900 pixels. The result is a great backdrop of overlapping cubes and no matter how wide your browser window, you won’t see the repeat. You can see in action at http://www.duoh.com/varia/cicada.

Veerle has some practical tips to finish with.

  • Name your layers. Turn off that preference in Photoshop that says “Add ‘copy’ to copied layers”.
  • If you rotate a bitmap, you sometimes end up with odd shifting pixels that look blurry. Change the point of origin of the rotation: use one of the corners instead of the centre.
  • If you paste from Illustrator to Photoshop the result can be blurry. Before pasting, select exactly the size you want to paste in. Experiment to find the right size to avoid blurring.
  • Tychpanel by Reimund Trost is a very handy tool for calculating sizes.
  • Another useful tool is a plugin called Guide Guide by Cameron McEfee which is particularly useful for grids.
  • Extensible baseline grids by Mike Precious is also really handy technique for creating a baseline grid.
  • When tweaking letter shapes and spacing, for a logo, for example, try turning the letters upside down to get a different perspective. It can be clearer what needs to be tweaked.
  • Colour management is tricky. Some people turn sRGB off for exporting to the web to avoid colour shifting. Actually you need to set up your environment the right way. Calibrate your screen. Then set up colour management for Adobe Creative Suite. Veerle chose the Adobe RGB environment: she works in print as well as web, so just using sRGB isn’t going to work for her. Have your environment set up to have a wide gamut; you can always narrow it down for specific exports like for the web, for example.
  • When importing, assign a profile rather than converting to a profile. Converting is a destructive process whereas assigning a colour profile doesn’t actually alter the image file.

Veerle likes to start by forgetting about technical constrains and just experimenting in a free-form way. That can lead to more creative, new ideas instead of limiting yourself. Of course you can’t go too far, but still, there’s a good zone for experimentation.