Apple Keynote:

“I put up this slide a little earlier this year. It represents what Apple is all about. We’re not just a tech company. Apple is more than that. It’s tech and humanity. It’s the hardware and the software working together. It’s not just a great new camera system, it’s the editing too, it’s not just a front-facing camera, it’s that plus 18 months of work on the software side. It’s the complete solution, so all of us don’t have to be system integrators.”

Microsoft Keynote:

“Tweet choir!”

Another example of the oral transformation of language by people who don’t read much. “For all intents and purposes” is an old cliché which won’t thrill anyone, but using the mistaken alternative is likely to elicit guffaws.

By people who don’t read much. Love it.

I’ve been working with the Trebuchet typeface heavily on a project for the last 3 weeks. I hate Trebuchet and don’t think I would use it if the decision to do so wasn’t made long before I entered the project. However, I have figured out how to work with it’s quirkiness, and I think these guidelines apply to similar faces.

• Give it space. Trebuchet is prickly and unpredictable, so give it nice wide lanes. Leading should be about 160-180% and go as wide as possible with your margins (sometimes it never feels right, but keep at it). Keep it light, too, as this will mask some of it’s quirks. (I don’t hate quirkiness, but it’s not a good effect in long paragraphs of text.
• Does not play nicely with others. And by “others” I’m referring to other “Web-safe” fonts. Rounded and condensed faces nearly worked out well for headlines and buttons (Segoe Condensed, Unit Rounded), but eventually I settled on Trebuchet everywhere and just introduced contrast through color and case.
• 14px or 15px is the ideal size for the web. I’m doing 14px with a 20px line-height, color #444444, and it reads pretty well. Don’t go much smaller, especially if your setting paragraphs of text.
• Looks good at a small size when set in uppercase and tracked loosely. With the all-caps, again you’re reducing the quirks and it almost feels like a different face. In fact, you’ll see a lot of small headings and labels around the web set like this because it is quite pretty.

Love this print ad from Verde. (Seen on defgrip.)

The first user interface gem I learned was “links go places, buttons do things.” It was the first time I remember understanding how all of the nuanced decisions I made about interface design weren’t just arbitrary.

I ran across a discussion recently about using select boxes versus using radio controls. A UX designer was arguing with one of the “engineers” (fancy thing to call a programmer) about whether or not a certain option should be represented by a dropdown or three radio buttons. They went so far as to run usability testing to find out the winner. Yes, they spent money on the engineer’s ego, but money spent usability testing is never too bad of a thing.

Here are some good rules to follow when faced with a similar problem:

Use a select box when…

• …space is limited. If you have 5 or more options and only so much space, a select box is going to be your only way out.
• …there is a good default option. The most efficient control is one a user doesn’t have to ever touch. Sure, you could have a radio button checked by default, but at the same time you are showing the user several other options that they don’t need to see. A defaulted select box looks like a pre-filled text box.
• …little or no comparison is required with regard to the user’s options. When a user makes a selection, the rest of the options will disappear. If the user wants to mull over the effects of their decision, requiring extra clicks won’t be very welcomed.

Use radio buttons when…

• …options require descriptive text. There’s just no way (no pretty way) a select box option can have supporting text. With radio buttons, it’s easier to juxtapose text and imagery to help the user.
• …comparison is welcomed or required with regard to the user’s options. For example, if a user is picking between a range of numbers (like prices), it’s helpful to present all their options at the fore so they can compare without needing the aide of their pointing device to reveal the other choices.
• …the act of making a decision leads to immediate interface changes. The key here is about reducing clicks and interface movement. With a select box, you have to invoke the display of all the options (click), possibly scroll to an option (more clicks), and finally make your selection with a (click). Plus, with radio buttons, you might be able to preview the result of the choice when the user merely hovers the radio button or label.
• …there aren’t too many options. There’s no hard number to go by so you’ll just need to know what feels right.

These are just general rules. Always consider the context of your decisions, and don’t be afraid to do a little usability testing if that’s what it takes to shut the “engineer” up.

Ran across an interesting blog meme whereby you show the results of typing each letter of the alphabet into your browser’s address bar and share the auto-complete results. Here are mine:

• Adobe.com
• Bankofamerica.com
• Cssbeauty.com
• Danpatrick.com
• Espn.com
• Facebook.com
• Gq.com
• Hexecontahedron (search)
• Itunes.com
• Judiciary.senate.gov
• Kentuckyderby.com
• Localhost
• Msnbc.com
• Netvibes.com
• Outlook 2007 (search)
• Pyrocms.com
• Quikorder.pizzahut.com
• Rhapsody.com
• Sxc.hu
• Twitter.com
• Underconsideration.com/brandnew
• Verizon.net
• Wc.tickspot.com
• Xbox.com
• Yfrog.com
• Zillow.com