Magus's Grimoire [Abridged]

I'm an unrepentant vim user, eschewing other text editors which might have less terrible internal scripting languages. I love vimperator for Firefox, and I'm about to give Chrome a whirl and the first thing I'm going to do is install Vrome for it. I prefer crawl to nethack and nethack to ADoM (at least in UI terms). I passionately hate almost every "webapp" ever written.

I do almost all my work in the console. It's not actually that I prefer doing everything in a cell matrix containing characters in a monospaced font; in fact, for a lot of things, especially reading, I'm increasingly finding that proportional fonts really are advantageous. [Please don't ask me about antialiasing; I still haven't done a good enough side-by-side comparison to determine whether it results in "smooth" or "blurry".] It's just that console applications as a general rule are much more likely to have an input UI which allows a little more expressiveness than pointing with your finger and grunting. (To be fair, some GUIs do allow you to grunt, whine, or whistle while pointing.)

The goal of the input portion of a tool's UI is to effectively transmit information (what you want to do) from your mind to the tool. I think there are a few basic principles that should be kept in mind when designing or evaluating a UI.

---

( Read more... )

As a designer of a tool, it's your job to think about how people will want to interact with that tool and make it as easy as possible for them to do so and get the most out of it. It's not good enough to do what's easiest for you to design, and it's not good enough to stop at only the features that will be easy to learn. For input, the tool should be able to capture relatively complex ideas in a simple way, and grow with the user. Users shouldn't have to ask, "I need to do this simple task about 20 times a day, why does it take 5 minutes to do each time?" At the worst, the answer should be because the user wasn't aware of the simpler way; it should never be because of an unnecessary limitation of the UI. Designers of database-interactive software, I'm looking at you, here.

I just requested of a friend that they reconfigure their email client to send email with a text width <=78 characters, so that when I quote relevant portions of their emails they can have every line indented and prepended with ">" without the formatting getting all screwed up. How 1990s is that? Why haven't we come up with a decent way of indicating quotes which is readable for people using plain-text, easily formatted to be pretty looking in serious mail clients, and doesn't depend on the terminal width being 80 columns? For that matter, why do we still send email with hard breaks somewhere in the 70th-78th column, rather than only using hard breaks for paragraph separation and allowing the reader's client to word-wrap nicely for readability based on the size of their actual view? Why did GMail, last I checked, fuck it up so that in their default configuration, if you do internal quoting rather than top-quoting or bottom-quoting, the quoted text is completely indistinguishable from the content of the new email?

Our tools suck. Here's what *should* happen:

* Our mailers should smoothly word-wrap the text of incoming emails when "lines" are longer than the width of whatever they're using to display the text. The cost in processing power is really negligible in today's world (and is being incurred at the sending end now anyway).

* We should all be able to assume this is going to happen, and thus send email which only uses whatever newline character is being used when it's necessary to denote something meaningful.

* Our mailers should do something to distinguish quoted text from the rest of the email body (every mail client I've used in the last 5 years has done this one way or the other).

* We should be able to assume this is going to happen, and thus be able to come up with a nice, simple, universal new standard for quoting text which degrades reasonably for crappy clients but doesn't make replying using internal quotation difficult/annoying. Actually, if we stop using hard breaks at the sending end in favor of word-wrap at the receiving end, the current standard of prepending "> " should suffice, since we no longer have to worry that adding characters to a line will screw up its formatting in the average case.

Have I just misconfigured mutt and vim and consequently missed out on the last 10 years of development? I'll have to look into that; it wouldn't be the first time it had happened. However, we *are* still including hard breaks in our email, and stripping out someone's hard breaks is dangerous (they might actually indicate formatting).

Along the same lines, in writing this post I need to type in crap like "&lt;". What's with that shit? The HTML team made a really crappy choice when deciding which characters should have special meanings and what we should do when we want to use them the normal way. Why can't I escape special characters with a backslash, so it's "\<" like in every fucking other thing I use, is trivial to type (just hit backslash before what you want), and is easy to remember (just hit backslash before what you want). Fuckers. I may have to figure out how the JLJ preprocessor works so I can extend it to do exactly that, because this crap is stupid.

(The formatting on this is probably going to be FUBAR because I can't be assed to enclose every paragraph in <P> tags like I usually do, and I haven't yet learned how to use this tool if I'm not going to send true HTML. I should do that sometime; it's a nice tool in general.)

BTW, how do I get vim to show text as word-wrapped without inserting actual hard breaks in some form of text mode? I don't need a newline every 78 characters when I'm writing LJ posts, but it's much easier to read what I've written if the visual lines wrap at word boundaries instead of at the edge of the terminal, and if up/down go by the visual line rather than the real line. I'm sure someone's written something to do this and I just haven't found it yet.

Please don't tell me to switch away from the terminal. The terminal is exceedingly useful in a lot of ways, and by now we should have evolved our tools to take advantage of its advantages without putting us hostage to its apparent limitations (apparent because they're only limitations if we're lazy programmers).

I have a feature request for any window manager designers out there: focus_follows_eyes

I currently use Ion as my window manager on my home computer. It's great. You hardly ever need to use the mouse, and it seems to generally just Do The Right Thing. Except that sometimes it's so good at doing what I want it to that I forget which window has keyboard focus and start typing into the wrong one, because I've moved my attention from Firefox over to an IM conversation I'm having but haven't actually told it to move focus.

Clearly, what I need is for focus to move by default to whatever window I'm paying attention to. An interesting paradigm for that would be a monitor-mounted camera tracking my eye movements and keeping focus in whatever window I'm looking at. (Better, use the sloppy focus model so if I'm copying text from a printout or having a conversation with somebody focus will stay where I last looked.) You'd need to bind Scroll Lock or something to lock focus on a window for when you're manually copying text from one window to another or something like that. But wouldn't it be cool?