I’ll always remember a line from a play I was in during college. It was an original musical, and the composer couldn’t come up with a good line by the time he had to hand out the scripts, so he filled it in with “Come around and schmoo” just to keep the rhyme in place. Oddly, I can’t remember the line he finally replaced it with.

And of course, Firefox’s cookie preferences were labeled “Cookies are delicious delicacies” for so long during the beta period that by the time they wrote a real description for 1.0, someone wrote an extension to put it back in!

Well, sometimes dummy text makes it through “rehearsals,” so to speak. Jim Heid found live sites with various kinds of filler text. Not just the ubiquitous “Untitled document” (millions of pages), but samples of “lorem ipsum” filler and even ~250 hits for “this is placeholder text” (whoops, I’m gonna skew those results a bit.)

(via Scobleizer, who recommends using “xxxxx” exclusively for placeholders.)

Here’s a pair of excellent articles about how to avoid cluttering up your website so that people can actually see your content. The article is, however, hampered by appearing on a site that seems to violate every usability principle imaginable…. to the extent that the second one showed up on the Cruel Site of the Day [archive.org]. From the introduction:

We’ve all visited websites that made us wince. You know what I mean: full of distracting animation, flashing text, and enough other clutter that it reminds you of a Victorian home filled to bursting with knick knacks. Are you guilty of filling your website with useless junk? Christian Heilmann takes you down his checklist of website clutter. You just might find yourself considering a redesign.

Yeah, that sounds like a description of Dev Articles to me. I count no fewer than 8 ads on the first page, 6 of them animated. The text is buried in a morass of advertisements and navigation that make it extremely difficult to actually read the article.

It reminds me of a book called Fumblerules, which collected (or possibly originated) guidelines like “Always proofread carefully to make sure you don’t any words out,” or “Plan ahead” with the last few letters scrunched together to fit on the page. These were designed to make their points by deliberately breaking the rules to make them more memorable.

Well, there’s always the Daily Sucker.

Update: I checked out the author’s website, which demonstrates he has the sense of taste and aesthetics one would expect from his articles. It really is too bad DevArticles isn’t willing to take his advice.

All the Linux desktop action these days is in KDE and GNOME, but on older hardware, servers, or anything else where you need to squeeze every last ounce of performance from the box, something lighter is needed.

[Screenshot of a WindowMaker desktop] My Linux box at work — a 300 MHz Pentium II — runs WindowMaker. It’s familiar, it stays out of the way, and it doesn’t tie up the memory or CPU that a modern version of KDE or Gnome (or Windows, for that matter) would. But you need to add applets like a clock or a desktop pager. You can find them easily enough — I ended up using the aptly-named wmclock and wmpager – but there’s a significant problem with both. WindowMaker lets you change the size of the dock icons, but when I shrank the dock to get more space I discovered that both applets have a hard-coded size of 64×64 pixels.

[Pair of WM Applets, first at default 64x64 size (they look fine), then at 48x48 (they don't adjust and edges get cut off)] As you can see, a 64×64 applet just doesn’t work in a 48×48 space. It surprised me, though, since these dockapps are designed specifically for WindowMaker, and it’s WindowMaker itself that lets you change the size. You open up Preferences, change the size, and restart WM. Just menus and buttons. No config files, no registry, no third-party add-on. This isn’t an esoteric hack that takes serious effort to find, it’s a basic feature. You might as well design a Mac program that assumes the Dock is on the bottom of the screen. For most people it will be, but it’s not rocket science to move it.

In my ICS classes, they always discouraged us from using “magic numbers” — just throwing a number in the code without identifying or abstracting it. There are two very good reasons for this. The first is that you might forget what this 64 is doing. The second is that you might decide to change it later on, and it’s much easier to change one SIZE=64 definition than to track down every 64 and hope you’ve neither missed any you need to change nor changed any you need to leave alone.

Those dock applets are stuck at 64×64 pixels because the programmers were thinking in terms of the pixel grid, not in terms of actual display size. Continue reading

Pet peeve: Login forms that move the cursor to the username field AFTER the page finishes loading. Sometimes I’m already typing by then. #

While working on a website for work, I inadvertently discovered why a web application I use frequently has the annoying habit of moving the cursor to the username field when I’m halfway through typing the password.

The basic way to set initial focus on a form field is to use JavaScript like this:


You can either embed it in the HTML after the form, or call it in the page’s onload() function. The problem with using onload is that it fires when everything is loaded, which means it waits for images, plugins, and so on. That’s very useful for some tasks, but isn’t the best choice here.

I’m impatient, especially with login forms. I don’t need the logos and background, I want to type in my username and password as quickly as possible and start using the app. Since this particular site isn’t exactly the fastest around, invariably the images don’t finish loading until I’ve started typing the password — and suddenly I’m typing the second half of the password in the username box.

Needless to say, I’m using the inline method on the site I’m building. Not that the login page has any images right now, but if I add any later on, it’ll save the users some aggravation.

Note: I’ve attached a 2009 tweet and the subsequent LiveJournal discussion to the original 2005 article.