Software Usability

assert currentReader.freeTime > timedelta(hours=1)
assert currentReader.humanEmpathy not in ['sociopath', 'autist', '/b/tard', '*NIX programmer', ]

Magic Ink
INFORMATION SOFTWARE AND THE GRAPHICAL INTERFACE
http://worrydream.com/#!/MagicInk

You can get a lot out of skimming this. There's a lot of good info here, and I'm still trying to digest it all, but my first reaction is "why didn't I read this sooner?" The whole treatise resonates with the line from SICP stating:
"Programs must be written for people to read, and only incidentally for machines to execute."

It follows from the reading, then: "These programs must be intuitively usable."

I imagine design doesn't get much discussion on /prog/ because anyone comfortable programming or using command-line programs doesn't think about it too much, because he's often doing it for himself - not other users.

Having just started a software company, it's something I'm working on more and more. Not how to best present graphical info necessarily, but just usability in general. Since I don't think /prog/ is game for a long discussion, I hope this thread can at least be used to point out the massive fails of usability - things that really piss you off about software.

The first non-CLI example that comes to mind is Windows' old disk defragmenting program. Why should I have to run it or even schedule it? Just fucking defrag when you need to, bro. You can tell when I'm not using the PC and it's safe to start, and if I come back while you're in the middle of it, just chill for a while. Goddamn.

I'll leave the low-hanging UNIX shite for others.

>>14

Sure - the common API that those shells/programs call can do a much better job defending.

As for (feigned) machine intelligence, the linked article and the disciplines of signal processing, AI, and statistics would disagree. It takes very little data to build context around a user's intent and actions.

Humans are not unpredictable, get over it.

>>15

rms, is that you? Even if so, you're not perfect. How about a system that's stable in the face of (inevitable) human error. No, the machine isn't perfect either, but it doesn't take much behavior pattern matching to tell. "Hmm, do I let the power user destroy the OS at 11AM while other users are running jobs on it? How about now that it's 9PM and he's booted into a single-user mode with a new distro CD?"