Survey the software you use for yourself, both browser- and desktop-based. Think about which applications provide the most invisible, effortless interfaces. I doubt it will be the ones that hide commands in complex menus and dropdown systems.

For some negative examples, let's look at Firefox and its more social cousin, Flock. Each app offers an advanced bookmark management mechanism, but the usability of that mechanism suffers in each due to over-reliance on cryptic menus.

Here's Firefox:

Can you guess which bookmark management options are going to appear under each menu? Where, for example, would the command for adding a separator live? What about sorting your bookmarks? Can't figure it out? Welcome to the world of evil icons.

For comparison, here's Flock, the social browser derived from Firefox:

Clearly, Flock provides friendlier menus; at least they've got text labels. With enough trial-and-error training, you'll probably be able to teach yourself which command lives under which menu.

Here's another example, this time from the webapp world: Confluence, the popular enterprise wiki package. Older versions of Confluence offered the by-now-familiar star icon. Click it, and a page would be added to your favorites. More recent versions, however, hide the "add favorite" option in one of several dropdown menus. Can you guess which?

If you guessed the "Add" menu, for "add to favorites," you're wrong. It's under the "Tools" menu. Welcome to the world of evil menus.

So where does that leave us? Must every single command available in an interface exist as an always-visible text link within the browser viewport? Of course not. But there are some best practices in choosing how to build our menus:

• Icons are great, but they should either be universally recognizable (such as a star or trash can) or paired with a text label.
• Menu groupings should be intuitive. Use care in choosing the top-level labels and don't group disparate items under the same menu.
• For frequently accessed functionality, consider leaving it as a dedicated clickable item on the page. There's nothing wrong with a mixture of icons and menus, the former for the most popular features and the latter for everything else.

Lots of big-name, highly successful sites eventually reach a state of paralysis in which they're too scared of alienating their customers to examine their interaction design and information architecture from a fresh perspective.

The cautionary tale of Amazon.com

Look at Amazon: The online retailer adopted DHTML navigation just last year - at least 5 years after most other big sites - because its tab interface had grown so comically large. Nevertheless, huge chunks of the Amazon user experience are still massively broken:

• Once you've started down the checkout process, the site tries to keep you from getting back to your shopping cart to add or remove additional items. If you use your back button to do so, you've got to start the checkout process all over again.
• Wish lists offer perhaps the most confusing, error-prone user interface I've ever had the displeasure to experience.
• Link targets on a wide variety of UI controls are tiny and persnickety enough to elicit involuntary profanity.

Why does Amazon let its design blunders live on in perpetuity? It's simple: Redesigns confuse users, and confused users don't spend money. Your current customers have invested so much effort in learning to work around your site's shortcomings that a new interface stops them in their tracks. Even the most humane and usable UI refresh takes acclimation - and that may cost your site conversions and revenue in the meantime.

The agony and the ecstasy of the redesign

I learned this lesson the hard way during my days at Reflect.com and Orbitz, where A/B testing constantly shocked us by revealing that change, any change, causes key metrics to dip, at least temporarily. Redesign an unusable feature and test the old and new versions with your current customer base on the live site. Chances are, the old version will win in the short term. That's why it takes guts to even consider a top-to-tails redesign. If small changes can have a negative impact, big changes could be deadly.

To me, however, it seems as if the bigger danger lies in allowing your site's information architecture to become ossified. Eventually, new UI paradigms will offer your younger competitors an avenue for feature differentiation. I was at Orbitz when Kayak.com launched, and I was sick with envy that a site could push the user experience of online travel into such new and compelling directions. I knew a company as large as mine could never rock the boat by switching to such an off-the-wall UI.

Sure, budget aggregator Kayak wasn't a direct competitor to an online travel agent like Orbitz. But if somebody had launched a full-service OTA with an interface as fresh as Kayak's, then Expedia, Orbitz and Travelocity would have been forced to play catch-up. After all, it was UI differentiation that had originally allowed Orbitz to woo customers from other, more established competitors: Its matrix-based results pages provided a compelling new way to find cheap seats. Eventually, though, other sites copied that feature. Now, all the big OTAs match each other feature for feature.

Beta sites: Hope for the future

That's what's so impressive about today's crop of Web 2.0 upstarts. A young service such as FriendFeed can offer an entirely separate, opt-in beta site and tinker away at it without annoying current users. Then, once the geekier end of the user base has helped work out the kinks, the service can flip the switch and roll out its new features to everyone. That's exactly what Facebook did with its new interface, but at far greater risk than FriendFeed. Facebook may be obscenely overvalued, but it does function as a business. A redesign is far less scary for the relatively unmonetized FriendFeed.

Regardless of whether you're a social networking giant or a microblogging upstart, this kind of usability and design lab has become de rigueur. By acclimating your users to frequent change early on, you can help ensure that future refreshes don't send them packing. Amazon may be in a design coma, but your site shouldn't have to be. Have the courage to redesign early and often.

First up we have Flickr, whose homepage redesign emphasizes the social networking aspects of the service. A Recent Activity feed, modeled on Facebook's iconic News Feed, showcases favorites and comments from your contacts. The default view for each item displays its age. When the user hovers, though, the same real estate becomes home to two icons. One allows you to add your own comment; the other "mutes" activity related to that photo and removes it from your feed. Neither option is represented by an industry-standard icon, and no tooltip is provided. Even the status bar shows only an inscrutable URL: a hash sign.

Next up we have Twitter, whose new homepage provides a similar user experience to that of Flickr, with two important differences: Rather than re-use existing real estate for its clickable context commands, Twitter re-purposes existing whitespace. And instead of cute, mysterious pictograms, Twitter uses industry-standard icons: a trash can and a star. For users schooled in the conventions of Web 2.0, it's obvious that the two icons, when clicked, will either assign "favorite" status to the item or delete the item altogether. For users without such a background, however, there are still no tooltips.

Finally we have Facebook, whose own News Feed now offers mouseover context commands. Unlike Twitter and Flickr, however, the social networking giant rolls all context options up into a single Options menu which is represented by text AND an icon. Users who click on the word or image see links such as "More about Brian, "Less about Brian, "More Status Stories" or "Fewer Status Stories."

Based on all of these examples, I'd say only Twitter hits the Web 2.0 sweet spot where simple, clear icons communicate everything you need to know about a feature. Even then, it would be nice if tooltips provided even further context. Facebook's approach goes further than Twitter's in guaranteeing that users always know what's going to happen when they click. But it's too fussy. Hover to see that there's a menu, click on the menu header, then finally see the available commands and click on one of them. When there are many options, that makes sense. But when there are two (a paired set of more/less links) it seems like overkill.

Flickr provides the least usable variation on this design pattern. The absence of both recognizable icons and tooltips turns context commands into a guessing game.

In terms of usability, however, there's another design pattern that trumps all of these options for clarity and usability: FriendFeed, which takes a very different approach to context commands. Items in FriendFeed now offer a very Web 1.0 grocery list of actions, all spelled out plainly in text and all visible regardless of hover state. Newbies and experts alike have instant access to popular commands such as "Comment," "Like" and "Hide." There are no wordless icons and no hover states. The only menu option that involves hide/show is the "More" submenu at the end of the list of options. Here, a down-arrow clearly indicates that this is dropdown. As expected, it contains additional, less popular commands for linking or resharing entries.

So I'm watching the big Apple notebook event and getting totally excited about the impressive new graphics capabilities. Finally I'll be able to get decent visuals on World of Warcraft on a Mac laptop. Then we get to the part about the new trackpads and my excitement wanes. Once again, Apple is opting for ultra-minimalist hardware and then using software to compensate (poorly) for that design choice.

Here's Steve Jobs:

We've got a new trackpad for notebooks. It's a gorgeous, large, multitouch glass trackpad for notebooks. It's 39 percent larger tracking area than before, it's multi-touch for gestures, it's glass for silky-smooth travel. And we've optimized the coefficient of friction on the glass, so it's really beautiful. And the entire trackpad is the button. It gives you more area on the trackpad and keeps you from hunting for that button. You can get multi-button support from software. And we've added some new four-finger gestures that are really nice.

Four-finger gestures may be really nice, but I'd opt for two hardware buttons any day. Whether you're playing video games or simply using productivity and development apps, you should be able to summon context menus without having to resort to arcane gestures. Apple's obsession with scaling hardware down to its essence may result in beautiful products, but usability almost always suffers. Need some more examples?

• iPod volume controls: Ever since the original model came out in 2001, users have had to cope with the iPod's irritating lack of a physical volume control. If your music library's like mine, the volume levels change drastically between tracks - even when you tell iTunes to level things. It's pretty annoying when the track changes from a quiet one to a painfully loud one while you're busy navigating some random menu. You've either got to rip your earphones out of your ears or painstakingly navigate back to "Now Playing" so you can once again adjust the volume. Then there's the single button that toggles between volume control, fast-forward, star ratings and media info. There's nothing more annoying than trying to fast-forward through a track using the slider control only to accidentally crank the volume all the way up and deafen yourself.

• Mighty Mouse: Worst mouse I've ever purchased - and also the most overpriced. The promos claimed that the single giant "button" would create a right-click or a left-click depending on how I pressed it. In reality, no matter how carefully I tried to attune my muscle memory, half of my right-clicks ended up as left-clicks instead. In the end, I disabled right- and left- click capabilities and went back to using the stupid option key. Then I really wised up, threw the Mighty Mouse in the garbage and bought an extremely ugly but extremely functional Microsoft notebook mouse.

• iPhone phone interface: The iPhone works great as an Internet device, but it's a lousy phone - and not just because of AT&T's immature 3G network. No, the real problem with the iPhone-as-phone is that its menu system is such a minimalist trainwreck. I can summon my "Favorites" list with a double-tap of the phone's single hardware button. But to get to any of the other sub-menus within the Phone application, I must launch the app, get my bearings - because the app retains whatever sub-menu I was using last time around - and then click an icon to get to Recents, or Voicemail, or Keypad. Actions that required a single click on a dedicated hardware button on my crappy old Motorola phone take three clicks and a lot of decision-making on the iPhone. Then there's the menu system once you're actually in the middle of a phone call - you know, the one that requires you to choose "Keypad" from a list of options before you can even respond to a standard touch-tone interface.

My point - and I do have one - is that minimalism should be a means to an end; the end itself should be usability. Simplifying a device's hardware does no good if it means forcing the user to think about how the software interface works. I'll almost certainly purchase one of these notebooks - possibly several. But as with so many Apple products, I'll curse softly nearly every time I use it. Apple's products are the best thing going in the notebook market, but they could still be so much better.

So pervasive has design thinking become in the last five years that Stanford University has created an elective program it calls d.school — more formally known as the Hasso Plattner Institute of Design — that has proved wildly popular with budding entrepreneurs from all corners of the campus.

It is a time in the spotlight for a process that historically has been relegated to the end of the business planning line.

Those of us involved in design already know that design thinking is one of several tools we use to help our clients stay competitive. Nonetheless, it’s nice to see major publications picking up on not only what design thinking is, but the importance of joining it with business thinking. Read the full article for a review of how this partnership works to create new solutions.

At the IDEA 2008 preconference workshop, Dave Bishop and Paul Gould from MAYA showed us another way to prioritize project tasks: a bullseye diagram. It’s still a ranking system, but done visually rather than numerically. The team first lists out all the project tasks. These are then placed in the bullseye based on where they fall in rank; the critical items are in the center and the less important items moving towards the outer rings. If this is done on a whiteboard with the tasks on Post-it-Notes, then information can be quickly be moved around in relation to new tasks that are added to the bullseye.

Once the tasks are prioritized and in the bullseye, you can organize, arrange and add structure. You can start to see relationships, which may indicate a different priority. You can start to see categories, which may affect iteration planning. You can begin to add structure. The outcome of this exercise is an easily understood diagram showing the project’s priorities. For teams that aren’t comfortable assigning a number to a task, this is a good alternative to try.

• Why diagram? We diagram in order to depict the information space in such a manner that allows us to visually validate to the client that we understand their domain. So often as consultants, we’re thrown in to domains where we have no or very little prior knowledge and minimal time to come up to speed at the level we need to be at in order to understand the context of the problem. Diagrams are one artifact that we use to organize the information space and document the users’ mental model. They are an essential element in verifying that your direction and understanding are correct.
• Future proofing. Don’t just design for the here and now; don’t design a solution that locks you into one way of thinking; don’t create a solution that can easily be broken by another idea. As solution designers, we need to look at the larger picture and how the various pieces can fit into the whole, rather than at just one feature or one path. We need to allow for evolution so the solution can accommodate growth and expansion without extensive redesign. All of these are concepts we’ve heard before; but it's already good to get the reminder and hear them again.
• UCD - user centered design focuses specifically on making systems usable to people. It tames complexity. Having the user integrated into the design process brings a focus around which you can organize the solution and design a usable interface. The direct benefits are increased productivity, reduction in support costs, improved user satisfaction, etc. The usual suspects, but nonetheless important to bring up with your clients when you remind them why UCD is relevant.

For the remainder of the session, MAYA reviewed some diagrams they use in their IA practice, including some I hadn't seen before. I’ll have more on that later.

CSS 2.1 is more like a Swiss Army knife than a fully stocked toolbox. We can accomplish a lot, but we have to get creative with the standard attachments. Floats, relative positioning, the box model - each tool must performs double or triple duty because they're the only ones we've got.

When we do discover a clever way to accomplish a common task using these limited tools, we're likely to employ that technique over and over. I'm not talking about CSS frameworks here; those help out more at the macro level. I'm talking about repeatable techniques that can be applied at the micro level. When done right, these simple techniques can feel like entirely new Swiss Army attachments rather than intelligent application of existing blades.

Whenever I start out on a new client project, I start off with the following plug-and-play components:

1. A reset stylesheet: Sometimes I plug Eric Meyer's latest reset in wholesale, while sometimes I pick and choose which parts make sense for my project. Regardless, it's absolutely essential to erase default styling and provide a common, cross-browser foundation on which to build.

2. Semantic, cross-browser float-clearing: I posted about this topic a year ago, generating plenty of debate. Whether you're using my Orbitz-inspired grocery-list-of-selectors approach or a generic clearfix class, you've got to tackle this problem if you employ float-based layout - until, that is, some future CSS spec implements a float-clear property.

3. Standard-issue pipe-delimited lists: If you're representing lists as paragraphs full of text punctuated by hard-coded pipe characters (|), you're probably not paying much attention to web standards. A set of CSS rules like the following makes it dead simple accomplish the same effect semantically with borders. True, Internet Explorer 6/7's lack of support for the first-child pseudo-class means you'll have to create an actual class called first-child and apply it to your initial list element. Still, once you adjust border colors and spacing to fit your site design, this solution works anywhere. Variations can even allow for pipe-delimited definition lists.

   /*
   	standard pipe-delimited list: add a class
   	of "first-child" to the first element
   	for IE either via script or in the markup
   */
   
   /*
   	- the 0 margin and padding are unnecessary if
   	  you're using a standard reset stylesheet
   	- you'll need to clear floats inside of ul.piped
   	  using whatever your preferred method is
   */
   ul.piped {
   	margin: 0;
   	padding: 0;
   }
   ul.piped li {
   	float: left;
   	margin-left: 8px;
   	padding-left: 8px;
   	border-left: 1px solid #000;
   	list-style: none;
   }
   ul.piped li:first-child,
   ul.piped li.first-child{
   	margin-left: 0;
   	padding-left: 0;
   	border-left: 0;
   }
   

4. Simple hide/show utility classes: Unless you're using an effects library to create visual transitions, it's easier to toggle classes on hide/show elements than to manipulate their style properties directly. The only problem is differentiating between block and inline elements when you're ready to show them again. That's where the block, inline, noneBlock and noneInline classes come in. Your JavaScript code just needs to know that elements with a class of block get toggled to noneBlock and vice-versa; same for elements with a class of inline and noneInline.

   /* classes to hide and show elements programmatically*/
   
   .inline {
   	display: inline;
   }
   .block {
   	display: block;
   }
   .noneInline,
   .noneBlock {
   	display: none;
   }
   

5. A style-as-link class for JavaScript actions: It's easier - not to mention more semantic - to trigger JavaScript code from click events on divs, spans or other non-anchor elements. That way, you don't have to deal with a dummy href value or cancel out the link's default action. Besides, the <a href=""></a> tag is for taking you to new pages, not performing an action within the existing page.

   Some JavaScript coders ignore these advantages because they want the built-in styling shortcut of the a tag: cursors and hover states. As the code below demonstrates, however, it's dead simple to achieve the same visual effects with some simple CSS. Modern browsers can apply the hover pseudo-class to most any element. Ditto custom cursors.

   a,
   .styleAsLink{
   	color: #08c;
   	text-decoration: none;
   }
   a:hover,
   .styleAsLink:hover{
   	color: #444;
   	text-decoration: underline;
   	cursor: pointer;
   }
   

   Once you've created a styleAsLink class, you can replace this type of code:

   <a href="#"
   onclick="alert('Isn't it annoying to have to return
   false every time?'); return false;">
   	this is an actual link
   </a>
   

   ... with this:

   <div class="styleAsLink"
   onclick="alert('In the real world the click event
   should be applied unobtrusively!');">
   	this is a pseudo-link
   </div>
   

   One caveat: This technique is useful for links that serve no other function than to trigger JavaScript code. Don't employ it in the case of a progressively enhanced link that triggers a script when JavaScript is available but takes you to a new page when it's not. A simple rule of thumb: If the link exists in your actual markup, it should remain a link. If it's inserted into the DOM wholesale by JavaScipt, it should be a pseudo-link.

Enough about my own personal Swiss Army attachments. How do you get all MacGyver with your CSS? Let us know in the comments.

During a recent GTD weekly review, I suddenly realized how many distractions had worked their way into my daily office routine: personal email, personal instant messaging, entertainment feeds, Facebook. I suspect such time-wasters pose a bigger danger to web developers than to other professionals, if only because the programs they run in are so central to our work. I run Firefox for web development, Adium for instant messaging, and NetNewsWire for industry news all day out of necessity. If I allow my personal distractions to jump out at me from those programs, my productivity plummets.

This weekend, I worked hard to de-tangle my professional and personal lives. My tools? Flock, the Mozilla-based "social browser," and Meebo, the browser-based IM aggregation service. My goal was to separate all personal bookmarks and RSS feeds from NetNewsWire and Firefox into Flock, then move all my personal IM accounts from Adium to Meebo. The end result was a self-imposed firewall between productive time and fun time. (Thanks to many a Lifehacker article for the basic idea, if not the implementation.)

Getting started with Flock

Flock represents a noble attempt to shoehorn social networks and other web utilities into the chassis of a Mozilla-based browser. Sure, many of its features could be achieved in a standard Firefox install. But I didn't want to have to run two copies of Firefox, one for work and one for play, and manage separate user profiles for each. Besides, my goal was to create a hub for my online social activities, so why not use a browser specifically designed for that purpose?

I also could have moved my social stuff to Safari, but that would have required adjusting to the quirks of a browser I'd previously employed only for cross-browser development. Flock 2 beta is essentially a tricked-out Firefox 3, so it offers a pretty seamless transition for this Mozilla. It even runs my essential Firefox 3 extensions, such as Foxmarks and Tab Mix Plus. With those in place, Flock looks like a souped-up sedan version of Firefox - slower, sure, but with more bells and whistles and a pretty coat of paint.

One feature that especially interested me was Flock's RSS integration. Sure, Firefox does this, too, but Flock's interface is nicer. You can interact with your feeds in a familiar two-pane interface rather than simply viewing headlines from a Live Bookmark. Flock's UI doesn't yet match the convenience of the keyboard-friendly NetNewsWire, but that's fine. I can live without power-user features when I'm just perusing The Consumerist or Whedonesque.

After a few days of using Flock to browse Facebook, scan FriendFeed, check Gmail, update Twitter and attend to my online banking, I'm sold. I don't really use the widgets on the My World splash page very much, but the integrated toolbar for interacting with Web 2.0 destinations works seamlessly. It's nice to be able to check for unread mail without firing up the entire Gmail interface. And I'm certain I'll use some of the blogging tools pretty frequently. One downside, though: You can't adjust fonts in the People Sidebar and other Flock-specific XUL widgets. My poor, aching eyes will forgive this misstep for now.

Getting started with Meebo

Instant messaging wastes as much time as it saves. Commingling of friends and coworkers on the same buddy list has always been dangerous. But even if you're careful, you'll get bleedthrough. Today's valued colleague often becomes tomorrow's high-maintenance friend once somebody switches jobs. Unless you want to give everybody you've ever known equal power to interrupt your work, you need a strategy for separating IM accounts. Creating a new account each time you start a job isn't enough. Hence my decision to segregate my accounts into two separate programs.

Cross-platform IM clients continue to proliferate, but web-based Meebo offers an interesting take on the concept. With its clean interface, soothing palette and lightning-fast Ajax interface, Meebo applies tried-and-true Web 2.0 design techniques to dowdy old chat. I used to have five IM accounts in my local Adium instance, but now I've moved four of them into Meebo. When I want to chat with friends, I can fire up Flock and open a Meebo tab. But when I need to focus on work, I can just shut it down and leave Adium open for agile team interactions at Pathfinder.

As with Flock, there's nothing about this setup that I couldn't have accomplished without Meebo. I could manually log off my non-business IM accounts whenever I want to focus on work. But I'm sufficiently prone to procrastination that such measures don't work. I need to trick myself psychologically, creating a completely different context for work chat and personal chat. Warm, inviting Meebo generates some much-needed contrast with cold, functional Adium.

Now the hard part: Sticking to the rules

Of course, prying apart the personal and the professional does no good if you're constantly firing up your fun apps alongside the work ones. Now that I've segregated all my time-wasting feeds, distracting chatter and enticing games, I've got to stick to the single rule that makes everything work: Only run Flock-plus-Meebo at specific intervals. I'm giving myself 15 minutes during morning coffee, 30 minutes at lunch, and unlimited time once I'm home at night.

It may seem counter-intuitive to get down to work with the help of two applications designed primarily for fun. But the work/play firewall helps me stay disciplined.

I've been an iPhone 3G owner for about six weeks now - six weeks of love, loathing, cool apps and connectivity problems. Rather than complain about poor network coverage, though, I'd like to delve into some of the vexing usability problems that hamper the phone's user experience.

No ability to disable autocorrect completely

Like pretty much every autocorrect feature ever built, the iPhone's does more harm than good. It always thinks it knows best. If you don't watch it like a hawk, it will render everything you type completely nonsensical. Proper nouns, abbreviations, profanity - all get turned into gibberish by this well-meaning but deeply flawed function. And god forbid you try to use the classic email e.e. cummings mode in which uppercase letters don't exist. The iPhone literally will not let you output the word "iPhone" without throwing in that capital "P." It's maddening.

If the purpose of autocorrect is to allow you to type quickly without having to monitor your output, it fails miserably. On the iPhone, if you want what you type to show up verbatim on the screen, you have to pause at the end of each word to ensure that the OS is not about to substitute its own wisdom for your actual intent. I would honestly rather type on a 1999-era StarTAC numeric keypad.

None of this would be as galling if there were a setting to turn this feature off. But there isn't. Elaborate, unwieldy workarounds have been suggested - all because Apple users know that the folks in Cupertino often paternalistically ignore their users. Microsoft's OS and apps may suck, but you can usually customize the hell out of them. Not so Apple's.

No saved password feature

Everybody and their brother has complained about the iPhone's virtual keyboard. Aside from the autocorrect feature, I think it's actually pretty good for composing email or SMS messages. But for passwords, it blows.

If you've got a strong password, chances are it's a combination of upper- and lowercase letters, numbers and special characters. That means you've got to switch back and forth between screen modes constantly. (And don't get me started on the way the iPhone automatically switches from numeric to alpha mode when you hit certain special characters.) Sure, it's nice that the phone shows you the most recently typed character in any password field so you can verify it's correct. But it's still such a painful, error-prone experience that once I've typed a password into my iPhone once, I want the phone to remember it forever.

No dice.

Mobile Safari has no built-in password manager. Sure, you could install an app like 1Password to get this functionality, but that means paying $29.95 for a feature that should be baked into any web browser - especially one that makes typing strong passwords such a maddening experience. Lots of iPhone users are downgrading to simple alphabetical passwords just so they can make this process less painful. That's a real blow to web security - especially the security of Apple accounts, whose passwords you've got to type over and over and over again on the iPhone just to perform such simple tasks as updating free applications.

No love for existing mobile stylesheets

I get it: Mobile Safari isn't like the other mobile browsers. It's got all the features of a real browser and can display web pages as they were originally designed.

But should it?

Pan-and-scan browsing makes for an incredibly frustrating user experience. Visual hierarchies that work wonderfully in an 800x600 or 1024x768 desktop viewport completely fail when they're reduced to the size of a deck of playing cards. Zooming in on little sections of the screen doesn't alleviate the problem. Mobile Safari's scaling abilities are impressive, but they're no substitute for a properly optimized interface.

Sure, you can serve up custom styles for Mobile Safari's viewport, you've got to use an extremely specific media queries. Normal mobile stylesheets are ignored:

<link href="mobile.css" rel="stylesheet" type="text/css" media="handheld" />

Instead, you've got to go the extra mile:

<link media="only screen and (max-device-width: 480px)" href="iPhone.css" type="text/css" rel="stylesheet" />

Why ignore the hard work of sites that have bothered to develop a mobile stylesheet? Why not at least offer a setting that will enable these stylesheets on a site-by-site basis? Failing that, could we at least have the ability to disable CSS altogether for certain sites? For the minority of sites with a lovely iPhone interface, Mobile Safari offers a great user experience. For almost everything else, it blows.

No default keypad in phonecall mode

Almost every phone number in the world is hooked up to some sort of touch-tone interface. From giant corporate phone trees to individual voicemail accounts, we live in a world where the lingua franca consists of 0-9, # and *.

So why doesn't the iPhone expose a numeric keypad by default during phone calls? To type an extension or navigate a phone tree or hit "0" to skip a voicemail greeting, one must stare at a row of icons for such rarely used functions as three-way calling, press the icon for the numeric keypad, and only then see the desired digits to tap. Sure, it's only one extra click. But considering this is the mainstream use case for most phone calls, shouldn't it be easier? Couldn't Apple at least offer a preference to show the keyboard, rather than the special features, by default?

No memory of wi-fi network preferences

If I don't have a WEP password to my neighbor's wi-fi network, I'm never going to be able to connect to it. But the iPhone has no capacity to remember that choice. If I have "Ask to Join Networks" turned on in my settings, it will ask me to join every network it finds. If I say "no" to a specific network, it'll keep asking me every time I launch an Internet-aware application within range of that network. My only choice is to turn off "Ask to Join Networks" altogether ... which means I won't be notified when my phone finds a network with unrestricted access. All it would take is a simple "ignore the existence of this network forever" button to banish a constant annoyance.

Does this irritant rise to the level of usability blunder? No. But it sure gets my teeth grinding.

Only recently has the technology that allows anyone to easily publish and edit online documents, in the form of Wiki's and Blogs, been developed. These tools have become so popular, so ubiquitous precisely because they cater to what users really want, fulfilling the potential that the web's founding father had envisioned for it almost 20 years ago.

And so given users obvious preferences for updated relevant content on the web, the ability to provide feedback to the wider community and the technology to allow web sites to provide all of this, I suppose that it's only a matter of time before all web sites are blogs or wikis, and the three terms become synonymous. The blogging and Wiki tools available today provide enough functionality and flexibility, are easy enough to implement, and give site owners so much advantage over traditional, mostly static web sites, that I don't see why any web solution couldn't or shouldn't be delivered as a Blog or Wiki.

Web design/development tools such as Adobe Dreamweaver, with their powerful but complex tools, and their steep learning curves, are designed to work with the traditional notion of the browser as a dumb viewport. As wikis and blogs--as well as the open source web based CMS's (such as Drupal, Joomla and even Wordpress)-- become the default method for creating, editing and viewing web pages, and hence as the browser comes to house more and more of the web publishing workflow, tools such as Dreamweaver will lose much of their value unless they evolve to support this new paradigm. The notion that a web site is like a painting, or sculpture, or some other piece of static art is outdated. Expensive tools that cater to this notion, by making it easy to waste hours manipulating the 'canvas' pixel by pixel are becoming unnecessary or even counter-productive. More so than ever, the web is a changing environment. It's easier, and better web design practice to get something online quickly, and tweak, or manage your design as it grows. Tools that support this new way of doing things are browser based and mostly free. There is still a lot of room for them to grow, especially in terms of usability, but I don't see traditional web design tools being able to compete without adapting to this new landscape.

Eventually, as the web becomes more of a democracy, and the viewing-publishing dichotomy breaks down, web designers will have to make more of an effort to work with these new rules, and the software that has enabled the web to flourish from a visual standpoint up until now will have to adapt as well.

As a happy transient fom the world of record stores to downloading my tunes happily from emusic, Loronix, moistworks and other fee based or file sharing sites, I am interested in how the music world is balancing art with commerce. With iTtunes being my least favorite way to get music, yet for convenience, it has surpassed 5 billion downloads, the pricing structure still seems broken. Radiohead made everyones news with releasing their record as a "how much would you like to pay" model. My problem with this was how difficult, confusing and somewhat rinky-dink the download/pay experience was handled. It actually made me not want to pay. Now comes the same idea done right - the 'mashup' artist Girl Talk, who put out one of my favorite records last year, has a pay what you like model done right.

The first page offers a clear value proposition, name your price - but if you pay 5 bucks you can get lossless versions. Pay 10 and get a 'real' cd whenever they create it. Then process the transaction using paypal, so no messy credit card transactions. Download at the same time so paying is not tied to actually getting the files (you can still bail on paying) However, being a fan I settled on $2.50, a tip so to speak. How about you, does the straightforwardness and ease of use make you want to pay at least something? Or to be profound - does ease of use translate into profits? I'm banking on yes, since the site was being hit so hard that it won't even load the cover picture, and it is my profession as well. I would love to see statistics on how this works out for Greg, but being a 'pirate' music site, we may never know what the ratio of payers to moochers is, which is a shame.

We software engineers - and our clients - tend to think of visual design as a coat of paint. The arrangement of elements on a screen seems like a purely decorative concern, something that can be applied to the bare walls of an otherwise functional application at the very end of the development process. Anybody who's ever spent much time coding at the view layer knows differently. If effective visual design planning doesn't occur early in a project, there's often a hidden cost. Reskinning an application is more like installing new drywall than applying fresh paint.

The PR wizards who launched the web standards movement have propagated the idea that if you just mark up your content and code semantically, then it's a trivial concern to alter its appearance. This is true up to a point, but most sites have a large number of person-hours invested in their stylesheets, images and other purely "decorative" assets. Because browser vendors haven't consistently implemented existing web standards, even the most well-meaning programmers must litter their code with hacks, filters and nested containers to achieve visual fidelity. The hooks for achieving a given look-and-feel often penetrate deep into the view-layer code. Altering that look-and-feel often requires changes to those hooks, which adds risk to a project and almost always breaks lots of tests.

To complicate matters, we engineers often conflate visual design with information architecture and interaction design. We leave all three until the very end of a project, when the change costs have increased exponentially. As we iterate on an application, we charge ahead doing "useful" things like building core functionality. We think it'll be easy to go back later and "clean up the view." By then, our code is riddled with assumptions about how that view will be rendered. Change is rarely as fast or as cheap as we expect.

When working with clients, I find it's helpful to frame design questions the same way I frame questions of development platform. Decisions about Rails vs. J2EE vs. .Net vs. LAMP are rarely taken lightly. The same care should be taken when choosing visual design, information architecture and interaction design. Platform changes carry a cost, even when the platform is a UI model rather than a programming language.

Every time this subject comes up on a project, I return to "The Elements of User Experience" by Jesse James Garrett. Six years after publication, this excellent primer could probably use an update. Some of its precepts could use a more agile spin. It would also benefit from a more explicit acknowledgement of today's increasingly complex interaction models. Still, I can think of no better introduction to Garrett's famous "five planes" of UxD.

If you run into any issues (which I'm sure you will, given the contortions we had to go through to deal with Typepad's funky url's), drop us a line at info@pathf.com.

In this case, the clever interaction design (and a hurdle for HTML) is to pair the actual article image (spanning multiple columns) with the text summary. The implementation makes scanning the paper a breeze and has a great visual clue of highlighting the image and overlaying the summary text. I'm delving into the markup to see how they managed to dynamically pair the images with the representative text, and seeing what other magic is under the hood.

Another nice feature was the rotating 'share' button, which takes care of not prominently promoting digg or reddit, but subtly reminding users that if they like to vote, here's where to do it. The only bad feature is that this is for paying customers only, but NYT has made free its online articles, hopefully in time this will follow suit, the days of microfilm readers may be numbered.

5. iPhlickr - http://www.chandlerkent.com/iphlickr/
What sets this apart is a seeming blur between the iphone features and the browsing world, when you select a photo, you can then share it, send it, or view it within the flickr world, unfortunately when iphone apps become available next month, flickr will probably become an 'app', but until then, this is a very ingenious and useful approximation.

4. Wikipedia

Iphones aren't fast in downloading data (yet) so when I want some info, I don't want a huge load time with lots of info that isn't getting me to my goal, this interface is very fast, and also does a great job in reformatting wikipedia content to take advantage of show/hide heading behaviors, which is a new iphone 'standard', and one that helps parse long documents quickly.

3. Amazon

A old-time favorite (was iphonized pretty much right away), but Amazon should be applauded by honing down their value propositions to fit on this screen, that is product, price, ratings. Thats it, and thats what In need when I'm thinking about picking up that camera in Circuit City, i want to swoop in and Amazon it for comparison and this does the job.

2. Reqall - www.reqall.com

I mentioned how much I liked this the other day, a technologically amazing mashup of voice/text note taking, plus some nice keyword recognition make a pretty darn useful to-do list! Add on the iphone interface, with good integration of thick finger style tabs, gets a reasonable amount of navigation in a small place to seal the deal. Bummer is that it makes you login every time, but I am lobbying for that to be fixed

1. Google reader - www.google.com/reader/i

I could say the google iphone interface, but the reason for this post is a huge shout out to Google for their revamping of the RSS interface for the iphone. I am super picky about RSS readers, my copy of NewsFire broke the other day in an update and I was in a panic to find a replacement, to no avail (I fixed it by installing a previous version). The thing I dislike most about other RSS readers is using the metaphor of email. I think we all get too much email, and RSS is not email, its more like a very personalized newspaper. The google reader nails this, and has kept me busy on train trips really enjoying reading stories, with excellent ajax integration, which really shines on the iphone since refreshing the page can take 20+ seconds, keeping info inline is imperative.

I also want to give credit to the password filler-inner 1password for their iphone interface, and twistori that shows that the same design works on both BS and little if the concept and interaction are clear. If I had a wishlist for sites I wish worked on the iphone it would be cellartracker (their regular site is not too great either, but the content is invaluable on mobile) and chase - if you are really embracing mobile users, let me really bank online.

The environment will change in the next month with the introduction of iPhone apps, but the resourcefulness of these developers to take 'plain ol' HTML and make a good user experience in a very constrained environment shouldn't be lost. Give your comments and contribute your favorites I may have missed.

It is one of the first problems of HTML markup that had no standard way to communicate to the user what they should do, I'm talkin' about the required form field. Personally, I have used some sort of asterisk in the past, coloration can work as well, but anything eye catching can distract from an error state (hey, you didn't notice we required that field, try again). So it caught my eye that the good people at reqall have an interesting pattern. In this case, make required fields have a bottom that is different from the non-required fields. This is fairly subtle, it took me a moment to figure out what it meant, but I give them kudos for trying something new. This is a long neglected design pattern of how to handle this in a consistent way, and this is a good a place to start. Its also a way to give a shout out to this service which mashes up text-to-speech, reminder lists, task distribution and has a nifty iphone interface as well, check it out!

How to do it

Here's a capture from their stylesheet, an interesting element here is I didn't know that you could restyle the drawn box of an input, so there is room for much variation. I also like the way they specified 'solid' to get rid of the horrid default 'picture frame' style of merging borders when they don't match, which always makes me flashback to 1998 web design.

 
input.essential {
border-top-width: 1px;
border-right-width: 1px;
border-bottom-width: 3px;
border-left-width: 1px;
border-top-style: solid;
border-right-style: solid;
border-bottom-style: solid;
border-left-style: solid;
border-top-color: #016098;
border-right-color: #016098;
border-bottom-color: #990000;
border-left-color: #016098;
}
 

Challenging, but simple enough, right? Immerse yourself in the product, do some user research, brainstorm designs that are meaningful, descriptive and culture neutral, and there you go. Oh, and one more thing...the device's display is 128 x 64 pixels with 1 bit color depth.

Such was the nature of the project I recently worked on, and it was a challenge of a very different kind then I had faced in a while. With either greater resolution or more color depth, It's relatively easy to depict pretty much anything with a high degree of recognizability. Shading, perspective, non-linear surfaces are all time consuming but doable with one or the other. Yet with only 2 colors and not many more pixels at your disposal, your so much more limited in what you can do. Take a look at some early GUI icons to see what I mean...

Since I couldn't use more than 2 colors, I couldn't anti-alias, so I was basically confined to horizontal, vertical and 45 degree diagonal lines. Forget about perspective. Since true perspective doesn't involve straight lines, depicting a product from an angle on such a small scale is out of the question. And shading--which is essential in illustrating that a surface displayed head on is curved--is just a matter of starting on the darker side with a high frequency of black, and then lessening the frequency as you move to the 'lit' side of the surface (Take a magnifying glass to a newspaper add to see what I mean). Again, not an option here due to the small screen size, there just want enough room to do that. I felt a lot like a writer being asked to weigh in on a complicated subject using 50 words or less. They say brevity is the soul of wit. I had to be clear and concise if I had any chance of success.

At 128 x 64, every pixel matters. And at 1 bit color depth, rotating, scaling or otherwise transforming anything in Photoshop is useless because the software automatically anti-aliases, creating shades of grey that were forbidden. So I had to design pixel by pixel--make a 1 x 1 selection, put my hands on the keyboard cursors and get to work. See Wikipedia's entry on Pixel Art for a good reference.

As it turns out, I was more at home on this project than i though I would be when found out the requirements. You see back when I was a kid, the first computer graphics program I ever used was on my father's DOS machine. The program itself wouldn't fit on the computer's hard drive, so it had to be loaded via floppy disk--the old 5 1/4" ones. The computer didn't have a mouse, so almost everything I created had to be tediously drawn pixel by pixel using the cursor keys. It took me months working 2-3 hours a night, but I created some pretty good stuff. In particular, I remember drawing a hockey rink, with players, stands and all, which I'm pretty proud of. Using Photoshop/Illustrator now, with the capabilities so far advanced over what I had to work with at that time, It's hard to see how I did what I did, or for that matter why I spent months doing it. But there's something about taking time to do something right, struggling through the frustration that comes with the absence of 'Undo', picking yourself back up after making a mistake that renders 10 hours of work useless. Creating art is a sprint. Back then it was a marathon.

So I forgot about my mouse, left the color picker behind, and zoomed in at 1600%. I soon found the hang of it again, and I got in the groove I remembered from way back. After a lot more time than I though it would take, I had a set of icons that worked...and that's the key. And in the end, I feel a little more satisfaction than I would have if I was allowed to let Photoshop do it's magic.

In looking at the elements controlled by another element, the most fitting markup is a definition list. For some reason these elements are mysterious and not too often used. It is a list <dl> that can contain two elements <dt> and <dd>. Normally they have a default display of one element being bigger and the other slightly indented, as to look like a directory. So, with little or no work we can describe the two types of list elements, the 'header' - <dt> and the information that can be 'opened' the <dd>.

So having my markup, well, marked up, I can set aside the HTML, produce some styles for the list, but what about the complicated part? Adding the behavior to hide/show, make the <dt> clickable, swap the GIF's that indicate opening and closing, and while we're at it why not a 'expand all' or 'close all'. Finding it was no mean feat, but with some very creative google searching I found the script - http://www.tjkdesign.com/articles/toggle_elements.asp. So this handles all the heavy lifting, and basically degrades nicely in a non-javascript situation to show all elements. Problem solved.

The satisfying thing about this solution is that the code is clean, and easy to change, and any presentation issues are handled within CSS, along with any behavior in javascript, and handled by the client. I think the two approaches compliment and contrast each other nicely, add your own solutions to the comments if there are even better ones.

The amazing thing in the research realm of computer vision is that some algorithms are becoming able to 'read' this obscure text, making it necessary to make them even more unreadable. Recently, I have found this alternate 'maptcha' - being used on a number of sites, replacing the text with a simple addition problem. Not only was it less burdensome on the eyes, it seemed a bit fun to do a small math or counting exercise. I am curious if this is terribly insecure, or just a small revolt against the difficulty many users have with the other method. Either way, a great pattern to emulate, and much easier to use.