I have a pretty stable way of tagging items in my bookmark library. This is by no means totally complete, but it serves me well.

• Use only singular tense as a rule (”artist” rather than “artists”)
• Separate phrases into their roots (”interaction” and “design” rather than “interactiondesign”). This helps me generalize searches (just “design”) while also promoting tag intersections (”interaction” + “design”).
• Use generic modifiers (”research”, “tools” and “*”) for subdividing later through intersections.
• Refactor tags every few months. I’m only human and my tags get out of kilter after a while, which reduces the findability of the links. I try to stem tags and remove niche ones.
• Use action phrases like “toread” and “towatch” to cull out those things I need to take action on.

Of course, this system is tuned just for me. I don’t expect anyone else to benefit from this, even if the system might be fairly usable by other people. For more information on this, see my earlier post “Tagging is Selfish.”

Universal Access is designed as an accessibility tool for disabled users. But I’ve co-opted it as a way to get a tan while still catching up on work. Here’s what to do:

1. Turn on Universal Access. Go to System Preferences > Universal Access. Under Seeing > Display, click the radio button “White on Black.” This inverts the screen’s chroma and keeps it from getting washed out.
2. Upsize your cursor. Under Mouse and Trackpad, crank up your cursor size so you don’t lose it. Because you will.
3. Zoom the Display. Text still kind of small and hard to read, no? Now you need to zoom the display. Hold down Control and do a two-fingered swipe up. This embiggens things. Zoom out by doing the opposite. (If the constantly panning display makes you seasick, you can change this in Universal Access > Seeing > Zoom > Options.)
4. Use Spaces: Resizing windows can be a chore. I use Spaces and put each window in a separate virtual display. Moving between them is a keystroke away: Control + arrow pad.
5. Learn Keyboard Commands: You should be doing this anyway, but if you’re not, here are a few good ones to get your started:
• Switch between apps: Command + Tab. Use the left and right arrows to cycle between the running apps.
• Access the Safari / Firefox address bar: Command + L
• Access the search bar (Firefox): Command + K
• Scroll the page down/ up: Spacebar / Shift-Spacebar, respectively.
• Go back in Safari / Firefox: Delete
6. Did you remember to put on sunscreen? Rub the lotion on the skin.

1. Making sure designs provide enough space to accommodate the players
2. Testing CMSes to make sure they don’t blow up when someone uses the Big YouTube player

Below I’ve pasted the result. You can grab the latest code for this from GitHub: http://github.com/oombrella/video-embed-test-sizes/tree/master

YouTube (320 x 265)

Youtube (425 x 344)

Youtube (480 x 325)

Youtube (640 x 505)

Vimeo (400 x 225 but configurable)

Wilderness - South Africa 2009 from Michael Grabner on Vimeo.

Viddler large (437 x 392)

Viddler standard (437 x 288)

Photobucket (448 x 361)

Succinctly, to elicit a certain behavior you can manipulate the environmental variables. People are who they are and it’s hard to coerce them in to behaving a certain way.

When I wrote that original post, I was thinking mostly about functionality. You can change the features you offer, such that you can channel people’s behavior. If a certain behavior is desirable, then build out tools to support it. But is that enough?

On a recent project, I was thinking about how to subtly encourage people to complete an action. The behavior we wanted was engagement: reading content on a site and completing certain activities. Drawing from patterns used on LinkedIn and online dating sites, we settled on a progress bar to encourage certain types of interaction. Surprisingly enough, knowing that you’re “incomplete” is an incentive to perform the next suggested action. This is especially true if that action substantially changes the completeness.

But the progress bar is a bit cold. It unemotionally calculates the height of a bar based on elementary math. So I started thinking. People tend to have a unique attraction to faces. You see this in eye tracking studies. What if the progress bar was humanized a bit?

Below are four comparisons of the same data. The first is the pure math, where completeness is expressed as a percentage. The second is a typical thermometer, which shows the completion differential. The third and fourth make this a bit more human. The third simply adds features, giving it more personality and expressive qualities. The fourth takes a static image and brings it out of the blur and into clarity.

With the last two, you lose a bit of the differential–i.e. your degree of completeness. But in the process, I think, you gain something a bit more humane and ludic.

What do you think?

Just for fun, I thought I’d see what Twitter might look like if it exposed some of the more commonly used features directly in the interface. Things like:

• messaging users both public and private
• providing a URL minification service
• allowing image attachments
• retweeting
• scheduling future tweets
• specifying hashtags

While I was at it, I figured that I’d throw in some more flair. So I:

• Abandoned the 140 character limit
• Let people favorite tweets
• Threw in a social bookmarking widget for good luck.

So, I present to you, the Extra Happy Twitterlicious Bonanza 2.0. It’s designed to make Twittering as much fun as doing your taxes. Enjoy!

Note: the redesign is a parody. I’m quite aware there are obvious IxD problems.

What I’m about to say might be be considered treason, seeing as how I’m writing this on Field Notes. But I’m throwing it out there to open discussion.

What would happen if companies simply took their marketing dollars and reinvested them in their business?

What would happen if…

• an online retailer on-shored their call centers and hired more phone reps?
• a car insurance company used the funds to lower rates and pay more claims without hassle?
• a product company applied the funds to improving their product?
• a mutual fund paid its customers back in lower maintenance fees?

The scenarios above are somewhat fictitious. But the funny thing is, some similar companies exist. And some of them are pretty successful too. American Funds is one of the largest mutual fund companies with a commitment to low management costs. Zappos.com is a star retailer with a world-class call center and return policy (and one whose 800 number is easy to find!).

Now, their success cannot be solely attributed to a small marketing footprint–but their decision to forgo these costs is not trivial either. So would this strategy be good for companies?

Proponents might argue that this is a good thing. Why not use the money to make a better product, improve the experience, or differentiate on price? Surely, the resulting goodwill and word-of-mouth would step in for the formal messaging.

But would it? Detractors might say such efforts are doomed to being unnoticed. They might argue that companies like Zappos are edge cases. Or there might be differences in business models that make such a proposition implausible.

What do you think?

I have my own opinion, but I want to hear yours. Is redirecting marketing dollars back into the business a good thing? What do you lose in the process?

The problem is that these were added after the fact–and that they were designed for the static Web. It comes with it a number of problems.

• Custom components are common. You can make a thumb-slider out of a set of DIVs and some images, for example. But the only elements that are natively navigable through the keyboard are links and form elements.
• In-page state changes, such as AJAX updates are also common. To assistive technology users, however, it can be difficult or impossible to determine what has changed on a page.

Enter WAI-ARIA

Web Accessibility Initiative’s Accessible Rich Internet Applications (WAI-ARIA) is a specification designed to provide better hooks for assistive technology devices. To Web developers, it’s a set of attributes that bolt on to the HTML elements you know and love.

These attributes help you provide instructions to AT devices, such as:

• Describe what objects are, using Roles. For example, you can define how one set of DIVs is a section vs. another set of DIVs, which represents a progress bar. This helps navigability of the page by providing much-needed context.
• Describe the States of objects, like “this progress bar is at 34%.”
• Make any element keyboard focusable — or not. This overrides the tabindex attribute and allows it to be applied to any visible element. Users can tab more effectively though the areas of your page.
• Designate places on a page to receive updates and changes with Live Regions. This is kind of analogous to the yellow fade technique, which is commonly used to visually indicate a state change on an AJAX-y page.

Support Today

Support for ARIA is strong and building, with Firefox 3, Opera, WebKit / Safari, and IE 8 actively implementing this spec. Freedom Scientific’s JAWS screenreader is also building in support.

Adding ARIA attributes won’t break current pages , or obsolete old browsers from your site. It only makes inaccessible widgets more accessible. It will, however, make your pages invalid XHTML or HTML. This is because those namespaces do not acknowledge these new attributes. HTML 5 is expected to include these, whenever it comes out. Nonetheless, the idea of avoiding ARIA because it doesn’t validate is a weak argument.

If you’re designing a site that you expect will receive traffic from visually impaired users, it makes sense to check out ARIA.

In this lurch-y adolescence, they began looking to big businesses for organizational and management models. Processes and structure were put in place. Two governance panels were created. A 16 step release process was enacted.

All of this was designed to to instill greater quality and help Meetup handle its growing pains. Yet the opposite occurred. Releases of new functionality to Meetup.com were stalled. People were at each other’s throats. They were becoming less responsive to their customers. Employee morale tanked.

So began “What happens when your give employees 100% instead of 20% time?“, a panel hosted by two of the brass from Meetup.com at SXSW09 . What continued over the next hour was incredibly compelling. In the next few paragraphs, I’ll recap what I heard.

Confronting the problem.

To confront the problem, executive management convened a two week marathon meeting. The goal was to walk out with a plan to reclaim the spirit of Meetup’s beginnings. For two weeks they deliberated and, at the end, they walked out without an answer.

But coming out totally empty-handed wasn’t doable. The execs decided they would stall for a bit longer. To the staff, they announced that all work on Meetup would cease. In its place, they would hold a six week hackathon.

The Hackathon.

The hackathon was simple. Any employee could work on whatever they wanted–given three basic rules.

1. Your project had to help out the Meetup community. This limited off-strategy projects.
2. You had to convince three other people to work on this with you. This limited pet projects.
3. You had to impress your team. This encouraged cool ideas.

Employees could also volunteer to work on any project suggested by their peers.

After presenting this plan to the staff, management excused themselves from the discussions. After less than an hour, ideas were flowing and groups forming. Over the next six weeks, teams collected and commandeered board rooms. People moved desks. Titles and seniority were cast away. In their place, people began to organize based on who was best able to execute their piece of the project.

At the end of the hackathon, lots of projects were in flight and making progress. Nothing was released yet, but the volume and quality of work accomplished was staggering. But sensing the end, employees started asking questions about what was next. Would they revert back to their old norms?

The honeymoon is over…or is it?

In the six weeks, there was little solid direction on how Meetup would be run in the future. The management team looked back at the hackathon. A lot of work had been done to date. Could the business keep working like this?

The team drew up five pages–on 8 pt type–of reasons why it wouldn’t work. “How do you measure and reward employees?” “How do you keep on strategy?” “How do you get VC funds when you have no real roadmap?” These were all questions with no answer.

Out of these five pages though, the realized most were edge cases. If they could handle these as they occurred–rather than being prematurely defensive–this might work.

100% time.

At Google, those in engineering roles get 20% of their time to devote to projects they personally want to do. At Meetup, the idea is 100% time. Employees both propose and self-select the projects they want to work on. Teams form and disband based on what interests their members.

Teams can choose whatever methodology they want to work in: agile, waterfall, whatever. They choose how they want to manage communication. Management helps in setting goals and holding people accountable, but the freedom for day-to-day execution rests solely in the hands of those in the trenches.

Where they’re at.

The speakers were very quick (and humble) to point out they had only been at this for about 18 months. They didn’t know how it would scale. There are some product consistency issues. Performance management is still a bit nebulous.

But the side effect is that employee morale has improved. They’re more responsive to their customers. The Meetup.com product, they believe, is better overall.

What’s your take?

Let’s hear your opinions in the comments below.

One of the hardest parts about user research and analysis is controlling for lying users. It’s not that users try to be deceitful. But there are many reasons why they may not be telling you the truth. Here are four:

Need to represent themselves.

Users may lie about choices they have made in the past because the truth reflects negatively on their self image. For example, a user may state they purchased an iPod because of it’s ease-of-use, when the real reason was that they felt buying a SanDisk MP3 player would mark them as less hip.

For this phenomenon, a best practice is to probe further until you can get specific information about what influenced the decision.

Inability to forecast future actions.

People are notoriously bad predictors of how they will behave in the future. They expect their future behavior to be markedly different than what past behavior suggests. Similarly, their ability to recall previous actions degrades over time. For example, a user may say that they really want a customization feature. If you ask them to recall customizing a similar feature in the past 6 months, the answer is often very different. In both cases, the further you get away from the present, the rosier the glasses become.

A tip for handling this situation is to follow questions that speculate about behavior with “grounding” questions that ask them to recall behaving like this in the past.

Fear of insulting the moderator.

Simply to avoid being critical or confrontational, users will often not truly confess dissatisfaction with a product. Not wanting to hurt the feelings of the researcher is a common unspoken issue.

At the onset of research, the researcher should explicitly distance himself from the design, saying something like “Be candid. I’m not the designer, so nothing you can say will hurt my feelings.”

Fear of looking uncreative.

This happens often in sessions where you simply ask the user to rattle off features they would like. Often, users base their responses on those they already know exist–rather than suggesting features that solve real problems they face. For example, you may hear “I’d like the page to be customizable like iGoogle” when they have no precedent of customizing pages.

For this situation, it’s ok to solicit features but make this a low-priority research tactic. Instead, focus on the actual challenges they face, agnostic of a solution.

Wrap up

These are just four of the many reasons users lie to researchers. The message is this: when doing research, consider the answers they give but be cautious and critical. Don’t take any self-reported information too seriously, since they are easily tainted. Where you expect there to be lying bias, probe for detail and past history to validate their responses.