Tags: phone




In the latest issue of Justin’s excellent Responsive Web Design weekly newsletter, he includes a segment called “The Snippet Show”:

This is what tells all our browsers on all our devices to set the viewport to be the same width of the current device, and to also set the initial scale to 1 (not scaled at all). This essentially allows us to have responsive design consistently.

<meta name="viewport" content="width=device-width, initial-scale=1">

The viewport value for the meta element was invented by Apple when the iPhone was released. Back then, it was a safe bet that most websites were wider than the iPhone’s 320 pixel wide display—most of them were 960 pixels wide …because reasons. So mobile Safari would automatically shrink those sites down to fit within the display. If you wanted to over-ride that behaviour, you had to use the meta viewport gubbins that they made up.

That was nine years ago. These days, if you’re building a responsive website, you still need to include that meta element.

That seems like a shame to me. I’m not suggesting that the default behaviour should switch to assuming a fluid layout, but maybe the browser could just figure it out. After all, the CSS will already be parsed by the time the HTML is rendering. Perhaps a quick test for the presence of a crawlbar could be used to trigger the shrinking behaviour. No crawlbar, no shrinking.

Maybe someday the assumption behind the current behaviour could be flipped—assume a website is responsive unless the author explicitly requests the shrinking behaviour. I’d like to think that could happen soon, but I suspect that a depressingly large number of sites are still fixed-width (I don’t even want to know—don’t tell me).

There are other browser default behaviours that might someday change. Right now, if I type example.com into a browser, it will first attempt to contact http://example.com rather than https://example.com. That means the example.com server has to do a redirect, costing the user valuable time.

You can mitigate this by putting your site on the HSTS preload list but wouldn’t it be nice if browsers first checked for HTTPS instead of HTTP? I don’t think that will happen anytime soon, but someday …someday.

100 words 015

An article in Wired highlights a key feature of the new Apple watch—to free us from the tyranny of the smartphone screen.

I’ve never set up email on my phone.

If I install an app on my phone, the first thing I do is switch off all notifications. That saves battery life and sanity.

The only time my phone is allowed to ask for my attention is for phone calls, SMS, or FaceTime (all rare occurrences). I initiate every other interaction—Twitter, Instagram, Foursquare, the web. My phone is a tool that I control, not the other way around.

100 words 014

I had a very early start yesterday. It was Anna and Cennydd’s big (and yet little) day. I needed to get to the registry office in Walthamstow by 10am which meant leaving Brighton before dawn. In my befuddled state, I forgot my phone.

I realised when I was in the taxi to the station. I readily admit that for a brief moment, I thought about asking the taxi driver to turn around so I could retrieve my camera, address book, city map, music collection, and web browser.

But I didn’t. And it was fine. I had a book to read.

Inspiration calling

Someone sent an email to Clearleft recently pointing out what they thought was a certain similarity between our website and the website for a company called Kent Web Host.

Kent Web Host

I can’t see it myself. But I can’t guarantee that we weren’t somehow unconsciously influenced by these guys.

Just to set the record straight, I gave them a call.

Chatting with Kent Web Host on Huffduffer

Update: a few points of clarification:

  • Garry from Kent Web Host is totally cool with me publishing our conversation.
  • I’m not publishing this out of any spirit of schadenfreude. I’m publishing it because it was a fun conversation and Garry handled the situation like a true gent.
  • Garry is a really nice guy. If you want to say unkind things about him on Twitter when you’re linking to this, don’t: you don’t know what you’re talking about.

What do I know?

On our way back from New Zealand, Jessica and I stopped off in Sydney for a day. That same evening, the “What Do You Know?” event was going on—a series of five minute lightning talks from Sydney’s finest web geeks.

Maxine asked me if I could do a turn so I put together a quick spiel called Five Things I Learned from the Internet. Those five things are:

  1. How to wrap headphone cables in a tangle-free way.
  2. How to fold a T-shirt in seconds.
  3. How to tie shoelaces correctly (thanks, Adam).
  4. How to eat a cupcake (thanks, Tara).
  5. How to peel a banana (thanks, Kyle) with a bonus lesson on the bananus.

At least one of those things will blow your mind. Pwshoo!

Voice of the bot-hive

Creating telephone answering systems can be fun as I discovered at History Hack Day when I put together the Huffduffer hotline using the Tropo API. There’s something thrilling about using the human voice as an interface on your loosely joined small pieces. Navigating by literally talking to a machine feels simultaneously retro and sci-fi.

I think there’s a lot of potential for some fun services in this area. What a shame then that the technology has mostly been used for dreary customer service narratives:

Horrific glimpse of a broken future. I sniffed while a voice activated phone menu was being read out and it started from the beginning again.

There’s been a lot of talk lately about injecting personality into web design, often through the tone of voice in the . When personality is conveyed in the spoken as well as the written word, the effect is even more striking.

Have a listen for yourself by calling:

That’s the number for Customer Service Romance:

What happens when Customer Service bots start getting too smart? What if they start needing help too? How would they use the tools at their disposal to reach out to those they care about? What if they start caring about us a little too much?

It’s using the Voxeo service, which looks similar to Tropo.

The end result is amusing …but also slightly disconcerting. You may find yourself chuckling, but your laughter will be tinged with nervousness.

Customer Service Romance on Huffduffer

On the face of it, it’s an amusing little art project. But it’s might also be a glimpse of an impending bot-driven algorithmpocalypse.

Orientation and scale

Paul Irish, Divya Manian and Shi Chuan launched Mobile Boilerplate recently—a mobile companion site to HTML5 Boilerplate.

There’s some good stuff in there but I was a little surprised to see that the meta viewport element included values for minimum-scale=1.0, maximum-scale=1.0, user-scalable=no:

Setting user-scalable=no is pretty much the same as setting minimum-scale=1.0, maximum-scale=1.0. In any case, I’m not keen on it. Like Roger, I don’t think we should take away the user’s right to pinch and zoom to make content larger. That’s why my usual viewport declaration is:

Yes, I know that most native apps don’t allow you to zoom but I see no reason to replicate that failing on the web.

But there’s a problem. Allowing users to scale content for comfort would be fine if it weren’t for a bug in Mobile Safari:

When the meta viewport tag is set to content="width=device-width,initial-scale=1", or any value that allows user-scaling, changing the device to landscape orientation causes the page to scale larger than 1.0. As a result, a portion of the page is cropped off the right, and the user must double-tap (sometimes more than once) to get the page to zoom properly into view.

This is really annoying so Shi Chuan set about fixing the problem.

His initial solution was to keep minimum-scale=1.0, maximum-scale=1.0 in the meta viewport element but then to change it using JavaScript once the user initiates a gesture (the gesturestart event is triggered as soon as two fingers are on the screen). At the point, the content attribute of the meta viewport element gets updated to read minimum-scale=0.25, maximum-scale=1.6, the default values:

var metas = document.getElementsByTagName('meta');
var i;
if (navigator.userAgent.match(/iPhone/i)) {
  document.addEventListener("gesturestart", gestureStart, false);
  function gestureStart() {
    for (i=0; i<metas.length; i++) {
      if (metas[i].name == "viewport") {
        metas[i].content = "width=device-width, minimum-scale=0.25, maximum-scale=1.6";

That works nicely but I wasn’t too keen on the dependency between the markup and the script. If, for whatever reason, the script doesn’t get executed, users are stuck with an unzoomable page.

I suggested that the script should also set the initial value to minimum-scale=1.0, maximum-scale=1.0:

var metas = document.getElementsByTagName('meta');
var i;
if (navigator.userAgent.match(/iPhone/i)) {
  for (i=0; i<metas.length; i++) {
    if (metas[i].name == "viewport") {
      metas[i].content = "width=device-width, minimum-scale=1.0, maximum-scale=1.0";
  document.addEventListener("gesturestart", gestureStart, false);
function gestureStart() {
  for (i=0; i<metas.length; i++) {
    if (metas[i].name == "viewport") {
      metas[i].content = "width=device-width, minimum-scale=0.25, maximum-scale=1.6";

Now the markup still contains the robust accessible default:

…while the script takes care of initially setting the scale values and also updating them when a gesture is detected. Here’s what’s happening:

  1. By default, the page is scaleable because the initial meta viewport declaration doesn’t set a minimum-scale or maximum-scale.
  2. Once the script loads, the page is no longer scalable because both minimum-scale and maximum-scale have been set to 1.0. If the device is switched from portrait to landscape, the resizing bug won’t be triggered because scaling is disabled.
  3. When the gesturestart event is detected—indicating that the user might be trying to scale the page—the minimum-scale and maximum-scale values are updated to allow scaling. At this point, if the device is switched from portrait to landscape, the resizing bug will occur because the page is now scaleable.

Jason Weaver points out that you should probably detect for iPad too. That’s a pretty straightforward update:

if (navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPad/i))

Mathias Bynens updated the code to use querySelectorAll which is supported in Mobile Safari. Here’s the code I’m currently using:

if (navigator.userAgent.match(/iPhone/i) || navigator.userAgent.match(/iPad/i)) {
  var viewportmeta = document.querySelector('meta[name="viewport"]');
  if (viewportmeta) {
    viewportmeta.content = 'width=device-width, minimum-scale=1.0, maximum-scale=1.0';
    document.body.addEventListener('gesturestart', function() {
      viewportmeta.content = 'width=device-width, minimum-scale=0.25, maximum-scale=1.6';
    }, false);

You can try it out on Huffduffer, Salter Cane, Principia Gastronomica and right here on Adactio.

Right now there’s still a little sluggishness between the initial pinch-zoom gesture and the scaling; the scale values (0.25 - 1.6) don’t seem to take effect immediately. A second pinch-zoom gesture is often required. If you have any ideas for improving the event capturing and propagation, dive in there.

Update: the bug has been fixed in iOS 6.

The Huffduffer Hotline

After seeing (and hearing) what Brian was doing at History Hack Day, I decided I’d have to have a play with Tropo. Like Twilio, it’s a service that allows you to build voice-activated apps that you call up and talk to.

The API is pretty straightforward and it seems like there’s quite a lot that you can do as a developer before upgrading to a paid account. They’ll also host your code for you, and you have a choice of scripting languages.

At the most basic level, you can send text-to-voice messages:

say("Hello world")

But you can also give it audio files to play:


Huffduffer has the locations of thousands of audio files, so I thought a voice interface onto Huffduffer’s collection would be fun.

Call +1 202 600 8751 in the US, +44 2035 142722 in the UK, or use Skype. When the nice digital man on the other end picks up the phone and asks you want you want to hear, you can respond with “what’s new”, “what’s popular”, or say a tag like music, science, history, politics, technology, etc.

The script then fetches the latest files with that tag and will go through them with you one by one, asking “Would you like to hear… ?” followed by the title. If you don’t like the sound of it, just say no. When you find something you do want to hear, say yes. It will then start playing and you will be listening to a podcast down a telephone line.

Audioboo / searching huffduffer.com audio by phone on Huffduffer

I call it the Huffduffer Hotline. The code is on Github. If you fancy playing around with the Tropo API and want to use Huffduffer’s links to audio files, go ahead. You should find everything you need through the Huffduffer API.

If people find the Huffduffer Hotline useful or just plain fun, I’ll upgrade from the developer account to get better performance. Let me know your thoughts on Get Satisfaction.


When the original came out, it was pretty impressive. Every subsequent iteration has featured improvements of varying levels of impressiveness. The latest version, though, has bowled me over.

I’m not talking about faster speeds, bigger storage, or any new fangled gizmos or geegaws. I’m talking about VoiceOver in the iPhone.

Watch the video to get the low-down. Then read this first-hand account of using an accessible touch-screen device.

That’s quite a design challenge: an accessible touch-screen device! I doff my hat in the general direction of the Apple engineers who rose to this challenge.

Speaking of exciting developments in the world of accessibility…

The second Accessibility 2.0 conference will be taking place in London on the 22nd of this month. It was a cracking event last year and, judging by the line-up, this year is going to be a winner too. Grab a ticket now.

Self loathing for Sumo

I’m such a blogwhore.

I was contacted a while back by the people who make Sumo chairs asking if I wanted an Omni. All I had to do in return was blog about it—just like Cameron did.

This is just the sort of slightly sleazy marketing ploy that gets Tom so upset. And I agree with him. But, the thing is, Jessica and I were talking about getting a beanbag anyway. With that in mind, this Faustian bargain was just too hard to resist.

So here goes…

It’s a nice chair; quite comfy. But the outside material, though easy to clean, is a bit synthetic for my taste. I prefer more organic, cosy materials in my home. Still, the Omni would be perfect for the office. If you’re planning to get one for your home, think about getting the Omni Plus which has a microsuede covering.

Okay, that’s that taken care of. If you don’t respect me in the morning, I’ll understand.

This isn’t the first time I’ve been sent goodies in the post. Nokia lent me a pre-sale trial version of their N78 phone but they didn’t demand a blog post in return. That’s just as well because the phone turned out to be a piece of unintuitive crap. It doesn’t matter how many features you pack into a device—WiFi, GPS, what have you—if the hardware and software interface requires a degree in puzzle-solving, it’s a useless lump of plastic. The iPhone has shown us that we don’t have to put up with crappy mobiles any more …and I don’t even have an iPhone.

I feel slightly guilty badmouthing a freebie. Not only did Nokia send me a shiny toy, they also offered to fly me over to Helsinki for last week’s workshops. I couldn’t afford to take the time off work and anyway, far more capable people than I were in attendance: Ms. Jen, Rebecca and Micki to name just three.

Judging from the evidence on Flickr, an enjoyable and productive time was had by all. And, if my eyes don’t deceive me, I do believe …yes, I think those are Sumo chairs that everyone was lounging around on.

Update: Nope, Rebecca says those beanbags are Fatboys.

iPhone, uPhone, we all scream for iPhone

Like everyone else in the geekosphere, I was vicariously attending MacWorld through all those Mac rumour sites as well as Twitter. Unsurprisingly, the iPhone has a lot of people excited.

Jason Kottke got so excited, he immediately whipped up a cardboard scale model of the iPhone. Jeff Croft is really excited that the iPhone is running Leopard.

A lot of people are talking about how to get their heads around this thing. Is it a phone or is it a PDA? John Allsopp wouldn’t mind losing the phone functionality altogether.

Mike Davidson thinks that the iPhone is worthy of the moniker Steve’s Amazing New Device. He must be pretty pleased that his prediction that Apple would no longer be just a computer company became reality with the official change of the company’s name. Khoi Vinh, on the other hand, will be disappointed to hear that the iPhone does indeed use iTunes to do its syncing.

I spent part of the keynote chanting Get to the web browsing! Get to the web browsing! Then Steve Jobs got to the web browsing… with expando-Safari.

Dave Hyatt may be slightly biased but he thinks that this may spell the beginning of the end for a separate mobile web. Dan Cederholm is pretty impressed too. Cameron Moll, on the other hand, believes that the iPhone won’t revolutionise the mobile web landscape for most people. Brian Fling disagrees. He thinks the impact of the iPhone will be huge.

Bursting Apple’s reality distortion field with Photoshop, Jon Hicks demonstrates the problem with the iPhone’s screen. Roger Johansson also throws a cold bucket of reality on proceedings when he asks where the tactile feedback is supposed to come from when there’s no keyboard. That’s a valid concern according to David Pogue’s hands-on experience.

The biggest downer probably won’t be anything to do with the device itself but the lock-in with some crappy provider, as Dave Shea explains. That’s still not enough to dissuade Jason Santa Maria from wanting an Apple mobile device.

I met up with Brighton’s own mobile guru, Tom Hume, for lunch today. He’s taking a pragmatic and somewhat pessimistic approach with his thoughts on the iPhone.

Only time will tell how Apple’s baby will fare once its released into the wild. For some historical perspective, I invite you to cast your mind back to a Slashdot article from 2001 announcing the iPod.

New Year’s Resolution

In a comment on Roger’s post about fixed and liquid layouts, Cameron wrote:

This issue seems to generate a heated debate every time it’s mentioned. I imagine one could pen an article with the headline “Fluid or fixed?” and nothing else, and yet dozens of comments would inevitably appear.

But rather than use that title, I couldn’t resist borrowing a pun from Andy, prompted by a post from Scrivs called What Resolution Will You Design for in 2007? (a classic example of the fallacy of many questions).

Now, firstly, we need to draw a distinction between monitor size and browser size. In other words, the difference between screen resolution and the viewport size:

There’s a real danger in thinking that “the numbers speak for themselves.” Numbers don’t speak for themselves; numbers need to be interpreted.

The numbers clearly show that monitor sizes and resolutions are getting bigger. The most common interpretation of that is more and more people have bigger displays. But an equally valid interpretation of the numbers is the range of displays is bigger than ever. It’s a subtle but important distinction. One interpretation focuses solely on the size of the highest numbers; the other interpretation focuses on the range of all the numbers.

The way I see it, the range is growing at both ends of the spectrum. Yes, desktop monitors are getting wider (though that doesn’t mean that viewports get any wider above a certain size) but handheld and gaming devices are likely to remain at the lower end of the scale. The Wii, for example, has a resolution of 640 x 480.

Mind you, the iPhone turns the whole question on its head with its scalable browsing. At MacWorld, Steve Jobs demonstrated this by visiting the New York Times, an unashamedly wide fixed-width website. On the Apple site, Wikipedia—a liquid layout— is shown fitting nicely on the display. The iPhone deals with both. Still, rather than letting my liquid layouts scale down to the iPhone’s width, I should probably start putting a min-width value on the body element.

Speaking of which…

A common argument against using liquid layouts is the issue of line lengths. On the face of it, this seems like a valid argument. Readability is supremely important and nobody likes over-long line lengths. But it’s not quite as simple as that when it comes to readability on screen compared to print, as Richard noted:

Surprisingly, I find short line lengths tiresome on screen; I don’t really subscribe to the empirical prescription of 7–10 words per line for comfortable reading. Most novels have 10–15 words per line and I think the upper region of that range is more appropriate for screen.

In any case, the idea that liquid layouts automatically means long line lengths on large screens is, I feel, a misconception. The problem is that a lot of the examples of liquid layouts aren’t very good and line lengths do expand without limit. But it doesn’t have to be that way.

In my opinion, the most important addition to Internet Explorer 7 is the max-width property. It means that we can now really start to look at creating fluid layouts within defined parameters, as demonstrated by Cameron in Andy’s book. In fact, I think we’re just scratching the surface of what’s possible in creating seamless adaptive layouts (and, more importantly, seamless adaptive page elements) using the dual power of max-width and min-width.

That still leaves Internet Explorer 6 and below. Should they get unbounded fluid layouts or should they get a fixed width fallback? The second is certainly an option using conditional comments, which is the Microsoft-approved way of dealing with rendering inconsistencies. I think that the lack of support for max-width certainly falls into that category. Call it transcending CSS if you will; I call it routing around damage on the designer’s network.

I want to hear what you have to say… if you’ve got something new to say. Let’s not just rehash the same old arguments that would inevitably appear had I simply asked “Fluid or fixed?”