Other uses for Unicode

Unicode identifiers are impractical because users can't type them. But languages can safely use Unicode characters for many other purposes. For example:

• Prompts. Doesn't every language need a distinctive prompt? Why not adopt a Unicode character, so the prompt won't look like anything users type?
• Alternate names: If you allow one symbol to have multiple names, the pretty-printer can use Unicode while humans type in ASCII. Doing a lot of this would interfere with learning, but basics like printing Haskell \ x -> x as λ x → x shouldn't hurt much.
• Alternate reader syntax: Similarly, print can use Unicode characters in place of the least satisfactory ASCII ones. Wouldn't it be nice if vectors printed with proper angle brackets instead of #(...)?
• Unreadable objects: If an object's printed representation can't be read back in, it need not be typed by humans, so it can use arbitrary characters. This might improve the printed representations of functions, classes, promises, etc., which often print unhelpfully at the REPL.
• Non-ASCII art: Languages (and libraries) often print everything as text, even things like tables that shouldn't be, because that's the only output interface they can rely on. Unicode can help make this less ugly. (Box-drawing characters!)
• Documentation and error messages: you can use whatever you want here.

REPLs, by the way, should exploit terminal control before worrying about Unicode. Small improvements like coloring and a syntax-aware line editor make a big difference to usability. Not everyone has an IDE or wants to use it for everything.

No value

Slime (the Emacs mode for Common Lisp) is nothing if not helpful. It autoindents, it completes symbols, it shows backtraces, it fontifies output. It even helpfully points out when an expression returned no values:

CL-USER> (values)
; No value

This is missing the point. Almost all CL functions can find something useful to return — even those, like rplacd or write, that are called purely for their side effects usually return one of their arguments, just to make them easier to insert into existing code. Functions producing zero values usually do so not because they have nothing to return, but because they're intended to be used at the REPL, and they don't want to clutter up the output with an uninteresting value. But Slime's helpful comment defeats their efforts. Observe:

CL-USER> (describe 'values)
VALUES is an external symbol in #<PACKAGE "COMMON-LISP">.
Function: #<FUNCTION VALUES>
Its associated name (as in FUNCTION-LAMBDA-EXPRESSION) is VALUES.
The function's arguments are:  (&REST VALUES)
Function documentation:
  Return all arguments, in order, as values.
On Fri, Mar 24, 2006 07:42:39 AM EST it was compiled from:
SYS:SRC;CODE;EVAL.LISP
  Created: Friday, April 15, 2005 09:57:55 AM EDT

; No value

How is this an improvement on a meaningless NIL?

(Hey, look, a logical pathname! I didn't know anyone used those.)

Scrolling vs. pointing

Scrolling is one of the most common operations in most user interfaces, so it's not surprising that we have special hardware for it. Scrollwheels (and trackballs, the two-dimensional equivalent) are now common on mice, and on some other devices such as Blackberries. But this is a fairly recent phenomenon. Fifteen years ago, almost nobody had hardware for scrolling.

This is significant because it affects user interface design. We're accustomed to having dedicated pointing devices, and consequently our designs assume that pointing is easy. (And when this assumption is wrong, as it usually is on laptops, our interfaces can become quite clunky.) But we're still getting used to having dedicated scrolling hardware, so we design as though we didn't. We waste screen space on scrollbars, even though users rarely use them. (I only use mine when my scroll ball is gummed up.) We try to avoid having to scroll, because we think it's cumbersome. (And it still is, even with hardware, but it's not quite as bad as we're accustomed to.) We eschew spatial navigation in favor of more abstract interfaces, because we don't expect to have a good way to express movement in space.

Standard scrollwheels do have some annoying problems: their quantum is large, so it's impossible to scroll slowly or smoothly with them. This could be overcome with small changes to the hardware, or entirely in software by smoothing the scrolling. And they require repetitive movements to scroll long distances, which may be an RSI risk. Maybe something like a joystick would be better.

Any interface designer knows to optimize the most common operations, and we should remember that one way to do this is to use what the hardware gives us. If scrolling can be expressed only clumsily, via pointing, we should minimize it. Now that we have hardware for it, shouldn't we exploit it?

You know you think about usability too much when...

Last night I dreamed I was hurriedly trying to type something into a cellphone. It had a clever keyboard layout, designed to minimize the number of presses for common letters at the expense of rare ones, so ETAONRISH were just one press each. Fortunately I never had to type Q.

So far, so good. There was just one little problem: it didn't match the keys. They were labeled with the standard layout, where the common letter S takes four presses. The phone worked around this problem by showing the captions on an onscreen keyboard, for the convenience of beginners like me.

Unfortunately the ones it showed belonged to a different clever layout - one that tried to reduce keystrokes by spreading them more uniformly across all twelve keys. (This doesn't make a lot of sense, but I was asleep, okay?) So I was reduced to guessing, while both keyboards helpfully misled me, and the efficient layout was for naught.

Remember those easy, carefree flying dreams? I don't have those anymore. Instead I dream about difficulties controlling my flight. This is what happens when you think about usability problems too much. You start to dream bad user interfaces.

Losing data made easy

In the Save As... dialog box in Mac OS X, it is possible to select an existing file, in which case that file will be overwritten. Just like Windows, in other words. (Is there a single feature Mac OS X has adopted from Windows that's good?) Actually it's more dangerous than the Windows equivalent, because there's no obvious indication that you've selected a file, and the filename field is at the top of the dialog, where you won't look after clicking on the file list below it. So it's easy to misclick and not notice that your carefully typed filename has just been replaced by the name of an existing file you do not want to lose. And if you thoughtlessly press return when asked "Are you sure you want to overwrite this file?", it will.

I had noticed this could be a problem, but I wasn't careful enough, and today I did it for the first time. Fortunately I was using Aquamacs, which helpfully made a backup of the file before clobbering it, so I didn't lose anything. (The backups can be annoying, but this is not the first time they've saved me. I should really be using a versioning filesystem.) But the same problem affects virtually every OS X application, and very few of them make backups. So here, in a system designed for ease of use, is a subtle feature with a rather unlikely intended use (usually the Save command does all the overwriting you want), and a very easy accidental use that loses data.

As the old joke goes:

How do you shoot yourself in the foot with Mac OS?

It's easy - just point and shoot!