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?

Comments on Blogger

Has anyone in the programming blogosphere complained to Blogger about the paucity of tags allowed in comments? Anyone discussing programming is likely to want code and pre, and anyone discussing pretty much anything may want blockquote from time to time. The restriction to b, i and a greatly discourages conversations (at least about programming) in comments. And isn't that what blogs are for?

There's a small issue with pre: long lines will disrupt page layout, especially when comments are formatted narrow. This is possibly with plain old text if you use very long words, but it's much more likely to happen by accident with pre. But couldn't the comment software just check for long lines while it's checking for forbidden tags?

WordPress allows these elements. Why doesn't Blogger?

While I'm complaining about Blogger, I should complain about something else that's annoyed me: the small size of their textareas, both for posts and comments. I can see how the small comment area might help discourage long comments, but couldn't the posting area be a little bigger? Maybe twenty lines instead of fifteen?

Not that I really care. I write most of my posts in Emacs.

Edit: How could I forget Blogger's most annoying feature? By default, posts appear with the wrong timestamp: it's the time you created the post, not the time you published it. If you don't finish a post right away, you will accidentally backdate it, unless you remember to edit the date. This is one of the reasons I write my posts in Emacs instead.

Remapping keys

There are two keys on standard keyboards for which I have no use: Caps Lock and Insert. Both are intended to bring a slight convenience to a rare operation (typing in all caps or replacing fixed-length data), and both break keyboard input by entering a nonobvious mode where keys do not do what you expect. This wouldn't be a problem except that both keys are located next to frequently used ones, so it's easy to hit them by accident.

Well, not always by accident. I've remapped Caps Lock to Control on every machine I use regularly. This works great, except when I try to use someone else's machine. Then I routinely find myself typing something like C-d to delete a character, and being confused when I find the character still there, and subsequent typing in all caps. This is especially embarrassing when I do it on Windows, where C-d wouldn't have worked even if I'd used the right key.

I've also tried swapping parentheses with square brackets in my emacs (using keyboard-translate), but this is even more confusing, because it doesn't apply in other software on the same machine, let alone on others. (I've been using it for weeks and haven't gotten used to it.) And even when it works, its benefit is questionable. The square-bracket keys are far enough from the home keys that they're not terribly easy to type - maybe no easier than the regular parentheses. A number of Lispers recommend this swap, but I haven't found it helpful, even for Lisp.

I haven't remapped Insert, because it's not in as valuable a place as Caps Lock, and my home keyboard doesn't even have it. Mac keyboards use it for Help instead, which is only slightly less annoying when you hit it by mistake, and still not frequently used enough to deserve a key. Maybe it's comforting to beginners, but I suspect beginners would find an Undo key much more comforting, as long as it worked reliably. There must be many other common operations worthy of a key (although I can't think of any right now; someone help me). So do we have to waste hardware on annoyances like Caps Lock and Insert?

Learning to touch-type (finally)

Confession time: I can't touch-type. I've never bothered to learn, and when I try, I make so many mistakes that I give up and go back to visual typing. (And by the way, I mean visual typing, not hunt-and-peck. I know where the keys are; I just can't hit them reliably by touch alone.) In this I'm like most typists - touch typing is an ideal more aspired to than practiced.

But many people more productive than me highly recommend it. So today I googled up a nice typing-practice program, and I'm amazed at how fast I'm learning. My unconscious knowledge outstrips my knowledge of it, so after less than an hour of practice, I already find my fingers correctly typing things while I'm still trying to remember where the keys are. This suggests I actually touch-type more than I'm aware of, and have only a little kinesthesia to learn. Well, that and using the right fingers, and keeping my wrists straight. I should have done this years ago.

Better late than never. I touch-typed this post.

You know you're a programmer when...

Last night I was trying to decide where to plant some flowers. There were some restrictions - for one thing, I didn't want any plant to be hidden behind a taller one. The morning glory had to go next to the railing, so it would have something to climb. Identical plants should be adjacent, but similar colors shouldn't be. And something conspicuous should probably go in front, so no one would trample the flowerbed by accident. Obviously this was a constraint problem, and one too hard to solve in my head. So, trowel in hand, I set about figuring out how to solve it by machine.

It is a valuable habit for a programmer to hand any problem over to a program at the first sign of difficulty. Or at least it's valuable when you're sitting at the keyboard and already know how to solve the problem. Unfortunately I've never actually done constraint programming, and nothing in the garden proved helpful. So I was still trying to figure out how to explain the problem to a computer when I noticed it had gotten dark, and I had only planted a few of the flowers.

Real programmers can build constraint solvers out of dirt and weeds. I, on the other hand, got to plant my flowers in the dark.

A heap of possibilities

I needed a priority queue a few months ago, and didn't have a predefined one, so I used a sorted list, since n was always small. But that won't work for many applications. Yesterday I wanted a pq for a best-first search with a potentially large n. Obviously a heap was the answer. But the modest trouble of implementing one was enough to discourage me from trying that search. It wasn't in the standard library, so it was too much trouble to bother with.

Heaps are quite useful, and quite stereotyped, so they make good candidates for a standard library. I think they (like most data structures) would be most convenient as a heap type which supports the same operations as other collections, but with the particular performance characteristics of heaps. In addition, it's probably a good idea to expose the two internal reheap operations (adding and removing) so they can be reused for variations like limited-size heaps, or heapifying an existing array as in heapsort or heap-select.

And they should be ordinary destructive heaps, not functional ones. The motivation for heaps is performance, and heaps that require consing can't compete with those built on arrays. The flexibility functional heaps offer isn't worth the performance cost, because heaps are almost always used linearly.

When you have heaps, some fancy algorithms become much easier. The search I wanted yesterday, for example (in pseudo-Lisp):

(defun a* (expand min-cost done? init)
  "Best-first heuristic graph search. Starting from INIT,
find the lowest-cost node that satisfies DONE?, where
NEIGHBORS is a function on a node that returns a list of
its neighbors, and MIN-COST is function from a node to a
lower bound on the cost of any node reachable from it."
  (def pq (heap (o* < min-cost)))
  (def (step x)
    (if (done? x)
      x
      (do (each (expand x) (add! _ pq))
          (aif (pop! pq)
            (step it)
            nil))))
  (step init))

If you really want to make fancy algorithms easy, you could include functions like that one in the standard library. The greatest strength of functional programming (in the high-order sense) is the ability to abstract algorithms; we might as well use it.

How not to keep a to-do list

One of the main functions of a feed reader, as I use it, is a to-do list: it keeps track of what items I haven't read yet. This is an affordance that I find useful, but it's not really intended by the authors of feedreaders. This leads to some annoying deficiencies.

Google Reader only remembers items for a month. After that, it automatically deletes them, whether you've read them or not. This makes sense if you use the reader for browsing recent news, but not if you use it for remembering to read every post. For a to-do list, it is difficult to imagine a misfeature worse than automatically forgetting items.

I've lost some 30 unread items in the last week. Some were unread because they were uninteresting. Some were unread because they were so interesting that I was not done with them after one reading. Some were unread because I simply hadn't gotten around to them yet. I don't know how many of each there were, because Google Reader won't even show me what's expired. This invisibility makes the expiration misfeature far more annoying than it would otherwise be. I have lost part of my to-do list, and I don't even know what I lost.

I like Google Reader's portability - I can read my feeds from any machine. But I do almost all of my reading from one machine, so maybe I should find a reader that doesn't forget things. I can do that just fine by myself.

Faster than an arrow

Speaking of Emacs keys - I have lately found myself using C-n and C-p more and more often, instead of the arrow keys. These chords seem like they'd be more work, since they require pressing two keys instead of one, but the fingers don't have to move as far from home, so it's faster. In addition, I frequently use them in combination with C-a or C-e, in which case I already have a finger on Control and they only cost one additional keypress.

I don't use C-f and C-b much, possibly because I usually want to move by more than one character, so I use commands like M-f and M-b instead. When I do want to move by less than a word (e.g. to insert a missing space in the middle of a word) I usually want to do so repeatedly, so moving a hand to the arrow keys is less of a burden. I mostly use C-f and C-b on the rare occasions when I only want to move by one or two characters. There are fewer alternatives for vertical movement, so I use C-n and C-p more often.

Learning emacs the fun way

Welcome to keywiz
There are currently 366 commands.

Only 366, yet I still don't know most of them...

Keywiz is a game for learning emacs commands. This is something like the second best way to help users learn an interface. (The best is to unobtrusively show them what commands are available, as menus do, but that's hard to do for hundreds of commands.) It's not a great game - it's obnoxiously modal, its difficulty isn't variable, and it rudely stops play after two minutes. Nor is it thorough - it appears to only cover global keybindings, so it misses mode-specific goodies and anything requiring M-x. All it does is give you the names and docstrings of functions bound to keys, and ask you to type the key sequence. But as a training tool it's better than any documentation ever written.

tab-to-tab-stop
Insert spaces or tabs to next defined tab-stop column.

Well, that's easy. Tab.

Incorrect.  The correct answer is: M-i

There's another kind of tab? Ohhh, it's the manual indent, not autoindent. Hey, I needed that yesterday!

describe-coding-system
Display information about CODING-SYSTEM.

That's guessable. C-h c, right?

Wrong.  The correct answer is: C-h C, <f1> C, <help> C

Case-sensitivity, how do I hate thee...

isearch-backward
Do incremental search backward.

At last, one I know!

Indeed.  The answer is: C-r

Time's up
You made 4 points.

Ouch. I've been using emacs for years, and I still only know a tiny fraction of it. Maybe if I play a few more games...

Via Marco Baringer (probably) on Cliki.