Cambio

I never used to be particularly interested in designing mobile applications. I just thought it was a hopeless platform, plagued by tiny screens and keys that were designed for inputting numbers (how often do you actually type numbers into your phone?) I also had never thought of my phone as something that I want to use for various applications. This scepticism had become so ingrained that I initially didn't even see much point in Apple opening up the iPhone for third-party developers. I thought it might destroy the purity of this well-designed platform if developers were suddenly given reign over users' mobile screens.

However, two months ago or so, a certain curiosity, a thirst for a new challenge and a feeling that I was missing a boat (to where I did not know) combined to make me go out and buy an iPod touch (I don't want to buy an iPhone because my current phone deal is too good to give up). I almost immediately appreciated both what a well-designed platform it is and what a compelling playground the third-party application market represents, for users and developers alike.

You see, what I had not realised before was that:

1. My preconception that mobile apps are pointless was based on the fact that previous platforms were so unsuitable for them. I had simply not witnessed how good it can be.
2. I had forgotten how good Apple are at framework design. The SDK allows you to make rich, highly interactive and very consistent user interfaces rather easily.

I obviously wasn't the first person to think that a unit converter would be an ideal iPhone application. It seemed like the perfect programming exercise, but I didn't want to produce something that was redundant. I had a look at a selection of what seemed like popular unit converters, but none of them worked quite the way I thought they ought to. Like so many times in the past, that was motivation enough for me to sit down and roll my own.

The result is Cambio:

Get it at the App Store. It's free.

I am planning a separate article on the design of Cambio. For now, please give it a spin and let me know what you think. Do you find anything unclear, confusing or annoying about the interaction? Are you missing any units or quantities? Feel free to comment here or drop me an email at contact@amarsagoo.info.

Tofu 2.0.1

Tofu 2.0 was released yesterday, which allows reading simple PDF documents, has a less obtrusive full-screen mode, supports scrolling on MacBook trackpads and is a Universal Binary (that is, it includes a native build for Intel Macs). An alpha version with most of these features had been available for quite some time, but it had some bugs, and it only recently dawned on me how to solve the trackpad problem.

I have since released revision 2.0.1, which fixes some bugs in yesterday's release.

In case you don't know what Tofu is: it tries to make reading text on the screen more pleasant by wrapping it into columns, which you navigate from left to right without ever scrolling vertically.

Go and get it here.

The science of keyboard design

The Handbook of Human–Computer Interaction, edited by Martin Helander, Thomas Landauer and Prasad Prabhu, is a book published in 1997 that attempts to summarise research relevant to the design of interactive software and hardware. Its 62 chapters fill 1500 pages and provide advice on a multitude of topics, covering analysis, design and evaluation of interactive systems, as well as the psychological and ergonomic underpinnings of human–computer interaction. One of those chapters is titled Keys and Keyboards and was written by James Lewis, Kathleen Potosnak and Regis Magyar. It considers virtually every imaginable factor involved in designing keyboards, and, by drawing from experimental studies, provides recommendations for each of them. Ever since I read this chapter a couple of years ago, I've been meaning to summarise some of their conclusions and to consider them in the context of modern keyboard design. The recent string of keyboard-related links on Daring Fireball (e.g. here, here, here, here, here and here) moved me to finally sit down and do it, so here it is.

Clickiness

One of the most-cited criteria for keyboard aficionados to prefer a certain keyboard over another is “clickiness”. The idea behind this is that a good keyboard should give you some tactile feedback when you've successfully “actuated” a key, and that you shouldn't have to depress the key all the way to the bottom to be sure, as this would not allow you to type very fast. Some keyboards don't click at all, some give a softer and others a sharper click. The exact behaviour can be described by a graph plotting how the physical force required to push the key varies along its way down and its way up. The sudden dip in force on the downstroke is where you will feel the “click”.

I have to agree with many others that the Apple Extended Keyboard II is the finest keyboard I have used in terms of key feel. I used it for a couple of years in the late 90s, and it was the first to even make me aware of how good a keyboard could feel. I have not found a match since. In 2004 I bought a Matias TactilePro, which supposedly uses the exact same mechanical switches as the Apple Extended Keyboard II. However, it seemed to require more force, wasn't as smooth and seemed more noisy. Keys also kept failing, so I eventually gave up on it and now use a Macally icekey, which uses scissor-switch keys like those found on a laptop, but feels a bit firmer. I have also been quite impressed with a standard HP keyboard that I use at work. It uses rubber dome switches, which usually have a much inferior feel to mechanical or scissor switches, but they are square rather than round, which seems to give it an acute but soft clickiness and a very pleasant overall feel.

Hysteresis

I already mentioned that the key actuates when the click happens, but when should it deactuate? The obvious choice would be to make it the same as the actuation point:

However, this behaviour leads to an unexpected problem: any tiny amount of vibration around the actuation point can mean that the switch briefly fluctuates between the open and closed states, causing, for example, a letter to be inserted twice on one key press. To avoid this happening, keys should have to return some way (0.25–1.5 mm) before deactuating. This distance is called hysteresis:

Astonishingly, plenty of modern keyboards seem to have no hysteresis built into their switches. I get duplicated letters more than occasionally when typing on my Macally icekey or on my G4 iBook. The MacBooks don't seem to use hysteresis either. I haven't had a chance to test one of the new aluminium Apple keyboards or a MacBook Pro for this.

Travel and force

Another common factor mentioned when assessing keyboards is the distance the keys travel. Laptop keyboards and laptop-like keyboards tend to have shorter travel than most desktop keyboards. Related to travel is the amount of force required to depress a key. The Handbook of HCI recommends key travel to be between 1.3 and 6.4 mm, and the key force to be between 28 and 142 g. These are rather wide ranges, and in fact experiments showed that users are not too fussed about these two variables and will simply adapt their typing behaviour accordingly.

Keyboard profile

The book chapter summarises the results of two studies looking into keyboard profiles. The dished profile seemed to narrowly come out on top, with higher throughput than the stepped profile in one study. The flat profile performed worst (ahem), with more errors going undetected by typists and with lower throughput.

Key shape

The vast majority of keyboards have key caps that are either concave or dished. Apple however, has started giving their keyboards flat keys. Unfortunately, the book doesn't give any recommendations in this regard. However, I have my own little theory about this. I think that key shape matters because the direction at which you strike a key is rarely perfectly parallel with the key's travel path. Most of the force you apply may go into moving the key down, but the rest will go into pushing the key sideways and into pushing your finger along the surface. The less force goes into moving your finger sideways, the more force goes into the key. A concave key cap directs more of the force into the key when you strike it an angle, which effectively increases the area that you can comfortably use to depress the key.

As I said, this is purely a theory, and I have no evidence that the key cap shape actually makes any difference. I haven't spent enough time on one of the newer Apple keyboards to really form an opinion about them.

Other factors

Some of the other factors to consider in keyboard design are tilt, key size and key spacing.

All users in the studies referred to preferred having some tilt rather than a completely horizontal keyboard. 50% preferred an angle between 15˚ and 25˚. Not surprisingly, the preferred angle correlates with the seat height and with the user's stature.

Keys should be no less than 19 mm apart, as more tightly spaced keys tend to slow users down. There were no conclusive results on key size, but the ANSI standard recommends a size of 12 mm × 12 mm.

Final thoughts

Clearly, a fair amount of work, time and research funding went into this topic, especially during the years when computers were less of a commodity and still more of a research topic. The work successfully produced empirical evidence that led to very concrete and specific recommendations for the design of keyboards. Even so, today's keyboard makers seem either oblivious or ignorant of all this latent wisdom. Given that we're talking about a device that millions of people have to physically interact with on a daily basis – in many cases for several solid hours – it is sad that we've kept repeating the same mistakes that we've had the potential to avoid for more than twenty years.

Hyphens, dashes, et cetera

I have a thing about correct punctuation, and although I'm aware that most people would find me over-zealous in this regard, I would bring to my defence that it's not just a pointless obsession or a purely aesthetic matter. A bit of poor punctuation will in the best case distract those from the text who notice it and affect their impression of the author, and in the worst case actually give the reader trouble understanding a sentence. Having said that, what I'm going to write about today is more on the aesthetic side, but could nevertheless help you make a good impression on a reader who notices these things.

I have noticed what seems to be a recent trend, especially on the web, to put unnecessary hyphens between adverbs and adjectives when they modify a noun, as in a brightly-lit street (which should be simply a brightly lit street). This habit seems to originate in the hyphenation of compound modifiers, as in real-estate agent or an out-of-date book. But those examples are hyphenated to avoid ambiguity or because the words in that order would not make a valid sentence structure without hyphens. Adverbs that end in -ly are always modifying an adjective or another adverb, so there is no ambiguity. Only adverbs that don't end in -ly, such as well, most or fast should get a hyphen, as in fast-running man.

Here are some examples from sites that I read regularly, including BBC News:

newly-elected councillors
reasonably-sized buttons
poorly-served areas
the highly-anticipated device

These should just be:

newly elected councillors
reasonably sized buttons
poorly served areas
the highly anticipated device

After all, you wouldn't write a really-good movie either.

Another trend I've noticed is around the use of dashes in what are called strong interruptions. When you have the right symbols available, there are two ways to punctuate such an interruption:

You can use en-dashes – Option-Minus on a Mac keyboard – surrounded by spaces.

Or you can use the longer em-dashes—Shift-Option-Minus on a Mac keyboard—without spaces.

Using an en-dash with spaces is common in Britain, while using the em-dash is more common in America. Personally I prefer the British style, because it visually offsets the interruption from the rest of the sentence more. What some people tend to use on the web, however, is an em-dash with spaces — like this — which I think looks odd because it creates a huge gap between words. If you prefer the look with spaces, just use an en-dash.

While we're on the topic of dashes, I'll briefly mention two common cases where an en-dash should be used rather than a hyphen. One is for ranges, such as 1980–2008. Another is when combining two nouns in a way that implies a to- or and-relationship, as in the London–Paris Eurostar or parent–child relationship.

My sources for most of this are The Penguin Guide to Punctuation by R. L. Trask and Type and Typography by Phil Baines and Andrew Haslam.

Surface computing, move over!

For a few weeks now, my two team-mates at work and I have been using a “horizontal” whiteboard, lying across the desk surface between us. I had been wanting to try this for a while, but it wasn’t possible because of our previous desk arrangement. Now that we have this large area of space between us and no partitions, this small whiteboard fits perfectly without getting in the way.

We’ve found ourselves using it virtually every day, illustrating explanations, walking through calculations and brainstorming design ideas. Visitors will intuitively pick up a pen and start using the whiteboard when explaining things. It somehow seems to invite people to use it more than most whiteboards. However, it’s not only a collaborative tool: it also makes a great scratch-pad when you’re brainstorming on your own. To ensure that it stays useful, we make an effort to keep the board clean; nothing tends to stay on there for longer than a day or so.

Overall, it’s being used far more than any wall-mounted whiteboards we’ve had near us, and I think this is due to two key differences to wall-mounted boards. Firstly, each one of us can reach the board very easily without having to get up. You just turn your chair slightly and there it is. Secondly, the whiteboard is between us, so it feels less like a presentation aid and more like a collaborative work surface, accessible equally well from all sides.

If your work involves collaborative problem-solving, and if your desk arrangement allows it, I highly recommend setting up a whiteboard like this. Don’t make it too big, because you won’t be able to reach all corners and it will also eat into your desk real-estate. I think ours is 90×60 cm, which is just right. I also recommend investing in some pens with a finer tip than the standard ones you tend to get. Those are designed to be visible from a few meters away, but you’ll find them too thick for handwriting at a comfortable size for close-up work. Edding do quite a range of dry-erase board markers.

Neutech desktop background redux

There was once an appearance theme for Mac OS 8 and 9 called Neutech, by Flanksteak Design. I don't think I particular liked the theme as a whole, but it included a desktop background that has been my favourite background for the last eight years or so since I discovered it:

Here's a detail:

I have made sure I that I always have a copy, which has survived across all the different Macs I've used since. However, the image is only 1024 × 768 pixels, which wasn't small at the time, but makes the image look rather pixelated and blurry on modern displays. I have made several attempts in the past to reproduce it in Photoshop, but never got very far. Today, I sat down again with renewed determination and finally found the secret recipe to emulate the look of the original:

One thing that really helped here was Photoshop CS3's Smart Filters, because I could experiment and keep tweaking the many effects I had to apply. This also means that I can easily produce updated versions in the future as screen resolutions increase.

For the time being, here's a 2560 × 1600 version.

Update: I've changed the grid to look more like dried earth and less like reptile skin, and made minor changes to shading.

Namely 2.5

Sorry to be late by a week or so, but there are several reasons why I didn't get a Leopard-compatible update to Namely out sooner.

First of all, I didn't have Leopard any earlier than most of you; I bought it on Friday the 26th of October at the Apple Store on Regent Street. That's because unlike many Mac developers who dedicate a lot more time to this stuff and who have an income from it, I don't have a Select membership with the Apple Developer Connection.

Secondly, I decided to try out Leopard's improved support for application launching through Spotlight before putting any effort into updating Namely. Ever since Scott Forstall had hinted at this feature at the World-Wide Developers' Conference in 2006, I had been feeling a bit anxious about Leopard rendering Namely redundant. (I generally think it's a good thing when Apple fills a gap that was identified and addressed by third-party developers, but nevertheless, we do tend to fall in love with our applications.) My verdict: Spotlight is not bad, but it didn't win me over. I didn't spend enough time with it to figure out how clever it is about choosing between candidate matches (it seems to at least take into account which app you chose last time), but long enough to find a few things that I didn't like about it:

1. A lot of stuff happens visually in the Spotlight menu, which distracts from your main task: quickly identifying the application you want to launch.
2. The icons of listed apps don't always appear straightaway.
3. It only shows three matches, so it's effectively a bit less tolerant.

I guess these things shouldn't be an issue if you only occasionally need an application that's not in your Dock. Finding it through Spotlight will still be much faster than navigating to it in the Finder. But I think that if you use Namely (or, for that matter, any other keyboard-based launcher) for most of your application launching, anything that isn't super-fast isn't fast enough. When I launch an application, I don't want to think much, and I don't want to see much. I just want to launch it. Although Namely's sorting isn't perfectly predictable because it adapts over time, it stabilises quickly enough so you can be pretty confident about what it will suggest when you type something.

The third reason for the delay is that I just wasn't sure what to release. I have been (slowly) working on Namely 3.0, which is controlled through a preference pane and doesn't show up in the Dock. So I was considering finishing that off rather than releasing another update to Namely 2.x. However, I wasn't confident that I could get Namely 3 finished and stable within a few days, so I decided to push out a minor update in the meantime.

Here it is. Annoyingly, I couldn't find a way to make it work on both 10.3.9/10.4 and 10.5 (I link against the 10.5 libraries in order to support Spaces, but this seems to stop Apple's secret application-listing function from working on 10.4), so I had to leave version 2.1 available as a separate download.