Ellen Beldner

Okay, I already knew that I hate and detest the new-ish Facebook practice in which you don't just navigate to outgoing links; you get taken to a Facebook page with the site you were trying to visit loaded into a frame, and with a Facebook toolbar at the top of the page.

And now, not only does Digg do it too, but the sites are so dumb that they're double stacking these stupid toolbars.

This is crap primarily because it breaks basic web behavior: the URL on your web browser no longer represents the page you're viewing, or trying to view. Big juju nono. We've known this since 1996, people!

Also, I don't want to send someone to http://www.facebook.com/ext/share.php?sid=89405539347&h=1e79i&u=2fnBr&ref=nf. I want to send them the link that's www.youtube.com so they know where they're going and what they're going to get.

The one case where Google does something like this -- a frame with another site inside its toolbar -- is when a user clicks on an image search result. That frame bothers a lot of site owners that Google links to, but it was a necessary tradeoff because image search is kind of sketchy and occasionally unreliable. Users click on an image result and get taken to pages that no longer have the image they were looking for, and the toolbar exists to help them identify the image they wanted -- NOT as a marketing-sticky thing for Google. And even though it's often beneficial, it still confuses a lot of users.

Note that mismatched content and URLs is a usability problem for Google Maps. The URL that many users copy from their browser address bar usually doesn't correctly represent the state that the user's in due to the way the site's AJAX works. AJAX or FRAME, it's the same problem.

Halvorsen is the typeface I recently used for my GreenBetween redesign. Turns out that Dan likes it too.

I don't really know Dan, although I hired him via Google to do some fast icons for a small project a couple of years ago. (I happened to be at his website because a friend of mine needs a template for his blog & I was going to recommend Dan.)

GreenBetween is a site that allows people to buy carbon offsets. A friend of mine was starting the site and asked me if I'd design some website badges ("I purchased a carbon offset!") and a printable certificate. I agreed, and in the process gave them a fresher look, made a new logo, suggested some product ideas, tweaked their navigation, and redesigned their page layout to improve the visual direction. Tragically I didn't save a "before" screenshot for comparison.

The project took about 15 hours. I did it in a weekend. I agreed to do two iterations of the badges and certificate. The rest was essentially voluntary. I used 37signals' Basecamp to manage the file delivery and post the milestones / deadlines I was adhering to.

Step 1: Choose a typeface for a new logo.

I'm not a logo or graphics expert, but the previous logo was Arial and I knew that with the right typeface we could make the logo look more fresh, polished, and professional. I went through a bunch of fonts on MyFonts.com, picked some that might work, and sent the comp to Elad and Chuck for review with my recommendations.

I did this first because the typeface they chose would guide the rest of the visual design work I did. They selected (3) - also my top pick -- a font called Halvorsen.

Step 2: Draft the homepage

I did this before the badges and certificate. I needed to know what the site would look like so the badges and certificate would match.

The graphic at the top of the page was one they had chosen; I replaced a black background with green. I made the page background white instead of gray and made the headers and links shades of green. It's an environmental site so I wanted it to feel fresh, green, organic, and light. The page gradient might be a little gratuitous but it adds a bit of visual balance to the top of the page.

I clustered the links into logical groups ["actions the user wants to do", "learn about carbon offsets and global warming", and "about the company"] and moved it to the right, and made the dominant page element the actionable "Buy a carbon offset". Previously there had been 4 or 5 HTML buttons in the middle of the page with a lot more text -- it was a little hard to focus on the next action (buy an offset).

I created one big button ("buy a carbon offset") and made the purchase options into a checkbox-list, instead of separate buttons as they had been. First, I thought the original buttons competed too much with one another, and second, they didn't afford multiple items in your "basket". Also I added the Google Checkout logo so purchasers would know that their payments were being processed by a reputable company.

Step 4: Certificates and badges

I created several versions and had Elad and Chuck give me feedback.

Step 5: Product brainstorm -- a carbon offset catalog page

One of the goals of the site is to help people understand their impact. I suggested first that they include packages to offset specific high-carbon activities -- they already had a long flight, and I suggested offset packages for things like remodeling your home and taking a road trip. I also suggested that in their offset calculator, they fill in each form field with the average consumption as a default to give users a starting point.

Step 6: Get feedback

Step 7: Revise and deliver

I sent the revised comps, plus a ZIP of sliced production graphics.

Now, go buy an offset! (I also designed the Google Checkout interaction, so you'll be using implentations of my design work all the way through to checkout.)

Jon Kolko, who I met at CMU, just published his book Thoughts on Interaction Design. I'm a guest author and wrote a chapter called "Getting Design Done".

The book's website is http://www.thoughtsoninteraction.com/.

http://www.nytimes.com/2007/03/25/business/yourmoney/25Proto.html?_r=1&oref=slogin

Summary: Let advanced users hack on your products. They will come up with innovations that you didn't think of.

This stands up nicely to an economic interpretation too: If someone is willing to take the time to hack around and build something that wasn't part of the spec, that means that they're willing to spend capital to have that functionality. Which means it's some sort of market opportunity.

Enterprise software can often be maddening like this: companies sell their software for $200k + and they want to be gatekeepers and prevent customers from getting into the code -- they want to preserve the mystique or something. But often they just end up being roadblocks to customer happiness. Like, I bet if we could have hacked on Oracle Calendar rather than having to build our own totally separate version, we'd be vastly more advanced than either system ends up being. Good, complex software takes time (a lot of time) and figuring out how to build on the accumulated knowledge of others (represented in code)

Unfortunately, the article puts this technique in opposition to "traditional" anthropological design processes -- which often aren't well-integrated anyway. There's absolutely no reason why you can't derive benefit from both techniques.

(...I was thinking about calling this post "Ellen on Joel on Software" but I think that would be a gross thing to say.)

We had a thread on the UE team mailing list where someone had -- reasonably -- gotten a bit miffed that Joel Spolsky blithely assumes that most of usability and design are trivial functions that anyone can easily do anytime. One of the Joelisms she cited from User Interface Design for Programmers was:

if usability engineers designed a nightclub, it would be clean, quiet, brightly lit, with lots of places to sit down, plenty of bartenders, menus written in 18-point sans serif, and easy-to-find bathrooms - and nobody would be there? (p. 130)

I am generally a huge fan of Joel on Software -- although I am a bit annoyed by his attitude towards my profession -- and to lighten the mood, said this as part of my message in the thread:

...and by the way, we all know that usability engineers would never design a brightly lit nightclub. you'd do some contextual interviews, learn that no one really wants to see each other in a nightclub because the primary user motivations are getting laid and drinking away depression, and obviously the place would need to be dark. at which point the designer would come along and suggest putting the menus with 18-point type behind lucite slabs (protects against spilled drinks, too!) with LEDs embedded in the top edge. ;)

As part of the Decidr and Widget Bitch tshirt series, I just published tag clouds don't work to the WidgetBitch CafePress store. Because tag clouds don't work. They're the UGG boots of interaction design: no one really believes in them but you see everyone else with them and you're like "ummm maybe I should" and then you just look like a mess and in 3 years you look back an you're like "oh god what was I thinking?" Be ahead of the curve.

Woohoo -- new design for the Google Base bulk upload dashboard! The old bulk upload dashboard was a 3-second one-off using our generic tabular data widget. Since most of our bulk uploaders have only a couple of files, the tabular format was overly busy and misused the screen real estate. The page was also getting messier as we added promos (for AdWords, Checkout, and some of the other inernal tools, like using FTP to submit your files).

These changes were some of the few we've made that didn't stem directly from usability research mandates. Rather, they're based on design principles and heuristics. We left most of the info architecture untouched. I suggested moving to the blurb style instead of the tabular format, and moved all the promos to the righthand side to hierarchize the information. The tabular format is almost totally useless for this page's main tasks: "What's the status of my file?" and "I need to update my file". Most users only have one bulk upload file: tabular data display is good for comparing across rows, and most people only have one (maybe two) rows. We have better error messages and links to help for specific item types.

And instead of the previous "upload" widget -- which has users select the file they are updating and then browse for the file -- we now make "upload" a function of each file. Throughout our system we present bulk upload files as granular objects, so it seems more appropriate to have "upload a new version" be an action on a particular file. (There aren't enough actions-per-object, I think, that it's necessary to have both object-verb and verb-object models embedded into the system.)

This is another example of where thorough programming and PMing really made the page. The engineer who implemented this did all of the logical conditions correctly: so when you update a file, we have extra text that warns you "This will erase all the items that you currently have and replace them with whatever's in your file." And it only shows up if you're updating a file, not when you're uploading for the first time.

The other day we launched the Google Base Store Connector.

The progression to the final version was pretty neat. When I started working on the project there was a functional demo that had already been built, wizard-style. I came up with a few user scenarios that led to functions like storing account information so users can easily update their items in one click. That is, if someone has an Ebay store and they want to get listed on Google, it'll be better for them if they can store account information so all they have to do is periodically click something to say "okay, update my items" rather than having to re-enter account information each time.

(Yes, there would be faster and more humane ways to do this that don't involve an intermediary application, but those are outside of technical scope.)

The engineers and PMs on the project did an awesome job getting the details right. For example, based on the store you select (eBay versus Amazon, for example) the textual labels change next to the input fields. We used the language from each of the source sites: Amazon uses the terminology "sign in" with your "email address" instead of something like "log in" with your "username" or "user id". Yahoo! has a "Yahoo! ID". This keeps it just a little bit more familar for users. They probably couldn't tell you if Yahoo! calls it an "id", a "user id", or your "yahoo signin", but seeing the same verbiage will trigger subconscious memory and feel a little more "right". Cognitive priming, anyone?

So: a very small piece of software, but reviews on Ebay's forums generally commented on how simple it was to use. Yay! We wouldn't have gotten there without a comittment to good technology from the PMs and engineers. Good user experience is only partly UI design; a lot has to do with the engineering behind the interface.

Less suck, more hot. We did a ton of usability testing of Base in the past few months, and this revised homepage came out of it. Goals were to make item types more visible, help users understand what base is, deemphasize search (to keep the focus on Base as place for uploading, not for searching) and help users make better choices about the right upload technology for them.

One of the things that I think makes this design work really well is the IA of the page. Users who come here are either brand new (never heard of Base), brand new but who have heard of Base (e.g. through a marketing email or similar), or are returning users who want to manage their items. I wanted to clearly draw users' attention to the first choice they have to make: how are they getting their stuff on to Base? This is a bit system-centric (how will a user know which technology to choose?) but it turned out in all the studies that we did that people did a good job of identifying the technology that would be suitable for their needs.

Everything that you need to do to get going is on the right: either sign in (for existing users) or click one of the giant iconed links to get started. The blue background draws further attention to the section and, along with the icons, helps balance the huge sea of blue links on the lefthand side of the page.

The left, in its turn, is the "learn more" part of the page. If you're not sure what Base is, you can focus mostly on the left -- browse a few item types, see which ones are popular and which ones are sort of randomly interesting, and get the couple lines of promo / marketing text. Some users really really want to investigate; some users want to jump right in and start playing around to figure it out. (I'm not sure if it has more to do with technology familiarity, age, or how much you need your stuff to show up on Google for your business to survive.)

There are still a few bugs, but those will get worked out soon. Official post on the Google Base blog.

When it comes to discussions about writing software specs, I really like to quote Sen-Rikyu, the master of the modern Japanese tea ceremony: "Tea is naught but this. First you make the water boil. Then infuse the tea. Then you drink it properly. That is all you need to know." But if you know anything about the actual practice of the tea ceremony, there is -- for laypeople who have not mastered the Zen of simply boiling the water and infusing the tea -- an immensely complex protocool, replete with symbolism that must be adhered to.

Writing specs is simple. All you do is document what has been decided and capture known uncertainties, and underlie everything with a giant disclaimer that until the code is written you won't know exactly how it's going to work.

In fact, perhaps we shouldn't think of specs as specifications of software. They are specifications of goals for the software.

I'm about to start working on a UI spec for some upcoming changes to the Google Base UI. I'm always looking to improve, and this is a pretty complex series of workflows that we have to get just right. So I want to make sure that I capture and communicate all of the decision points that I've traversed up until now, and that I specify behavior that may not be fully obvious in the prototype that I built.

Let me highlight some key concepts from that last paragraph: Capture. Communicate. Spell out corner cases.

So I searched for write UI specs. The first result is 37 signals explaining why specs don't work. I read this type of article -- along with some Agile and XP techniques -- as a radical overreaction to the other extreme (of overplanning and presuming you can actually precisely specify software on a piece of paper before anything is written). In that sense, the 37 signals article is irresponsible. It's speaking to a particular historical context of software engineering without acknowledging that there are a lot of ways that specs can be written, usefully, in the context of more modern software engineering practices. Moreover, when you're not working at a small startup, it is irresponsible to not write specs. Specs help other teams anticipate and plan for what's happening down the line, and when you don't have the same 10 people doing everything -- when you have a marketing department, a customer service team, writers who have to do help documentation -- you need to let them know as early as possible what you think is coming down the pipe, so they have maximum time to plan their own resources and schedules.

I already wrote the blog post on the official blog. But this is one of the more successful design-to-implementation experiences I've had on Base.

Sitting down with my architect this weekend to make decisions about kitchen cabinets, countertops, sink, and how the stairs will work. The kitchen will be monolithic charcoal gray (or maybe white) so it doesn't compete too much with the brick & timber in my loft. Work will start ASAP.

I can't wait to start cooking again. My 14 boxes of kitchen and dinnerware are starting to annoy me, and I want to have dinner parties again.

Pironimo.net is a twiki installation that I deployed, customized, and maintain for a small community of friends (around 30 people). It began on another server in September 2002. Since then I've done about three major UI revs and one software upgrade.

At work we have a bunch of Toto washlets. One day I was explaining to some friends about the wall-attached remote control. One of them, in annoyed puzzlement, asked why on earth would you need a remote-controlled bidet control? This sketch is an exploration of different solutions based on my task analysis.