Phones grow big and their top edges inch closer and closer toward the horizon. Over time, iOS and apps moved some of the important surfaces to the bottom (for better or worse – I still struggle with seeing results and completions appearing above inputs), and the well-designed Reachability gesture helps, too.
Still, the iOS web browser called Quiche Browser chose to tackle the problem, not the symptoms. It offers “Comfort Mode,” where you can ask it to move down the top edge of a bunch of surfaces closer to your fingers:
On top of that, true to the spirit of the app which revels in power-user customization, Quiche Browser allows you to decide precisely where the top should go in order to accommodate different people’s hands, and it even offers to do so per surface:
These are the affected surfaces with the option off and on:
The author, Greg de J., expanded on that on Threads:
While designing Comfort Mode in Quiche Browser, a tricky problem I had to be thoughtful about:
When you hold your phone in your right hand, favorite icons in the top left are harder to reach than ones on the right.
Search suggestions don’t have this problem, since they span the width of the screen.
That’s why favorites need to sit slightly lower than search suggestions, and why Comfort Mode lets you position both independently, so they all stay easy to reach one-handed.
It’s an interesting idea and I wonder if it’s seeing a lot of use.
The only design thought I had was: could the top space be filled or stylized so that this looks more intentional, rather than a potential rendering bug? Reachability does a good job of making it feel physical and adding a little arrow:
Then again, given my job, my brain might be perfectly primed to see rendering errors everywhere.
It is a testament to how much things have changed in competitive NES Tetris – a game released the same month the Berlin Wall fell – that this hour-long documentary by Summoning Salt that talks about the 2018 Tetris Championship covers the previous revolution in a play technique:
I don’t watch a lot of sports, but I think this is a sport movie: a battle between the classic DAS players – DAS stands for Delayed Auto Shift and means that the player just holds the left or right pad and have the piece slide on its own – and the new-at-the-time technique of hypertapping, which allowed to move the piece to the side faster, but was really demanding on the player’s hands.
It’s gripping at times – wait until the moment when a DAS player runs with a dangerous move called “quick tap” – but also surprisingly touching at the very end.
(If you are interested, the newer playing technique that was invented in the 2020s, and even more effective than hypertapping, is rolling.)
If you’re a professional web app, your key shortcut situation is not to be envied. Once the operating system grabs the ⌘ shortcuts it requires (⌘M to minimize, ⌘H to hide, ⌘Q to quit, etc.), the browser has its turn, claiming everything from ⌘R, T, N, L, W for tab operation, to ⌘F, P, O, and S for other things. And then, some input controls inside the browser also need to listen to ⌘Z and XCV, and maybe even A (select all), B (bold), and I (italic).
At this point things feel barren, and some web apps start reaching instead for less common modifier keys (⇧, ⌥, ⌘⇧), and others go straight to no modifier zone, or override those of the above shortcuts that they can. Each approach, of course, has its own set of challenges.
It’s perhaps not a surprise that someone got fed up, and that someone was people working on the project management tool Asana, which did something relatively unique: it promoted Tab to be a modifier key.
The video shows me using Tab+K to like tasks, Tab+Return to open a sidebar, Tab+Q to add a quick task, and Tab+H to return home. Here’s the entire official shortcut list, with Tab shortcuts emphasized:
What’s fascinating about choosing Tab is that the key already has so much to do:
it moves focus to the next UI control,
it indents a bullet point or even just text,
it accepts an autosuggestion or a placeholder (and similar things).
On top of that, repurposing a key to be a modifier key – especially one that already has a job or two – will also have a long tail of strange consequences. And, Tab is only on one side, which could wreak havoc with the ergonomics of keyboard use. (You are, technically, always supposed to use the modifier key with the opposite hand to the hand you’re pressing the main key with.)
But…
I am not ready to hate it quite yet.
Tab is not the worst key to use in this context, as it’s really the only available big key other than Caps Lock, which is impossible to mess with on the web. The other big keys – the spacebar, Return, and Backspace – would be radioactive for this purpose.
The asymmetry issue? Anecdotally, I understand that both right-handed and left-handed people most often use the pointing device (mouse or trackpad) with their right hand, and consequently often prioritize left modifier keys anyway.
Here is how Asana deals with some other challenges:
When you press Tab to move focus around, the action can now only take place on key up, not key down, so tabbing (or, indentation of bullet points) feels slower.
When you hold a regular modifier key and then change your mind and simply release it, no action occurs. But Tab already has a job as a regular key (tabbing or indentation, depending on context), so if you change your mind, something will still happen. This might be annoying. (You can press Tab+Esc or Tab+Space for a safe cancel, but that doesn’t seem very intuitive, especially in a moment of panic.)
An action only on key up also means there can be no repeat when holding Tab. I am not sure how important this is, especially in the context of accessibility.
What’s interesting and I bet the main reason Asana approached it this way, is that Tab is a separate little island, far away from other modifier keys – and thus not just without any preexisting conflicts, but also impossible to confuse with other modifier keys. Asana could have kept all the shortcuts above but substituted Tab with Ctrl on a Mac and Alt on a PC, but those would then be packed among many other similar-feeling keys.
(There is a price for this isolation, as Tab backfires the moment you have to combine it with other modifier keys. Asana doesn’t do it very often – I have only seen Tab+Shift+D, G, and F – but I wish they didn’t do it at all.)
Overall, I’m surprised how positively I feel about it. If you use Asana a lot, I’d be curious how Tab-based shortcuts feel to you. If you work at Asana, I would love to know if you consider these a success.
The only thing that seems to be missing is an option to go back to regular shortcuts if needed, for people who might want it for motor control reasons. (It is possible to achieve that with tools like Karabiner Elements, but that tool is really unpleasant to use.)
Oh, also. Tab+B does this, because, well, “tabby.” Cute.
What Version History, a YouTube show from The Verge, does really well is revisiting older tech products from today’s perspective without allowing nostalgia to take over.
This episode about the Western Electric 500 – the canonical American landline rotary phone – is worth watching by all UX designers. There is no software here, as the phone is entirely electromechanical. But there are a whole lot of details to admire and be inspired by: the shape of the handset, the interface to change the volume, the iconic ring, the balanced and improved rotary dial, the behaviour of the cable, even the weight and balance of the whole device.
It’s not only that phone calls should all sound as good as they did in the 1950s – in my experience FaceTime Audio comes close, sometimes, but it’s so unreliable – it’s that you should try to play with a Western Electric 500 because you want your modern interface to feel like that.
The hosts – David Pierce and Nilay Patel, helped by Tim Wu, author of the excellent The Master Switch – also weave into it an entirely different angle, of how that phone fit into (and reflected) a specific period of American tech history, and how it related to AT&T’s then monopoly, including the phone jack and third-party access we just discussed re: John Deere. Even the discussion whether this is or isn’t a “hall of fame” object is good fodder for thought.
The episode – and the entire show – is also just a really enjoyable watch. If you like this ep, it pairs nicely with the one about the iPhone 4, another phone that transcended its origins through good industrial design, exactly sixty years later.
Speaking of fly-by-wire… William Langewiesche is one of my favourite technical writers. He finds a way to explain complex aviation aspects really well, and then add a certain amount of beauty and poetry on top of that. His style was a big influence on my book, and I like him so much I once compiled links to his writing so that others could find it more easily.
Here’s Langewiesche’s essay from 2014 about the 2009 Air France Flight 447, where an implementation of fly-by-wire – which means disconnecting the flight stick and attendant levers from immediately controlling flight surfaces via physical linkage, and instead putting motors and software in between – caused a fatal accident, as the pilots’ mental model of the system diverged too far from what was happening:
The [Airbus] A330 is a masterpiece of design, and one of the most foolproof airplanes ever built. How could a brief airspeed indication failure in an uncritical phase of the flight have caused these Air France pilots to get so tangled up? And how could they not have understood that the airplane had stalled? The roots of the problem seem to lie paradoxically in the very same cockpit designs that have helped to make the last few generations of airliners extraordinarily safe and easy to fly.
It’s an interesting read today in the context of robotaxis and self-driving, but also AI changing software writing:
This is another unintended consequence of designing airplanes that anyone can fly: anyone can take you up on the offer. Beyond the degradation of basic skills of people who may once have been competent pilots, the fourth-generation jets have enabled people who probably never had the skills to begin with and should not have been in the cockpit. As a result, the mental makeup of airline pilots has changed. On this there is nearly universal agreement—at Boeing and Airbus, and among accident investigators, regulators, flight-operations managers, instructors, and academics. A different crowd is flying now, and though excellent pilots still work the job, on average the knowledge base has become very thin.
It seems that we are locked into a spiral in which poor human performance begets automation, which worsens human performance, which begets increasing automation.
I was devastated to discover, while writing this post, that Langewiesche died last year. Rest in peace.
As a Mac user I naturally focus on that platform, but Windows 11 has had its own share of problems – and that list has grown so vast it’s hard to know where to start.
So let’s pick it up at random, with a post by Thom Holwerda with a great title “You can actually stop Windows Explorer from flashbanging you in dark mode”:
One of the most annoying things I encountered while trying out Windows 11 a few months ago was the utterly broken dark mode; broken since its inception nine years ago, but finally getting some fixes. One of the smaller but downright disturbing issues with dark mode on Windows 11 is that when Explorer is in dark mode, it will flash bright white whenever you open a new window or a new tab. It’s like the operating system is throwing flashbangs at you every time you need to do some file management.
I find the videogame-inspired nickname darkly – I’m sorry! – funny, but the problem is real. It looks like this (video via windowscentral.com):
It’s not a problem unique to Windows 11 – just the other night I saw this on Wikipedia on my iPhone, exacerbated by the delayed reaction of Liquid Glass buttons spastically adapting to the changing background:
But there is something about this that feels a notch more important than other visual and layout issues.
I think this is because dark mode is a contract – we’ll lower the brightness, and we’ll let your eyes rest. There’s a physiological part to it: a sudden flash of light when your eyes are not expecting to it can be actually physically painful. I think it’s worth thinking about it and futureproofing and sanding dark-mode views especially at their edges: loading states, error messages, signing in and logging off areas. The “flashbang” analogy is very apt, and especially so on bigger screens.
Chapanis began interviewing pilots who had crashed B-17s and B-25s and a pattern emerged that turned his attention to the controls within the cockpit. As Fitts said ‘the intense effort to produce new weapons, the race against time in industrial production, and the magnitude of the program required to train men to operate these new machines resulted inevitably in many instances in which the final man-machine combination failed to function effectively.’
What Chapanis found when inspecting the cockpits of these planes were two identical toggle switches side by side, one for the landing gear, the other for the landing flaps. These controls were also similar in size and shape. […]
He modified the landing gear control by adding a wheel-shaped knob and a wedge like shape to the wing flap control. Now pilots could feel and easily map the shape to the intended purpose. […] Chapanis had solved a real life and death issue with one brilliant insight.
Chapanis was a contemporary of Fitts of Fitts’s Law fame.
I forgot this was called “shape coding,” or perhaps I never knew that? I have employed and sometimes pushed for a similar thing, but I called it making sure things have “distinct visual signature” or something like this. I think “shape coding” would be a more appropriate term.
The article shows one simple UX example – I would love to learn more about who’s employing this deliberately. It is, after all, the opposite force to consistency, and I’m always interested in negotiating with consistency.
