Vincent Gable’s Blog

January 30, 2009

Color is Cultural

Filed under: Design,Usability | ,
― Vincent Gable on January 30, 2009

An Asian student in my laboratory was working on an application to visualize changes in computer software. She chose to represent deleted entities with the color green and new entities with red. I suggested to her that red is normally used for a warning, while green symbolizes renewal, so perhaps the reverse coding would be more appropriate. She protested, explaining that green symbolizes death in China, while red symbolizes luck and good fortune. The use of color codes to indicate meaning is highly culture-specific.

Information Visualization, Second Edition: Perception for Design, page 16 (via Keith Lang)

I hypothesize that color-codings derived from nature and physics (for example more and less mapping to hotter and colder colors) would work across cultural divides. But maybe that’s just the science-worshiping American in me talking.

UPDATED 2009-02-02: There’s some very good commentary on this post. My hypothesis was wrong, or at very least missed the real difficulty of color coding. Also, it now appears the anecdote was not real culture shock, but a smart student defending their design with the first thing they could think of when it was suddenly challenged.

January 29, 2009

Social Epidemics Take Time

Filed under: Quotes | , , ,
― Vincent Gable on January 29, 2009

The best viral content on the internet won’t reach its audience in a single week. It might sit on YouTube for weeks or even months before it gets noticed and distributed. There’s just so much content out there to compete with. My guess is, viral marketing is pretty hit and miss, but if you’re going to try to do it, give it time to happen. If you’d like to promote an event next year, start writing about it on your blog or MySpace page now.

Jobe Roberts

This reminds me of one of Steve Yegge’s anecdotes,

… long before we had company internal blogs (at Amazon.com), Jacob Gabrielson wrote and circulated a brilliant essay called Zero Config. At least that’s what people call it nowadays. The actual title is longer, but famous essays tend to get shortened, like the way Dick Gabriel’s The Rise of “Worse is Better” became widely known as the “Worse is Better” essay.

Jacob’s essay clearly articulated an acute pain we’d all been feeling, but which nobody had elevated to the status of First-Class Pain. That is, configuration was a huge problem, but it hadn’t made it onto anyone’s radar as an official problem to which we should dedicate company resources.

Sure, everyone had been bitching and whining about it, but we bitch and whine about everything around here, so it wasn’t a problem that was readily discernable in all the noise.

Jacob’s paper was brilliant on several levels. He was able to distinguish configuration as a first-class problem, worthy of a paper — and this was back when there was almost no precedent for writing and circulating papers within Amazon. He made his point in an amusing and memorable way, writing with considerable style and intellectual force. And he articulated a long-term vision for fixing the problem. His goal wasn’t to solve it, but simply to increase general awareness of the problem. It was a little masterpiece.

And nobody read it.

I read it, although not immediately; as I recall, it may have been a few days before I got around to it. But it was relatively soon after he’d circulated it. When I finally did read it, I was very excited, and thought everyone ought to read it immediately. I started asking around, and found that only a few of the people on the circulation list had read it. I felt rather deflated: the company was missing out on an important insight, one that could help steer us in the direction of faster development, more stability, and less pain. I’m sure Jacob felt pretty bummed about having wasted all that time on the essay.

I didn’t give Jacob’s essay much thought after that, although I’d of course internalized his core ideas, which helped me steer my own teams’ work occasionally. About eight months went by, and then the most remarkable thing happened: suddenly all the VPs were talking about the “config problem”. They were citing Jacob’s paper, and from the way they were talking about it, it was obviously considered a well-known and long-standing problem: in other words, in 8 months it had gone from a relatively unknown issue to one that had permeated our corporate consciousness.

It didn’t happen overnight, either. I started hearing references to the paper in meetings about 4 months after he published it, and the frequency gradually went up, until the config problem finally emerged on various strategic planning agendas almost a year after Jacob had written about it.

I was surprised at the time that it took so long, but now it makes sense. People will only read something as meaty as an essay when the time is right. The right time isn’t going to coincide for everyone.

Like anything else, word of mouth drives adoption for essays. Only a few people will read it at first: friends, and a few people who just stumble across it and think it looks potentially interesting. If the essay isn’t relevant enough, then people will just forget about it and move on. No big deal.

But if your essay strikes the right chord with enough people, it will eventually reach critical mass, and you’ll have effected change in the organization. It may not be a huge change, but think about it: getting an idea through to a thousand people, in such a way that they all remember it and more or less agree with you — this is no easy feat. You can’t do it with a single email, unless it’s a really controversial one, and then you’ll just be infamous. You can’t do it with a single public speech: only the folks in the room are likely to remember it. Trying to do it with hallway conversations doesn’t scale.

Jacob’s Zero Config article demonstrated that essays are the best way to change minds on a large scale, maybe the only way, and even then, it often takes months for the message to sink in via mass osmosis.

For Jeff Atwood, of Coding Horror fame, popularity took years

I started this blog in 2004, and it took a solid three years of writing 3 to 5 times per week before it achieved anything resembling popularity within the software development community.

Flash Hate

Filed under: Quotes | , , , ,
― Vincent Gable on January 29, 2009

I don’t like Flash because it is responsible for the overwhelming majority of my browser crashes. I don’t like it because it consumes memory and (especially) CPU resources on my computer for almost the sole purpose of showing me advertisements, which also translates directly to reduced battery life on my laptop.

But it’s interesting to note that it’s quite a technical and ethical challenge to run a browser without Flash.

Steven Frank

I’ve written before about how important it is to optimize CPU usage of your website for the mobile world. And this is yet another reason for anyone who is add-supported. People will tolerate advertisements that are just there. But when they kill their work time, or are otherwise malignant, then they will take active steps to stop them. And that means no more advertising revenue.

January 26, 2009

Adobe UI Gripes

Filed under: Design | , , ,
― Vincent Gable on January 26, 2009

Adobe UI Gripes is a blog with screenshots of Adobe’s weird, non-standard interfaces. (Too much of) Adobe’s current Mac software is like Microsoft’s during the Word 6 period.

(Via Michael Tsai, Jonathan Rentzsch.)

If Adobe didn’t make, you know Photoshop etc. al., I would cut them more slack when it comes to their software’s face. It’s like a dermatologist with terrible acne. Graphic designers seem like exactly the types who would be bothered the most by a tool’s interface not being pixel perfect.

But I am impressed by what I’ve seen of Adobe Lightroom. They deserve UI props for that.

Compressibility of English Text

Filed under: Research | , , ,
― Vincent Gable on January 26, 2009

Theory:

Some early experiments by Shannon67 and Cover and King68 attempted to find a lower bound for the compressibility of English text by having human subjects make the predictions for a compression system. These authors concluded that English has an inherent entropy of around 1 bit per character, and that we are unlikely ever to be able to compress it at a better rate than this.

67 C. E. Shannon, “Prediction and entropy of printed English”, Bell Systems Technical J. 30 (1951) 55. (Here’s a bad PDF scan)

68 T.M. Cover and R. C. King, “A convergent gambling estimate of the entropy of English”, IEEE Trans. on Information Theory IT-24 (1978) 413-421

Signal Compression: Coding of Speech, Audio, Text, Image and Video
By N. Jayant

Shannon says 0.6-1.3 bits per character of English — 0.6 bits is the lowest value I have seen anyone claim.

Practice:

Just as a datapoint I tried gzip --best on plain-text file of The Adventures of Sherlock Holmes, weighing in at 105471 words, and using 578798 bytes. The compressed file was 220417 bytes.

If we assume the uncompressed version used one byte (8 bits) per character, then gzip --best used about 3 bits per character.

Best so Far

The state-of-the-art in the Hutter Prize, a challenge to compress 150 MB of Wikipedia content, is 1.319 bits per character. But that’s with a program tuned just for that data set, and it took 9 hours to run.

January 24, 2009

Schneier on Security for Designers

Filed under: Accessibility,Announcement,Design,Security | , ,
― Vincent Gable on January 24, 2009

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.

January 23, 2009

Never Submit

Filed under: Bug Bite,Design,Programming,Usability | , ,
― Vincent Gable on January 23, 2009

Submit is always the wrong title for a button. Yet it’s still commonly used, even by people who should know better. I had “Submit Comment” buttons on my blog when I first published this.

Buttons should say what happens when they are pushed, in the vocabulary of the person pressing them. Technically a button might submit a form to a server, but what matters is the consequence of submitting the form.

For example,

Picture 27.png

this button should be called “Search” or “Find” or “See Matches” — something that describes what happens when it is pressed, or what the operator will see after pressing it.

That’s a Bad Word

“Submit” has negative connotations, and should be avoided. The first three example usages (in Mac OS X’s Dictionary.app) are all negative,

submit

verb
1 [ intrans. ] accept or yield to a superior force or to the authority or will of another person : the original settlers were forced to submit to Bulgarian rule.

• ( submit oneself) consent to undergo a certain treatment : he submitted himself to a body search.

• [ trans. ] subject to a particular process, treatment, or condition : samples submitted to low pressure.

Say an apartment takes applications on their website. It would be pedantically correct to say “Submit Application”. But it is more respectful to say “Send Application”, or “Apply”. Pressing a “Submit” button implicitly says “I submit”. And that’s the wrong relationship for a user to have to an interface.

Blame The Programmers (Not Really)

One reason so many buttons are labeled “Submit” is that the HTML code for making a button has the word “submit” in it. The code for is <input type="submit" value="This Button">.

If the keyword send was used to build buttons, I would argue that the web would be a slightly less intimidating place today. A button that demands you “send” something is better then a button that forces you to “submit”.

Choose Your Words Carefully…

So perhaps, when choosing programming terms, we should pick the ones with the fewest negative connotations, since inevitably some of those words will bleed over into user-land. Even if programmer words stay in programmer-land, word-choice influences the way we think about things. Best not to encourage berating your users and customers.

Of course, you shouldn’t go overboard avoiding “ungood” words! There is no question that the most clear term should be used (even if it’s offensive). A better programming-vocabulary means better, less buggy, programs. And that’s better for users (no matter what they are called behind their back). But if possible, avoid disparaging words.

And never submit to the temptation of calling a button “Submit”. There’s always a more accurate, respectful name.

New Police Computer System Impeding Arrests

Filed under: Security,Usability | , ,
― Vincent Gable on January 23, 2009

In Queensland, Australia, policemen are arresting fewer people because their new data-entry system is too annoying:

He said police were growing reluctant to make arrests following the latest phased roll-out of QPRIME, or Queensland Police Records Information Management Exchange.
“They are reluctant to make arrests and they’re showing a lot more discretion in the arrests they make because QPRIME is so convoluted to navigate,” Mr Leavers said. He said minor street offences, some traffic offences and minor property matters were going unchallenged, but not serious offences.

However, Mr Leavers said there had been occasions where offenders were released rather than kept in custody because of the length of time it now took to prepare court summaries.

“There was an occasion where two people were arrested on multiple charges. It took six detectives more than six hours to enter the details into QPRIME,” he said. “It would have taken even longer to do the summary to go to court the next morning, so basically the suspects were released on bail, rather than kept in custody.”

He said jobs could now take up to seven hours to process because of the amount of data entry involved.

(Via Schneier on Security.)

January 20, 2009

Control Screen Saver Security With Automator

Filed under: Announcement,Security | , , ,
― Vincent Gable on January 20, 2009

Set Screen Saver Security sets the time until the screen saver activates, and whether a password is required to unlock the screen saver.

Preview.png

Every company I’ve worked for that had an office also had a rule that any computer in the office had to be password-protected with a screensaver that kicked in pretty quickly. But at home it’s annoying to have to unlock your own laptop when you get up to make a sandwich.

If you use the same computer at home and in the office, IMLocation can use this action to lock down your computer at work, but leave it easy-to-use at home.

I recommend trying IMLocation (which includes the Set Screen Saver Security action) for best results.

January 19, 2009

Setting iChat Status With Automator

Filed under: Announcement,MacOSX | , ,
― Vincent Gable on January 19, 2009

Set iChat Status is an Automator action that sets your status message, and availability in iChat. Amazingly, this action did not ship with Mac OS X.

Preview.png

I wrote it, because I wanted a user-friendly way for people to control iChat in IMLocation workflows.

I Need Your Help, Tiger

This action should run on Mac OS X 10.4. But since I don’t have a second computer running Tiger, I’m not sure. If someone would let me know if this works on Tiger I would really appreciate it! It should work just fine, but you know what they say about “should”…

Download.

Older Posts »

Powered by WordPress