President Barack Obama, and two other presidents, have retaken their oaths of office, because of some mistake with their inauguration. That means a little over one in fifteen presidential oaths were botched. If that sounds high, it is. But only because people make mistakes.
That’s why, we must make our software so that people can recover after making a mistake.
In 1987, Alan kay said,
By the way, Sketchpad was the first system where it was discovered that the light pen was a very bad input device. The blood runs out of your hand in about 20 seconds, and leaves it numb. And in spite of that it’s been re-invented at least 90 times in the last 25 years.
Almost 50 years after Sketchpad, you can find a light pen at any computer store today. Today, these light pens are used to supplement more circulation-friendly input devices. Maybe that’s enough to solve the problems Sketchpad had.
Personally, I think the metaphor of a the pen is too blindingly strong. People love their pens, because they grew up with them. I don’t accept that they are the pinnacle of input. We can do better then copying a pointy stick filled with dye.
But I have my own biases and unique experiences. I am dysgraphic — I have trouble writing legibly by hand, and spelling. To me a pen is not something that feels good or puts me in the zone. It’s something that gets in the way of expressing my ideas. But fundamentally, isn’t every input device a barrier between your mind and the medium?
I highly recommend Bruce Schneier’s blog. Security involves thinking about what how things can go wrong, and that’s an excellent skill for any designer to have. Psychologically people are biased to remember catastrophically bad experiences, and can develop an adversarial relationship to something from just one bad experience, if it’s unpleasant enough. Minimizing unpleasantness can be more important then optimizing goodness, when trying to cultivate a good relationship with users.
Alan Kay talking about GRaIL, Graphical Input Language, a system implemented in the late ’60s that was so far ahead of it’s time, it’s still pretty impressive today.
“I felt like I was sticking my hands right through the display and actually touching the information structures directly.”
I had no idea this sort of interface was done so early.
(Sheedy, Hayes, & Engle) found that reading with difficult environmental conditions such as upward gaze, glare, flickering light, or small text caused the participants to report symptoms of burning, irritation, and dryness.
While reading with internal problems like having to turn your eyes inward, astigmatism, and stress on the focusing lens caused the participants to report ache, strain, and headache.
Sheedy, J.E., Hayes, J., & Engle, J. (2003). Is all Asthenopia the Same? Optometry and Vision Science, 80 (11), 732-739.
Via fontblog.
If you are ambidextrous, feel smug and ignore this.
This is a bit counterintuitive. I used to keep them in my strong-side pocket for years. It’s natural to use your strong hand to unlock a door or buy a sandwich. But it causes problems when you need to open a door while carrying something awkward/heavy (say groceries, a cat, etc).
You should be carrying awkward things with your strong hand. It’s safer and easier. But when your strong-hand is full, it’s hard to get keys from your strong-side pocket. Meanwhile, keys in your weak-side pocket are still easy to employ.
I’m not especially dexterous, but in my experience, using my weak hand to unlock something hasn’t been a problem. I expected it to be harder, but honestly it hasn’t been perceptibly more difficult. Keeping keys in my weak-side pocket has been nothing but good.
But, anything you need to use while your strong hand is full should still live on your weak side with your keys. Phones make handy flashlights, for example.
I’ve been trying to train myself to do this for years, and I haven’t been able to.
The theory is that your weak hand is plenty up to the task of bringing a glass to your mouth (if it isn’t, you shouldn’t be drinking!), and it’s useful to have your strong hand free. Plus holding a cold drink makes your hand cold and wet, which surprisingly isn’t cool when you need to shake with that hand. So holding drinks in your left hand = a better first impression.
Here’s a lightly-edited transcription of Alan Kay, explaining why computer-aided instruction so often fails (from “Doing with Images makes Symbols”, 1987),
After the experience I’ve had with working with both children and adults with computers (and at least dabbling in the areas of learning and education), I think that one of the best ways of thinking of a computer is very similar to thinking of what a piano means when teaching music.
The piano can amplify musical impulse. We can only sing with one voice. If we want to play a four-part fugue, we have to use something mechanical, like a piano to do it. And it can be done very beautifully.
But for most people the piano has been the biggest thing that turns millions of people away from music for the rest of their lives. And I think the best way to sum it up is just to say that all musicians know that the music is not inside the piano…
So, in any situation where education and learning is involved, you first have to develop a curriculum based on ideas, not on media. Media can be an amplifier of those ideas, but you have to have the ideas first.
And I think the reason computers have failed is that almost everybody, no matter which way they have tried to use computers, have wanted the computer to to be some sort of magic ointment over the suppurating wound of bad concepts. … But first you have to have the ideas.
This was exactly my experience as a student. I am dysgraphic — I have trouble writing legibly by hand, and spelling. So I took a laptop to all my classes, from 8th grade (1997) through college. The laptop solved a particular problem for me. But outside of that, it did not enhance my education; in some cases it got in the way. (One professor found students using laptops the most during class did 11% worse on tests compared to the rest of the class). If I wasn’t dysgraphic, I would have been better-off with a Moleskine.
Never use NSASCIIStringEncoding
“Foreign” characters, like the ï in “naïve”, will break your code, if you use NSASCIIStringEncoding. Such characters are more common then you might expect, even if you do not have an internationalized application. “Smart quotes”, and most well-rendered punctuation marks, are not 7-bit ASCII. For example, that last sentence can’t be encoded into ASCII, because my blog uses smart-quotes. (Seriously, [thatSentence cStringUsingEncoding:NSASCIIStringEncoding] will return nil!)
Here are some simple alternatives:
C-String Paths
Use - (const char *)fileSystemRepresentation; to get a C-string that you can pass to POSIX functions. The C-string will be freed when the NSString it came from is freed.
An Alternate Encoding
NSUTF8StringEncoding is the closest safe alternative to NSASCIIStringEncoding. ASCII characters have the same representation in UTF-8 as in ASCII. UTF-8 strings will printf correctly, but will look wrong (‘fancy’ characters will be garbage) if you use NSLog(%s).
Native Foundation (NSLog) Encoding
Generally, Foundation uses UTF-16. It is my understanding that this is what NSStrings are by default under the hood. UTF-16 strings will look right if you print them with NSLog(%s), but will not print correctly using printf. In my experience printf truncates UTF-16 strings in an unpredictable way. Do not mix UTF-16 and printf.
Convenience C-Ctrings
[someNSString UTF8String] will give you a const char * to a NULL-terminated UTF8-string. ASCII characters have the same representation in UTF-8 as in ASCII.
Take a minute to search all your projects for NSASCIIStringEncoding, and replace it with a more robust option.
It never hurts to brush up on unicode.
With every programming language/development environment I know of, you have to do extra work to make a string localizable. For example,
errorMessage = NSLocalizedString(@"This is hard!",@"");
not simply,
errorMessage = @"This is hard!";
And it’s not just extra work, it’s a ridiculous amount of work. E.g. to create an Objective-C string, you just put an @ in front of a standard C string. But to create a localized string, you have to surround your string in ()‘s, and prefix it with a seventeen character mixed-case function-name, and finally add an empty “note” for the translator. (Rarely, you may want to add a note for the translator, and it’s good that you can, but you should not be forced to write something when it is not necessary.)
There isn’t really an excuse for this; it’s just how languages have lazily evolved.
Non-localizable (“hardcoded”) strings are a huge issue, even though they are trivially simple for programmers to fix. The problem is that translators do not work with source code, they work with resource files. So when they find a “hardwired” string that must be changed in code, they tell a programmer to fix it. And that communication is slow and costly. Especially when you consider that good localizers are probably native to the place they are localizing for — meaning that having a real-time conversation involves at least one party staying up past 3AM.
I dream of a day where "this would be localized by default"; "and"("syntactic sugar for adding optional translator notes would be there too"); and creating C"literal C-strings" would be easy.
“Unicode support libraries” are doomed to institutionalized-failure, because they will never make it easier to do the right thing. It must be so easy to create a localizable program that you wouldn’t dream of doing anything else.
Powered by WordPress