At Covenant Eyes we’re continually in the churn of Agile development, and integrating user experience work can be challenging. We’re figuring it out, and have definitely made some breakthroughs, but this article has provided another perspective that is helping me think about timing of user experience work within the loose phases of work that a typical project runs through.

It isn’t a stretch to layer the phases of Discovery, Reframe, Envision, and Create over a project’s lifecycle, and so tying different models for design work in each phase provides an opportunity to reflect on how we’re doing with matching up appropriate design work.

I’m asking my team and our project managers to read through it, and perhaps we’ll get a chance to discuss it together and consider if we can use some of the ideas to do better work.

The utm_medium is pretty straightforward in that the medium would be values like email, web, twitter, rss, and so on.

But, what’s the difference between utm_source and utm_campaign?

Google’s documentation on these variables is helpful in general, but is not all that clear on the difference between these two variables.

So, here’s how I think of those variables. The utm_source is like a noun, and utm_campaign is like an adjective. The utm_source will be more consistent from one edition to another, while the utm_campaign will change.

Let’s look at an example. Let’s say I send an e-mail newsletter called Brilliant Widgets every season (Spring, Summer, Fall, and Winter), and I want to track how many links back to my website each edition generates. Here are the utm_* values I would use.

utm_* values for the Winter edition of Brilliant Widgets

So, the href value of the link back to my website would look like this: http://blog.davingranroth.com/?utm_source=Brilliant_Widgets&utm_campaign=Winter_2011&utm_medium=email

Now, assuming I use those parameters on the links back to my website and that my website activity is being tracked with Google Analytics, I’ll be able use Google Analytics to identify website visits that came from that e-mail newsletter. Then for the next edition, I would keep utm_source and utm_medium the same, but update to utm_campaign=Spring_2012.

With this thinking, you could define a set of values for all the e-mails you send out, and create a system that would help you know what those values should be when you introduce new online publications.

I’m sure that other people and companies have come up with their own approaches to using these utm_* values.

I’m curious, does anyone else have different ideas or examples to share?

Kanban/Lean manufacturing makes sense for factories. I'm not sure how well it translates to web and software development.

Kanban is a balm now being used by some Agile development teams to soothe the pain caused by timeboxed development cycles. Jeff Patton’s statement, “Short timeboxes herniate,” sums up that pain (from his excellent post “Kanban development oversimplified”). As a Product Owner with a team that started out using Scrum and has gradually drifted to something else, I identified with all those critiques of timeboxed development.

Management expected the team to deliver user stories every week because our iterations were week-long. So when the team realized at mid-week that they wouldn’t be able to deliver a story by Friday, the team would pick up a small bug to fix just to show something by week’s end. That’s a problem. As a Product Owner I saw this mid-week “save” for the sprint review as pure distraction from more important work. So we dropped the weekly delivery requirement.

When I read Jeff’s article, I realized that the way we were working looked more like Kanban than it did Scrum—except we were still using Scrum words and concepts to discuss and analyze our work. Words like “iteration”, “sprint”, “daily scrum” no longer fit.

As a team, we had let go of the expectations of a sprint, and we were still delivering great value, just on a more natural timetable. I believe our efficiency stepped up when we ceased adhering to the rules of Scrum.

However, because we still spoke in Scrum phrases, our company had not followed-suit. Frankly, without a name and model for what we were doing, we weren’t sure ourselves.

Months have passed since then, and some Kanban ideas have seeped in to our work. But we haven’t embraced any change, really.

Why change? Despite the problems I’ve alluded to, the team is really doing great work. They are delivering value to the company and its customers. So one argument is to simply continue on our course. The other is that we’re already practically doing Kanban, so why not start using words and tools that match?

In my brief review of Kanban, I see that it comes from the Lean Manufacturing philosophy. How it is being used in the Agile world is really taking Kanban as a metaphor. It is adapting a model from the manufacturing world and applying it to the software development world. I’m naturally wary, and so want to critique this adaptation for the sake of clear-headedness.

First, let me admit that of all the Agile flavors, Kanban seems the most practical to me. I’m a fan. That said, software development is not an assembly line. We don’t deal with pre-designed units like car doors. Instead, we have a variety of problems and need to be able to design a system to appropriately handle whatever those problems happen to be.

Whereas Kanban works well for an assembly line that puts the cars together, software development looks a lot more like the design shop that engineers and prototypes new car concepts or revisits problems with existing cars to make them more efficient and safer for the next model year. Sure, we produce applications, but a whole lot of the work is really design work.

Design work tends to be iterative and recursive, but I don’t see words from Kanban that support iterative work. In general, a card moves from left to right across the board. Sometimes, the card ought to be killed and restarted with the  ideas we’ve learned during it’s first round. However, from what I see of the Kanban model, this just doesn’t happen. (Not that is happens in Scrum either.)

Why is that? Maybe it’s because coding is expensive and we suffer from the sunk-cost bias. That seems like flawed thinking.

Maybe, as I wrap up this half-thought-out post, I’m simply frustrated by the lack of deep design work in our projects.

More later. I’ve been thinking of the design process with insights from some recent research and articles seen via SIGCHI, and it may result in some design management postings.

Anyone else have ideas to share here?

Let’s say you had an abbreviation, like CSS, that you wanted to put into small-caps, say with a little extra tracking. You might think you could use the CSS property font-variant: small-caps, and you’d be good to go. Not so.

Here’s why. Because for small-caps to work, you need to start with lowercase letters.

However, when you’re simply typing your thoughts out before you’ve decided on small-caps for abbreviations, acronyms, etc., you probably typed those abbreviations in uppercase.

So, when you tried small-caps, it simply didn’t work. For example, see this web page from 2005 that Joe Clark wrote to test small-caps. Note how the small-caps versions are more like regular capital letters. Not cool. It makes the hack look good, which is bad.

So, here’s what you can do (and what I think browsers ought to be doing automatically anyway):

1. First apply text-transform: lowercase
2. Then apply font-variant: small-caps

That ought to do it.

Here’s a more specific example of the CSS.

abbr, acronym {
text-transform: lowercase;
font-variant: small-caps;
letter-spacing: 1px;
}

We all know the <br /> tag is used to insert a line break in HTML. But what we’ve been missing is that we were too often after something else. Let me explain.

Common reasons to use line breaks

Why would a web writer interrupt a passage of text with a forced line break? Here are a few possibilities.

• Trying to avoid an orphan
• Inserting a line break before a 2-word proper noun, like “American Airlines,” so the noun isn’t split
• Formatting content like a mailing address

The problem with line breaks (<br /> tags)

Forcing a line to break in a document that will be printed is a no-brainer. But web writing has different constraints that we shouldn’t ignore.

Copy on the web has the luxury and burden of being portable. That text can show up anywhere:

• in an e-mail message
• on some other web page
• in an RSS reader
• copied and pasted into a Tweet
• in a web browser on a mobile phone

This means that the line length you wrote your text for is simply not reliable. You need to consider how that text will show up in other places too, at unknown line lengths.

A line break may look fine on your screen, but it might look really awkward when that text appears somewhere else beyond your control.

Instead of splitting text, stick text together

Orphans

Avoid orphans especially where the text is most likely to appear, but relax. You can’t prevent them altogether.

Instead of inserting a line break, opt to rephrase the text to change the length and prevent the orphan. But realize that when that text appears elsewhere, it might just have an orphan.

You also have the option of a special white-space character called a non-breaking space. In HTML, it looks like this:  . When you put a non-breaking space between two words, those two words will always be on the same line of text.

2+ word proper nouns

If you want to be sure that “American Airlines” remains on the same line in body text, employ a sprinkle of CSS magic. In the markup, a corporate name should be contained within a span element, like this:

<span class="brand_name">American Airlines</span>

And then to make sure that those two words stay on the same line, add a line like this to your CSS file.

.brand_name {white-space: nowrap;}

That will prevent the brand name text from being split at the end of a line. Instead, both words will flip to the next line if there is not enough room for them on the current line of text.

Formatting content like mailing addresses

In this case, I’m actually okay with using <br /> tags. But, left to my own devices, I might use some different markup and some CSS instead.

Let’s say we have an address like this fictional one.

You could just put that text in an address element and use line breaks.

Or you could mark it up in the hcard microformat, and then think about styling it based on that markup. So, it might instead be coded like this.

<address class="vcard">
<span class="fn">Samuel Clemens</span>
<span class="street-address">1835 Huckleberry Row</span>
<span class="locality">Hannibal</span>,
<abbr title="Missouri" class="region">MO</abbr>
<span class="postal-code">63401</span>
</address>

And then a little bit of CSS like this would take care of the line breaks.

.vcard .fn,
.vcard .street-address{
display: block;
}

The point: we overuse line breaks because they don’t require any extra thought

Instead, let’s consider why we actually want a line break the next time we go to use one. There’s probably a better option once you realize that you don’t actually want to break a line of text, you really just want some of the text to stick together.

Jan 27, 2011 - I had the pleasure of sharing this design review method at an IxDA Lansing meeting. Here are designers practicing this method. Photocredit: Chris Bachelder.

Design reviews are so important for our work as user experience designers, but they too often fail us. Here is a model for design reviews that overcomes the problems of ego, emotion, and communication that so often get in the way of helpful feedback.

Alaina Kraus, Caitlin Potts, and I presented this process for the Jan 27, 2011 IxDA Lansing meeting.

Roles in the design review process

1. Designer
2. Facilitator (may also be a reviewer)
3. Reviewers (you’ll need at least 2, but 6 may be too many)

Step 1: Designer explains the project and design concerns

At this step the designer shows the design (on paper, on screen, a prototype, etc.) and explains to the reviewers the context of this design. The designer should also point out specific areas that she wants feedback on.

Step 2: Reviewers discuss the design

This is the part that’s going to go against your habits.

The designer steps back and withdraws from the discussion. She should use body language to exclude herself to make it harder for the reviewers to address her. She should instead focus on her listening and note-taking.

Meanwhile, the reviewers are discussing the design amongst themselves. Instead of referring to the designer, they should refer to the design. Instead of talking to the designer, they should talk to each other.

Of course, the reviewers should point out good aspects of the design as well as discuss areas that they’d like to see improved.

By intentionally excluding the designer from this conversation, the dialogue can cover more ground and the feedback can be more honest. Otherwise, the dialogue has a good chance of focusing on a single point or so as the designer begins to explain or defend her decisions. That will derail good feedback, and everyone loses out on good information. People’s feelings are also at risk.

Step 3: The designer rejoins the conversation.

Finally, once the facilitator has determined the design has been discussed enough, he will invite the designer back into the discussion.

The designer can now summarize the notes she has taken in order to give the reviewers the opportunity to catch any misinterpretations. She can also ask follow up questions to clarify feedback she may not have fully understood.

The designer will probably want to defend the work or explain it, but really doesn’t have to. The goal is feedback for her, and at this point, she has it.

Why this method works

This method works because it makes it okay for the designer to simply listen in without feeling a need to defend her work. Likewise, it frees up the reviewers to not have to worry about hurting the designer’s feelings or fear the reaction of feedback taken poorly. While the method may feel a little awkward at first, after a few times it becomes easier.

What kinds of feedback make sense?

The reviewers should provide feedback that matches the fidelity of the design. This is to say, if it’s a rough sketch or task flow diagram, talking about pixel-perfect alignment of the layout is inappropriate. This should be obvious to most of us.

Also, instead of simply presenting your opinion about a design, discuss it in terms of usability heuristics (Nielsen’s list of 10, Tognazzini’s 1st principles document), accessibility concerns, visual design principles (e.g., proximity, alignment, repetition, contrast), and your observations from usability tests.

Where did this method come from?

In the mid-90s I worked at the Michigan State University Writing Center, and we used a similar process that we called the “fishbowl” to teach people to do peer-review writing workshops. In many ways, writing and designing are similar. When I started doing more design work, I recalled this process and adapted it to design reviews. It seems to work great. I credit learning this method from Dr. Sharon Thomas and Dr. Laura Julier of Michigan State University.

Update Feb 26, 2011: Wordcast live on Design Critique

Tim Keirnan over at the Design Critique podcast posted an interview we did on this process. Check it out! And thanks, Tim, for inviting me.

Update July 14, 2011: Michigan UPA workshop

This evening Alaina, Caitlin and I ran this workshop for a Michigan UPA event in Lansing. We had fun and it sounded like the attendees enjoyed themselves while learning this model. Thanks again Second Gear Coworking for letting us use your excellent venue!

1. Analysis
2. Synthesis
3. Evaluation

Diagramming these activities

They also provide some models for conceiving of these three activities, from linear to finally advising on a traditional equally-weighted 3-circle Venn diagram.

I like the thinking, and the clear reclassifying of design as including all of these activities, as opposed to only synthesis. However, their Venn diagram leaves direction out of the picture. I like this approach better.

This model simply adds the arrows to what Lewandowski and Dilworth provided. It’s simple, but serves to organize the concepts.

Working together isn’t always simple

In addition, the authors recommend involving analysts in synthesis activities, and designers and developers in analysis activities. This, I agree, is good advice, but they didn’t provide any techniques to help you actually pull this off.

Analysis, synthesis, and evaluation each require different types of thinking, and a person specialized in, say, analysis may end up stepping on the toes of the people specialized in synthesis. The result may be a stunted synthesis activity, shut down because an analyst broke down the problem again before a designer or developer had a real chance to synthesize the ideas into various solutions.

To avoid these types of problems, creating intentional design (be they analysis, synthesis, or evaluation) sessions is important.

Setting up design facilitation sessions

I’ve been listening lately to some lectures by Professor Michael Roberto, and in them he’s advised what he calls the 4-Cs of encouraging real ideas in a debate. Roberto is focused on strategic decision making, but I think we can learn from this advice and apply similar thinking to how to set up design facilitation sessions.

1. Composition – of group, who should be invited
2. Context – Atmosphere, shared norms, ground rules, location
3. Communication – How will we discuss and exchange views? E.g., subgroups, devil’s advocates.
4. Control the process – Will I as leader be in the room? Do I ask for a packaged solution or do I ask to see a debate.

You might think this is over-thinking it all. Just put the people in the same room and have them discuss the design, and good things should happen right? Maybe. But why gamble? Even 10 minutes of planning a design session based on these 4-Cs could turn a waste of time into a breakthrough design session.

Credit where it is due: James Walker’s post on how to set up self-signed certificates for e-mail with OS 10.4. His post gave me a few steps to follow that I’m  just updating here to match what is needed for Mac OS 10.6.

Create your certificate

Open up Keychain Access. This is an application in your Applications/Utilities directory. (It is faster to just hit command+spacebar to open Spotlight, then enter keych, and hit the enter key when Keychain Access appears highlighted.)

Click on the Keychain Access menu, hover over the Certificate Assistant option, and then select Create a Certificate….

Here are a few details to note about the Create  Your Certificate options.

• You might want to add an e-mail descriptor to the name field. E.g., Davin Granroth (gmail).
• Go with Self-Signed Root and S/MIME (Email).
• By default, the certificate will be valid for a year. If you want to extend that a bit, you need to check the Let me override defaults checkbox. You’ll get to make changes after you click the Continue button.
• If you need a certificate for your non-primary e-mail account, you’ll need to check the Let me override defaults box for that too.

If you checked the override box, you’ll eventually see a series of Extension windows. Just go with the default values. Apple figures out what you need based on the first screen where you chose the certificate type.

Continue and you’ll see a window with your new certificate information in it. Congratulations!

Now if you could only trust that certificate.

Trusting your certificate

If you haven’t already, click the Done button to close that Certificate Assistant window. Now, back in Keychain Access, click on the My Certificates category on the right of the main Keychain Access window.

You’ll see your new certificate listed with a little white X in a red circle on the icon. That indicates the certificate is not trusted. Double-click on the certificate, and a new window will open with details of the certificate.

Near the top of that window you’ll notice the word Trust with a little triangle to the left of it. Click the triangle to twist open the Trust options.

In the When using this certificate select list, select Always Trust. Then close that window. You’ll be prompted for your administrator password. Enter it, and you should be all set. Your new certificate should now be trusted.

Sending signed or encrypted e-mails

At this point, if you restart Apple Mail, you’ll notice a new option available when you compose a message.

The check icon indicates that your signed certificate will be included in the message. Once you've exchanged signed certs with your recipient, you'll be able to exchange S/MIME encrypted messages.

For more on exchanging signed or encrypted e-mails, see James Walker’s article. Scroll down to the section on Exchanging Signed or Encrypted E-mail.

Why would you want to send encrypted e-mails?

Hah! “Why wouldn’t you want to,” is the better question. Actually, if you send or receive sensitive information like usernames and passwords, legal information, or confidential business information, you might really want to consider this.

The trick is getting the person you exchange these messages with to also set up S/MIME on their end of the e-mail.

So after I upgraded this blog to WordPress 3.01′s Twenty Ten theme, I was mildly irritated to find that I had a few validation errors. I viewed the source code to investigate the offending lines of code, and noted that the code the validator cited was not in the source.

This phantom code led me to suspect that DOM scripting from a plugin caused the errors by inserting more code into the markup. That was it, and this evening I finally took the time to track it down. Here’s the scoop.

First, the phantom code that broke validation

The error indicates an empty target attribute. It turned out, this code was inserted by a plugin.

Honestly, the first time I saw this error message, I didn’t notice the error text that pointed to the target attribute. No, I was first startled by a pattern that looked to me like the tail-end of Javascript code used in an anchor’s href or onclick attribute. I was startled because, having already looked through the code, I thought I would’ve noticed that pattern, since it is one that I avoid.

Where was this code? Well, all 9 errors were in the same area of code: links to other websites (blogroll) in the sidebar. I wanted to see it for myself, so I opened the page and viewed the source code. I used the Find command and pasted in some of the code from the validator error message, but the Find came up empty-handed.

While the offending code was not in the served markup, the validator was certainly picking it up, so I went back to the validator to examine that code in more detail.

Code with an onclick Javascript snippet inserted for Google Analytics tracking. Note the target attribute.

The value of the onclick attribute was the immediate tell for where this code came from. It was the Google Analytics plugin I’m using.

Investigating the plugin that caused the validation error

Google Analytics for WordPress is a fantastic plugin. It makes integrating Google Analytics easy, and it has some excellent advanced settings.

One setting is to track outbound clicks and downloads as events so they are are viewable in Google Analytics.

Checkbox to track outbound links in WordPress.

To test the theory, I unchecked that box, saved the settings, and revalidated the web page.

It passed with flying colors.

Validation error identified, but I’m actually curious about tracking downloads

For the time being, I’m okay with leaving that feature turned off. I’ll let the plugin author know about it and hope the problem will be resolved soon.

Yes, I lose a feature to get back to valid code. Perhaps there is a support group for this kind of behavior.

But in my defense, this is just a personal site. I don’t make any money on it, and my interest in tracking downloads is just curiosity. I only have a few downloads or outbound links I’m interested in, and I have nothing riding on that knowledge beyond satisfied curiosity.

Still, the entirety of this problem can be laid to rest on a simple, meddlesome, and empty target="" attribute. That’s irritating.

Richard Saul Wurman, author of “Information Architects” and founder of the TED conference, spoke at the Cooper-Hewitt National Design Museum‘s “Why Design Now” event. This is that talk.

Wurman emphasizes that so much is designed, even the questions that we ask. To illustrate, at one point he asked Bill Moggridge, who was attending as the new director of the Cooper-Hewitt, how old he is. Bill answered the question, and Wurman pointed out, “Now we all know your age, but you know nothing new.” His point is that the power is in the question, not the answer.

That is worth ruminating on. From a design perspective, coming up with good questions to understand a problem is often difficult. It takes dialogue and exploration and work before you get to the good questions. And then you begin to understand the problem better. Wurman also points out in this talk that organizations too often jump to action before they really understand the problem.

Wurman packs a lot, including some humor, into this short talk. It’s worth watching.

I found out that they were a little shorthanded on specialized web help, so I  volunteered to assist. Pabini Gabriel-Petit, the publisher and editor-in-chief, graciously accepted my offer.

Creating print CSS is usually simpler than web page layouts, because the goal is typically to have the content of the page print out well on standard size paper. Multiple columns and site navigation are usually uncalled for.

My first try was to revise the existing print CSS file. After half an hour at that, I decided it would be simpler to start from scratch. The original print CSS was quite complex, and it seemed I was searching for one issue: why did the pages stop printing after page 1?

So I rewrote the CSS, simplifying the CSS code greatly. I had the layout in good shape, but oddly still had the 1 page issue.

I went back to the main screen CSS file and begin sifting through it, looking for clues. Then on a hunch, I found the issue.

The global CSS file is thick. There’s a ton going on there to defend against various cross browser issues. One particular rule I saw repeatedly was the use of overflow: hidden. That rule is used for a few reasons, but one of them is to force a floated box (div or what have you) to expand when it wants to collapse, vertically. This allows things like backgrounds to show through properly.

One of the selectors that this rule was used on was actually a wrapper for much of the page content. It made sense to me, in a way, that this could confound a browser into hiding paged content that went beyond a page.

So the real key to the much simpler CSS file was to add in an overflow: visible to a large set of selectors to override that overflow: hidden for printed pages.

I sent Pabini the new code, and over the following weeks she tested it and added some details I had missed. About a month ago she deployed the new print CSS code  to the website.

This little evening project was a fun puzzle, and I’m glad I was able to help make such great content on the UXmatters website print out better for more people.

(Back in 2002 or 2003, I forget when, I wrote an article on print styling for web pages.)

Presentation overview

Dan’s presentation was both informative and controversial. He provided some nice background on the naming of the field of information architecture, citing Richard Saul Wurman phrasings at the 1976 AIA convention in Philadelphia and then Wurman’s book “Information Architects.”

Dan also proposed a way of considering what information architecture is through a target diagram, from core to outside as:

1. Ontology (the study of being)
2. Taxonomy (the science of order or arrangement)
3. Choreography (writing/describing circular dance)

I like this description of IA. I do feel it gets to the heart of the work, and I can immediately consider certain areas of my own job in this light. Of course there are plenty of other descriptions of IA from Wurman, Rosenfeld, Morville, and others, but as I bring them to mind, they seem to be more focused on describing IA to outsiders whereas this one speaks to those of us already  in the field.

I wouldn’t, for instance, walk up to a client and say, “I’m concerned with the ontology of your system.” But I can talk with other information architects about questions of ontology, and they will likely bring their own experiences to bear.

After discussing this model for IA and how it circles the concept of understanding, Dan shared two ways to answer the question “How do we know when IA is good?”

• performance (need to measure change in performance from a benchmark)
• propriety (how appropriate to the context is the IA solution)

When discussing this question of quality of IA, the point was made that a functional, adequate solution is artless. It is insufficient. We’ve all used a website or service that we end up getting irritated with, and could comment afterward “Well at least it worked.” Good IA goes beyond sheer performance to fulfill propriety as well.

Isn’t naming always controversial?

The controversial part of Dan’s presentation is in the naming of things. The gist of my issue is that I felt Dan was saying that strategic-level IA work—the work that involves not just end-users but is concerned with larger business concerns—is beyond the scope of user experience work. (I really hope I’m not misrepresenting Dan’s meaning.)

My experience as a UX professional (note that I used to refer to myself as an information architect) says that UX begins with understanding both user and business needs, and is best done when exploring the strategic-level in order to frame the tactical work.

That said, I will say that with all the work demanded of UX in my job, I regret that I haven’t had the time to devote to a more traditional strategic IA-based analysis of our systems.

Dan made the point that this strategic work, though done by a smaller group, has greater leverage than choosing which style of form field to use. He is right, of course. I just think that that work is still to be done under the UX umbrella.

Thanks Dan for the talk, and Chris Bachelder for bringing it together

All-in-all, I’m really glad I had this opportunity to take part in Dan Klyn’s presentation. It was well-done and thought-provoking. Dan has shared his slides for “The Nature of Information Architecture.”

IxDA Lansing is the first Michigan group of the Interaction Design Association, and was initiated by Chris Bachelder of Techsmith Corp. I, for one, am grateful to have a Lansing-based group to advance UX events. Thanks Chris!

Stopwatch graphic by Casey Marshall

Recently, I watched a series of people observe informal usability tests.

Two of the observers have recently graduated with Masters degrees in HCI or an adjacent field.

Both recent graduates used a watch to record time-on-task and completion of the task. One actually broke out a stopwatch while the other referred to his wristwatch.

While these stopwatch fixations livened my day, I do wonder about graduate education in the usability field.

I recall that for the first half-dozen website usability tests that I moderated, I also recorded time. Then I realized that timing tasks obscured more important observations, and I haven’t bothered with timing since then. Besides, we can get times off the recordings.

Is the working world really that far off from graduate studies?

So why did these two graduates pull out timers?

Well, I think they were parroting “proper” methods they were taught without understanding when it is useful. If, in grad school, they only practice for ideal research situations, they’re missing out on the realities of the work world.

I’ve worked in an Agile development environment for the last couple years, and for the decade prior to that I worked on fast-moving projects that used whatever SDL I applied to them. The mission: Deliver value, ASAP.

With that charge, decisions are made that don’t allow for insight from in-depth, long-term studies with huge numbers of participants. I’m grateful for even the small, quick sessions of user and design research.

Regardless, I got a chuckle out of seeing these two bring out timers for a completely informal, one-off usability test. As expected, they both missed seeing key interactions because they were watching the clock.

When to be concerned about time, usability-wise

Okay, I’d hate to give the impression that time doesn’t matter. I just find that a long time to complete a task on a website is rarely the issue, instead it may be a symptom of other issues which become apparent during research.

However, I do find response times of a system to a user’s actions to be very important because too much delay in a system’s response can really hurt the user’s experience and even distract people from completing whatever they set out to complete. Still, this class of problem is often noticeable during observation. (Unless you missed it while you were fiddling with your stopwatch.)

With that in mind, I’ll gesture towards Nielsen’s take on response times.

Home page of Newsweek.com, May 31, 2010

I don’t know when it happened, exactly, but Newseek.com was recently redesigned. There is so much to say about it, and it is mostly good.

I’ll start with the most obvious: the design.

In short, the home page is easy to scan. There is a clear visual hierarchy. The lead photos and articles have been spot-on for Memorial Day news items, and the clarity of the layout made certain I couldn’t miss them.

The article pages are easy to read and keep enough of the patterns, like the byline and publication date, that it’s easy to figure out what’s what.

My biggest complaint is one that they no doubt haven’t figured out how to get rid of yet: the banner ads.

There’s more talk about the visuals for the new newsweek.com at nymag.com. I won’t go on about that, myself, other than to say, gee, it looks like a professional blog. Oddly, that’s a compliment.

Now let’s look at the markup.

Newsweek.com's namespaces point to interesting uses of meta data.

I’ve had a penchant for information architecture since the late 1990s, and about the first thing I noticed when glancing at the markup for the home page is the references to the Dublin Core meta data definitions and other meta data sets.

I was suddenly intrigued. Good use of meta data is sadly absent in many large-scale websites, and it’s really great to see an effort to play the game for real.

So, at a quick glance through the markup you’ll notice some unusual pieces, first this:
data-track="{'title':'stories being discussed'}", which is an attribute with a value that looks a bit like JSON.

I admit to being behind the times with studying HTML 5, but that attribute spurred my suspicion that this page was using HTML 5. I stopped wondering a few lines later when I spotted an article element, followed soon thereafter by a header element, and a nav element sporting an attribute of role="navigation". Whoa. Newsweek jumped right in.

So what about the meta data? Well, I can’t really know what they’re actually doing, but here is an observation. In a sidebar, they have a list of quotes. Each quote is marked up as a blockquote with an id attribute. Following each quote is a span with attributes like property="dc:creator" and about="#q1". The about attribute refers to the id of the blockquote in question. The content of that span itself is the name of the quoted person, plus which publication the quote came from.

Pretty cool idea: internal markup references like this can build relationships into the content. It could provide some interesting opportunities for parsing later on. Yeah, that’s right, the semantic web.

The problem with this all is…it’s half-baked!

Newsweek.com used "http-equiv" when they needed "name". Oops.

That list of quotes with the ID attributes? All that meta data is duplicated and thereby meaningless! Further, why use a span element when they could have used a cite element? More semantic and those attributes would’ve played as well. Gah!

And back at the top of the markup by those meta data namespace references there is another set of meta tag elements which are sadly marked up incorrectly.

There is a stack of 5 meta elements that use the http-equiv attribute when they should have used the name attribute. I’ll bet whoever coded that knows the difference, but I wonder if they were rushed to get this version out. It feels like a beta.

They are so close to providing some really great examples of meta data use in HTML 5! I hope they release another version soon that gets more precise and cleans up some of this code.

View from top of Yerbe Buena Gardens, San Francisco, March 2010.

Saturday PM: Sunshine!

I actually began to sweat under my blazer from the warm sun shining brightly through the window.

I had arrived in San Francisco a little early on Saturday, dropped my suitcase off at the Intercontinental Hotel, and walked around the corner to a sandwich shop for a bite to eat and to get online. As I draped my coat over the back of the chair, I decided I really like San Francisco. It’s the sun, I admit it. Oh, and I had already noted that the two billboards I noticed on the taxi from the airport were pure tech: one for an enterprise search system and another for PGP. Billboards talking to me? Amazing.

After settling in at the hotel, I had dinner with my old colleague Chris Burley and his girfriend at a nice Italian restaurant. Chris is awesome. I love talking with him because he has such passion for what he does, which currently is to help lead efforts like urban farming in the Bay area.

Sunday AM: 3 good things

The next morning I woke early due to the time zone difference, and I had three excellent experiences:

1. In the aching fog of caffeine deprivation, had the best cup of coffee of my life, thanks to the Blue Bottle Café. (I admit, I ordered a second cup to go.)
2. Paused in the Yerbe Buena Gardens where some elderly practiced tai chi and parents snapped photos as their little children hid behind a waterfall. I stood on a bridge and watched the morning sun ripple on the glass of San Francisco skyscrapers.
3. Crashed a church service at a music venue called Mezzanine put on by a group that calls itself IKON. I was the oldest person there, amidst a crowd of art school students. We sang, we listened to a teaching from the Word, we had communion. It was good.

Sunday PM: MX day 1

Sunday afternoon saw the start of the 2010 MX Conference.

MX2010 is largely focused on managing user experience and less on the tactical end of UX practice, and there were some thought-provoking presentations from people who have been managing user experience for a number of years, in a number of different types of companies. Off the top of my head, presenters represented firms in financial industries (Vanguard), publishing (Harvard Business Review), retail sporting goods, and online media (Youtube).

The series of talks was fantastic, and was kicked off with a keynote by Jared Spool in which he shared insights like that Gallup’s Customer Engagement (CE11) metric has high correlation to the quality of user experience. Spool’s keynote actually turned out to predict some themes that carried throughout the many presentations. Among them were the importance of establishing a vision for user experience and that experience ultimately must be addressed well across multiple channels (web, mobile, physical space, etc.).

Spool talked about three core attributes necessary for great user experience: Vision, Feedback, and Culture. He posed three questions that UX managers should ask.

1. VISION: Can everyone on the team describe the experience of using your design 5 years from now?
2. FEEDBACK: In the last six weeks have you spent more than two hours watching someone use your design or a competitor’s design?
3. CULTURE: In the last six weeks have you rewarded a team member for creating a major design failure?

After the conference reception, I wound down the evening by taking a walk around a few blocks and ending at a nearby bar. I ate a burger and watched the Academy Awards for a while. Back at the hotel I watched the end of a Clint Eastwood Western flick and fell asleep.

Monday AM+PM: MX day 2

I woke at 4 in the morning. I checked analytics, email, and my usual RSS feeds. I stretched, washed, dressed, and still had time to kill. I read a few chapters in The Shack, a book Adam gave me last week.

I chatted throughout the day with Haakon, a usability specialist attending from the design company Tarantell in Norway, and as he sipped his coffee, I decided to not mention my mere three hour time difference.

The rest of the day was another series of excellent presentations. Themes: customer (more than user) experience, vision that guides the business, new models for working in the network, UX leadership stories from Youtube, customer experience in renovation of thinking at Harvard Business Review Online, understanding the holistic customer, data-driven design decisions (and when not to rely on data for design decisions), experience design as business strategy, and operating as a chief experience officer in your company.

It was great to hear first-hand the stories from these user experience leaders. Now, for what to do with it all when returning to the office.

Tomorrow and then

Tomorrow morning I fly back to Michigan, and need to get my head back into product owner and user experience work. But I also need to hold onto the ideas from this conference, and shift into actively leading user (or is that customer) experience work at Covenant Eyes.