2008-04-24

Sliders on the Web

Browsing a site I'd never seen before, I saw a cool nod to accessibility: the site lets you make the size of the type in the main article bigger.

Great.

Except.

The control to do this is a miniscule Javascript slider.



So in order for their special font-size needs to be accommodated, users with those needs must acquire a tiny target that's 7 pixels in diameter, hold the mouse button down without moving of the target, drag it over by a few pixels without accidentally releasing the mouse button, and finally release the button when they're done.

And all that is after they've realized that thing can be clicked on and dragged.

And unlike a real, standard desktop UI slider widget, you can't click on an arbitrary point on the slider rail and make the slider jump to that spot. The only way you can change the font size is by sliding.

And the range of sizes is only a handful of discrete font sizes, not a continuous value (which is what sliders are good for).

And the target users for the grow-the-font feature are typically those who will have more problems dealing with small-target widgets and/or drag and drop.

And it's not keyboard-controllable the way a plain text link would be (you can't tab to it, and you can't move it with the keyboard).

That's a lot of "and"s, and just as many reasons why this is a bad design decision. This is nothing new--it's been known for ages that drag and drop is hard to perform and non-intuitive for certain actions. So why put a hard, unnecessary constraint into Web pages?

I don't know what made sliders in Web apps so popular in the past couple of years, but I really wish designers and developers would realize what a horrible widget they are. They're very difficult to acquire, maneuver and discover, and you can always replace them with an easier, more discoverable UI element.

Here are obvious suggestions that would take exactly the same amount of space on the screen and considerably less time to implement and debug, not to mention obviating the need for the slider JavaScript library to be downloaded with the page:

  1. icons of the letter A in different sizes, each mapped to a font size
  2. one big icon of the letter A with an up arrow next to it, and another with a down arrow next to it. Ideally the "shrink" A would be a little smaller than the "grow" A
  3. text links labeled "bigger font" and "smaller font"

Simple and standard usually win in my book; the burden of proof is always on the more complicated option.

2008-04-13

On Tools

The starting point for a recent post on Coding Horror about attitudes towards open source and free software is a discussion of programming tools for diffing code or building regular expressions. I won't debate the merits of free v. pay or open-source v. proprietary, since that's a mostly pointless argument and Atwood's readers already beat it into the ground. What I would like to take up is the narrow notion of tools for programming. Some smart aleck posted the following comment:

One more thing--real programmers don't need tools to work with regular expressions.


To which someone responded:

Yeah yeah. Neither do you need IDEs and nice flashy GUIs. Unfortunately "real programmers" are Martians on a totally different plane of existence from "real people", for which usable GUIs are made. We are on the business of helping humans, not Martians, so you "real programmers" can go ahead and marry your console apps for all we care.


I think the response misses the point. I am completely in favor of using tools to make software development easier, faster, and less error-prone. Syntax highlighting, fast access to files in your project, code auto-completion, visual diff tools like WinMerge, one-key access to your language's documentation, all of those are great--the computer's memory and ruthlessly error-free comparison skills are an excellent substitute for a human's, especially when it's late and you're tired or you have repetitive stress injury and can save a few keystrokes.

While I do expect a good programmer to remember most of their language's syntax and common libraries, I see no problem with having to look up the parameter order or the specific name of a method, especially when you're dealing with sprawling, messy beasts like PHP, the Win32 API or Java. What matters is that the developer knows what they want to accomplish and how to make it happen. Using visual tools for building regular expressions, on the other hand, suggests that the developer lacks a fundamental skill that should be part of their core skill set.

Again, I have no problem with someone looking up their language's specific syntax for the "word boundary" character group, or the greed-inversion switch, or any silly implementation detail of that nature. Remembering all of those details is great, but what I look for in a developer is someone who knows how to do things in general and has a sense of what the technology makes available to them. In other words, I'd rather hire someone who needs to look up the greed-inversion switch in PHP but knows it exists than someone who writes massively complicated regular expressions that could be simplified if only they knew about that switch.

For example, let's say you're trying to extract whatever is between tags in an XML document in PHP, and for some reason you don't want to use a parser. You could do something like:

$regex = "/>([A-Za-z0-9_-]+)</";

which means "give me any letter, number, underscore or hyphen between > and <". It's the naive implementation, and it will work most of the time, until you run into, say, an escaped HTML entity starting with a #, at which point you have to go back and fix your regular expression.

Instead, you could do something like this:

$regex = "/>([^<]+)/";

which means "give me everything you find after > that's not a < ". In other words, "give me everything you find until you hit a <".

But perhaps more elegantly you could write:

$regex = "/>(.*?)</";

which means "give me everything you find starting at > but stop as soon as you run into a <", using the greed-inversion switch ? after the *. I find this approach somewhat more satisfying, because it has the "everything between tags" semantics built-in, and it is pretty robust, because it assumes nothing about the input it's expecting (other than "be a reasonably well-formed XML document"). All it takes is the use of an extra switch that's sadly not mentioned in very many tutorials and that I often have to explain to very good, experienced developers.

The point of this digression is not to show off regex-building skills. The point is that a GUI tool for building regular expressions won't help much in this particular situation, because ultimately there's no question that you have to build a complicated thing--the tool only helps you cobble that thing together, but in the end you still have to live with it. There's only so much you can look up about regular expressions, and if you don't understand them or know their capabilities very well, you'll only write mediocre or brittle ones.

The upshot of all this is that tools are perfectly fine, and even encouraged, when they substitute machine reliability for human frailty. But they're certainly no substitute for a solid, well-rounded skill-set, and that well-roundedness requires a lot of painstaking, manual work. Microsoft Word's spellchecker will fix your typos, but it's not going to make you a better writer.

2008-04-04

The Cheezburgery Tales

I just realized that LOLcat is really Chaucer with modern illuminations.
here bygynneth the Book of the tales of Caunterbury.

1 Whan that Aprille, with hise shoures soote,
2 The droghte of March hath perced to the roote
3 And bathed every veyne in swich licour,
4 Of which vertu engendred is the flour;
5 Whan Zephirus eek with his swete breeth
6 Inspired hath in every holt and heeth
7 The tendre croppes, and the yonge sonne
8 Hath in the Ram his halfe cours yronne,
9 And smale foweles maken melodye,
10 That slepen al the nyght with open eye-
11 So priketh hem Nature in hir corages-
12 Thanne longen folk to goon on pilgrimages
13 And palmeres for to seken straunge strondes
14 To ferne halwes, kowthe in sondry londes;

How is that any different from, say: