Thoughts on the Palm Prē: Category Catastrophe

Note, Added A Few Days Later: This post does not tell the whole story. This is a wail of anguish, and is not intended to be balanced. For a more balanced look at the Palm Prē, read my later, and broader, evaluation of it as well as this post.


There are a lot of good things about the Prē, but right now, they’re almost all being overshadowed by the catastrophic mistake the webOS developers made with the Memo Pad and Task List. They appear to have been swayed by the general Google-based philosophy that “If you’ve got really good search, you don’t need any internal structure or divisions.”

This idea is completely wrong.

Not allowing me to divide things into categories and subcategories is a painful thing. The excuse that “you can find anything you want, just by searching”, misses the point that I don’t always want to search at all — sometimes I want to browse.

Sometimes, I don’t want to select a single item. Instead, I want to see which items are available. Dividing things into categories is also an exploration of the ways that things are connected to one another. Allowing access only by searching demolishes those interconnections.

The only thing that’s more wrong than denying the user the ability to sort things into categories from the beginning, as Gmail does, is to take away the categories a user has already set up. And that’s what the Memo Pad and Task List in webOS did with my imported data from PalmOS.

I used to have 237 memos, sorted into 11 different categories that relate to various hobbies and interests, projects I’m working on, my girlfriend, and so on. And within each category, memos were automatically sorted alphabetically by title. And I had 50 To-Do items arranged in 11 other categories, these ranging from locations (i.e., “things that can only be done at home”) to types of shopping trip (e.g., “things to pick up at the supermarket” vs. “things to pick up at Fry’s”).

These internal divisions are now completely gone. My 237 memos are now arranged in the order they were created in, which is absolutely useless to me. I can, apparently, assign each memo one of four colors, and I can drag them to reorder them, but I’d still be stuck trying to deal with a list of 237 items, where previously no category had more than about 2 dozen. This is the difference between a manageable list, and one that is completely unmanageable.

(As you might guess, I also had a bunch of categories in my Date Book — only 10, as it turns out. But categories aren’t quite as indispensable there, because a calendar app has a natural way of organizing data that’s more primary. Months and weeks even subdivide time for you automatically. So while I sorely miss the categories in my Date Book, their lack isn’t a complete, crippling, deal-breaker.)

To add to the difficulty of a 237-item list, webOS doesn’t seem to have scrollbars. The content will scroll just fine, but there’s nothing to indicate where you are in the list. Are you right at the top? Halfway through? There is no way to know. There is also no way to go quickly or easily from one end to the other; you have to laboriously traverse all the territory in between.

Confronted with such a nightmare, my first thought is, “What if I just throw away all my old memos and start fresh?” Admittedly, there is some cruft in there. (In fact, I do occasionally archive stale memos to my computer’s hard drive and then delete them. It could be worse; it’s not like I’ve kept everything.)

The mere fact that I’m considering nuking all my old data, just because the new system can’t handle it, is a tragedy of poor software design and backward incompatibility. But honestly, even that wouldn’t really help:

The very nature of the new memo pad means that it cannot handle very many memos before it becomes unwieldy. With no scroll bar and no way to filter the view, the user is forced to confront all of the information that’s present, instead of having any way of interacting with a reasonable subset of it.

Once there are more than, say, three or four dozen memos in the new memo-pad system, it will be unusable again.

And this means I’m going to have to find a new way to organize my stuff. My notes. My thoughts. My ways of remembering stuff when I’m on the go.

Maybe Palm will eventually put categories back in. I dearly hope so, because their lack is a calamity for me. But by the time they do such a thing, I’ll probably have found some completely new way to keep myself organized.

I am very upset right now. And this has all just been about one particular problem; it’s not like the Prē doesn’t have some other flaws. (The lack of a D-pad is pretty annoying.)

It has some nice features, and I really ought to write about them at some point, just for balance. But right now, confronting the complete breakdown of my organizational system, it’s hard for me to see any of the good stuff that lies beyond.

Edited to Add: It seems the To-Do List or Task List app actually does have a feature that effectively allows a single-level category grouping. It’s just somewhat easy to overlook at first. The Calendar will color-code items based on their source — for example, all items derived from Google Calendar might be blue, while ones from MS Exchange might be red. I think this is silly; I’d rather have, for example, parties in red, work tasks in blue, social appointments in green, and what-have-you.

Right now, all my items are green, indicating that they all came from the same source. I really hope later ones don’t pick up some other color; I’d rather have no categorization than color-coding that doesn’t match my thoughts and that I can’t turn off.

Notes on LJ Content Sieve

My latest project is something I call “LJ Content Sieve”: a Greasemonkey script to filter out content on one’s Livejournal views based on nearly any attribute of a post or comment.

However, Livejournal is very customizable. It has 31 different “layouts”, each of which can then be further “themed” by application of CSS. This means that a user viewing a given journal, community, or single post, at a given time, may receive an HTML document containing any of 31 different DOM structures.

This means that finding a post’s author, or title, or even just a single post or comment, is not a straightforward process. I’ve set myself up a Ruby script that downloaded my “friends” view, a representative entry with lots of comments, and my own journal view, thus giving me a set of 93 fixtures that I can test against. The Ruby script also tweaked each fixture in the process of spooling it to my hard drive, by adding the proper calls to JSUnit files.

At the end of each document’s <head> element, there’s a call to jsUnitCore.js. Then, at the end of each <body>, I add a call to the lj-content-sieve.user.js script itself, as well as a set of test files that depends on which fixture this is. Every fixture gets an ljcs-global-tests.js call added to it — that file contains tests that should work anywhere, regardless of what sort of page you’re on.

Then all the “friends” page fixtures get an ljcs-friends-tests.js file, which tests operations that should happen on every friends page. For example, determining which entries need to be deleted. (In contrast, single-entry pages get ljcs-entry-tests.js, and the page from my own journal — which stands in for a view of a community — gets ljcs-self-tests.js.)

Finally, each fixture page gets a test file based on its layout: the “3 Column” layout gets ljcs-3 Column-tests.js, while “Cuteness Attack” gets ljcs-Cuteness Attack-tests.js. (Hey, I didn’t write or name the layouts; I just have to make sure LJCS works with all of ’em.) These files will test that the actual DOM manipulations work properly.

Without test-driven development and automated testing to ensure that each layout and page-type is being handled properly, I don’t think this project would be manageable at all.

Musing on Mac Keyboards

I’m at a one-week contract this week, and the client uses only Macs. So I’m using an unfamiliar Mac keyboard — the kind with the transparent plastic casing, and the really stiff keys (by my standards, anyway).

I am starting to get used to the propeller key already, and getting sort of used to using Meta-K instead of my usual Meta-E to access the search bar/field in Firefox. But one nice thing…

Because of the weird keyboard, I’m hoping that I can avoid transferring these habits back to my normal, PC-keyboard typing. Maybe I’ll be able to turn this drawback into a minor advantage. (Which would be nice, because reaching for the propeller key on my home computer would be seriously annoying to me.)

Would Shlemiel the Painter Optimize Prematurely?

I don’t want to optimize this code prematurely. And “while you’re still writing it” is probably premature. On the other hand, totally ignoring algorithmic complexity is a sure route to a Shlemiel the Painter’s algorithm.

Do I really want to just write the whole thing, and then start profiling it to see where the hot spots are, and then possibly have to re-design the whole thing? That seems like the complete opposite of “work smarter, not harder”. Then again, it doesn’t matter if you write an O(n2) or even O(n!) algorithm if n is always going to be small… and in this application, I expect low-to-middling n values.

Of course, even if n will always be small, and increasing CPU power is my friend… even if it performs fast enough to make users happy, I’ll still know there’s a problem down there in the details. That may be the deciding factor.

Launching SSHblock

My latest software project is now available… where “latest” means “the latest thing I’ve launched, even if I actually wrote it over a year ago.”

The story is simple: I was tired of seeing “failed password” messages from sshd cluttering up my logs. I was also annoyed at the constant flow of dictionary attacks, even if I knew they’d never get in. So I whipped up a quick Perl script that acted as some glue between Swatch and iptables, and which would also give me some amount of reporting and history on who and what it was blocking.

Then I posted about it in my online journal, and a friend said it sounded useful. So I started getting it ready for release as a package that anyone could use…

And promptly realized that doing a decent, professional job of it would take more time than I had available. Fast-forward to now, when I’m unemployed and can only spend so many hours per day job-hunting — the result is that the world gets more software!

Cruel Rollover Trickery

I found an interesting UI problem today, on a site that I will be kind enough not to actually link to. Instead, I’ll just reproduce the general concept and problem here:



The links all just link straight to the nav bar itself, so if you scroll your browser view so that the list isn’t right at the top, you’ll be able to tell when you’ve clicked one of the links. See what happens?

You roll over one of the list items, and you get an immediate visual reaction: not only does the background change color, but the mouse cursor even becomes a pointer. It’s not just suggesting that your cursor is over a clickable item; it’s flat-out asserting that to be the case.

And it’s lying.

The clickable area is nothing but the text in the very center of the nav bar item, and the only feedback you’ll get when you hover over that is the destination URL appearing in your browser’s status bar — if you have that turned on; many browsers leave the status bar off by default.

I’m fairly sure the people at Anonycorp didn’t mean to do this. I think it was just an ill-considered (and poorly QA-ed!) mistake in choosing which CSS rules to apply on which elements. But it’s a horrible, cruel UI trick to play on your visitors and users. Don’t do this.

Don’t Waste My Time With Email Confirmation Fields

I just ran into yet another form on a web page that looked like this:






… and so on



These things drive me nuts. Once I’ve typed my email address in the first time, I just type Shift-Home to highlight the entire field, Ctrl-C to copy, then tab to the next field and paste it in. That’s still four more keystrokes than I should have to bother with.

Why do we never see forms like this?







… and so on



Why not just make the user confirm everything? What’s so special about email addresses that we have to type them twice?

My simple answer: nothing. Don’t do this. The only reason password fields have a second “confirm” field is that password fields mask the input, so the user can’t see what they’re typing.

If I Leave the Tutorial, Can I Get Back In?

While reading c|Net’s preview of the upcoming Palm Prē, I came across: “When you fire up the smartphone for the first time, there’s a brief animated tutorial to familiarize you with the various gestures” the Prē uses. And having a first-time orientation is a pretty common UX decision, especially for products that are trying to introduce new features or concepts.

But what I’d really like is to try the thing out on my own for a while, and then read the instructions if I get into trouble. That impulse to explore is part of why I’m so good with technology in the first place; it’s a shame to have to put it aside when I try out a new device.

And really, the only reason to put it aside at all is because I worry that, when I break out of the first-time tutorial, I’ll have no way to get back into it if I want to later on.

Actually, ignoring the instructions is a fairly common male use-mode: lots of guys would rather have their shoulder dislocated than admit that they couldn’t magically, psychically divine the best way to work a mechanical or electronic device the first time they saw it. While I feel disinclined to cater to that particular aspect of machismo, I think we could use a solution that would allow people with a drive to explore (like me) to indulge that drive. It would also have the happy side-effect of assisting the Tim Taylors of the world, if they decide to avail themselves of it.

But the problem isn’t one of letting the user bail out of the first-time tutorial; it’s one of assuring the user that they’ll be able to get back in if they decide they want to later. So a simple button saying “Exit Tutorial” is not enough.

Messaging saying “Exit Tutorial (you will be able to come back later, if you wish)” isn’t much better. For one, it’s as clunky as a Mack truck wearing snowshoes inside the house. (Or as a bizarre mixed metaphor.) For two, in a situation like the Palm Prē, where screen real estate is at a premium, you may not be able to fit that many words into the UI at all.

Really, it’s a special case of the general problem: How do you assure the user that a given action will be reversible? That’s a feature that’s becoming more crucial all the time, and yet it’s something that our current UI metaphors don’t really have any vocabulary for.

Eyeball-Deep in Legalese

I used to not have a problem when I wanted to release software. I’d just release it under the GPL (what we’d now call the GPLv2), and be pretty happy with that decision.

Now there’s GPLv3, and I’m really uncertain whether I like it at all. I understand that Tivoization is a serious problem, but I don’t quite understand the special non-consumer exemption for the anti-Tivoization clause. There are some other new and weird clauses the FSF has added, dealing with patents, and the WIPO Copyright treaty of 1996, and so on.

The GPL used to be pretty simple and elegant. Now? I recognize that the FSF is trying to make the best of a pretty bad situation. But their license has become something bizarre and awkward.

Theoretically, I could still use the old version. But that feels kind of odd, too, now that version 3 is out.

So now I have to look at things like the CPL, the Apache License, and so on. I’m already fairly sure I don’t want to use the MIT or modified BSD licenses; one of the things I liked about the GPL is that it keeps other people from dragging my open-source work into a proprietary package. I’m releasing it as open source for a reason, after all.

All of this is merely by of saying: I’m getting ready to release another software package. I’m not so sure the Creative Commons license I used on Hummingbird is quite as appropriate for this package, so I’m having to do some annoying research.

Announcing Hummingbird

If you read Coyote Tracks*, you’ve probably noticed that I recently set up a thing over there in the right-hand side that says “My Latest Tweets”. At first, that was just a little PHP widget that I’d hacked together myself. But then I realized it could actually be useful to other people, because it does a bunch of things that many of the other “latest tweets” widgets in existence don’t do.

So I decided to get it cleaned up and make a real, distributable software package out of it. That took a few days, especially when I started banging on it, and trying to ensure that it had a prayer of working on anyone else’s server. Plus there was the time involved for writing the docs.

But now that all of that stuff is done, I am pleased to announce: Hummingbird. A lightweight, pretty, and compact gizmo for displaying your latest tweets on a blog or other PHP-powered web page.

* And if you don’t read Coyote Tracks… what the heck is wrong with you? *g*