Vincent Gable’s Blog

June 22, 2009

(Hyper)Text is King of Substance

Filed under: Accessibility,Design,Quotes,Usability | , , , , ,
― Vincent Gable on June 22, 2009

…I’d rather have the text of Clay’s speech than the video. For things that matter, written words are unambiguously better than speech. To start with, anything that matters isn’t just written, it’s usually rewritten repeatedly (and more important, condensed). Plus, it has hyperlinks. Plus, it’s smaller and cheaper to ship around. Plus, it’s searchable. Plus, it works on more devices. (I acknowledge that only the first of these is fundamental; but that alone would be enough).

Tim Bray

Videos, speech, etc. will always carry more emotional content. But for consuming ideas, text offers the highest bandwidth and most precision. Unfortunately, writing well takes time, and can hinder conversation.

Conceptually, I believe illustrative pictures and infographics are valid elements of modern text, like links, or typography.

June 19, 2009

All’s Well That Ends Well

Filed under: Design,Quotes,Usability | , , , ,
― Vincent Gable on June 19, 2009

the peak end rule. When thinking about a total experience, people tend to place too much weight on the last part of the experience. In one experiment, people had to hold their hands under cold water for one minute. Then, they had to hold their hands under cold water for one minute again, then keep their hands in the water for an additional 30 seconds while the temperature was gradually raised. When asked about it afterwards, most people preferred the second option to the first, even though the second had more total discomfort. (An intrusive medical device was redesigned along these lines, resulting in a longer period of discomfort but a relatively comfortable final few seconds. People liked it a lot better.)

Bruce Schneier

June 17, 2009

We Feel Faster Than We Think

Filed under: Quotes | , , , , ,
― Vincent Gable on June 17, 2009

I’ve been saying this for a while — as a medium gets faster, it gets more emotional. We feel faster than we think.

Clay Shirky

June 15, 2009

Ignoring Just One Deprecated Warning

Switching projects over to iPhone OS 3.0 means discovering that functions I’m using are deprecated. Occasionally there isn’t a totally straightforward replacement, and the best thing to do is to file a bug/TODO/note for myself, and ignore the warning until a later version, when major refactoring will be possible. But bitter experience has taught me to have Xcode treat warnings as errors1, so it’s necessary to trick the compiler into ignoring the warning for things to build.

-Wno-deprecated

The -Wno-deprecated flag tells GCC to suppress warnings about deprecated code. But adding it to an Xcode project means you won’t get useful warnings about other depreciated code.

You could file a bug telling yourself to turn that warning back on after the deprecated functionality has been updated. That should work just fine. But it feels like bad project hygiene to me.

Casting and Protocols

Type casting is a dangerous old-C technique that’s earned its infamy. But it’s undeniably fitting to use a deprecated language feature to get deprecated code to build. The basic idea is to declare a protocol that includes the method you want to suppress warnings for,

@protocol DeprecatedHack
- (void) myDeprecatedMethod;
@end

then just cast your objects so the compiler thinks they implement the protocol,

[foo myDeprecatedMethod]; //warnings
[(id<DeprecatedHack>>)foo myDeprecatedMethod]; //no warnings

Although having to declare a protocol is somewhat heavyweight, it leaves a nice artifact in the code reminding you to replace deprecated functionality.

Protocols Not Required

Sometimes just casting to id is enough. This happens if another object has a non-deprecated method with the same name.

1For experimental or prototyping projects I let warnings slide. But in the main project I always treat warnings as errors. Ignoring them in production code has never worked — warnings fester and grow on each other.

Because Objective-C is so dynamic, there are many errors that the compiler can warn you about, but can’t be totally sure are errors. For example, methods can be added to a class at runtime, so if you call -someMethodThatDoesNotExistAnywhere, the compiler will warn you that something is up, but won’t stop the build, because the necessary code could magically appear at runtime. Of course, 99% of the time, it’s me accidentally using count when I meant length, etc. What I’m really trying to say here is that treating warnings as errors is an even better idea in Objective-C.

June 11, 2009

Early Adopters Wanted!

Filed under: Announcement,iPhone | , , ,
― Vincent Gable on June 11, 2009

I am wrapping up work on Prometheus, an iPhone app that edits the Simple English Wikipedia.

Unfortunately, I am having trouble finding people to take the pre-release version for a spin, and tell me what they think. I want to be sure I’ve fixed any glaring issues before I push my work out to the App Store.

If you are interested in helping, please visit the Prometheus webpage.

Thank you!

June 4, 2009

links for 2009-06-04

Filed under: Announcement,iPhone,Programming,Quotes,Research,Usability
― Vincent Gable on June 4, 2009

This was an experiment, in doing more with my delicious bookmarks. I was hoping that I could get more feedback and discussion on things I found interesting enough to bookmark by automatically posting links to them here. Many sites that I enjoy reading do something similar. But it hasn’t felt like a good fit for me.

MicroISV

Filed under: Programming | , , , , , , ,
― Vincent Gable on June 4, 2009

The word microISV is all business, in all the wrong ways.

MicroISV stands for “Micro Independent Software Vendor”, which in plain english means a tiny software company, usually on the order of one or three people.

Probably the best reason to buy software from such a small shop is passion. People who build and sell their own software directly tend to care very deeply about it. Their program is their baby. Nobody in a microISV is just in it for the paycheck. No matter how cool a large corporation is, at the end of the day everyone has to compromise on their dream to work together on it. But a one man shop never has to compromise or design by committee.

“Micro Independent Software Vendor” doesn’t communicate this agile vision. It sounds like the same kind of turgid enterprise think that drove the world’s largest software company to rename Netbooks, “low-cost small notebook PCs”. (You just can’t make this stuff up!)

Three people are never going to out-Big-Business a Big Business. So it just doesn’t make sense to label what they do with a Big Business Word. (And by word, I mean several words, because that’s how Enterprise Speak works.)

The most popular synonym for microISV I see in the Mac software scene is indy developer. I think it’s a fine term — better than microISV by about a factor of IBM’s income. But there are many other excellent alternatives to “indie”, like boutique, nano, one-man, etc. The exact term isn’t important; and it need not be short. If someone wants to open their own “Hand Cyphered Soft-Wares Emporium“, then more power to them! What’s important is that their taxonomy reflect the culture of commitment that goes into their unique software.

EDITED TO ADD: Small Batch Business is another fantastic name.

June 1, 2009

Pass Phrases, Not Passwords

Filed under: Accessibility,Research,Security,Usability | , , , ,
― Vincent Gable on June 1, 2009

Thomas Baekdal makes a convincing argument for using pass-phrases not passwords (via). It’s excellent advice, and I know I’m not alone in having advocated it for years.

My keyboard has 26 letters, 10 numbers, and 12 symbol keys, like ~. All but spacebar make a different symbol when I hold down shift, giving me 93 characters to use in my passwords. But the number of words that can make-up a pass-phrase is easily in the 100,000s. Estimating exactly how big is a bit tricky, but I will stick with 250,000 here (I think it’s an undercount, more on this later).

We Know How To Talk

The human brain has an amazing aptitude for language. But “passwords” aren’t really words, so they don’t tap into this ability. In fact, we often use words to try and remember the nonsense-characters of a password.

Wouldn’t it make more sense to just use the words directly, if we can remember them more easily?

Hard For Computers, Not Hard For Us

People feel that if security system A is harder for them to use then system B, then A must be harder for an attacker to bypass. But the facts don’t always match this intuition.

What authentication code do you think is harder for a bad guy to hack, the 7 character strong password “1Ea.$]/”, or the mnemonic for the first 3 characters, “One Elvis Amazon”? Certainly “1Ea.$]/” is harder for a person to remember. It feels like it should be harder to break. But a computer, not a person, is going to be doing the guessing, and all it cares about is how big the search space is. There are 937 possible 7 character passwords. Let’s say there are 250,000 possible English words (more on that figure later). Then there are 250,0003 3 word combinations — meaning an attacker would have to do 260 times more work to guess “One Elvis Amazon” than to guess “1Ea.$]/”.

With pass phrases, easier for the good guys is also harder for the bad guys.

Exactly How Much Harder

The “250,000 word” figure is a bunch of hand-waiving, but I believe it’s an undercount. I picked it, because I wanted a round number to crunch; it’s what Thomas Baekdal picked; and it’s about the size of the Mac OS X words file,

$ wc -l /usr/share/dict/words 
  234936

But liberally descriptive linguists say that the 1,000,000th word will be added to the English Language on June 10th, 2009. The more conservative Webster’s Third New International Dictionary, Unabridged list 475,000 English words. Obviously neologisms, slang, and archaic terms are fine for pass phrases. People like discovering quirky words. I see far more more people embracing the login, “kilderkin of locats”, then rejecting it.

Different conjugations (can) count as different words in pass-phrases. There’s only one entry in a dictionary for swim, but swim, swimming, swam, etc. make for distinct pass-phrases (eg. “Elvis swims fast”, “Elvis swam fast”, etc. Both phrases don’t show up in a google search by the way.) So the real number of words should be a few fold larger than a dictionary indicates.

But not all words are equally likely to be chosen — just as some characters are more popular in passwords. My earlier figure of “2500003 3 word combinations” was based on the naive assumption that each of the 3 words is independent. But people do not pick things at random. And a phrase is by definition not completely random — it must have some structure. I’m unaware of research into exactly how predictable people are when making-up pass-phrases.

But given how terrible we are at picking good passwords, and how good we are at remembering non-nonsense-words, I am optimistic that we can remember pass-phrases that are orders of magnitude harder to guess than the “good” passwords we can’t remember today.

Fewer Ways To Fail

We’ve all locked ourselves out of an account because of typos or caps lock. But pass-phrases can be more forgiving.

Pass-phrases are caseinsensitive. There’s no need to lock someone out over “ELvis…”.

Common typos can be auto-corrected, much as google automatically suggests words. Consider the authentication attempt “Elvis Swimmms fast”. The system could recognize that “Swimms” isn’t a word, and try the most likely correction, “Elvis Swimms fast” — if it matches, then there’s no reason to ask the user if it’s what they really meant. (Note that only one pass-phrase is checked per login attempt.) I don’t have hard data here, but given how successful google is at interpreting typos, I’d expect such a system to work very well.

Pass-phrases might be more difficult on Phones, and similarly awkward to write with devices. Writing more letters means more work. Predictive text can only do so much. Repeatedly typing 3 letters and accepting a suggestion is clearly more work then just tapping out 6 characters. Additionally, there are security concerns with a predictive text system remembering your pass-phrase, or even a small part of it.

But for computers, pass phrases look like a clear usability win.

Easily Secure Conclusion

(In case you were wondering that was a unique phrase when I wrote this.) Using pass-phrases over passwords (which are really pass-strings-of-nonsense-sybols-that-nobody-can-remember) makes a system significantly harder to crack. Pass-phrases are easier for humans to remember, and a system that uses them can be very forgiving. But as always, the devil is in the details. It’s terrifying to be an early adopter of a new security practice, even if it seems sound.

Powered by WordPress