We made a world populated with objects that reacted to what humans did, but they didn’t interact very strongly. Whereas that isn’t enough, pure discovery learning took us 100,000 years to get to science. So you actually need learning that’s facilitated. And if you can’t make 1,000 good teachers in a year to save yourself, you have to have a user interface that can do that.
—Alan Kay, answering questions on the OLPC project, November 5, 2008
Obstacles to getting real feedback are now mainly cultural, not technological; any business that isn’t learning from their users doesn’t want to learn from their users.
Being a Lisp Is a Handicap
There are a large number of people who find Lisp code hard to read. I’m one of them. I’m fully prepared to admit that this is a shortcoming in myself not Lisp, but I think the shortcoming is widely shared.
Perhaps if I’d learned Lisp before plunging into the procedural mainstream, I wouldn’t have this problem — but it’s not clear the results of MIT’s decades-long experiment in doing so would support that hypothesis.
I think it’s worse than that. In school, we all learn
3 + 4 = 7and then
sin(?/2) = 1
and then many of us speak languages with infix verbs. So Lisp is fighting uphill.It also may be the case that there’s something about some human minds that has trouble with thinking about data list-at-a-time rather than item-at-a-time …
…I think I really totally understand the value of being homoiconic, and the awesome power of macros, and the notion of the reader. I want to like Lisp; but I think readability is an insanely important characteristic in programming systems.
Practically speaking, this means that it’d be hard for me to go out there on Sun’s (or Oracle’s) behalf and tell them that the way to take the best advantage of modern many-core hardware is to start with S-Expressions before breakfast.
—Tim Bray (emphasis mine)
I’m afraid he’s on to something. We have an amazing ability to parse language. But people aren’t terribly good at building the kinds of stacks needed to parse LISP with their short term memory.
This is the cheese that the rat that the cat that the dog that the neighbor owned bothered chased ate.
Say what?!
(This is the cheese (that the rat (that the cat (that the dog (that the neighbor owned) bothered) chased) ate)).
See the LISP connection?
All functional languages are fighting an uphill battle to be understood. The world we evolved in is stateful (modal) and imperative. We navigate it in a me-at-a-time way. Unfortunately, LISP’s prefix syntax is another, unnecessary, barrier.
The bottom line is that every word of code spends more time being read than written — so writing in a syntax that most people have a hard time reading is one of the worst programming choices imaginable. I believe functional programming languages are well worth learning; but I don’t believe it’s worth suffering a poor syntax.
…Knuth has a terrible track record, bringing us TeX, which is a great typesetting language, but impossible to read, and a three-volume set of great algorithms written in some of the most impenetrable, quirky pseudocode you’re ever likely to see.
There, it’s been said. But let the posse note I wasn’t technically the one to do it!
Today’s Daringfireball article on the shortcomings of the Mac application-install procedure is worth a skim. Gruber’s suggestion that Mac OS X automatically move 3rd-party applications into the /Applications/ folder on first-run, (a la the dashboard widget install process) is a good one1. Since Mac OS X already prompts you on first run (“Are you sure you want to run a program Apple didn’t write?”) it’s hard to see any downsides to this idea.
But that’s not the behavior we have today1.
As it stands today, I don’t see a good reason to ship your apps as a .dmg. I’ve been suspicious of disk images for a few years now; and usability tests show that people get confused by them.
Distribute your application as a single .app in a .zip archive. What possible use are other files besides the application? If a “Readme” file should be read before using the application, then show it when the application is first launched.
Installers are opaque and un-Mac like. There’s always a risk that they’ll install something that breaks the computer. As a developer I am even more suspicious of installers on the Mac, because I know how broken Apple’s installer tools are.
Of course, as a developer, I know that applications do sometimes need to install components. And here the best solution is for the application to check it’s environment and ask to install missing components as needed (in essence be it’s own installer). It’s more robust, since it detects-and-corrects missing or damaged components. It always preserves the user-facing abstraction that the icon is the application.
Applications shouldn’t install hacks dangerous enough to require a bundled user-facing unisntaller. To make IMLocation work, I had to install a background process — but I made it intelligent enough that it would uninstall itself if the main application had been deleted. Yes, this is more work, but it’s worth it.
1Another idea is to make Safari and Firefox smart enough to download applications directly into the right /Applications/ folder, bypassing the usual downloads folder. This elegantly solves the instillation problem, although it creates some new problems.
2Although it would be a cool hack to write.
Idea: your iPhone knows your passwords, so when you make a small typo, it corrects it for you.
There are obviously major security concerns here. But I believe they can be acceptably mitigated by the phone itself. Someone would have to physically use the iPhone to get password correction, and correctly could only happen on the first or second password attempt. Also, correction could be limited to the kinds of typos a person would make.
Passwords are broken by machines, not people. I believe password correction can help people, without substantially helping machines, and compromising security.
It’s hard to type precisely on an iPhone’s virtual keyboard. That prevents people from using secure passwords, and that hurts security. Because password correction helps people actually use strong passwords, it should be to be a net security benefit.
I had some time to kill today, waiting for a catalytic converter replacement, and the book Design Your Life: The Pleasures and Perils of Everyday Things
Visually it’s is appealing (but of course it has to be!), and accessibly written.
But what really impressed me the most, is that it gives you a critical eye and a reason to ask ‘why?’. And I think that’s the most important thing you can get out of a book on UX/design/accessibility.
The authors also have have a website which looks to be every bit as good as the book.
1You’re probably wondering why I didn’t buy the book if I like it enough to recommend it. Well, I had my iPhone with me in the store, and I looked up the price on amazon. It was half what the brick-and-mortar store was asking. So I didn’t buy it. Speaking of which, if you order the book through any of the links on this page, I get a small commission from Amazon. So please do doubt my recommendation — that’s what critical thinking is all about!
…control interfaces must not be intelligent. Briefly, intelligent user interfaces should be limited to applications in which the user does not expect to control the behavior of the product. If the product is used as a tool, its interface should be as unintelligent as possible. Stupid is predictable; predictable is learnable; learnable is usable.
Jeff Raskin calls this principle it monotony, and explains it comprehensively in The Humane Interface.
I’ve always felt a little uneasy about the idea. Computers are supposed to free us from tedium and repetition, by doing things for us. A fluid interface is unnatural yes, but the goal of computing should be to exceed what’s possible in the corporal word, not to copy it imperfectly.
But fundamentally, I think Raskin and Molbug are more right than wrong. Paradoxically, dumb interfaces beat smart interfaces most of the time.
/* If you are uncertain of the correct encoding, you should use UTF-8, */ /* which is the encoding designated by RFC 2396 as the correct encoding */ /* for use in URLs.… */
— CFURL.h
This echos my experience, when in doubt, choose UTF8 for the web. UTF8 is backwards compatible with 7-bit ASCII (eg. ‘A’ is 0x41 in ASCII and UTF8).
But know that UTF8 is a variable-length encoding: non-ASCII characters maybe represented by > 1 byte. As a general rule with Unicode, I do not expect a char or wchar_t to always map to a character in a string. Encoding details can be messy, e.g. “É” might be represented as one character, or two composed characters “´E”. It never hurts to brush up on Unicode.
When it comes to building the physical world, we kind of understand our limitations. We build steps. … We understand our limitations. And we build around it. But for some reason when it comes to the mental world, when we design things like healthcare and retirement and stockmarkets, we somehow forget the idea that we are limited. I think that if we understood our cognitive limitations in the same way that we understand our physical limitations, even though they don’t stare us in the face in the same way, we could design a better world. And that, I think, is the hope of this thing.
—Dan Ariely, concluding a very entertaining TED talk. The transcript is up, but I liked his delivery so much I watched the video.
Stairs and ladders aren’t an implication that you’re too weak to pull yourself out of a pool. Yet amazingly people sometimes get insulted by simplified interfaces, as if it somehow implies they are so stupid they can’t handle complexity.
I was fortunate enough to hear Jonathan Ive talk about launching the iMac. As he was leaving a store on launch-day, a furious technology reported accosted him in the parking lot, shouting What have you done? He was incensed that the iMac was so cute, approachable, and untechnical — everything that he thought a computer shouldn’t be.
Some of this behavior is explained by simple elitism. If computers are hard to use, than it keeps the idiots out, and proves what a macho man you are if you can use them.
But I suspect refusal to accept our cognitive limitations is also related to our cultural refusal to accept mental illness. Quoting Mark C. Chu-Carroll’s experience with depression,
How many people have heard about my stomach problems? A lot of people. I need to take the drugs three times a day, so people see me popping pills. … Out of the dozens of people who’ve heard about my stomach problem, and know about the drugs I take for it, how many have lectured me about how I shouldn’t take those nasty drugs? Zero. No one has ever even made a comment about how I shouldn’t be taking medications for something that’s just uncomfortable. Even knowing that some of the stuff I take for it is addictive, no one, not one single person has ever told me that I didn’t need my medication. No one would even consider it.
But depression? It’s a very different story.…
Somewhat over 1/2 of the people who hear that I take an antidepressant express disapproval in some way. Around 1/3 make snide comments about “happy pills” and lecture me about how only weak-willed nebbishes who can’t deal with reality need psychiatric medication.
I confess to being thoroughly mystified by this. Why is it OK for my stomach, or my heart, or my pancreas to be ill in a way that needs to be treated with medication, but it’s not OK for my brain? Why are illnesses that originate in this one organ so different from all others, so that so many people believe that nothing can possibly go wrong with it? That there are absolutely no problems with the brain that can possibly be treated by medication?
Why is it OK for me to take expensive, addictive drugs for a painful but non-life-threatening problem with my stomach; but totally unacceptable for me to take cheap harmless drugs for a painful but non-threatening problem with my brain?
If we can accept that our brains are fallible, like everything else, and that this isn’t somehow immoral, we can build a better world.
Powered by WordPress