Every site has nouns and verbs. What I call nouns are the individual pieces of information that fall into your site structure. Verbs are activities that your users engage in.

Nouns

The nouns are the objects, sectional breakdowns, and data that pull most of the weight in structuring the site or page IA. Nouns create context.

• You are here
• This page primarily contains information about an object of type A
• This page also contains some info about objects of type B and C, which are related to A thusly
• This is the information on the type A object you selected
• This is a list of other nouns that we have content about
• etc...

They are the primary drivers of navigation menus, breadcrumbs, and headings. Linked nouns typically take users to information based destination pages. Browsing a site via noun links is an information gathering, exploratory exercise. You're offering information to your users. Following a noun link should generally not alter the mode of a user session. Object meta data and content text blocks support your nouns and may contain noun links as well. In my opinion, verb links in meta data and text blocks should be kept to a minimum. As the designer, you should recognize the nouns on a page and their relationship within your site AI. In the example above, if there is value in offering more information on a specific type B object than displays on the type A page, the noun should be linked to a drill down page focusing on the type B object. I'll repeat myself for emphasis: The noun should be linked. Don't leave the noun as raw text, then add an arbitrary verb link such as read more.... If your typography is clear, it should be obvious that the noun is a link, and that's enough.

Verbs

Verbs keep your users on your site. Some verbs are for your benefit, such as site registration; others for their benefit, such as purchasing something. In general, sites built to directly bring in revenue are built around verbs. If you have a site where your users can engage in unique or profitable activities or workflows, then by all means, invite them to do so. And make a big deal out of it! Verbs give your users a sense of ownership. They engage users to intellectually protect their experience on your site. The user is doing something and you are helping. The better and more transparently you do your job (helping), the more likely they will stay on your site. On any given page, you should be inviting your users to act. The language used in your verbs should be plain and clear. The visual prominence of verbs should reflect their importance to your users (not to you). If a user is engaged in a multi-step workflow, tone down verbs not directly related to their path. If the page is informational, or a functional terminus, then present them with an obvious doorway to somewhere they can act again. Presenting them with contextually useful verbs keeps the user moving forward. If there are textual verbs on page representing actions the user can take, they should be linked. If the user can't take these actions from this page, then you need to reconsider their inclusion in the content. If their presence is informational ("You will be able to do X") then identify in the text or typography that the function is potential, not a starting point for that action. Make the verb into a noun, basically. Linking this noun should target a page or popup with more details about the action. Treat your verbs with respect. Display them prominently and with pride. Being good to them is being good to your users, and being good to your users is good for your bottom line.

Overriding common word definitions or conventional perceptions in your interface is a one way ticket to Sorrowsville. Written language is a series of symbols that describe concepts. Dictionaries exist to document the concepts commonly agreed upon by the general public. I realize that language evolves (though I sometimes lament just how it evolves), but when it comes to user interface design, I find it's best to stick to conventions when it comes to naming features. Example: inbox. The inbox paradigm implies a collection of items (usually of a unified type), populated via submission from external sources. What's in it is usually news to you. If you're writing an application and you have a feature that behaves in these ways, then by all means call it an inbox if that suits you. Actually, unless there are extenuating circumstances or the nomenclature would be somehow confusing to the user, you probably should call the feature an inbox. However, if the feature doesn't satisfy the conventional definition or supports numerous behaviors beyond that of the definition, you should absolutely not call it an inbox. The value of following convention is that you don't need to teach your users how to do things. This saves them time and brain power. You're helping them not have to think.

The Swiss Army Inbox™

Let's suppose that you have an application which misrepresents the inbox convention. New users will encounter your inbox and expect X, but be delivered Y (which may = X + Z). Strike one! You've unnecessarily made new users think. Over time, your users will learn that your inbox can do Y, at which point, the inbox symbol comes to represent Y (within the context of your application). They don't think about the connotations of the word anymore, they perceive it symbolically as a tool, useful to accomplish their goals. If you later realize there is a better name for the feature (which there most likely is), you can't simply rename the current feature without compromising user expectations. Pulling the rug out from under your current user base like that would be strike two. Now what happens if a new revision of your application includes a feature that perfectly fits the inbox convention? Well, you're out of luck, because the word has already become symbolic of a different interaction model. And don't even think about creating a conventional inbox along side your non-conventional inbox, because that breaks your lexicon. I've used the inbox paradigm as an example, but the same policy holds true for all mature conventions. Emerging conventions aren't as volatile, but you do run the risk of choosing a representation that will become dated as the new convention matures. Feature naming is often one of the hardest parts of building an interface. Just be careful when you include conventional terms in your naming options. You might be looking at trouble ahead that you didn't expect.

I bought a CD some time ago of all the back issues of SysAdmin magazine—complete with back issues of The Perl Journal as well. I'm not a sysad, but I host my site on a virtual colo, so I have to pretend to administer my server. In reality, I just bother my sysad friends all the time. So I saw the offer on techbargains.com and I figured maybe I should learn something.

But I...can't...read it!

last night I cracked it open for the first time. All the issues and articles are in html, so I loaded up index.htm (I'm always weary of html files with the htm extension) and lo and behold, it's a framed interface with content oddly presented in a TBL. Standards aside, why bother with a table when you only have one cell in one row? This is a shot of an article list page: And one of an article page: I found the typography claustrophobic and the image button navigation distracting. I couldn't finish the first article because the lack of whitespace between the red cell border and the content kept dragging my eye down.

Hands on

Fortunately, the CD has all the source, so I copy it all to my hard drive and start up vim. I'd prefer to modify as few files as possible, so css is the logical choice. There are thousands of files comprising the complete documentation, so without writing some perl scripts to strip the content out of the TBL, etc etc, I have no control over the markup. This makes updating the css more challenging. To boot, there are no class or id assignments. Most design elements were created using tag attributes such as bgcolor. The topnav is one file consistently populating the top frame, so I rewrite it and the supporting css to do away with the dreadful buttons. Otherwise, I haven't peeked at many articles, so I assume their layout is consistent, and I attack the main (notably sparse) css file to improve the content layout where I can.

A little breathing room

The new article list page: And an article page with a larger font and a little more breathing room. I spent very little time on it, and it's far from perfect. There's really only so much you can do with bad markup, anyway. But at least now there's a chance I could read it. Naturally, by the time I had tweaked it enough to remove it from the Complete Disaster category, I needed to go to bed. Knowing me, I'll probably write the perl scripts to extract the content into a local db and write a better UI wrapper for it all. Then, maybe I'll get around to reading it. What were those articles about, again?

Yesterday was a day filled with many rich emotional, psychological, and physical experiences.

Guilt and liberation

It was my last day at ePublishing. It was my first 100% remote position, and I loved it. I learned invaluable lessons about personal time and workload management, about the comparative valuation of human capital to client revenue, and about the importance of communication and support in distributed team environments. I was able to internalize these ideas for the first time, and now I believe I have the confidence and perspective I've needed to step into a management role. Like every company, they had their own challenges, but the team there was very good, and I regret leaving them. I felt valued and valuable, and I have the utmost faith that they have the people and the will to grow and improve in the right ways to keep the company successful. At the same time, my role there was limited to development, and I was chomping at the bit to be involved with design and UI decisions. The recent workload was quite daunting and burnout was imminent for many on the team. The prospect of returning to more reasonable hours while working on the UI side is exciting, but I have strong sense of responsibility regarding the projects and companies I work for, so I always feel guilty for leaving.

Painful cold

It was 1 degree most of the day, and frost has formed on the inside of our windows. Heidi and I didn't spend a lot of time outside, but had to walk a few blocks from our car to a restaurant for dinner—Friday night and all. It was 0 by then, or -0 as the bank signs said, but fortunately not that windy. Still, the cold instantly froze any moisture in the air, and it was stinging to breath. Within half a block, the skin on my face was stiff and aching. I really enjoy it here, but this will take some getting used to.

The pangs of pregnancy

Heidi is about 20weeks pregnant right now, and only recently was the news of her pregnancy made public. Not until we visited friends and family in Portland a couple weeks ago did most learn about it. It's of course very exciting for us, and certainly more than a little surreal, but that much I've been dealing with for a while. Some very dear friends of ours have been trying to get pregnant for some time with little success. The wife is one of Heidi's closest friends, so when she learned of Heidi's state, it was very difficult to handle. She happens to be one of the strongest people I know, so recognizing the impact the news had on her was humbling. I talked to her on the phone yesterday and in the process, got a glimpse of both the magnitude of her experience as well as the fortitude of her character. She really is an amazing person.

Good food

In honor of my last day, Heidi and I went out to a wonderful Indian restaurant. I love Indian food, but it tends to be a bit heavy for Heidi's taste, so every time is a special occasion indeed. It's a popular place, and it being Friday night didn't shorten the wait to get in. We were quite hungry by the time we were seated. At this point, I wanted some of everything on the menu, but I knew I could only eat so much. Nonetheless, we ordered three entrees, some rice, and some naan, and planned for plenty of leftovers. Fine by me. The inevitable point arrived where I just didn't have room for more. But the food was so good and it was such a rare opportunity that I experienced a sort of panic. My body was clearly telling me that I was already overdue to pack up and go home, but my brain direly wanted more because it was so pleasurable. I look forward to the leftovers.

Just a quick note to say that I, among so many others, think the newly announced iPhone is amazingly cool. A few bloggers have pointed out that the lack of tactile feedback due to the absence of a keypad may cause issues, and I agree. I also agree that Apple's choice of Cingular as their exclusive carrier through 2009 is real shame, though I understand their business reasoning. That being said, count me amongst the ranks of those people that recognize the potential pitfalls but still want one. On this topic I'll delegate my enthusiastic digression to the incalculable buzz that's currently not peppering the web, but thickly coating it. iPhone. And there was much rejoicing.

Everybody has those moments where you come across your old work and groan. Sometimes you don't even need to see it. Out of the blue, you just remember something, and boy, does it ruin your day. A couple jobs ago I was employed as a developer, but in reality I was the UI guy. The previous UI guy left before I got there. The interface he left me was...shall we say...less than ideal. The user interaction model included a limited set of interface paradigms (every problem was solvable with a hammer or a screw driver). The interface was IE specific TBL madness. The color scheme was atrocious. The Information Architecture was fragmented and unclear. The CSS for all pages was in one huge unorganized file with useless nomenclature. Excessive amounts of procedural javascript were required to make the interface function at all. And beyond all that, it did a rotten job of addressing the customers' operational requirements. It was quite the house of cards. Well, after some ramp up time, I decided to start introducing some interface changes. Nothing too big or sudden. I had grand ideas and plenty of notes and sketches, but those were a major rewrite away. So in the mean time, I took some basic principles and began introducing them into the UI. And introducing them. And introducing them. MAN, did I introduce them! Iconography, for example. I went completely overboard with the icons. On various pages, a medley of different component objects would be presented in a table with discriminating information in a tiny font amidst misaligned columns. The problem I attacked was that the users couldn't easily identify what they were seeing. That, however, wasn't the problem, but the symptom. The real problem was that the users didn't care about what we were showing them. The tasks they needed to accomplish and the tools we'd given them to do it just didn't jive. We'd solved their problems our way and expected them to get on board. The puzzle pieces we used didn't correlate at all to their MO. Therefore, went my thinking at the time, every bit of extra information was helpful, right? I went on a rampage. I wanted those icons everywhere. Sometimes one item would have a little zoo of icons—one type indicative icon, and a collection of others representing various meta data. In lieu of an intuitive UI, I wanted to give the user as much data as their little color receptors could take in. The use of color to communicate simple concepts is more efficient than relying on text, but what I should have done was spend time removing information. The graphic elements drastically reduced the active real estate and served no good purpose. Within 1024 x 768, only about 500 x 300px were gainfully used. Removing some of this cruft would have offered more breathing room to the bad IA. The dense TBL was largely preventative when it came to reorganizing layout. Breaking up, annotating, and categorizing the CSS would have made the surgical removal of table after table more manageable and the introduction of new interface paradigms easier. In retrospect, I wish I would have attacked the fundamental issues rather than the symptoms. I also wish I didn't have all that other work to manage while doing it :) It was a more educational experience than I realized, and I'm happy to say there were things I produced that I am still proud of. I still think about how to improve that interface, though. It's amazing what people pay for these days.

If your users can describe a task simply, chances are the interface can be built to make that task at least that simple.

When designing a user interface, sometimes the less you know about the architecture, the better. The more time you spend working with the component objects, the more your mental model of the application uses these building blocks when conceiving of the application from all perspectives.

Address user goals

It's important to remember that your users are trying to accomplish something. The path from A to B will involve interaction with your component objects on the backend. In all likelihood, the most usable solution will not involve letting (aka making) the user create and interact with the objects directly. Instead, the design should address goals and attempt to simplify the process and create an intuitive interaction. If your users can describe a task simply, chances are the interface can be built to make that task at least that simple. Sure you created a super flexible architecture where all sorts of your objects could be hooked into each other in any number of ways—The sky's the limit!, you shout. Then you show the user the application and tell them that to do X, you create a type A object and a type B object, and hook them together like so, but to do Y, you create a type A object, a type B object, and a type C object, then hook the B to the C first, then the C to the A—be sure not to hook the A to the B!—and flip this switch. And voila! An unusable, unintuitive interface.

Speak plainly

Users are not application architects. They may be able to understand complex constructs in varying contexts, but why should they have to in your application? You should learn what the user's goals are and use your knowledge of the architecture to obviate the magic that goes on behind the scenes. Speak in plain language on the interface; don't refer to the objects and their architectural relationships unless A) absolutely necessary, and B) you can do so in plain terms. Do your best to make it so the user doesn't need to know what the man behind the curtain is doing. That's what the curtain is there for, after all.