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.

UNIX is very well designed from the user perspective. It's not its fault that you are a moron who can't figure it out.

"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."

Your logic is flawed. Please read SICP and come back later.
Writing programs for people to read implies simple, concise code. Writing goey bloat implies the opposite. Who the fuck cares if it has a million pretty buttons? I want to goddamn script it.

Such is the life of a fartist.

>>3

Then don't write bloat. Write something that conveys the most important information well without wasting users' time. Both CLI and GUI are capable of delivering on this, and both are capable of supporting "goddamn scripting."

The "intuitively usable" bit is inferred from the linked article, not SICP. It's a corollary. Nobody cares what programming language fetish you've acted out to make your program, just so long as they can get what they need from it as effectively as possible, so they too can finish work, go home, and wank.

>>2
AssertionError

I study human-computer interaction and I can give objective and measurable reasons why one interface is better than another, within certain criteria and why certain interfaces feel bad or uncomfortable to use.

My understanding on this subject began with Jef Raskins enlightening book, The Humane Interface. These days, I agree strongly with Raskin's opinion that pretty much all general human computer interfaces are woefully designed with regard to human strengths and weaknesses.

>>1
assert currentReader.humanEmpathy not in ['sociopath', 'autist', '/b/tard', '*NIX programmer', ]
I think you've come to the wrong place, my friend.

>>6
All the three last things in the list belong in the first one.
Also why in the fuck shit is there a comma after the last element?

>>7
Another thing: Why didnt you homo just use lisp?

>>7
Python allows that.

>>7

It allows one to quickly add another element to the end when needed. Sometimes, in our haste to add another list item we forgot, we might also forget to add the leading comma, introducing a error. Of course, one could just as easily not forget to add the leading comma, so it's really a matter of style.

I've heard vi users suggest always taking the editor back out of insert mode when done with it for a while (referring to this as "parking [with the e-brake on]" or something similar). To each their own.

That SICP line is too often used out of context. It's an embarassment, really.

Windows' old disk defragmenting program.
This is the most retarded thing I've read in a while. Not only it does run automatically (and pauses on user action) since 5 years ago, I also fail to see what that has to do with usability. I'm no expert on this but I haven't heard a lot of people complaining about having to run the defragmenter, probably because you don't have to run the defragmenter.

What part of the word old is lost on you?

Let's try a retard-proof, time-tested example: rm -rf /

This world-destroyer typo (or simply malicious command) could be stopped by the shell, who refuses to call the program, or it could be stopped by the program having noticed it will fuck the system, or it could be stopped by the victim system itself.

Instead, all three happily comply and the system is fucked. At the very least, an "are you sure, dickhead?" prompt could appear. Or the system could instead prioritize self-preservation over whoever happened to get the root password (eg. attacker, idiot co-worker, drunken/typo-prone self).

There are a billion other examples of poor usability that focusing on one example is a waste of time. For this class of situation, how about a general: "don't let the user fuck up the system"? Forget the prompt "Are you sure you want to delete those system files?" and opt for "These files are needed by the system and cannot be deleted." Anticipating the whining of "power users", it could continue: "If you're so goddamn intent on messing with them, why don't you go play in this nice VM sandbox I just built for you with a copy of the current environment, faggot?"

>>13
It's impossible to defend against all shell one-liners (also cool example bro, modern distributions took your shitty idea and rm -rf / doesn't work anymore).

Machines are not intelligent, get over it.

don't let the user fuck up the system
It's MY system and I will do whatever I want with it.

Anyone who believes otherwise does not believe in freedom.

>>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?"

>>16
Humans don't even know what are they trying to do the majority of the time.

Oh, and "detecting malicious intent" is equivalent to solving the halting problem. Good luck with your heuristics, maybe they'll stop an attacker for five minutes.

>>16
User input is sacred. It really irks me off when a stupid machine second-guesses me. Hopefully imbeciles would learn not to type shit they don't understand on a terminal after the first time.

The only way to effectively defend against users is by limiting permissions, and that's what is done on all modern systems. You'd think people on a multi-user system wouldn't have the power to hose down the machine, and it's a reasonable assumption the admin isn't going to go and type sudo rm -rf /*

In any case, "defending against the power user" implies taking control away, and that's a terrible slippery slope you don't want to walk into. Just buy locked toys if that's what you want, there are many companies marketing those.

By the way, the usability problem here is that the user had to type some incomprehensible (to him) gibberish in a command prompt in the first place.

>>1
Just fucking defrag when you need to, bro.
It can be annoying to see sudden heavy disk usage when you leave the computer unattended. I prefer to manually defragment my disk. I also prefer to manually defragment individual files if there is a need to. If defragmentation isn't done atomically, you also risk losing data if your computer crashes while idle or if there's some hardware or power failure.

I also don't think your deduction is correct. Having a good UI is nice, but it's not what was implied by that sentence.

>>16
fuck off and die, proprietary scum

People still defrag?

>>1`
>2011
>using windows

Humans tolerate tools like typewriters and hammers and get frustrated by the computer because the computer bears the sin of stateful behavior.

>because the computer bears the sin of stateful behavior.

 because the computer is black box for most people, unlike a typewriter

>>24
Humans get frustrated by the computer because computer designers are not taught human psychology. There's no good reason in this day why computers shouldn't cater to human strengths and weaknesses rather than carry out traditional interface ideas.

>>26
human strengths
Hahaha. Good one.

because FrozenVoid is an autist

Computers should cater to autistic people.

╔═══════════ ೋღ☃ღೋ ═══════════╗
~ ~ ~~ ~ ~ ~ ~ ~ ~ Repost this if ~ ~ ~ ~ ~ ~ ~ ~
~ ~ ~~ ~ you are a beautiful strong black woman ~
~ ~ ~ ~ ~ ~ ~ ~ who don’t need no man ~ ~ ~ ~ ~
╚═══════════ ೋღ☃ღೋ ═══════════╝

╔═══════════ ೋღ☃ღೋ ═══════════╗
~ ~ ~~ ~ ~ ~ ~ ~ ~ Repost this if ~ ~ ~ ~ ~ ~ ~ ~
~ ~ ~~ ~ you are a beautiful strong black woman ~
~ ~ ~ ~ ~ ~ ~ ~ who don’t need no man ~ ~ ~ ~ ~
╚═══════════ ೋღ☃ღೋ ═══════════╝

What is a machine?

A miserable little pile of state!