Code Crunch

Design Meets Research

2012-01-10T12:25:00.001+08:00

via aiga.org

The "Java Life" Rap Music Video

2012-01-06T11:12:00.001+08:00

via youtube.com

The KJ-Technique: A Group Process for Establishing Priorities

2012-01-04T15:37:00.001+08:00

The KJ-Technique: A Group Process for Establishing Priorities

By Jared M. Spool

Originally published: May 11, 2004

Back in the late 1970’s, the US government commissioned a study to look at effective group decision making. In the study, they asked 30 military experts to study intelligence data and try to construct the enemy’s troop movements.

Each expert analyzed the data and compiled a report. The commission then “scored” each report on how well it reported the actual troop movements. They found that the average military expert only got 7 out of a 100 elements correct.

Each expert then reviewed all of the other experts’ reports and rewrote their initial assessment. The average accuracy for these revised reports was 79 out of a 100.

What was different between the first report and the second? The experts didn’t have any new information. All they had were the perspectives of the other experts. When they added those perspectives to their own, their accuracy increased ten-fold.

Deriving Priorities When Resources are Limited

In design, our resources are limited. Priorities become a necessity. We need to ensure we are working on the most important parts of the problem. How do we assess what is most important?

In our consulting work, we’ve found that, like the military experts, our clients usually have most of the answers already in their own organization. The trick is to get all the people with the right perspectives to reach consensus quickly.

For this, we’ve turned to a group consensus technique we’ve been using for years, called a KJ-Method (also sometimes referred to as an “affinity diagram”). The KJ-Method, named for its inventor, Jiro Kawakita (the Japanese put their last names first), allows groups to quickly reach a consensus on priorities of subjective, qualitative data.

Sometimes, we’ll be in a situation when every team member has different opinions on how we should proceed, such as identifying who the most important users are for an upcoming study. Other times, we’ll have collected tons of subjective data, such as our observations from hours of user testing. We find the KJ-Method to be very effective for organizing and prioritizing opinions and subjective data.

The Accuracy of the KJ-Technique

One of the most amazing things about the KJ-Method is how well it objectively gets groups to the top priorities. Different groups can analyze the same data and will often come to the same results.

A few years back, we conducted an experiment where we had 15 teams use the method simultaneously. Each team consisted of ten usability specialists, each from different organizations. Their goal was to take their own individual experiences and prioritize an action plan as a team. We focused the exercise around the question, “What are the biggest obstacles to producing quality products that you face in your job?”

Each person started by listing their own personal obstacles. Then, using the process, they spent approximately 40 minutes reaching consensus. By the end, we asked each team to list the top 3 items.

When we compared the all 15 teams’ results, they all had basically the same top items: Need to define requirements better; Need to understand the users better; and Need to have better communication with their design team.

It was amazing how each of these teams came to basically the same top priorities, even though they each started with individual data. We’ve repeated this experiment 3 times, always with very similar results. The KJ-Method really does work to get an objective group consensus out of a collection of subjective, opinionated data.

The KJ-Method: Step By Step

The KJ-Method is simple and easy to do. It focuses the group on the task at hand and is excellent at eliminating unnecessary discussion and distractions from the goal. It’s a tool that everyone should have in their designer’s toolbox.

We’ve got it down to an eight-step process that we can do with any size group in less than an hour. Here’s how we do it: We use two colors of removable sticky notes, such as yellow and blue. We like the standard 3x5 size or the 4x6 size, if we can get it. We need a room with a lot of wall space. Typically, a large conference room will work well. We also need a facilitator. This is a person who will move the group from one step to the next. (While a facilitator can also contribute as a group member, politics may make this less than desirable. The safe road is to have the facilitator play a neutral role.)

We’ll need a whiteboard or flipchart for the final ranking step.

Step 1: Determine a Focus Question

The focus question drives the results. Every session will have its own focus question. Sample focus questions are:

Who are our users?

What features do users need?

What goals do users have when they come to our site?

What did we learn in our usability study?

What are the biggest obstacles preventing our products from selling?

We can only work on one focus question at a time, so we pick the most important one first. (An experienced team can do two rounds of KJ’s in an hour allowing them to deal with two important questions.)

Step 2: Organize the Group

Get folks together for an hour. We want people from different parts of the organization, to get their different perspectives.

Step 3: Put Opinions (or Data) onto Sticky Notes

Putting one item on each sticky note, we ask each group participant brainstorm as many items as they can think of.

Step 4: Put Sticky Notes on the Wall

In random order, each participant puts their sticky notes up on the wall. Then, they read other people’s contributions. If, at any time, they think of something else that should go on the wall, they need to jot it down on a sticky note and add it to the collection.

Step 5: Group Similar Items

Once everyone has had a chance to add their contributions to the wall, the facilitator instructs the group to start grouping like items in another part of the room. This is what we say when we’re facilitating

“Take two items that seem like they belong together and place them in an empty portion of the wall, at least 2 feet away from any other sticky notes. Then keep moving other like items into that group.”

“Feel free to move items into groups other people create. If, when reviewing someone else’s group, it doesn’t quite make sense to you, please feel free to rearrange the items until the grouping makes sense.”

“You’re to complete this step without any discussion of the sticky notes or the groups. Every item has to be in a group, though there are likely to be a few groups with only one item.”

Notice that we’ve not allowed the group any discussion about the contents yet. We’ve found that premature discussion often focuses on borderline items -- things might be unimportant to the focus question. If they aren’t important, then spending any time discussing them is a waste.

In later steps in the process, we have time to discuss the important items. Therefore, by preventing conversation now, we save time for the important conversations later.

This step is complete when all the items are moved from the original wall into groups.

Step 6: Naming Each Group

Using the second color of sticky notes, we ask each participant to assign a name to each group. Here are the instructions we give:

“I want you to now give each group a name. Read through each group and write down a name that best represents each group on the new set of sticky notes I just gave you.”

“A name is a noun cluster, such as 'Printer Support Problems'. Please refrain from writing entire sentences.”

“As you read through each group, you may realize that the group really has two themes. Feel free to split those groups up, as appropriate.”

“You may also notice that two groups really share the same theme. In that case, you can feel free to combine the two groups into one.”

“Please give every group a name. A group can have more than one name. The only time you´re excused from giving a group a name is if someone has already used the exact words you had intended to use.”

Again, notice here that we’re not allowing the group to discuss the name. Everyone gets a chance to get their own views out, regardless of the politics and personalities involved.

This step has a hidden agenda: the final review. By insisting that everyone read every group, it forces the participants to review everything on the wall and consider it. This is critical for the next step: voting.

Step 7: Voting for the Most Important Groups

When we have finished this step, every participant will have democratically shared their opinion on the most important groups. This will be independent of any coercion amongst their peers or factors like the number of items in each group. They’ll purely use their own viewpoint to choose those groups are most important to answering the focus question.

To get through this stage quickly, we break it up into three parts. First, we have each participant grab a piece of scrap paper and write down the names of the three groups that they feel are most important.

We’ll repeat the focus question at this point, so they know which question they are answering. For example, if our focus is “What features do users need?”, we’ll give these instructions to the participants:

“On a piece of scrap paper that you will neither post nor share, I want you to write down the three names of groups that you think best answer this question: What are the most important features that users need?”

“If a group has more than one name, you are to chose the name that best represents the most important features in that group.”

Occasionally, participants will have trouble narrowing the groups to just three. We’ll often instruct the people having trouble to write down five, then cross two off. While this often produces a giggle, it turns out to be helpful to some participants.

The second part of this step happens when they have their three choices. We ask them to rank them from most important to least important. We’ve found that doing this separately from identifying the top three makes it easier on the participants.

After we’ve ensured that everyone has their three top choices and has ranked them, we give the last part of the instructions: to record their votes on the group sticky. If, for example, the group sticky notes are blue, we´d use these instructions:

“I want you to go to the blue sticky that best represents your first most important choice and put three X’s on it.”

“You can then go to your second most important choice and put two X’s on it.”

“Finally, go to your third most important choice and put a single X on it.”

When we’re done, everyone will mark six X’s on the group names that they feel are most important.

Again, notice that there we’ve not allowed any group discussion up until this point. Even though they’ve worked as a group, we’ve prevented discussion from eating up any portion of the meeting.

This is because, up until now, we’ve not known what items were most important. It just doesn’t make sense to spend time discussing unimportant items.

Step 8: Ranking the Most Important Groups

Once everyone has marked their votes, we grab all the group sticky notes with votes on them and place them on the whiteboard (or flipchart). We’ll order them by the number of votes each sticky received, with the highest numbers at the top.

At this point we ask the group to gather around the whiteboard and we read off, in order of importance, the names of each group that received votes.

Because some groups may actually represent identical priorities, we allow the team a few moments to consider combining groups. We have a simple process for doing this. Here’s how we explain it to the participants:

“We now need to see if there are any groups that we should combine. You can nominate two groups that you think are the same thing.”

“We’ll then take a preliminary vote, to see if anyone thinks they aren’t the same. If anyone believes they are different, we’ll spend a little time discussing why they believe that.”

“After the brief discussion, we’ll take a final vote. That vote needs to be unanimous for us to combine the items and their scores.”

“Remember, the two groups being considered need to be identical. That means you could substitute one for the other. A group that’s a subset of the other group does not qualify for combining.”

As each pair is nominated, we take the preliminary vote. We let the participants discuss amongst themselves why they are for or against combining. As facilitator, we let everyone have their say and pay close attention to the group dynamics, to prevent people from getting their opinions bullied.

Since we insist on unanimous agreement for combining items, it gives great power to a single person. However, since the items were already scored, it’s hard to abuse the power in any meaningful way. Someone who is trying to hold up the process by being argumentative won’t get very far.

Every time we combine two items, their scores are added together and they are moved higher in the list. Usually, we reach a point where there are three or four items which are ranked much higher than the rest. At this point, the facilitator can stop the process, since any further combinations are unlikely to change these top priorities in any meaningful way.

At this point, the facilitator declares the exercise finished and reviews the top three or four ranked items. These are the top priorities for the focus question.

Reaching Consensus in Record Time

When the KJ-Method works (and it has rarely failed us), we reach group consensus much faster than any other method we’ve had. Because we’ve encouraged people from all over the organization to participate, the resulting priorities will typically stand the test of time and won’t come under constant challenge.

The KJ-Method is a fascinating mix of independent brainstorming, group dynamics, and democracy. It allows a team to be creative and critical in a productive manner, where strong personalities and politics play second fiddle to the independent perspectives and experience of the team.

The KJ-Method is such a valuable tool that we sometimes wonder how we’d ever get our job done without it.

via uie.com

Inbound Marketing Ecosystem

2012-01-03T14:23:00.001+08:00

via 4.bp.blogspot.com

Bite-Sized UX Research

2011-12-31T12:46:00.001+08:00

Bite-Sized UX Research

By Steve Baty

Published: May 7, 2008

It’s not uncommon for projects to lack the time, money, or resources to conduct ideal user research activities. There are many reasons why this occurs:

Sometimes we’re brought onto a project late.

Perhaps we’re new to an organization that doesn’t really get UX.

Maybe a company is rushing to bring a product to market for some reason—and there are plenty of good and bad reasons this might be so—and there simply isn’t time to “go big”.

Perhaps your client or organization is following an Agile development methodology.

“As UX professionals, we can always add value, at any stage in a project.”

At such times, it can be tempting to just throw up our hands in dismay and do nothing or lament the fact that everything isn’t perfect. But the simple fact is that, as UX professionals, we can always add value, at any stage in a project—even if a project team can’t act on our advice straight away.

Focus on Winning Small Victories Often

Regardless of the cause for your company’s resource crunch, focus on getting small wins as often as possible throughout your involvement in a project. This is a fairly common piece of advice that crops up time and time again, but it’s very much worth repeating. And it applies just as readily to both situations where time is short and those when there’s just not enough of you to go around.

This advice is equally valid for UX professionals who find themselves in new positions as the sole user experience person. It’s common for new hires to ask: “How do I sell the benefits of UX?” The answer is generally something along the lines of: “Focus on small wins.” In other words, don’t waste your energy putting together a series of case studies on how other people have created value at other organizations. Instead, do something positive and tangible—however small—and it’ll carry a lot more weight.

Go for Impact

Concentrate on getting bang for your buck. Depending on your circumstances, you may not get many opportunities to demonstrate the value of UX, and when time is short, there can be a tendency to just do something—anything. It’s an urge you should try to resist. If you want to have a greater impact, ask your project team—the project manager, the development team, and the business stakeholders—a few pointed questions before you get started:

What are the critical features of the Web site or application?

What features would be hardest for the developers to change once they’ve developed them?

What are the areas of greatest ambiguity in terms of user requirements, audience groups, or competitive offerings?

And then ask a few more questions:

How can I best document my user research findings, so the project team can use them?

Do we have time for iterations? And if so, how many?

With this information, you can start planning some activities that focus on the most important elements of the project—the critical features for success; the features that are hardest to change; or the gray areas of the project—and deliver some real value.

It’s all very well to say “do something small,” but what, exactly, can you do?

Early Days

You can demonstrate the value of UX during the early stages of a project—such as scoping, initial designs, general requirements, and so on—when there’s the potential for more leeway in the feature set of an online service and more ambiguity around users’ needs. Some activities that can demonstrate value early in the process—and may even alleviate some of your resource constraints further down the track—include the following:

user interviews or contextual enquiries—Get out of the office and meet some of your prospective users. This is a really low-cost way of rapidly building up an understanding of your users’ needs and their context of use. You’ll also learn in what ways users differ from each other and may uncover some surprises. The best part is that—aside from the cost of your time—it’s largely a free activity.

competitor reviews—Help map out the current state of the domain, allowing your team to set better targets. Look at the existing offerings of your competitors to identify the things they do really well and the things they’re failing to do well. Competitor reviews also provide you with a baseline set of features that represent the barrier to entry and can also help to identify opportunities the obvious gaps represent.

internal stakeholder interviews—If you don’t have direct access to your audience, go and talk to the business stakeholders and ask them about the decision-making process by which they selected and prioritized features. This can help you uncover assumptions that you can test as a project progresses. It can also provide insights into the mental models in operation for the project.

mud map personas—There’s a good chance you won’t have the time or resources to conduct the in-depth user research you’d need to turn out well-defined audience personas. However, low-fidelity personas that capture all of the information you do know about your audience segments can be valuable as time progresses. While you can flesh out these mud maps as you learn more about your audience, they also serve to demonstrate how little your team currently knows first-hand about your target users.

About Mud Maps

A mud map is a drawing scratched into the dirt. You can use mud maps when there are no other materials at hand and draw them with a stick or boot. Mud maps are low fidelity, but contain the main characteristics of the terrain.

What About Card Sorts?

Conducting a card-sorting exercise early in a project is desirable when the concept space is not well understood. Early on, you’d typically perform an open card sort, which may require more time and resources—for recruitment, implementation, and analysis—than you have.

Although it is possible to design, recruit, conduct, and analyze a card sort in a matter of days, the question remains whether you might spend that time on another task, offering higher impact to the project. However, there are times when nailing the information architecture is the most critical element for the success of a project, and a card sort would be the best use of your time.

What to Deliver?

“The critical features of your project will drive your choice of what elements to detail.”

Although your time may be short, don’t abdicate responsibility for an information architecture to others. Do wireframes, even if you show only some elements in detail. The critical features of your project will drive your choice of what elements to detail. You might spend your time designing the elements that are most important to the success of a project, leave less important elements to the development team, and iterate the design of those less important elements later on, when you have more time. Alternatively, design and test complex elements that it would be costly to redesign and reimplement at later stages in a project.

As Time Goes By

As a project moves out of its early stages and into the implementation cycle, you can start shifting your attention from requirements to refinement. At this stage of a project, useful activities include

user walkthroughs

closed card sorts

usability testing

definition of metrics

User Walkthroughs

You can do small-scale user walkthroughs of wireframes, a paper prototype, or a stack of screen shots for very little cost. The aim is to generate feedback from real users—or, at least, realistic users—on the design of features at a relatively early stage in a project—that is, before too much development work has taken place.

This activity doesn’t necessarily have to be a big deal. Take a stack of paper printouts to a local cafe and ask people if they’ll walk through a task or two with you, in exchange for a coffee or snack. Don’t take up too much of any one person’s time. It’s better to get several different people to try out a feature or two rather than possibly annoying people by demanding too much of them. They’re trying to relax after all!

Iterate this process if you can.

Closed Card Sorts

“Focus on task failures and look for common mistakes participants make.”

A closed card sort is a little easier to conduct than an open card sort— and, in my opinion, a lot easier to analyze. Using decks of cards representing a site’s structure as you’ve designed it, ask people to find their way to particular low-level pages. You can plan your card sort based on the major user tasks, critical features, or areas of known ambiguity.

You can easily conduct a closed cart sort just about anywhere, and it should take only a few minutes per task. For each task you test, note the path each user takes—that is, the card a user selects at each step—and whether a user successfully located the low-level page.

You can carry out a test like this in a single day, including its setup. Since time is short, focus on task failures and look for common mistakes participants make. Report only such issues, but make the full test results available to your project team. You don’t want to be the bearer of only bad news. Instead say: “A lot of stuff worked well, but here are some things we need to look at changing.”

Usability Testing

Using whatever version of a Web site or application you have available—whether wireframe printouts or a low-fidelity prototype—conduct a more formal usability test, during which you ask each participant to complete all tasks. Although this can be time consuming, a usability test with six participants takes just a few days and can provide valuable insights for your project team.

You can take this opportunity to test your whole design solution. Alternatively, you can concentrate on high-impact features, according to your time, people, and budget constraints.

As a finished Web site or application becomes more tangible, continue doing iterative, small-scale usability testing. There will come a time when you can’t incorporate the findings from your testing into the upcoming release, but your recommendations can form the basis for a subsequent version.

Define Metrics

If you’ve joined a project very late, there may be very little you can do to influence the finished product. However, you can still add value to the project by defining a set of analytics that can help the project team make design decisions during the product lifecycle. So, get the team to record page-completion times for a multi-step transaction process, make sure you get good search logs and reports, and give yourself an opportunity to learn something about how customers are interacting with your site.

Don’t be disheartened if your project team can’t incorporate your changes straight away. Start laying the groundwork for the next iteration of the product or service and stay ahead of the curve if you can.

Summary

“Undertake small, tactical, iterative user research activities throughout the course of the project.”

If you don’t have the resources of a large UX team, with the budgets and timelines to undertake the ideal user-centered design (UCD) or activity-centered design process, you can still make a valuable contribution to a project. Undertake small, tactical, iterative user research activities throughout the course of the project. Focus your efforts on the areas of greatest impact, and produce documentation that your project team can understand and use efficiently.

If you demonstrate value through a series of small, high-impact UX activities, the extra budget, people, and timeline flexibility you need will eventually come your way. Then, you can come closer to implementing your ideal UX process.

I’d like to thank Ruth Ellison, of Stamford Interactive, Daniel Szuc, of Apogee, and Russ Unger, of User Glue, for motivating me to write this column and for their input into the ideas it presents.

Topic: Columns | User Research

via uxmatters.com

10 Heuristics for User Interface Design

2011-12-30T06:51:00.001+08:00

Ten Usability Heuristics
by Jakob Nielsen
These are ten general principles for user interface design. They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.

Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
Match between system and the real world
The system should speak the users' language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.
User control and freedom
Users often choose system functions by mistake and will need a clearly marked "emergency exit" to leave the unwanted state without having to go through an extended dialogue. Support undo and redo.
Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
Recognition rather than recall
Minimize the user's memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.
Flexibility and efficiency of use
Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.

via useit.com

- STREET ART UTOPIA

2011-12-30T06:26:00.001+08:00

via streetartutopia.com

CEO Friday: Why we don’t hire .NET programmers « Expensify Blog

2011-12-26T10:46:00.001+08:00

via blog.expensify.com

Readers' responses are always a good read.

» Changes in Facebook Insights » Fresh Egg SEO Blog

2011-12-25T03:54:00.001+08:00

Check out this website I found at freshegg.com

Social Media and Your Business Communication Strategy

2011-12-21T20:13:00.001+08:00

via blog.socialcast.com

Reality.

2011-12-21T19:53:00.001+08:00

via iwastesomuchtime.com

so true.

Thermalchromatic urinal.

2011-12-21T19:33:00.001+08:00

via iwastesomuchtime.com

cool!

Oh, that's interesting.

2011-12-21T19:29:00.001+08:00

via iwastesomuchtime.com

Reaching for the Skies

2011-12-19T16:42:00.001+08:00

via visual.ly

The Internet Justice League

2011-12-19T16:36:00.001+08:00

via visual.ly

Kicker Studio: The Disciplines of User Experience

2011-12-19T07:43:00.001+08:00

via kickerstudio.com

Why you Should Bury your Sign Up Button

2011-12-12T06:17:00.003+08:00

Why you Should Bury your Sign Up Button

by Joshua Porter | Responses--> October 21st, 2011 | shortlink: http://bokardo.com/p/1991

A short while ago I was involved in a project redesigning a home page of a website. I dutifully designed the page in the common fashion, using a bold headline, some bullet points, and a juicy call-to-action button. It was very similar to many of the startup home pages that you might run across every day.

The goal of the redesign was to increase conversion on the primary call to action of sign-up. We wanted to double or triple (or more) the number of people who were signing up and trying out the product.

I knew the redesign was a vast improvement over the existing one, merely because the page better communicated what was going on. Instead of a vague headline that wasn’t communicating value to readers I used a much more descriptive one that helped orient people immediately to have some idea of what the site does. And the button…well let’s just say that it was so hot it made you want to click it.

So we launched, and then we looked at the data. Uh Oh. No big increase in conversion, certainly not enough to change the business. The conversion rate had improved about 20%, which is OK, but the rate itself was so low to have very little effect on the company’s bottom line.

What was wrong? Why wasn’t there a big improvement in conversion? Why was our click-through so low on what was obviously the primary call-to-action? Didn’t we follow all of the visual design rules here? Make headline big and bold. Check. Make a bullet list of important points. Check. Make a beautiful, sexy button that looks like it was born to be clicked. Check.

Why then, were people not clicking the sexy button?

It’s at this point when you have to step back and ask yourself: what exactly is design? Is design creating something for creation sake? We certainly had done that, and we had already done as much work as is done on most redesign projects. Most projects would have launched and been done…when redesign is the goal the launch is the end.

But that’s not what passes as good design these days. Good design is design that works. So to honestly assess the redesign I did I had to admit…this design was still not working.

Damn was that hard to admit. Really, really hard to admit. I hated admitting it because it was an admission that I failed. I’ve not often admitted that on projects in the past that just didn’t get the usage that I wanted. In so many cases it was easier to say to myself that what I did was better than what was there before and the work of launching was enough. It is so easy to confuse getting stuff done with doing good work.

Yet, this admission also allowed me to see the problem more clearly. Once I accepted that the redesign still wasn’t working, I created the opportunity to find out why not. See that interesting little trick I pulled there? Failure is an opportunity to problem solve! We all love to problem solve, right?

So in hindsight the answer is obvious…people weren’t clicking “Sign Up” because they were not ready to. They saw the button and did not care enough to click it. I could have made it flashing big-ass and red, but still nobody would have clicked on it.

No visual design wizardry at this point would have improved things. No matter how much we tweak the call-to-action, we’re not going to significantly improve click-through on it. We’re not fighting an attention war here…we have people’s attention because they’re on our website. No, we’re fighting an emotional war. We need to convince people of the value of what we’re offering enough so they actually care. They are aware that our big-ass honking button is there…how could they not be? We made it impossible to miss! in fact they’ve read the text on it that says “Sign-up for Free”. They can barely get it out of their peripheral vision…

No, our visitors can see clearly…they’re not failing to notice the button. And they can read…they can see what the button says. They’re also not obstinate…they’re not doing this just to spite you.

The hard fact is that they just don’t care.

Or more precisely, they don’t care yet. They’re interested, but they do not know enough to care. We have not given them enough of a reason to care. They are not ready to take that step.

So the right answer in this situation is not to give our call-to-action a stronger drop shadow, double its text size, make it fire engine red (#CE1620), or make it blink. No amount of visual design on that button will make people click it more. The right answer is to remove the button altogether and replace it with something that people do want to click. Something they do want to do…the appropriate next step in their lifecycle as a customer.

I call this Designing for the Next Step. And in my next post I will explain what I’m talking about in much more detail…

Addendum: The folks at Zurb have published an example of a 350% improvement from simply burying the sign-up button. That’s some serious improvement.

via bokardo.com

Why you Should Bury your Sign Up Button « Bokardo

2011-12-12T06:17:00.001+08:00

Why you Should Bury your Sign Up Button

by Joshua Porter | Responses--> October 21st, 2011 | shortlink: http://bokardo.com/p/1991

A short while ago I was involved in a project redesigning a home page of a website. I dutifully designed the page in the common fashion, using a bold headline, some bullet points, and a juicy call-to-action button. It was very similar to many of the startup home pages that you might run across every day.

The goal of the redesign was to increase conversion on the primary call to action of sign-up. We wanted to double or triple (or more) the number of people who were signing up and trying out the product.

I knew the redesign was a vast improvement over the existing one, merely because the page better communicated what was going on. Instead of a vague headline that wasn’t communicating value to readers I used a much more descriptive one that helped orient people immediately to have some idea of what the site does. And the button…well let’s just say that it was so hot it made you want to click it.

So we launched, and then we looked at the data. Uh Oh. No big increase in conversion, certainly not enough to change the business. The conversion rate had improved about 20%, which is OK, but the rate itself was so low to have very little effect on the company’s bottom line.

What was wrong? Why wasn’t there a big improvement in conversion? Why was our click-through so low on what was obviously the primary call-to-action? Didn’t we follow all of the visual design rules here? Make headline big and bold. Check. Make a bullet list of important points. Check. Make a beautiful, sexy button that looks like it was born to be clicked. Check.

Why then, were people not clicking the sexy button?

It’s at this point when you have to step back and ask yourself: what exactly is design? Is design creating something for creation sake? We certainly had done that, and we had already done as much work as is done on most redesign projects. Most projects would have launched and been done…when redesign is the goal the launch is the end.

But that’s not what passes as good design these days. Good design is design that works. So to honestly assess the redesign I did I had to admit…this design was still not working.

Damn was that hard to admit. Really, really hard to admit. I hated admitting it because it was an admission that I failed. I’ve not often admitted that on projects in the past that just didn’t get the usage that I wanted. In so many cases it was easier to say to myself that what I did was better than what was there before and the work of launching was enough. It is so easy to confuse getting stuff done with doing good work.

Yet, this admission also allowed me to see the problem more clearly. Once I accepted that the redesign still wasn’t working, I created the opportunity to find out why not. See that interesting little trick I pulled there? Failure is an opportunity to problem solve! We all love to problem solve, right?

So in hindsight the answer is obvious…people weren’t clicking “Sign Up” because they were not ready to. They saw the button and did not care enough to click it. I could have made it flashing big-ass and red, but still nobody would have clicked on it.

No visual design wizardry at this point would have improved things. No matter how much we tweak the call-to-action, we’re not going to significantly improve click-through on it. We’re not fighting an attention war here…we have people’s attention because they’re on our website. No, we’re fighting an emotional war. We need to convince people of the value of what we’re offering enough so they actually care. They are aware that our big-ass honking button is there…how could they not be? We made it impossible to miss! in fact they’ve read the text on it that says “Sign-up for Free”. They can barely get it out of their peripheral vision…

No, our visitors can see clearly…they’re not failing to notice the button. And they can read…they can see what the button says. They’re also not obstinate…they’re not doing this just to spite you.

The hard fact is that they just don’t care.

Or more precisely, they don’t care yet. They’re interested, but they do not know enough to care. We have not given them enough of a reason to care. They are not ready to take that step.

So the right answer in this situation is not to give our call-to-action a stronger drop shadow, double its text size, make it fire engine red (#CE1620), or make it blink. No amount of visual design on that button will make people click it more. The right answer is to remove the button altogether and replace it with something that people do want to click. Something they do want to do…the appropriate next step in their lifecycle as a customer.

I call this Designing for the Next Step. And in my next post I will explain what I’m talking about in much more detail…

Addendum: The folks at Zurb have published an example of a 350% improvement from simply burying the sign-up button. That’s some serious improvement.

via bokardo.com

Complexity and User Experience

2011-12-12T06:09:00.001+08:00

via boxesandarrows.com

The difference between a UX Designer and UI Developer

2011-12-07T17:35:00.001+08:00

via asinthecity.com

The 25 Most Popular Passwords of 2011

2011-11-23T13:28:00.001+08:00

via gizmodo.com

Technology Footprint: Starting Up in New York

2011-11-23T05:38:00.001+08:00

via nytimes.com

The New York Times mapped out the offices of the Big Apple’s hottest startups, color-coding the companies by industry.

HTML5 - 12 Cool HTML5 Geolocation Ideas

2011-11-22T16:22:00.001+08:00

via msdn.microsoft.com

Ignore us, ignore human rights. - Amnesty international

2011-11-07T21:30:00.001+08:00

via zzzqu.com

Don’t Call Yourself A Programmer, And Other Career Advice

2011-11-06T22:47:00.001+08:00

If there was one course I could add to every engineering education, it wouldn’t involve compilers or gates or time complexity. It would be Realities Of Your Industry 101, because we don’t teach them and this results in lots of unnecessary pain and suffering. This post aspires to be README.txt for your career as a young engineer. The goal is to make you happy, by filling in the gaps in your education regarding how the “real world” actually works. It took me about ten years and a lot of suffering to figure out some of this, starting from “fairly bright engineer with low self-confidence and zero practical knowledge of business.” I wouldn’t trust this as the definitive guide, but hopefully it will provide value over what your college Career Center isn’t telling you.

90% of programming jobs are in creating Line of Business software: Economics 101: the price for anything (including you) is a function of the supply of it and demand for it. Let’s talk about the demand side first. Most software is not sold in boxes, available on the Internet, or downloaded from the App Store. Most software is boring one-off applications in corporations, under-girding every imaginable facet of the global economy. It tracks expenses, it optimizes shipping costs, it assists the accounting department in preparing projections, it helps design new widgets, it prices insurance policies, it flags orders for manual review by the fraud department, etc etc. Software solves business problems. Software often solves business problems despite being soul-crushingly boring and of minimal technical complexity. For example, consider an internal travel expense reporting form. Across a company with 2,000 employees, that might save 5,000 man-hours a year (at an average fully-loaded cost of $50 an hour) versus handling expenses on paper, for a savings of $250,000 a year. It does not matter to the company that the reporting form is the world’s simplest CRUD app, it only matters that it either saves the company costs or generates additional revenue.

There are companies which create software which actually gets used by customers, which describes almost everything that you probably think of when you think of software. It is unlikely that you will work at one unless you work towards making this happen. Even if you actually work at one, many of the programmers there do not work on customer-facing software, either.

Engineers are hired to create business value, not to program things: Businesses do things for irrational and political reasons all the time (see below), but in the main they converge on doing things which increase revenue or reduce costs. Status in well-run businesses generally is awarded to people who successfully take credit for doing one of these things. (That can, but does not necessarily, entail actually doing them.) The person who has decided to bring on one more engineer is not doing it because they love having a geek around the room, they are doing it because adding the geek allows them to complete a project (or projects) which will add revenue or decrease costs. Producing beautiful software is not a goal. Solving complex technical problems is not a goal. Writing bug-free code is not a goal. Using sexy programming languages is not a goal. Add revenue. Reduce costs. Those are your only goals.

Peter Drucker — you haven’t heard of him, but he is a prophet among people who sign checks — came up with the terms Profit Center and Cost Center. Profit Centers are the part of an organization that bring in the bacon: partners at law firms, sales at enterprise software companies, “masters of the universe” on Wall Street, etc etc. Cost Centers are, well, everybody else. You really want to be attached to Profit Centers because it will bring you higher wages, more respect, and greater opportunities for everything of value to you. It isn’t hard: a bright high schooler, given a paragraph-long description of a business, can usually identify where the Profit Center is. If you want to work there, work for that. If you can’t, either a) work elsewhere or b) engineer your transfer after joining the company.

Engineers in particular are usually very highly paid Cost Centers, which sets MBA’s optimization antennae to twitching. This is what brings us wonderful ideas like outsourcing, which is “Let’s replace really expensive Cost Centers who do some magic which we kinda need but don’t really care about with less expensive Cost Centers in a lower wage country”. (Quick sidenote: You can absolutely ignore outsourcing as a career threat if you read the rest of this guide.) Nobody ever outsources Profit Centers. Attempting to do so would be the setup for MBA humor. It’s like suggesting replacing your source control system with a bunch of copies maintained on floppy disks.

Don’t call yourself a programmer: “Programmer” sounds like “anomalously high-cost peon who types some mumbo-jumbo into some other mumbo-jumbo.” If you call yourself a programmer, someone is already working on a way to get you fired. You know Salesforce, widely perceived among engineers to be a Software as a Services company? Their motto and sales point is “No Software”, which conveys to their actual customers “You know those programmers you have working on your internal systems? If you used Salesforce, you could fire half of them and pocket part of the difference in your bonus.” (There’s nothing wrong with this, by the way. You’re in the business of unemploying people. If you think that is unfair, go back to school and study something that doesn’t matter.)

Instead, describe yourself by what you have accomplished for previously employers vis-a-vis increasing revenues or reducing costs. If you have not had the opportunity to do this yet, describe things which suggest you have the ability to increase revenue or reduce costs, or ideas to do so.

There are many varieties of well-paid professionals who sling code but do not describe themselves as slinging code for a living. Quants on Wall Street are the first and best-known example: they use computers and math as a lever to make high-consequence decisions better and faster than an unaided human could, and the punchline to those decisions is “our firm make billions of dollars.” Successful quants make more in bonuses in a good year than many equivalently talented engineers will earn in a decade or lifetime.

Similarly, even though you might think Google sounds like a programmer-friendly company, there are programmers and then there’s the people who are closely tied to 1% improvements in AdWords click-through rates. (Hint: provably worth billions of dollars.) I recently stumbled across a web-page from the guy whose professional bio is “wrote the backend billing code that 97% of Google’s revenue passes through.” He’s now an angel investor (a polite synonym for “rich”).

You are not defined by your chosen software stack: I recently asked via Twitter what young engineers wanted to know about careers. Many asked how to know what programming language or stack to study. It doesn’t matter. There you go.

Do Java programmers make more money than .NET programmers? Anyone describing themselves as either a Java programmer or .NET programmer has already lost, because a) they’re a programmer (you’re not, see above) and b) they’re making themselves non-hireable for most programming jobs. In the real world, picking up a new language takes a few weeks of effort and after 6 to 12 months nobody will ever notice you haven’t been doing that one for your entire career. I did back-end Big Freaking Java Web Application development as recently as March 2010. Trust me, nobody cares about that. If a Python shop was looking for somebody technical to make them a pile of money, the fact that I’ve never written a line of Python would not get held against me.

Talented engineers are rare — vastly rarer than opportunities to use them — and it is a seller’s market for talent right now in almost every facet of the field. Everybody at Matasano uses Ruby. If you don’t, but are a good engineer, they’ll hire you anyway. (A good engineer has a track record of — repeat after me — increasing revenue or decreasing costs.) Much of Fog Creek uses the Microsoft Stack. I can’t even spell ASP.NET and they’d still hire me.

There are companies with broken HR policies where lack of a buzzword means you won’t be selected. You don’t want to work for them, but if you really do, you can add the relevant buzzword to your resume for the costs of a few nights and weekends, or by controlling technology choices at your current job in such a manner that in advances your career interests. Want to get trained on Ruby at a .NET shop? Implement a one-off project in Ruby. Bam, you are now a professional Ruby programmer — you coded Ruby and you took money for it. (You laugh? I did this at a Java shop. The one-off Ruby project made the company $30,000. My boss was, predictably, quite happy and never even asked what produced the deliverable.)

Co-workers and bosses are not usually your friends: You will spend a lot of time with co-workers. You may eventually become close friends with some of them, but in general, you will move on in three years and aside from maintaining cordial relations you will not go out of your way to invite them over to dinner. They will treat you in exactly the same way. You should be a good person to everyone you meet — it is the moral thing to do, and as a sidenote will really help your networking — but do not be under the delusion that everyone is your friend.

For example, at a job interview, even if you are talking to an affable 28 year old who feels like a slightly older version of you he is in a transaction. You are not his friend, you are an input for an industrial process which he is trying to buy for the company at the lowest price. That banter about World of Warcraft is just establishing a professional rapport, but he will (perfectly ethically) attempt to do things that none of your actual friends would ever do, like try to talk you down several thousand dollars in salary or guilt-trip you into spending more time with the company when you could be spending time with your actual friends. You will have other coworkers who — affably and ethically — will suggest things which go against your interests, from “I should get credit for that project you just did” (probably not phrased in so many words) to “We should do this thing which advances my professional growth goals rather than yours.” Don’t be surprised when this happens.

You radically overestimate the average skill of the competition because of the crowd you hang around with: Many people already successfully employed as senior engineers cannot actually implement FizzBuzz. Just read it and weep. Key takeaway: you probably are good enough to work at that company you think you’re not good enough for. They hire better mortals, but they still hire mortals.

“Read ad. Send in resume. Go to job interview. Receive offer.” is the exception, not the typical case, for getting employment: Most jobs are never available publicly, just like most worthwhile candidates are not available publicly (see here). Information about the position travels at approximately the speed of beer, sometimes lubricated by email. The decisionmaker at a company knows he needs someone. He tells his friends and business contacts. One of them knows someone — family, a roommate from college, someone they met at a conference, an ex-colleague, whatever. Introductions are made, a meeting happens, and they achieve agreement in principle on the job offer. Then the resume/HR department/formal offer dance comes about.

This is disproportionately true of jobs you actually want to get. ”First employee at a successful startup” has a certain cachet for a lot of geeks, and virtually none of those got placed by sending in a cover letter to an HR department, in part because two-man startups don’t have enough scar tissue to form HR departments yet. (P.S. You probably don’t want to be first employee for a startup. Be the last co-founder instead.) Want to get a job at Googler? They have a formal process for giving you a leg up because a Googler likes you. (They also have multiple informal ways for a Googler who likes you an awful lot to short-circuit that process. One example: buy the company you work for. When you have a couple of billion lying around you have many interesting options for solving problems.)

There are many reasons why most hiring happens privately. One is that publicly visible job offers get spammed by hundreds of resumes (particularly in this economy) from people who are stunningly inappropriate for the position. The other is that other companies are so bad at hiring that, if you don’t have close personal knowledge about the candidate, you might accidentally hire a non-FizzBuzzer.

Networking: it isn’t just for TCP packets: Networking just means a) meeting people who at some point can do things for you (or vice versa) and b) making a favorable impression on them.

There are many places to meet people. Events in your industry, such as conferences or academic symposia which get seen by non-academics, are one. User groups are another. Keep in mind that user groups draw a very different crowd than industry conferences and optimize accordingly.

Strive to help people. It is the right thing to do, and people are keenly aware of who have in the past given them or theirs favors. If you ever can’t help someone but know someone who can, pass them to the appropriate person with a recommendation. If you do this right, two people will be happy with you and favorably disposed to helping you out in the future.

You can meet people over the Internet (oh God, can you), but something in our monkey brains makes in-the-flesh meeting a bigger thing. I’ve Internet-met a great many people who I’ve then gone on to meet in real life. The physical handshake is a major step up in the relationship, even when Internet-meeting lead to very consequential things like “Made them a lot of money through good advice.” Definitely blog and participate on your industry-appropriate watering holes like HN, but make it out to the meetups for it.

Academia is not like the real world: Your GPA largely doesn’t matter (modulo one high profile exception: a multinational advertising firm). To the extent that it does matter, it only determines whether your resume gets selected for job interviews. If you’re reading the rest of this, you know that your resume isn’t the primary way to get job interviews, so don’t spend huge amount of efforts optimizing something that you either have sufficiently optimized already (since you’ll get the same amount of interviews at 3.96 as you will at 3.8) or that you don’t need at all (since you’ll get job interviews because you’re competent at asking the right people to have coffee with you).

Your major and minor don’t matter. Most decisionmakers in industry couldn’t tell the difference between a major in Computer Science and a major in Mathematics if they tried. I was once reduced to tears because a minor academic snafu threatened my ability to get a Bachelor of Science with a major in Computer Science, which my advisor told me was more prestigious than a Bachelor of Science in Computer Science. Academia cares about distinctions like that. The real world does not.

Your professors might understand how the academic job market works (short story: it is ridiculously inefficient in engineering and fubared beyond mortal comprehension in English) but they often have quixotic understandings of how the real world works. For example, they may push you to get extra degrees because a) it sounds like a good idea to them and b) they enjoy having research-producing peons who work for ramen. Remember, market wages for people capable of producing research are $80~100k+++ in your field. That buys an awful lot of ramen.

The prof in charge of my research project offered me a spot in his lab, a tuition waiver, and a whole $12,000 dollars as a stipend if I would commit 4~6 years to him. That’s a great deal if, and only if, you have recently immigrated from a low-wage country and need someone to intervene with the government to get you a visa.

If you really like the atmosphere at universities, that is cool. Put a backpack on and you can walk into any building at any university in the United States any time you want. Backpacks are a lot cheaper than working in academia. You can lead the life of the mind in industry, too — and enjoy less politics and better pay. You can even get published in journals, if that floats your boat. (After you’ve escaped the mind-warping miasma of academia, you might rightfully question whether Published In A Journal is really personally or societally significant as opposed to close approximations like Wrote A Blog Post And Showed It To Smart People.)

How much money do engineers make?

Wrong question. The right question is “What kind of offers do engineers routinely work for?”, because salary is one of many levers that people can use to motivate you. The answer to this is, less than helpfully, “Offers are all over the map.”

In general, big companies pay more (money, benefits, etc) than startups. Engineers with high perceived value make more than those with low perceived value. Senior engineers make more than junior engineers. People working in high-cost areas make more than people in low-cost areas. People who are skilled in negotiation make more than those who are not.

We have strong cultural training to not ask about salary, ever. This is not universal. In many cultures, professional contexts are a perfectly appropriate time to discuss money. (If you were a middle class Japanese man, you could reasonably be expected to reveal your exact salary to a 2nd date, anyone from your soccer club, or the guy who makes your sushi. If you owned a company, you’d probably be cagey about your net worth but you’d talk about employee salaries the way programmers talk about compilers — quite frequently, without being embarrassed.) If I were a Marxist academic or a conspiracy theorist, I might think that this bit of middle class American culture was specifically engineered to be in the interests of employers and against the interests of employees. Prior to a discussion of salary at any particular target employer, you should speak to someone who works there in a similar situation and ask about the salary range for the position. It is <%= Date.today.year %>; you can find these people online. (LinkedIn, Facebook, Twitter, and your (non-graph-database) social networks are all good to lean on.)

Anyhow. Engineers are routinely offered a suite of benefits. It is worth worrying, in the United States, about health insurance (traditionally, you get it and your employer foots most or all of the costs) and your retirement program, which is some variant of “we will match contributions to your 401k up to X% of salary.” The value of that is easy to calculate: X% of salary. (It is free money, so always max out your IRA up to the employer match. Put it in index funds and forget about it for 40 years.)

There are other benefits like “free soda”, “catered lunches”, “free programming books”, etc. These are social signals more than anything else. When I say that I’m going to buy you soda, that says a specific thing about how I run my workplace, who I expect to work for me, and how I expect to treat them. (It says “I like to move the behavior of unsophisticated young engineers by making this job seem fun by buying 20 cent cans of soda, saving myself tens of thousands in compensation while simultaneously encouraging them to ruin their health.” And I like soda.) Read social signals and react appropriately — someone who signals that, e.g., employee education is worth paying money for might very well be a great company to work for — but don’t give up huge amounts of compensation in return for perks that you could trivially buy.

How do I become better at negotiation? This could be a post in itself. Short version:

a) Remember you’re selling the solution to a business need (raise revenue or decrease costs) rather than programming skill or your beautiful face.

b) Negotiate aggressively with appropriate confidence, like the ethical professional you are. It is what your counterparty is probably doing. You’re aiming for a mutual beneficial offer, not for saying Yes every time they say something.

c) ”What is your previous salary?” is employer-speak for “Please give me reasons to pay you less money.” Answer appropriately.

d) Always have a counteroffer. Be comfortable counteroffering around axes you care about other than money. If they can’t go higher on salary then talk about vacation instead.

e) The only time to ever discuss salary is after you have reached agreement in principle that they will hire you if you can strike a mutually beneficial deal. This is late in the process after they have invested a lot of time and money in you, specifically, not at the interview. Remember that there are large costs associated with them saying “No, we can’t make that work” and, appropriately, they will probably not scuttle the deal over comparatively small issues which matter quite a bit to you, like e.g. taking their offer and countering for that plus a few thousand bucks then sticking to it.

f) Read a book. Many have been written about negotiation. I like Getting To Yes. It is a little disconcerting that negotiation skills are worth thousands of dollars per year for your entire career but engineers think that directed effort to study them is crazy when that could be applied to trivialities about a technology that briefly caught their fancy.

How to value an equity grant:

Roll d100. (Not the right kind of geek? Sorry. rand(100) then.)

0~70: Your equity grant is worth nothing.

71~94: Your equity grant is worth a lump sum of money which makes you about as much money as you gave up working for the startup, instead of working for a megacorp at a higher salary with better benefits.

95~99: Your equity grant is a lifechanging amount of money. You won’t feel rich — you’re not the richest person you know, because many of the people you spent the last several years with are now richer than you by definition — but your family will never again give you grief for not having gone into $FAVORED_FIELD like a proper $YOUR_INGROUP.

100: You worked at the next Google, and are rich beyond the dreams of avarice. Congratulations.

Perceptive readers will note that 100 does not actually show up on a d100 or rand(100).

Why are you so negative about equity grants?

Because you radically overestimate the likelihood that your startup will succeed and radically overestimate the portion of the pie that will be allocated to you if the startup succeeds. Read about dilution and liquidation preferences on Hacker News or Venture Hacks, then remember that there are people who know more about negotiating deals than you know about programming and imagine what you could do to a program if there were several hundred million on the line.

Are startups great for your career as a fresh graduate?

The high-percentage outcome is you work really hard for the next couple of years, fail ingloriously, and then be jobless and looking to get into another startup. If you really wanted to get into a startup two years out of school, you could also just go work at a megacorp for the next two years, earn a bit of money, then take your warchest, domain knowledge, and contacts and found one.

Working at a startup, you tend to meet people doing startups. Most of them will not be able to hire you in two years. Working at a large corporation, you tend to meet other people in large corporations in your area. Many of them either will be able to hire you or will have the ear of someone able to hire you in two years.

So would you recommend working at a startup? Working in a startup is a career path but, more than that, it is a lifestyle choice. This is similar to working in investment banking or academia. Those are three very different lifestyles. Many people will attempt to sell you those lifestyles as being in your interests, for their own reasons. If you genuinely would enjoy that lifestyle, go nuts. If you only enjoy certain bits of it, remember that many things are available a la carte if you really want them. For example, if you want to work on cutting-edge technology but also want to see your kids at 5:30 PM, you can work on cutting-edge technology at many, many, many megacorps.

(Yeah, really. If it creates value for them, heck yes, they’ll invest in it. They’ll also invest in a lot of CRUD apps, but then again, so do startups — they just market making CRUD apps better than most megacorps do. The first hour of the Social Network is about making a CRUD app seem like sexy, the second is a Lifetime drama about a divorce improbably involving two heterosexual men.)

Your most important professional skill is communication: Remember engineers are not hired to create programs and how they are hired to create business value? The dominant quality which gets you jobs is the ability to give people the perception that you will create value. This is not necessarily coextensive with ability to create value.

Some of the best programmers I know are pathologically incapable of carrying on a conversation. People disproportionately a) wouldn’t want to work with them or b) will underestimate their value-creation ability because they gain insight into that ability through conversation and the person just doesn’t implement that protocol. Conversely, people routinely assume that I am among the best programmers they know entirely because a) there exists observable evidence that I can program and b) I write and speak really, really well.

(Once upon a time I would have described myself as “Slightly below average” in programming skill. I have since learned that I had a radically skewed impression of the skill distribution, that programming skill is not what people actually optimize for, and that modesty is against my interests. These days if you ask me how good of a programmer I am I will start telling you stories about how I have programmed systems which helped millions of kids learn to read or which provably made companies millions. The question of where I am on the bell curve matters to no one, so why bother worrying about it?)

Communication is a skill. Practice it: you will get better. One key sub-skill is being able to quickly, concisely, and confidently explain how you create value to someone who is not an expert in your field and who does not have a priori reasons to love you. If when you attempt to do this technical buzzwords keep coming up (“Reduced 99th percentile query times by 200 ms by optimizing indexes on…”), take them out and try again. You should be able to explain what you do to a bright 8 year old, the CFO of your company, or a programmer in a different specialty, at whatever the appropriate level of abstraction is.

You will often be called to do Enterprise Sales and other stuff you got into engineering to avoid: Enterprise Sales is going into a corporation and trying to convince them to spend six or seven figures on buying a system which will either improve their revenue or reduce costs. Every job interview you will ever have is Enterprise Sales. Politics, relationships, and communication skills matter a heck of a lot, technical reality not quite so much.

When you have meetings with coworkers and are attempting to convince them to implement your suggestions, you will also be doing Enterprise Sales. If getting stuff done is your job description, then convincing people to get stuff done is a core job skill for you. Spend appropriate effort on getting good at it. This means being able to communicate effectively in memos, emails, conversations, meetings, and PowerPoint (when appropriate). It means understanding how to make a business case for a technological initiative. It means knowing that sometimes you will make technological sacrifices in pursuit of business objectives and that this is the right call.

Modesty is not a career-enhancing character trait: Many engineers have self-confidence issues (hello, self). Many also come from upbringings where modesty with regards to one’s accomplishments is culturally celebrated. American businesses largely do not value modesty about one’s accomplishments. The right tone to aim for in interviews, interactions with other people, and life is closer to “restrained, confident professionalism.”

If you are part of a team effort and the team effort succeeds, the right note to hit is not “I owe it all to my team” unless your position is such that everyone will understand you are lying to be modest. Try for “It was a privilege to assist my team by leading their efforts with regards to $YOUR_SPECIALTY.” Say it in a mirror a thousand times until you can say it with a straight face. You might feel like you’re overstating your accomplishments. Screw that. Someone who claims to Lead Efforts To Optimize Production while having the title Sandwich Artist is overstating their accomplishments. You are an engineer. You work magic which makes people’s lives better. If you were in charge of the database specifically on an important project involving people then heck yes you lead the database effort which was crucial for the success of the project. This is how the game is played. If you feel poorly about it, you’re like a batter who feels poorly about stealing bases in baseball: you’re not morally superior, you’re just playing poorly

All business decisions are ultimately made by one or a handful of multi-cellular organisms closely related to chimpanzees, not by rules or by algorithms: People are people. Social grooming is a really important skill. People will often back suggestions by friends because they are friends, even when other suggestions might actually be better. People will often be favoritably disposed to people they have broken bread with. (There is a business book called Never Eat Alone. It might be worth reading, but that title is whatever the antonym of deceptive advertising is.) People routinely favor people who they think are like them over people they think are not like them. (This can be good, neutral, or invidious. Accepting that it happens is the first step to profitably exploiting it.)

Actual grooming is at least moderately important, too, because people are hilariously easy to hack by expedients such as dressing appropriately for the situation, maintaining a professional appearance, speaking in a confident tone of voice, etc. Your business suit will probably cost about as much as a computer monitor. You only need it once in a blue moon, but when you need it you’ll be really, really, really glad that you have it. Take my word for it, if I wear everyday casual when I visit e.g. City Hall I get treated like a hapless awkward twenty-something, if I wear the suit I get treated like the CEO of a multinational company. I’m actually the awkward twenty-something CEO of a multinational company, but I get to pick which side to emphasize when I want favorable treatment from a bureaucrat.

(People familiar with my business might object to me describing it as a multinational company because it is not what most people think of when “multinational company” gets used in conversation. Sorry — it is a simple conversational hack. If you think people are pissed off at being manipulated when they find that out, well, some people passionately hate business suits, too. That doesn’t mean business suits are valueless. Be appropriate to the circumstances. Technically true answers are the best kind of answers when the alternative is Immigration deporting you, by the way.)

At the end of the day, your life happiness will not be dominated by your career. Either talk to older people or trust the social scientists who have: family, faith, hobbies, etc etc generally swamp career achievements and money in terms of things which actually produce happiness. Optimize appropriately. Your career is important, and right now it might seem like the most important thing in your life, but odds are that is not what you’ll believe forever. Work to live, don’t live to work.

via kalzumeus.com

A good perspective and entertaining.

Re:

2011-10-25T22:34:00.001+08:00

Be cool! Stop smoking!. http://plaisanceadhesifs.fr/com.page.php?qCID=21o7

Free Download: Cheat Sheet For Designing Web Forms - Smashing UX Design

2011-10-24T02:00:00.001+08:00

via uxdesign.smashingmagazine.com

Continuous Partial Attention | Linda Stone

2011-10-22T13:26:00.001+08:00

What is continuous partial attention?

Continuous partial attention describes how many of us use our attention today. It is different from multi-tasking. The two are differentiated by the impulse that motivates them. When we multi-task, we are motivated by a desire to be more productive and more efficient. We’re often doing things that are automatic, that require very little cognitive processing. We give the same priority to much of what we do when we multi-task — we file and copy papers, talk on the phone, eat lunch — we get as many things done at one time as we possibly can in order to make more time for ourselves and in order to be more efficient and more productive.

To pay continuous partial attention is to pay partial attention — CONTINUOUSLY. It is motivated by a desire to be a LIVE node on the network. Another way of saying this is that we want to connect and be connected. We want to effectively scan for opportunity and optimize for the best opportunities, activities, and contacts, in any given moment. To be busy, to be connected, is to be alive, to be recognized, and to matter.

We pay continuous partial attention in an effort NOT TO MISS ANYTHING. It is an always-on, anywhere, anytime, any place behavior that involves an artificial sense of constant crisis. We are always in high alert when we pay continuous partial attention. This artificial sense of constant crisis is more typical of continuous partial attention than it is of multi-tasking.

Is continuous partial attention a good thing or a bad thing?

Like so many things, in small doses, continuous partial attention can be a very functional behavior. However, in large doses, it contributes to a stressful lifestyle, to operating in crisis management mode, and to a compromised ability to reflect, to make decisions, and to think creatively. In a 24/7, always-on world, continuous partial attention used as our dominant attention mode contributes to a feeling of overwhelm, over-stimulation and to a sense of being unfulfilled. We are so accessible, we’re inaccessible. The latest, greatest powerful technologies have contributed to our feeling increasingly powerless.

Is this theory U.S. centric?

In my research to date, most of the examples and time frames are U.S. centric. However, in looking at other cultures, there appears to be a similar flow from one dominant attention paradigm into the next. We may not all find ourselves in the same attention era at the same time. We are likely to find ourselves experiencing a flow: attraction to an ideal, taking the expression of the ideal to an extreme and experiencing unintended and less than pleasant consequences, giving birth to and launching a new ideal while integrating the best of what came before.

How does this play out with different generations?

The younger generations are on the leading edge of thought for the coming dominant attention paradigm. This is one of the many reasons why the most successful companies are likely to effectively recruit, employ, incent, and manage representatives from every generation and keep an active listening channel toward the ideas and ideals, and the habits and passions of the younger generation.

When I’ve interviewed 18-22 year olds, I notice that they are often using communications technology in a mode that I call “semi-sync.” It’s not quite synchronous and it’s not really asynchronous communication either. Text messaging is often used in a semi-sync way.    When Jyri Engestrom, Jaiku co-founder, demonstrates Jaiku, he describes semi-sync usage patterns. Meanwhile, Matt Webb, in collaboration with Nokia, is experimenting with interfaces that ease the stress of continuous partial attention.   Jyri is actively looking at ways to manage activity streams as well as interoperability issues.

Many in the generation now entering the workforce view phone calls as intrusive and prefer text messaging. In interviews, orbits of communication are described:   My Space to keep up with a wide set of friends and acquaintances, text messaging for both one to one and one to many communications and, for one’s closest friends, phone calls.

What do we do about it?

We have focused on managing our time. Our opportunity is to focus on how we manage our attention. We are evolving beyond an always-on lifestyle. As we make choices to turn the technology OFF, to give full attention to others in interactions, to block out interruption-free time, and to use the full range of communication tools more appropriately, we will re-orient our trek toward a path of more engaged attention, more fulfulling relationships, and opportunities for the type of reflection that fuels innovation.

BREATHE. Notice what happens to your breath as you pull down and check your email or vmail. Most of us hold our breath. Some of us tighten our upper body. If we’re aware of what we’re doing and we are able to manage our breath — that is, keep breathing — the stress response is minimized.

How do we react to friends and loved ones who just can’t put the phone or Blackberry away — there are a range of approaches.   When you sit down to a meal, you can let them know that you’re putting your phone/Blackberry away so you can focus your attention on them. You can let them know you’re expecting one call you need to take for 2 minutes, and after that, you’ll be putting your device away. You can choose activities that require full attention or activities that you would be able to enjoy whether they were on their Blackberry or not.

Why care?

There is a wonderful evolution taking place. Understanding how it’s unfolding offers insights into what drives us and what inspires us.

via lindastone.net

The Architecture of Participation - O'Reilly Media

2011-10-19T17:03:00.001+08:00

The Architecture of Participation

by Tim O'Reilly
June 2004

I've come to use the term "the architecture of participation" to describe the nature of systems that are designed for user contribution. Larry Lessig's book, Code and Other Laws of Cyberspace, which he characterizes as an extended meditation on Mitch Kapor's maxim, "architecture is politics", made the case that we need to pay attention to the architecture of systems if we want to understand their effects.

I immediately thought of Kernighan and Pike's description of the Unix software tools philosophy referred to above. I also recalled an unpublished portion of the interview we did with Linus Torvalds to create his essay for the 1998 book, Open Sources. Linus too expressed a sense that architecture may be more important than source code. "I couldn't do what I did with Linux for Windows, even if I had the source code. The architecture just wouldn't support it." Too much of the windows source code consists of interdependent, tightly coupled layers for a single developer to drop in a replacement module.

And of course, the Internet and the World Wide Web have this participatory architecture in spades. As outlined above in the section on software commoditization, any system designed around communications protocols is intrinsically designed for participation. Anyone can create a participating, first-class component.

In addition, the IETF, the Internet standards process, has a great many similarities with an open source software project. The only substantial difference is that the IETF's output is a standards document rather than a code module. Especially in the early years, anyone could participate, simply by joining a mailing list and having something to say, or by showing up to one of the three annual face-to-face meetings. Standards were decided by participating individuals, irrespective of their company affiliations. The very name for proposed Internet standards, RFCs (Request for Comments), reflects the participatory design of the Net. Though commercial participation was welcomed and encouraged, companies, like individuals, were expected to compete on the basis of their ideas and implementations, not their money or disproportional representation. The IETF approach is where open source and open standards meet.

And while there are successful open source projects like Sendmail, which are largely the creation of a single individual, and have a monolithic architecture, those that have built large development communities have done so because they have a modular architecture that allows easy participation by independent or loosely coordinated developers. The use of Perl, for example, exploded along with CPAN, the Comprehensive Perl Archive Network, and Perl's module system, which allowed anyone to enhance the language with specialized functions, and make them available to other users.

The web, however, took the idea of participation to a new level, because it opened that participation not just to software developers but to all users of the system.

It has always baffled and disappointed me that the open source community has not claimed the web as one of its greatest success stories. If you asked most end users, they are most likely to associate the web with proprietary clients such as Microsoft's Internet Explorer than with the revolutionary open source architecture that made the web possible. That's a PR failure! Tim Berners-Lee's original web implementation was not just open source, it was public domain. NCSA's web server and Mosaic browser were not technically open source, but source was freely available. While the move of the NCSA team to Netscape sought to take key parts of the web infrastructure to the proprietary side, and the Microsoft-Netscape battles made it appear that the web was primarily a proprietary software battleground, we should know better. Apache, the phoenix that grew from the NCSA server, kept the open vision alive, keeping the standards honest, and not succumbing to proprietary embrace-and-extend strategies.

But even more significantly, HTML, the language of web pages, opened participation to ordinary users, not just software developers. The "View Source" menu item migrated from Tim Berners-Lee's original browser, to Mosaic, and then on to Netscape Navigator and even Microsoft's Internet Explorer. Though no one thinks of HTML as an open source technology, its openness was absolutely key to the explosive spread of the web. Barriers to entry for "amateurs" were low, because anyone could look "over the shoulder" of anyone else producing a web page. Dynamic content created with interpreted languages continued the trend toward transparency.

And more germane to my argument here, the fundamental architecture of hyperlinking ensures that the value of the web is created by its users.

In this context, it's worth noting an observation originally made by Dan Bricklin in his paper, The Cornucopia of the Commons. There are three ways to build a large database, wrote Dan. The first, demonstrated by Yahoo, is to pay people to do it. The second, inspired by lessons from the open source community, is to get volunteers to perform the same task. The Open Directory Project, an open source Yahoo competitor, is the result. (Wikipedia provides another example.) But Napster demonstrates a third way. Because Napster set its defaults to automatically share any music that was downloaded, every user automatically helped to build the value of the shared database.

This architectural insight may actually be more central to the success of open source than the more frequently cited appeal to volunteerism. The architecture of Linux, the Internet, and the World Wide Web are such that users pursuing their own "selfish" interests build collective value as an automatic byproduct. In other words, these technologies demonstrate some of the same network effect as eBay and Napster, simply through the way that they have been designed.

These projects can be seen to have a natural architecture of participation. But as Amazon demonstrates, by consistent effort (as well as economic incentives such as the Associates program), it is possible to overlay such an architecture on a system that would not normally seem to possess it.
Note: I had mistakenly attributed the insight about three ways to build a shared database to Clay Shirky when it had originated from Dan Bricklin. Read more in this Radar blog entry.

via oreillynet.com

danah boyd | apophenia » answers to questions from Twitter on teen practices

2011-10-19T15:35:00.001+08:00

Before I headed to Atlanta to do fieldwork, I asked folks who follow me on Twitter (@zephoria) what questions I should ask teens. Many of the questions that I received were more general questions about teens, rather than questions for teens. Still, I’m going to take a stab at very briefly answering some of the questions that I received based on what I know and what I learned. I am not answering the larger questions that would require pages and pages and my apologies if my short answers are not sufficient but I wanted to at least respond. Thank you all who contributed questions and my apologies if I didn’t answer yours.

To all who asked questions about Twitter: average teens don’t use Twitter. They may in the future, but they do not now. Those who do are early adopters and not representative of any mainstream teen practice. Because of Oprah and celebs, some teens are starting to hear about it, but they don’t understand it and they aren’t using it.

@connyb: Parents’ concerned with what kids do online, right? I’d ask teens if they know what exactly their parents do at their dayjobs.

Teens do not tend to know exactly what their parents do, nor do they particularly care. (It’s important to note that parental concern stems from a position of power, not interest in the actual activities.)

@mauraweb: when they’re searching for info, how do they know what info to trust? esp. w/internet searches

Media literacy amongst teens is extremely varied, but the short answer is that most don’t know what to trust. They know that they are not supposed to trust Wikipedia because it’s editable (and they automatically recall Wikipedia when you ask about trustworthy information.. that’s so actively hammered down their throat, it’s painful). One girl told me that she trusts websites that “look” like they are reputable. When I asked her about this, she told me that she could “just tell” when something was a good source. And besides, it came from Google. Le sigh.

@AlterSeekers: According to Facebook Era, Teens see email as a “work” tool and prefer to Facebook message. Is this true among these teens?

I was surprised to find that email is deader than ever among teens. As more of their parents and teachers are getting on Facebook (or MySpace), they see little reason to email with anyone. Thus, email is increasingly needed for having an account on various sites and for getting access to or sending attachments. But even when teens do use email for “work”, they do not use it for social purposes.

@mirroredpool: What borders to teens place of social networking sites and education? How would they react to using an SNS to do class work?

@annejonas: i’m curious if they want schools involved in social networks or if they like it as a social space outside the realm of formal edu.

This is messy. Many teens have ZERO interest in interacting with teachers on social network sites, but there are also quite a few who are interested in interacting with SOME teachers there. Still, this is primarily a social space and their interactions with teachers are primarily to get more general advice and help. In some ways, its biggest asset in the classroom is the way in which its not a classroom tool and not loaded this way. Given that teens don’t Friend all of their classmates, there are major issues in terms of using this for groupwork because of boundary issues.

@shcdean: What future do they see for FB or Twitter.

They don’t use Twitter. When asked, teens always say that they’ll use their preferred social network site (or social media service) FOREVER as a sign of their passion for it now. If they expect that they’ll “grow out of it”, it’s a sign that the service is waning among that group at this very moment. So they’re not a good predictor of their own future usage.

@lazygal: Do they really care about/use school library websites? Twitter? Pageflakes? Libguides? or only if teacher insists?

Nope, they don’t. All but Twitter are categorized as school tools and are only used when absolutely necessary and Google won’t suffice.

@anindita: My favorite question: read anything good lately?

I asked “Recent book that you enjoyed” on my questionnaire. Half said “none” and most said books they read in school (with a *). Books that were mentioned: City of Bones, Ashes & Glass, A Year of Impossible Goodbyes, The Outsiders*, Drama High Series, Mice and Men*, Catcher in the Rye*, The Poisonwood Bible*, Twilight series (twice).

@texas_sooner: I’d be interested to know if teens denied access to SNS (by parents/choice/SES reasons etc ) feel left out/pressure to join, etc.

Parental restrictions are a huge source of frustration because of a sense of isolation. (As a result, they are typically ignored.) SES is not actually a predictor of non-use at this point except in more rural regions where Internet access is generally absent for the majority of teens. In these cases, teens don’t feel left out because they aren’t being socially isolated by it.

@SavvyPriya: what is one thing that teens are passionate about?

This varies across teens, but God comes up a lot. The only thing that really competes is friends. Family is also important to some teens. School and sports are also important to some teens. And then some teens have particular hobbies or activities that they love. But God and friends really dominate the passion list.

@paullowe: where do they get their news from and what kind of news do they want to get

Teens primarily get their news from word-of-mouth, not directly from any particular source. School current events and TV time are the other dominant place I hear about. Otherwise, it’s generally osmosis. They walk through the living room when their parents are watching the news. Or they pass by a news article when they get online. But they are not directly and intentionally consuming much news at all.

@thornet: ask ‘em how they judge whether a news outlet is credible.teens r good @ spotting fakes & phonies;wonder what their news criteria r

They don’t watch a lot of news and they have no media literacy training and they’re not even thinking about credibility of news.

@andrewmiller: how does having a smartphone change their interactions w/each other on SNS? more photos/videos? faster rumors? have/have-not gap?

A gap is definitely occurring. A smart phone means more more more more more – more SMS, more web consumption, more status updates, more photos, etc. Certain smart phones are desperately desired items. That said, teens are also doing quite well with the iPod Touch + wifi as an alternative. Smart phones are helping them stay more engaged and connected.

@shawncalhoun: Were teens more engaged in politics by Obamas #socialmedia storm? If so has engagmnt continued evolved in2 something new or faded?

Most teens are pretty oblivious to his social media practices. That’s actually hitting the college/20-somethings more.

@alexleavitt: Ask them if they feel like they’ll want to develop the social Net when they get older: eg., developers developers developers.

No. Most don’t associate using social media with computer science or developing software whatsoever. And the classes on programming in their schools aren’t helping.

@pbernard: do they still care about changing the ringtone on their phone, even though they make less and less calls?

Ringtones are tricky with American youth because it very much depends on who pays for the phone/ringtones. Among teens who can change their ringtones whenever they want, there’s still motivation. The phone still rings (and beeps with new SMSes) and having a cool sound is desired. But of course many teens spend most of their day with their phones on buzz-only.

@harraton: Do they care about their privacy?

VERY much so. But what constitutes privacy for them is often quite different than what constitutes privacy for adults. Privacy is not dead.

@simonchambers: I’d ask how they see themselves helping to solve problems like climate change and extreme poverty…

They don’t. Most teens are not that engaged with larger societal issues (except as activities to get into college). This makes sense – they are not part of public life. They have no voice. They don’t hear the debates. They aren’t exposed to much beyond their narrow worlds. And, for most of them, their parents aren’t involved either.

@dougthomas: Teens; what are their thoughts about downloading songs? films? software? without paying for it.

They want access. Their parents won’t pay for it. They don’t have credit cards. They get what they are looking for by any means necessary. And those who get access to it traffic in that content among their peers who may be less technologically savvy/economically privileged.

@jamesb: how does their mobile contacts differ from social network contacts? When do they crossover?

Mobile consists of their closest friends because of the economics of the phone. Social network sites are their broader peer group. Their closest friends are a subset of their broader peer group.

@alfredtwo: Do teens view all adults in social networking the same or are parents a special case? Young relatives friend me not their parents

Depends on the teen, but many are happy to connect with adults who don’t directly hold power over them or who they “trust” – aunts, older cousins, youth pastors, “cool” teachers, etc.

@mjmantey: how aware are they of general advertising/marketing ways and means?

If it has advertising, they think that it means that it’ll be free for a long time. But they don’t really think much about it.

@mojo_girl: how many email accounts do they have that parents don’t know about- do they use same password 4 all #socialmedia ? #teens

They don’t use email so it’s more a matter of which ones they forgot about. They often forget their passwords so I would guess that they don’t use the same password consistently. Of course, they also share certain passwords with their closest “trusted” friends so that gets messy really fast. And they change it when there’s a breakup.

@matlockmatlock: OMGSEXTINGWTF?

Continuing to be present and very very messy. Sharing of naked photos seems to be more prevalent in certain teen groups than others and I’m still trying to work out what this means.

An interesting question from the comments:

maxoid: is there any data on teen usage of Capitalization and proper grammar vs. SMS-shorthand and all-lowercase? (is format now used as a way to stand out from adults as much as langauge has long been?)

You can definitely look to certain subcultural practices to witness distinctions, such as the culture around AzN pRiDe. But there are huge differences between linguistic practices that are meant to be distinct and culturally resistant (such as those that are actually hard to produce) and those that are meant to make communication easier (fast IMing) or accommodate techno-economic limitations (160 chars). It’s important to remember that a lot of our writing (and speaking) is intentionally redundant to account for issues in hearing and penmanship. With typing, a lot of this falls by the wayside and it’s hard to argue against shorthand except to cling to inertia. Language changes. New genres of media change language. Expect things to change. Expect new generations to be pulled between what they will see as “obvious” shifts and what they’ll be forced to accommodate by those who demand status quo.

via zephoria.org

113 Design Guidelines for Homepage Usability (Nielsen Norman Group)

2011-10-16T17:42:00.001+08:00

113 Design Guidelines for Homepage Usability

Summary:
These design guidelines are excerpted from our book Homepage Usability: 50 Websites Deconstructed which contains more details, including copiously annotated screenshots of 50 homepages.

While many of these guidelines can apply to web design in general, they are especially critical to follow when designing your homepage, because the stakes are so high. Your homepage is often your first — and possibly your last — chance to attract and retain each customer, rather like the front page of a newspaper. One of the biggest values of a newspaper's front page is the priority given to top news items. All homepages would benefit from being treated like a front page of a major newspaper, with editors who determine the high-priority content and ensure continuity and style consistency.
Even small changes to homepages can have drastic effects. Consider the homepage for The New York Times. If you kept all design and writing exactly the same on this site but decided to show only local New York content on the homepage and link to all national and international news, it would inexorably alter the entire site. On closer examination, this change doesn't seem small at all.
While we encourage you to use these guidelines as a checklist when designing your homepage, recognize that they are written in an abbreviated manner here. You'll need to look at the individual site examples to see these guidelines used properly or, more often, overlooked. This is an extensively illustrated book, and it is only in the context of a visual example that you can fully appreciate the negative impact of ignoring these guidelines.
All said, these are just guidelines, not axioms. For all sites, there are surely exceptions. However, we've developed these guidelines from our combined 14 years of experience, running user tests on homepages and observing what makes them pass or fail user scrutiny. Although you can greatly improve the usability of your homepage by following these guidelines, you also need to involve your own users in the process through methods such as field studies and usability testing and incorporate iterative feedback into your development cycle. If you make a decision not to follow a guideline, do so based on customer information in the context of your homepage.
What's Not in These Guidelines
In an effort to limit the focus specifically to homepage guidelines, there are several important issues we do not address. Most of these topics deserve a level of detail that we feel is best left to separate books and reports, many of which exist already and are listed here.
Determining Homepage Content
One of the most important design decisions for any homepage is determining what content merits homepage coverage. We don't address this issue in these guidelines because it depends on each site's users and tasks, as well as the company's business goals. Unfortunately, many companies' corporate politics drive homepage design more than users' needs do. Often many departments are lobbying for homepage real estate, and the best lobbyists win. We encourage you to champion users' needs as the key factor in design decisions and to involve users throughout your design process.
There are several usability methods that can identify and prioritize users' needs based on real data and observation. This is not the place to go into details about user testing, task analysis, field studies, or usability engineering methodology and process in general. These topics each require their own book, and indeed several such books have been written and continue to be written. We maintain a set of web pages at http://www.useit.com/books, with references and links to those books that we recommend the most at any given time.
General Web Design
We have limited our guidelines to those that are critical for successful homepage usability, although many would improve the usability of other web pages as well. Similarly, many, if not most, of the guidelines for the design of general web pages, web content, and web navigation would increase the usability of homepages. After all, a homepage is a web page, and thus homepage designers should consider all of the guidelines for web usability, not just those that are specific to homepages. For detailed information on general web design, see our other book, Prioritizing Web Usability.
Vertical Industry Segments
We don't address special design considerations for vertical industry segments, such as homepages for software companies, conferences, or dentists. For every industry or type of company, there will be many detailed guidelines that address the ways customers of such companies expect to interact with websites and the best ways to serve those users' needs.
We cannot provide a set of generic vertical guidelines. That would be a contradiction in terms. The only way to generate vertical design guidelines is to study each industry's users and their tasks. Our preferred approach for doing so is the comparative usability test, which generalizes findings across a broad variety of sites within a given vertical segment. This is not the place for a discussion of how to run a comparative study; instead we refer you to a report that details the methodology used to derive hundreds of guidelines for e-commerce usability from several rounds of testing of multiple such websites. This methodology report is available from http://www.NNgroup.com/reports/ecommerce/methodology.html.
Accessibility
While some of our individual site reviews point out major design issues that would impede people using assistive technology, accessibility is too large a topic to do due diligence in these guidelines. We refer you instead to our detailed guidelines for accessibility at http://www.NNgroup.com/reports/accessibility.
International Users
While we point out a few guidelines for serving international users in this book, we refer you to our detailed guidelines at http://www.NNgroup.com/reports/ecommerce/international.html.
See also "International User Interfaces," by Elisa del Galdo and Jakob Nielsen.
The Guidelines
The following sections contain our 113 guidelines for ensuring homepage usability. The guidelines are categorized by topic area, and most give examples from the homepage reviews, which you can find in alphabetical order in the full Homepage Usability: 50 Websites Deconstructed book.
Updated Findings
These guidelines were written in 2001, and the examples refer to the design of various homepages that year. Despite the age, the guidelines have held up well — something that's usually true for usability guidelines which don't change much over time.
For an update, we present the newest usability guidelines and fresher examples from more recent user testing in the full-day tutorial on Fundamental Guidelines for Web Usability at the annual Usability Week conference.
The conference also has full-day training courses on the Principles of Interface Design and The Human Mind and Usability: How Your Customers Think for a broader perspective on why certain user interfaces work better than others, as well as more specialized topics like Information Architecture (IA) and mobile usability.
Communicating the Site's Purpose
Imagine how disorienting it would be to walk into a store and not be able to tell immediately what services or goods were available there. The same is true of your homepage. It must communicate in one short glance where users are, what your company does, and what users can do at your site. If your site misses the mark here, it's nearly impossible to recover. Why should users do anything at a site if they can't figure out what there is to do there? And yet in countless user studies, we've seen users staring right at the homepage, unable to satisfactorily answer the question "What is the purpose of this site?" In order to communicate well, homepages must give appropriate emphasis to both branding and high-priority tasks. The homepage must also have a memorable and distinct look, so that users can recognize it as their starting place when coming from any other part of the site.

Show the company name and/or logo in a reasonable size and noticeable location. This identity area doesn't need to be huge, but it should be larger and more prominent than the items around it so it gets first attention when users enter the site. The upper-left corner is usually the best placement for languages that read from left to right.
Include a tag line that explicitly summarizes what the site or company does. Tag lines should be brief, simple, and to the point. For example, Global Sources' tag line, "Product and Trade Information for Volume Buyers," is a good, straightforward summary of what the site offers (we did, however, offer minor suggestions for improvement in the homepage review). Vague or jargonistic tag lines only confuse users, or worse, make them mistrust the site, especially if users perceive them as marketing hype. For example, Ford's tag line, "Striving to Make the World a Better Place," while pluckily optimistic, doesn't describe Ford's automotive business in any way.
Tag lines might not be necessary when the company name itself explains what the company does, such as the Federal Highway Administration, or if the company is extremely famous, such as Microsoft. If your company has many sites or services, the tag line for the main company homepage should summarize what the company is all about, and the subsites should have their own tag lines explaining the purpose of that particular site or service.
Emphasize what your site does that's valuable from the user's point of view, as well as how you differ from key competitors. The tag line is a great place to do this, if you can do it succinctly. For example, Wal-Mart frequently differentiates itself from competitors in advertising media by claiming that it offers the lowest prices, but doesn't say so anywhere on its homepage except for a brief mention in the title bar. A simple tag line that stated this differentiator would give users unfamiliar with the company an instant sense of what the site can offer them.
Emphasize the highest priority tasks so that users have a clear starting point on the homepage. Give these tasks a prominent location, such as the upper-middle of the page, and don't give them a lot of visual competition. In other words, if you emphasize everything, nothing gets focus. Keep the number of core tasks small (1–4) and the area around them clear. For example, a financial news website, like CNNfn, should devote prime real estate to high-priority tasks like checking a stock quote, getting the current summary of the major U.S. stock markets, and getting a summary of the current financial news headlines. The most challenging, yet most critical, aspect of this guideline is actually determining what the highest priority tasks are from the user's perspective. You must have a deep understanding of your users' needs, which is best acquired by studying your users in the context in which they will use your website before you begin the homepage design.
Clearly designate one page per site as the official homepage. Within the site, restrict the use of the terms "Home" and "Home Page" to refer to this one main homepage and use a different term for the front pages of departments or subsites. Users should never face multiple "Home" buttons or links that go to different places. Of course, if your company is a conglomerate, the main homepage will likely link to other separate sites that have a clear identity and unique homepage apart from the parent company. For example, Philip Morris has a separate homepage for Miller Brewing Company (a subsidiary) that is linked to from the Philip Morris homepage.
On your main company website, don't use the word "website" to refer to anything but the totality of the company's web presence. Specifically, don't use it to refer to subsites or departments. Using "website" to refer to parts of the site separates, rather than unites, your company's total offerings and it can confuse users, who naturally think that a different website means that they are going to a different company. For example, Ford's homepage uses an icon to mark links to external websites. However, Ford only uses this icon next to the link for its dealer finder, making it seem like it isn't part of the company. From the user's' perspective, of course, getting information about the cars and getting information about where to buy the cars are all parts of the same task.
If you offer web applications or services on separate websites, some users might go straight to a service website without going through the corporate homepage. It's fine to refer to those subsites as websites on the specific sites themselves, but from the corporate homepage it's better to present them as major categories. This portrays them as part of your total offering, rather than separate from it. For example, the Philip Morris website lists its subsidiaries, such as Kraft Foods International Inc., as part of its "Family of Companies," but doesn't label them as websites.
Design the homepage to be clearly different from all the other pages on the site. Either use a slightly different visual design (that still fits with the look and feel of the site) or have a prominent location designator in the navigational apparatus. This visual distinction and navigational signposting ensures that users can recognize their starting point when they return from exploring a new part of the site.

Communicating Information About Your Company
In addition to the homepage tag line, all business websites need to provide a clear way to find information about the company, no matter how big or small the company is, or how simple or complex the range of products or services are. People like to know with whom they are doing business, and details about the company give credibility to the site. For some websites, such as those for large conglomerates, getting company information might be the sole reason that users come to the site. Yet even for sites that deliver a simple web service, many users still want to know who is behind the service.
These guidelines also apply to government sites and to sites for many other types of not-for-profit organizations, although some of the details may vary. For example, a government agency would not need an Investor Relations link. It is a common mistake, especially on government homepages, to play up the wrong kinds of information about the agency. People need to be able to find out how the organization is structured and who runs it, but they do not need to have an interface that's designed to emphasize internal bureaucratic structure or one that promotes the current minister or department head at the expense of granting citizens fast access to the services and information they need.

Group corporate information, such as About Us, Investor Relations, Press Room, Employment and other information about the company, in one distinct area. This grouping gives people who want the information a clear and memorable place to go. It also helps users who don't care about this information by separating it from the rest of the homepage content. (See also our separate reports with much more detailed guidelines on "About Us", IR, and PR.)
Include a homepage link to an "About Us" section that gives users an overview about the company and links to any relevant details about your products, services, company values, business proposition, management team, and so forth. The recommended name for this link is "About <name of company>." (See also our separate report with 50 design guidelines for the "About Us" section of a website.)
If you want to get press coverage for your company, include a "Press Room" or "News Room" link on your homepage. Journalists appreciate and rely on sections like these when trying to cover a particular company. For more information on optimizing web design for press relations, see http://www.NNgroup.com/reports/pr.
Present a unified face to the customer, in which the website is one of the touchpoints rather than an entity unto itself. Don't separate your web presence from the rest of your company by referring to "Company.com" as different from "Company." Your customers should feel they are dealing with one indivisible, consistent company. It is important, however, to make distinctions between web-only services and services listed on the site that are available only through a different medium. For example, a television station might offer webcasts that are available only on the website as well as list information for programs that are available only on television. Users need to understand where to go for which service.
Include a "Contact Us" link on the homepage that goes to a page with all contact information for your company. If you want to encourage site visitors to contact your company directly, instead of seeking information on the website first, include contact information such as the primary address, phone number, and email directly on the homepage.
If you provide a "feedback" mechanism, specify the purpose of the link and whether it will be read by customer service or the webmaster, and so forth.
Don't include internal company information (which is targeted for employees and should go on the intranet) on the public website. Not only does this internal information clutter the public website, it can actually be misleading if users think that internal policies are directed toward them. For example, Slusser's homepage links to its company's internal policy for computer resources, including guidelines for appropriate web usage, which could worry some users that Slusser's knows more about their web surfing habits than is actually the case. Job postings are an example of largely company-focused content that might be beneficial on both intranet and public sites, however, because they are chiefly targeted at potential employees, not current ones.
If your site gathers any customer information, include a "Privacy Policy" link on the homepage.
Explain how the website makes money if it's not self-evident. If users cannot easily discover a business model (such as selling stuff or carrying advertising), their trust in the site will be lowered because they will fear that it has some hidden way of "getting" at them. People know that there is no such thing as a free lunch

Content Writing
Effective content writing is one of the most critical aspects of all web design. Most users scan online content, rather than carefully reading, so you must optimize content for scannability and craft it to convey maximum information in few words. Although this is a general web guideline, we're offering content writing guidelines here that are especially important for homepages, where you must work hardest to capture and hold your users' interest, and where you often have the least amount of space to represent the greatest number of topics.
A skilled editor is an essential part of effective content creation. The editor should not only set style standards but must also ensure that the site follows them consistently. The editor should develop or revise content specifically for web use — it's not enough to repurpose content from other mediums and post it to the homepage. Of course, the design team must also involve real users in this process, both when gathering initial requirements and when revising the design as the site evolves.

Use customer-focused language. Label sections and categories according to the value they hold for the customer, not according to what they do for your company. For example, on a heating oil site, what should you call a category of home energy tips?
On www.jamesdevaney.com, it's called "Consumer Information." This company-focused phrase is based solely on how the fuel company values this customer (as a consumer, not a business). Instead, think of how the customer would view the information, such as "Home Energy Tips." Ask customers what they look for when they need such information. Use the words they use.
Avoid redundant content. Repeating identical items, such as categories or links, on the homepage in order to emphasize their importance actually reduces their impact. Redundant items also clutter the page; all items lose impact because they are competing with so many elements. In order to feature something prominently, feature it clearly in one place. On the other hand, redundant content can help people if you repeat items that belong in multiple categories or you include links to the same page but offer synonyms that represent words your users use to describe the content.
Don't use clever phrases and marketing lingo that make people work too hard to figure out what you're saying. For example, the "Dream, Plan, & Go" category on Travelocity might sound catchy to a marketing person, but it's not as straightforward as "Vacation Planning." Every time you make users ponder the meaning behind vague and cutesy phrases, you risk alienating or losing them altogether. Users quickly lose patience when they must click on a link just to figure out what it means. This isn't to say that homepage text should be bland, but it must be informative and should be unambiguous.
Use consistent capitalization and other style standards. Otherwise users read meaning into things when they shouldn't. For example, if some items in a list follow sentence-style capitalization, but one item uses initial uppercase letters, the inconsistency gives that one item undue emphasis over the other items. Usually this kind of inconsistency happens not by design, but because the content comes from different sources and isn't appropriately edited for consistency. Although these small mistakes might seem nitpicky, they can cause users to feel that the site is unprofessional or untrustworthy. We also advise against the popular style of using all lowercase letters for titles, categories, and other links. Not only is it not as scannable as mixed case, but also invariably you'll need to break with the style standard for a proper name, which will look inconsistent.
Don't label a clearly defined area of the page if the content is sufficiently self-explanatory. For example, it is usually not necessary to label the main news headline of the day because the size and placement indicate its role. Similarly, if you have a boxed area where you feature a product, it's probably not necessary to give it a generic title such as "Featured Product." Titles often are meaningless space wasters.
Avoid single-item categories and single-item bulleted lists. It's overkill to categorize one item, and things that don't fit into existing categories can signify a need to rewrite or reorganize the content. See Asia Cuisine for an example.
Use non-breaking spaces between words in phrases that need to go together in order to be scannable and understood. ( ) Most homepages use multicolumn layouts, and text must fit into narrow spaces. Because there are many possibilities for where text breaks depending on the user's screen resolution, monitor size, window size, browser version, and so forth, forcing certain phrases to stay together can maintain the integrity and logic of the content.
Only use imperative language such as "Enter a City or Zip Code" for mandatory tasks, or qualify the statement appropriately. For example, you might say, "To See Your Local Weather, Enter a City or Zip Code." People are naturally drawn to text that tells them what to do on a site, especially if it is next to a recognized widget, such as an input box or a dropdown menu, and often dutifully follow instructions because they think that they must do what the instructions say.
Spell out abbreviations, initialisms, and acronyms, and immediately follow them by the abbreviation, in the first instance. This is helpful for all users, especially for anyone using a screen reader. For example, the Federal Highway Administration's homepage refers several times to the "MUTCD" but fails to explain on the homepage that this is short for "Manual on Uniform Traffic Control Devices." Abbreviations that have become widely used words, such as DVD, are exceptions to this guideline. Especially avoid using unexplained abbreviations as navigation links.
Avoid exclamation marks. Exclamation marks don't belong in professional writing, and they especially don't belong on a homepage. Exclamation marks look chaotic and loud — don't yell at users. If you break this guideline once, you're likely to start breaking it all over the homepage, because all items on the homepage should be of high importance.
Use all uppercase letters sparingly or not at all as a formatting style. All uppercase words are not as easy to read as mixed case words, and they can make the page look busy and loud. For example, "PSYCHOLOGY OF WORDS" is not as readable as "Psychology of Words."
Avoid using spaces and punctuation inappropriately, for emphasis. For example, L O B S T E R S or L.O.B.S.T.E.R.S. might look interesting to you but would foil a user who was searching for "lobsters." Unusual punctuation also reduces scannability and would be annoying to visually impaired users whose audio browsers spell out the word instead of reading it as a word.
Content usability is covered in more depth in our 2-day training course on Writing for the Web at the annual Usability Week conference.
Revealing Content Through Examples
Showing examples of your site's content on the homepage helps users in many ways. First, example content can help instantly communicate what the site is all about, so users know whether they are on the right site for their needs. Second, examples can reveal the breadth of products or content offered at your site. Third, specifics are more interesting than generalities. You stand a better chance of piquing user interest if you provide something concrete to read or look at instead of just abstract category names. Last, and probably most important, examples can help users successfully navigate, because they show what lies beneath the abstract category names. Examples help differentiate categories, saving users from clicking through categories just to see what's there.

Use examples to reveal the site's content, rather than just describing it. Well-chosen examples of content can convey much more than words alone. For instance, a category called "Breaking News" with a description that says "Get All of Today's Top Stories Here" is not nearly as interesting or informative as showing the top five news headlines, followed by a link to all breaking news. Or, on an e-commerce site, a simple category called "Sale Items" is not as compelling as seeing a few actual products that are on sale, complete with their prices. Often it takes more words and space to describe a category than it does to show some of that category's contents and link to more information. In brick-and-mortar stores, customers rely on examples to orient themselves and find the items they need. Similarly, homepages should show small pictures of the products or other content in each department, so users can do a quick visual sweep to see if they are in the right place. Examples also help users who don't read your site's language very well.
For each example, have a link that goes directly to the detailed page for that example, rather than to a general category page of which that item is a part. Don't put the burden on the user to find the item they're interested in once again on the second page. For instance, if your homepage features news coverage of a film festival, and you show a photo and caption for a specific film, those items should link directly to information about that particular film, not a general page for the festival. The exception is examples that are so short and self-contained that there is no more information about them deeper within the site.
Provide a link to the broader category next to the specific example. If you prominently feature a single product, service, or article on the homepage, make sure that the rest of the page clearly communicates the full breadth of products, services, or content supported by the site (unless you are a one-product company), because people sometimes believe that the main feature is all there is. For example, if a job-listing site prominently features three listings in the medical industry with no adjacent link to "Listings in Other Industries," users might easily think that the site lists jobs only for medical personnel.
Make sure it's obvious which links lead to follow-up information about each example and which links lead to general information about the category as a whole. Do this both by wording and placement of the links. The link for the example should be directly next to the information about the example, while the link to the category should be offset with a small amount of whitespace. For example, if Amazon.com features a specific mystery novel on its homepage, it should have a link at the end of the description of the novel to "Complete Description and Reviews," as well as a link a bit lower in the section to "Complete Listing of Mystery Novels."

Archives and Accessing Past Content
Often, you have users who return to your site often or new users who are interested in what you've done before they found you. It's helpful to include archives to content that has recently moved off the homepage.

Make it easy to access anything that has been recently featured on your homepage, for example, in the last two weeks or month, by providing a list of recent features as well as putting recent items into the permanent archives. If you rotate content of featured stories or products, make sure to include a link to the other featured stories or products. If the featured story will be moved to another URL after it rotates off the homepage, make a link to the URL for the permanent location right away so people can bookmark the permanent link instead of the temporary link.

Links
Links are obviously not unique to homepages, but because homepages serve as the portal to the site and thus tend to have more links than typical site pages, following design guidelines for homepage links is especially crucial to user success.

Differentiate links and make them scannable. Begin links with the information-carrying word, because users often scan through the first word or two of links to compare them. Keep links as specific and brief as possible. Don't include obvious or redundant information in every link — adding non-differentiating words makes users work harder to find the important words. For example, if you list press releases for your company and every one of them begins with the company name, it's difficult to quickly get the gist of each press release by scanning through the list. Or, if the proper names of your subsidiaries include the company name, such as "FedEx Express," "FedEx Ground," "FedEx Home Delivery," listing them as such presents users with a column of identical words ("FedEx"), and they must read through all of the links carefully to glean the difference.
Don't use generic instructions, such as "Click Here" as a link name. Instead, use meaningful text in the link names to tell users what they'll get when they click. This helps users to quickly differentiate between links when they are scanning through them. For example, instead of saying "Click Here for Layette Items" just say "Layette Items."
Don't use generic links, such as "More…" at the end of a list of items. Instead, tell users specifically what they will get more of, such as "More New Fiction" or "Archived Book Reviews." Generic "More…" links are especially problematic when the page has several of them, since users can't easily differentiate between them when scanning the page.
Allow link colors to show visited and unvisited states. Reserve blue for unvisited links and use a clearly discernable and less saturated color for visited links. Although some sites are now using gray for visited links, we recommend against doing so because it is difficult to read and has been widely used in user interfaces to mean that something is unavailable. Similarly, it is unhelpful to use black for visited links when the text color is black, because it can cause people to have trouble finding the links they visited before.
Don't use the word "Links" to indicate links on the page. Show that things are links by underlining them and coloring them blue. Never name a category "Links" by itself — this is akin to labeling a category of information "Words" in a print medium. Name the category after what the links are pointing to.
If a link does anything other than go to another web page, such as linking to a PDF file or launching an audio or video player, email message, or another application, make sure the link explicitly indicates what will happen. For example, CNNfn uses icons quite effectively to indicate audio and video files as such. Being thrust into a new medium without warning is startling for any user, but is especially agonizing for users with slow connections, who often have to wait for the new application to load just so they can exit out of it. Worse, in a limited memory situation, launching a helper application or memory-intensive plug-in can crash the browser or computer.

Navigation
Because the primary purpose of a homepage is to facilitate navigation elsewhere on the site, it's critical that users be able to find the appropriate navigation area effortlessly, differentiate between the choices, and have a good sense of what lies beneath the links. Users should not have to click on things just to find out what they are. The navigation area should also reveal the most important content of the site so that users have a good sense of what's there by looking at the top-level categories.

Locate the primary navigation area in a highly noticeable place, preferably directly adjacent to the main body of the page. Avoid putting any top horizontal navigation (primary or otherwise) above graphical treatments such as horizontal rules or banner areas — users often ignore anything within or above a rectangular shape at the top of the screen. We call this behavior "banner blindness," and we have seen it in numerous tests. See Microsoft's top navigation area, which begins with "All Products" for an example of navigation that many users will likely miss.
Group items in the navigation area so that similar items are next to each other. Grouping helps users differentiate among similar or related categories and see the breadth of products or content you offer. For example, group product categories for prescription medications and over-the-counter medications. Similarly, on an e-commerce site, all items related to shopping, such as the shopping cart, account information, and customer service should be in the same area.
Don't provide multiple navigation areas for the same type of links.Groups that are too similar can fragment and complicate the interface, making the user work too hard to create order and meaning.
Don't include an active link to the homepage on the homepage. For example, if you include a "Home" link as part of your regular navigation bar, it shouldn't be clickable on the homepage. If you use components, create a special component that is used only on the homepage with an inactive Home link. If it's clickable, some users will inevitably click it and wonder if the page has indeed changed. Similarly, if you link your logo to the homepage from other pages on the site, the logo shouldn't be clickable from the homepage. All other pages on the site do need a link to the homepage.
Don't use made-up words for category navigation choices. Categories need to be immediately differentiable from each other — if users don't understand your made-up terminology, it will be impossible for them to differentiate categories. For example, although Accenture uses the made-up word "uCommerce" for its flavor of e-commerce, they appropriately use the more familiar term "eCommerce" in the navigation bar. On the other hand, Disney's mysteriously named "Zeether" category will likely give both kids and adults an undesirable pause in the navigation area.
If you have a shopping cart feature on your site, include a link to it on the homepage. This allows users to immediately see what they've selected, without having to navigate through any product screens or go through checkout before they are ready to do so. This is especially important if your site saves shopping cart selections from prior visits.
Use icons in navigation only if they help users to recognize a class of items immediately, such as new items, sale items, or video content. Don't use icons when simple text links are clearly differentiable from each other, such as in category names. If you find that you need to ponder to come up with an icon for navigation, chances are it's not going to be easily recognizable or intuitive for users. For example, the icons for "Links" and "Forum" on Asia Cuisine don't help to further explain these categories or make them more immediately recognizable; they just clutter the page.
Much more depth in our full-day course on Navigation Usability at the annual Usability Week conference.
Search
Search is one of the most important elements of the homepage, and it's essential that users be able to find it easily and use it effortlessly. Our recommendations for the homepage treatment of search are fairly straightforward: make it visible, make it wide, and keep it simple. Of course, the real power of search is all in the implementation. For a much larger set of in-depth search guidelines, see http://www.NNgroup.com/reports/ecommerce/search.html.

Give users an input box on the homepage to enter search queries, instead of just giving them a link to a search page. Users now expect and look for an input box with a button next to it — if they don't see it, they often assume the site doesn't have a search feature. Try to find search on Boeing's, Coles', or Southwest's homepages, for examples of how difficult it is without input boxes as the visual cue to search.
Input boxes should be wide enough for users to see and edit standard queries on the site. Allow enough space for at least 30 characters in the font size used by most of the users.
Don't label the search area with a heading; instead use a "Search" button to the right of the box. This design is preferred because it is the simplest. "Go" is also acceptable as the action button for search, but requires that you label the area "Search." Place search at the top of the main body of the page, but below any banner area. This gives people the greatest chance of finding search when they need it. Even if you follow the other guidelines for search, it doesn't help if you place it in a low-priority position on the page. See ExxonMobil for an example of a poorly placed search input box.
Unless advanced searches are the norm on your site, provide simple search on the homepage, with a link to advanced search or search tips if you have them. If you have advanced search, but it is used infrequently, don't include a link to it on the homepage. Instead, offer users the option to do an advanced search when you present the search results.
Search on the homepage should search the entire site by default. Never hide search scope from users if you narrow their search in any way. Users nearly always assume that they've searched the entire site, unless you tell them otherwise, and assume the site doesn't have what they're looking for if they don't find it with search.
Don't offer a feature to "Search the Web" from the site's search function. Users will use their favorite search engine to do that, and this option makes search more complex and error prone.

Tools and Task Shortcuts
Homepage tools, or shortcuts to certain tasks, can be a great way to give prominence to popular features of your site and meet your users' needs more quickly. The key is to choose carefully which tasks to feature as tools on the homepage.

Offer users direct access to high-priority tasks on the homepage. These homepage tools should let users enter any required data directly on the homepage. If possible, consider giving users zero-click access to the answers, meaning that the homepage displays the most-needed information automatically. This kind of feature is typically possible only for sites that recognize the user and personalize the page to display information that user is likely to request as a first task, such as "Current Balance of Your Bank Account: $xx." More commonly, you can offer users one-click access to the answers, meaning that you load a separate page to display the results. For example, the Travelocity "Book Your Flight Now" feature is an effective one-click tool, which allows users to enter criteria for a desired flight directly on the homepage and then see the results on a separate page.
Don't include tools unrelated to tasks users come to your site to do. Some sites seem compelled to include tools simply because they are available, not because they are appropriate. For example, you don't need to offer users a tool to get their weather forecast if you have a non-news or non-weather site, such as James Devaney Fuel Company. Tools are one of the first things users look at on homepages because they often contain input boxes and dropdown menus, which users recognize and are attracted to, so don't show them unless they are truly essential and facilitate top-priority tasks.
Don't provide tools that reproduce browser functionality, such as setting a page as the browser's default starting page or bookmarking the site.

Graphics and Animation
When you use graphics to purposefully illustrate content, you can greatly enhance a homepage. On the other hand, graphics can weigh down the design in visual clutter and slow download times, so it's important to use them judiciously and edit them for the Web. Similarly, animation with a purpose can enhance online content — but it typically is best suited for more complex content than appears at the homepage level.

Use graphics to show real content, not just to decorate your homepage. For example, use photos of identifiable people who have a connection to the content as opposed to models or generic stock photos. People are naturally drawn to pictures, so gratuitous graphics can distract users from critical content.
Label graphics and photos if their meaning is not clear from the context of the story they accompany. If the level of specificity between the picture and the story differ, it's a good idea to label the picture. For example, if you have a story about a film festival and show a still photo from one of the films, label it to clarify both what it is and how it relates to the more general category. On the other hand, if you're using a picture in an iconic way to help users quickly identify what a story is about when scanning the page, you probably don't need to label it. For example, if you use a close-up of a medicine bottle with pills in it next to an article on a new drug approved by the FDA, you don't need to label it. It's usually a good idea to label any photos of people — it doesn't hurt people who recognize the person and can help people who can't match the face with the name.
Edit photos and diagrams appropriately for the display size. Overly detailed photos and drawings don't convey information and look cluttered. It's often unhelpful just to shrink a big photo — it's usually better to crop it. See ESPN for examples of well-cropped photos; see CNNfn's photo of the market floor for an example of a poorly cropped photo.
Avoid watermark graphics (background images with text on top of them) . They add clutter and often decrease visibility. If the graphic is interesting and relevant, users won't be able to see it clearly; if it's not, it's unnecessary. Often, watermark graphics are purely decorative and add no value. For example, Ford's busy watermark graphic nearly disguises the only car photo.
Don't use animation for the sole purpose of drawing attention to an item on the homepage. Animation rarely has a place on the homepage because it distracts from other elements. Animation requires a user's attention and should be shown by itself, whereas homepages have multiple elements requiring attention. For example, animation could be very helpful to show how to do a procedure that is easier seen than described, like swaddling a baby, but it wouldn't be appropriate to show it on a homepage, where it would draw attention from all other elements on the page.
Never animate critical elements of the page, such as the logo, tag line, or main headline. Not only do users tend to ignore animated areas because they look like ads, they're also difficult to read. Animation tends to have a hypnotic effect on viewers, so even if you get people to stare at animated elements, they're less likely to absorb and retain the information than if they'd seen it in a simpler format. For example, Asia Cuisine's logo is difficult to read because it is still only for a few seconds at a time — the rest of the time (no joke) it is being drawn onto the screen by a lobster.
Let users choose whether they want to see an animated intro to your site — don't make it the default. If you do ever automatically launch an animation without the user's request, provide an easy and noticeable way to turn it off.

Graphic Design
Graphic design most often hurts usability when it's used as a starting point for the homepage design, rather than as a final step to draw appropriate focus to a customer-centered interaction design. Graphic design should help lend a sense of priority to the interaction design by drawing the user's attention to the most important elements on the page.

Limit font styles and other text formatting, such as sizes, colors, and so forth on the page because over-designed text can actually detract from the meaning of the words. If text elements look too much like graphics, users tend to overlook them, mistaking them for ads.
Use high-contrast text and background colors so that type is as legible as possible. .
Avoid horizontal scrolling at 1024x768. Horizontal scrolling invariably causes usability issues — the biggest being that users don't notice the scrollbar and miss seeing content that is scrolled off of the screen.
The most critical page elements should be visible "above the fold" (in the first screen of content, without scrolling) at the most prevalent window size (1024x768 as of 2009). If you have critical content that appears "below the fold" (requiring that the user scroll down), add visual clues so users know it is there. For example, don't include large amounts of whitespace between items that are above and below the fold — it's better if the items are closer together, since even seeing the top of a line gives users a good hint that there is more content below the visible portion of the screen. (See research on the distribution of users' attention at the top of the page vs. further down.)
Use a liquid layout so the homepage size adjusts to different screen resolutions.
Use logos judiciously. Aside from the logo for the site, use other logos only if your users know them well and you want to draw users' attention to them. Don't use a logo just because one exists for a particular product or program. For example, many government agencies design logos for each new initiative or program. Keep such logos for internal use — users don't need to see all of them. See the Coles image on this page for an example of how logos can clog up the interface.

UI Widgets
UI widgets, such as dropdown menus, selection lists, and text boxes, invariably draw users' attention. As we recommend you do with any graphical addition to your homepage, use them sparingly and only when they are necessary for the task.

Never use widgets for parts of the screen that you don't want people to click. Make sure widgets are clickable. For example, if you use graphical bullets next to text, make them clickable as well as the text. In countless studies, we've seen users carefully try to click bullets, and if they're not clickable, they assume the whole line isn't a link, even when the bullet text is clickable.
Avoid using multiple text entry boxes on the homepage, especially in the upper part of the page where people tend to look for the search feature. Users sometimes confuse text entry boxes with search boxes, and often type search queries in the wrong place. This is especially problematic if you don't offer an input box for search but do have input boxes for other features. See Victoria's Secret and PBS for examples.
Use dropdown menus sparingly, especially if the items in them are not self-explanatory. Users are attracted to them, and they're often the least effective navigation devices. If you have very few items in a dropdown list, it's often better to list them directly on the homepage. Similarly, avoid long dropdowns — they are difficult for users to operate effectively, and users often struggle to differentiate between the items in the list. It's often better to take users to a separate page for the selection, where you can explain the different items or at least organize them into more meaningful categories than a single list.

Window Titles
Each homepage needs a simple, straightforward window title (determined by the TITLE tag of each HTML document). Although many people might not notice window titles while they are using websites, titles play a critical role in bookmarking and finding the site with search engines. When users bookmark a site, the window title becomes the default bookmark name, so the title should begin with the word that users will most likely associate with the site when they are scanning through a bookmark list. Similarly, search engines display the window title in search results and use it to determine relevancy to the search terms, so the title must be scannable and identifiable in long results lists. In order to be scannable, window titles should convey the most information possible in the fewest words.

Begin the window title with the information-carrying word — usually the company name. Users scan, rather than read, text on screens, so if you don't catch them with the first word, you risk losing their attention. If you start the window title with anything but the most important word, the company name gets lost in bookmark lists and search results. For example, many window titles begin with "Welcome" or "Homepage," which might look okay in isolation, but convey no differentiating site information in the first word. Similarly, if your company name begins with an article, such as "the" or "a," don't include the article in the window title. For example, the window title for "The New York Times" should be "New York Times."
Don't include the top-level domain name, such as ".com" in the window title unless it is actually part of the company name, such as "Amazon.com." Suffixes such as ".com" add an unnecessary word to the window title and create an artificial distinction between a company's presence on and off the Web. Users already know that they are on the Web when they go to a website, so they don't need the ".com" to tell them so.
Don't include "homepage" in the title. This adds verbiage without value. As long as you have a simple URL for the homepage of the site, it's not necessary to specify the homepage as such in the window title. Of course, each page in your site should have a unique window title, so that no other page can be confused with the homepage in history lists and bookmarks.
Include a short description of the site in the window title. This description is especially important for sites that are not yet widely known, so users can easily remember or understand what the site's purpose is if they've previously bookmarked it or get it as a search result. Consider using the tag line for the site, if you have one, but only if it is short, meaningful, and in straightforward language instead of vague marketese. For example, Slusser's window title, "Slusser's Commercial Landscaping and Heavy Highway," works well because it lists the company name first, followed by an understandable description (although we suggest moving "Landscaping" to the end).
Limit window titles to no more than seven or eight words and fewer than 64 total characters. Longer titles are less scannable, especially in bookmark lists, and will not display correctly in many applications. See JobMagic's window title for an example of an overly long, truncated window title.

URLs
It's critical to keep homepage URLs as simple and memorable as possible. Users not only need to be able to remember the URLs for sites they've visited, but they also need to be able to succeed quickly when they are guessing a company's domain name, as people often must do. Once users locate a website, a simple homepage URL helps them quickly understand that they are in the right place, whereas complex URLs can make them wonder if they're indeed on the correct page.

Homepages for commercial websites should have the URL http://www.company.com (or an equivalent for your country or non-commercial top-level domain) . Do not append complex codes or even "index.html" after the domain name. It is especially startling when users enter a simple URL and get to a site, only to have the URL they typed replaced by a long, scary-looking URL. Make sure your site responds to both "www.company.com" and "company.com."
For any website that has an identity closely connected to a specific country other than the United States, use that country's top-level domain. A country-specific domain is appropriate either for localized sites that feature a particular country's language and/or content, or for sites that are differentiated because they are located in that country. If the site also has customers outside of its country, and especially if it has customers in the United States, it's good to also register the name with ".com" as the top-level domain. For example, Asia Cuisine is a Singapore-based company, but it appeals to an international audience. Users can reach the site by either the Singapore URL, http://www.asiacuisine.com.sg or http://www.asiacuisine.com.
If available, register domain names for alternative spellings, abbreviations, or common misspellings of the site name. This is especially true if you have any punctuation in the company name, such as Wal-Mart, or names made from several words, such as Victoria's Secret. Both of these sites allow for common misspellings — you can reach Wal-Mart's website at http://www.wal-mart.com or http://www.walmart.com and Victoria's Secret through http://www.victoriassecret.com or http://www.victoriasecret.com.
If you have alternative domain name spellings, choose one as the authorized version and redirect users to it from all the other spellings. Use this correct spelling in all instances on the site and in any offline promotions.

News and Press Releases
In order for news stories and press releases to be effective on your homepage, you need to craft effective headlines and decks (the summary of the story below the headline). This applies to either the company news that you show on your homepage, or any news that your site delivers as content. Headlines and decks should actually give users information, rather than merely trying to tantalize them into clicking through to the real information. It's just as important to help users know when not to click something, if they're truly not interested. You can only get so many wasted clicks from users before they give up.

Headlines should be succinct, yet descriptive, to give maximum information in as few words as possible. For example, the headline "Ben Affleck Recovering" gives more information in fewer words than "Doctors Report on Ben Affleck's Progress," which promises content in the article that follows, but doesn't really tell users anything. Headlines should relate to the deck below them, rather than to the whole story that follows.
Write and edit specific summaries for press releases and news stories that you feature on your homepage. Don't just repurpose the first paragraph of the full article, which was likely not written to be a standalone piece. Give users content in the deck — don't just describe the content that follows. Trying to hold out on the details in order to entice users to click through can backfire; generalities aren't as captivating as specifics. For example, "Getting more sleep and spending time with loved ones are two of the five ways you can increase your life span by five years, says Surgeon General Satcher" is more intriguing and informative than "Surgeon general describes ways that people can increase their life span."
Link headlines, rather than the deck, to the full news story. If your headline style doesn't have a perceived affordance for clickability, such as blue underlined text, include a "Full Story" link at the end of the deck. A perceived affordance is what you think you can do with a UI element based on looking at it. For example, the pseudo-3D appearance of a button suggests that you can click it. For more information about the use of affordances in user interface design, see Don Norman's classic book The Design of Everyday Things (Currency/Doubleday: New York, NY, 1990).
As long as all news stories on the homepage occurred within the week, there's no need to list the date and time in the deck of each story, unless it is truly a breaking news item that has frequent updates. The time and date at the top of the homepage are enough to show a user that content is current. For example, Red Herring uses a good deal of space unnecessarily listing dates that all occur within the same week. It is essential, however, to list the date prominently on the page for the full article, because articles can be found and cached (for example by search engines) much later in time, and old content can be mistaken for current news unless items are dated with a full date, including the year. For the same reason, articles should not refer to relative times, such as "today" or "next week."
See also our separate 287-page report Designing Websites to Maximize Press Relations: Guidelines from Usability Studies with Journalists for more information about online PR and newsrooms.
Popup Windows and Staging Pages
In general, it's best to show site content immediately. Intermediary screens are rarely necessary and keep users from getting to the main site content. What may be amusing once is often extremely annoying the 3rd or 30th time. Worse, the intermediate pages might confuse some users into not recognizing the "real" homepage.

Take users to your "real" homepage when they type your main URL or click a link to your site. Splash screens must die. An exception: If your site has material that is inappropriate for minors or that is likely to offend some users, it is appropriate to have a splash screen warning about the content.
Avoid popup windows. Extra windows keep users from getting to your site content, and even if such windows contain valuable information, users are likely to dismiss them immediately as ads. Instead, put critical information in a highly noticeable area of the homepage. The other drawback to popup windows is that they go away — once the user gets rid of them, they're gone, so users often can't find the information again even if they want to. It's better to design your homepage to give high priority to critical content.
Don't use routing pages for users to choose their geographical location unless you have versions of your site in many different languages, with no single dominant language. If you have very few language choices, it's best to provide homepage links to those languages in the native language. If you have a dominant language for your site with multiple other languages, take users directly to the homepage in that language, and include a single link to "International Versions of Site." It's best not to use dropdown menus for this purpose because they're difficult for users to navigate when long, and they often don't show users all the options at once.

Advertising
Warning: users have grown savvier about ads on websites. Users have learned to ignore ads. Unfortunately, they often also ignore anything resembling an ad or next to an ad. If you use advertising from outside companies, you must ensure that you preserve the integrity of your content. The cost of lost customers might quickly outweigh the benefits of advertising revenue.

Keep ads for outside companies on the periphery of the page. Never place ads next to high-priority items; they will cause such items to be ignored. Especially avoid placing any important items above an ad, because users will often exhibit banner blindness, ignoring anything above the banner area.
Keep external ads (ads for companies other than your own) as small and discreet as possible relative to your core homepage content. When you have users evaluate your homepage, ask them to tell you the first three things that come to mind when they open the page. If any of the three comments are about ads, the ads are attracting too much attention.
If you place ads outside the standard banner area at the top of the page, label them as advertising so that users don't confuse them with your site's content. See CNNfn for an example of how to label an advertisement in the middle of the page, and see USA Today for an example of how easily an unlabeled ad in the middle of the page can look like actual content.
Avoid using ad conventions to showcase regular features of the site. The more you make content look like an ad, the less likely users will read it. For example, GE describes its acquisition of Honeywell on the homepage in a box that looks very much like an ad, rather than a press release or news item.

Welcomes
Many sites seem compelled to include welcome messages on their homepages. Cheerful "welcomes" on homepages are nostalgic remnants of the early days of the Web, when getting to one of the few available sites was a feat worth acknowledging.

Don't literally welcome users to your site. Before you give up prime homepage real estate to a salutation, consider using it for a tag line instead. The best welcome you can give users is a concrete definition of what they can do on the site and a clear starting point from which to begin. An exception to this guideline is the more appropriate use of "welcome" in a phrase that confirms that the site has recognized a registered user.

Communicating Technical Problems and Handling Emergencies
Unfortunately, sometimes you encounter problems on your site or your company is affected by an emergency. It's important to update your homepage with relevant information that your users need.

If the website is down or important parts of the website are not operational, show it clearly on the homepage. Provide an estimate of how long it will take to correct the problem — not just "Try again later," but "We expect that we'll be ready to serve you again at 4:00 p.m. Eastern time." Inform the user about alternatives that might be available while the website is down, for example, "Our customer service department is ready to serve you at 1-800-456-7890." Reserve such messages for critical information that already exists on your site — don't give users "under construction" messages for parts of the site that are yet to come or are getting a redesign.
Have a plan for handling critical content on your website in the event of an emergency. In an actual emergency, there won't be time to come up with alternative versions of your homepage. For example, prepare an alternative homepage design that has a main feature area to notify users of the emergency, as well as a simplified navigation scheme that offers a few cross-references and a way to get back to your site's regular homepage. Emergencies are often characterized by flash crowds in which many times the normal number of users want to get information about the emergency. To serve this increased load, the alternative design should be more lightweight than the normal design: fewer graphics and other embedded objects, simplified HTML, and no dynamically computed elements.

Credits
Users come to your site for content. Avoid cluttering your homepage with useless credits or telling users how great your site is.

Don't waste space crediting the search engine, design firm, favorite browser company, or the technology behind the scenes. Users really don't care, and each item you add to a page adds to its overall complexity and steals focus from the actual content. If these items are links to other sites, they can also cause users to get lost on those sites when looking for something on yours. For technology-oriented sites, it might be appropriate to include a "How We Run This Website" section under "About Us," but keep the specifics off the homepage.
Exercise restraint in displaying awards won by your website. Most users don't really care that you have been appointed "Hot Site of the Day" by somebody. At the same time, awards, recognition, and favorable reviews from independent authorities can be one way to enhance credibility. Awards for the quality of products or services are usually more helpful in building trust than awards for "cool design" or other aspects of the website itself. Thus, awards for customer-oriented issues may be mentioned on the homepage, whereas awards for the web team's efforts should be relegated to an "About This Site" area. In either case, don't let awards overstay their welcome. Featuring a stale award from last year undermines credibility since it communicates that you haven't done anything good lately (except if it's included in a history section).

Page Reload and Refresh
When users reload or refresh your homepage, changes can be jarring. Try to keep the transition as smooth as possible and maintain continuity with their previous experience of your page.

Don't automatically refresh the homepage to push updates to users. Automatic reloading feels intrusive — it's like pulling the rug out from under your users, particularly if they are using a part of the page that disappears or changes position during the refresh. For example, NewsNow automatically updates the page every five minutes, which means many of the headlines move off of the homepage and get replaced by new ones. This forced reloading can also lead to technical problems for users on dialup connections, whose computers might try to dial up at unexpected times (such as when the user is on the telephone on a line shared by a modem), or when the previous version of the page is replaced with an error message stating that the page could not be loaded. On slow connections you're taking up the user's bandwidth and time without asking if it's okay. For site features that require real-time updates, like sports scores, chat rooms, and stock tickers, consider providing a tool that enables users to get a live data feed. Such tools might potentially utilize an audio signal to attract the user's attention in case of breaking news. If you do so, it will be important to exercise restraint and only "ring the bell" for something truly important, as determined by an editorial decision or by a user-defined alert preference setting.
When doing a refresh, update only content that has actually changed, such as news updates. For example, don't rotate through a set of photos, because users will waste their time trying to figure out what has happened and why the change has happened instead of focusing on useful tasks. Meaningless change is especially bad when sites randomly rotate through content — users waste time trying to figure out the pattern when there is none.

Customization
Homepage customization can work well if it gives users value without requiring much or any setup effort from them. If it is possible to make intelligent and relevant recommendations based on a user's past behavior on your site, or if you can offer users specialized content based on criteria such as their geographical location, then users might indeed benefit.

If your homepage has areas that will provide customized information once you know something about the user, don't provide a generic version of the content to first-time users — craft different content for that space. For example, if you have a customized welcome message that shows a registered user's name, don't display any of the text if you don't know the user's name. See MotherNature's homepage for an example of how silly such welcomes look when you don't have user information yet. Generic welcomes are akin to Dear Sir letters — they don't make anyone feel special. Similarly, don't offer users recommendations that purport to be tailored just for them, when in fact they are generic for all users. So, if you have a UK site that has an area for local weather, don't choose a city, such as London, for your users — if you don't know their city, offer users an area to enter it and a rationale for doing so. For example, "Enter Your City Name or Postal Code to See Your Local Weather Report."
Don't offer users features to customize the basic look of the homepage UI, such as color schemes. It's better to focus resources on coming up with the best design that will be the most readable for the greatest number of users. You should respect users' browser preferences, however, such as font size, by using relative rather than absolute sizes.

Gathering Customer Data
Many websites, including several of the ones in this book, begin asking for user data, such as email addresses, right on the homepage. Most do not explain why users should give up their privacy. In general, many web users, even experienced ones, are justifiably wary about giving away their personal information because they know now that fulfilling these requests often results in unsolicited commercial email and clogged inboxes.

Don't provide plain links to registration on the homepage; instead explain (or at least link to) the customer benefits of registration. For example, Amazon explains the benefit by simply saying "Sign in to get recommendation." Users don't come to sites to register, but they might do so if the reasons are compelling enough. Thankfully, more websites seem to be allowing users to explore the site without mandatory registration — none of the sites in this book required users to register. Yet many sites offer homepage links to registration without any explanation of why users might want to do so.
Explain the benefits and frequency of publication to users before asking them for their email addresses. Don't ask users to give their email addresses to get an unspecified newsletter or other item of unknown content or frequency. Also, link to a sample newsletter and explain the privacy policy next to the place where you ask for the user's email address.

Fostering Community
The best thing you can do at the homepage level to foster a community of users is to reveal what resources the site has to bring people together. Of course, the deeper issue is whether a user community is appropriate for your site, but if so, it's good to give people specific examples of what they can get from community features you provide.

If you support user communities with chat or other discussion features, don't show generic links to them. Instead list actual discussion topics and provide any schedules on the homepage.
Don't offer a "Guestbook" sign in for business sites. Guestbooks make a site look amateurish and give no customer benefit. Sites that cater to clubs or subcultures, where users might enjoy some benefit from just getting their names in the book or seeing who else visited the site are excepted from this guideline.

Dates and Times
Users need to know that information they see on your homepage is current, but they don't necessarily need to see dates and times next to each item. When you do show dates and times, it's important to format them so that all users will be able to translate them to their local time.

Show dates and times for time-sensitive information only, such as news items, live chats, stock quotes, and so forth. Don't show dates and times on e-commerce or other transaction sites that don't have time-sensitive material. It's not necessary to show the day of the week, but if you do, only do so if it is from the current week.
Show users the time that content was last updated, not the computer-generated current time. Clearly indicate this distinction, with a phrase such as "Updated <date, time>."
Include the time zone you are using whenever you reference a time. If your site has international users, show the time in the most common time zone, as well as relative to GMT, for example, 9:00 a.m. EDT or (GMT –4). Any localized homepages should show that location's local time, as well as the time relative to GMT.
Use standard abbreviations, such as p.m. or P.M. Don't abbreviate further, such as "p."
Spell out the month, or use month abbreviations, not numbers. Jan. 2, 2003 is much less ambiguous than 01/02/03, which could mean either the 2nd of January, or the 1st of February, since many countries conventionally mention the date, rather than the month, first.

Stock Quotes and Displaying Numbers
Because many homepages include stock quotes now, we've included a few guidelines to make them more readable and understandable. Although you can display stock quotes and numbers on any web page (and use these guidelines to optimize their display), it's especially important to follow these guidelines when displaying such information on the homepage, where even minute optimizations can reduce distracting clutter.

Give the percentage of change, not just the points gained or lost in stock quotes.
Spell out stock abbreviations unless the abbreviation is completely clear, such as "IBM." Many stock symbols are unintuitive, such as "C" for Citigroup, or "HWP" for Hewlett Packard ("HP" is taken by Helmerich & Payne).
Use a thousands separator appropriate to your locale for numbers that have five or more digits. For example, in the United States, fifty-three thousand should be written "53,000."
Align decimal points when showing columns of numbers. This makes it much easier for users to compare or mentally add and subtract numbers.
See also our separate report with 103 design guidelines for the Usability of the Investor Relations (IR) Area of Corporate Websites.
Homepage Design Conventions
In addition to the guidelines presented in this chapter, the next chapter (in the Homepage Usability book) presents design conventions that have evolved and are continuing to evolve on the Web based on our analysis of the homepages in this book. The chapter ends with our "Recommended Homepage Design" (page 52), which we suggest that you use, along with the guidelines in this chapter, to evaluate your existing homepage design and inform future designs.

via useit.com

The "Big Five" IT trends of the next half decade: Mobile, social, cloud, consumerization, and big data | ZDNet

2011-10-04T00:14:00.001+08:00

via zdnet.com

Site Structure | Web Style Guide 3

2011-10-03T14:48:00.001+08:00

via webstyleguide.com

First Impressions Count in Website Design - visual appeal, beauty and aesthetics, halo effect, cognitive perception, webpage judgments of credibility

2011-09-24T12:27:00.001+08:00

via websiteoptimization.com

The three levels of design patterns: Implementation, flow, and context

2011-09-24T01:31:00.001+08:00

via ui-patterns.com

On the ground running: Lessons from experience design

2011-09-22T17:38:00.001+08:00

From Adobe Design Center’s Think Tank, May 2007

We live, it seems, in an age in which the long-standing and pleasingly crisp distinctions between what constitutes a “product” and what a “service” are beginning to break down. Even in the early days of this evolutionary shift, we can already see that the implications for both individual designers and the profession of design as a whole are likely to be deep and lasting.

Traditionally, a product was physical and discrete – something obviously demarcated in space but, equally, in time. The designer’s brief rarely extended to much more than the form of an object, at most encompassing the contours of its use immediately after purchase, and that extending only to a narrow range of scenarios and anticipated users. But driven by lightweight and ubiquitous networking, and the open standards it gives rise to, all of this has started to change: no longer can the designer of any product assume that it will stand on its own, autonomous and serenely uninvolved with the wider world, for its entire lifetime of use.

The already-classic example is, of course, the product-service ecology Apple devised for their iPod. Considering the close integration between iPod, the physical device, iTunes, the desktop application, and iTunes Music Store, the online environment, it’s clear that Apple understood relatively early on that the only way their contender would be likely to gain traction in an already crowded field of MP3 players was not to frame it as an MP3 player at all.

Their stroke of genius – and it’s easy to see it as such now, in retrospect, but most commentators missed it at the time – lay in positing the iPod not so much as a stand-alone device, but as the tangible presence in your life of a larger and much more ambitious experience. Apple grasped, before any of their competitors, that evoking a truly pleasurable experience of use transcended questions of the placement of controls or the sequence of menu items, as important as these things are. It required a consistency of conception extending from the moment you opened the iPod’s box for the first time to the way it felt to find new music for it on the iTunes service.

There are two nontrivial insights here, and maybe we’d benefit from unpacking them a little. The first is that the perceived quality of the iPod in use depends to an unusual extent on Apple’s framing what you’re actually buying from them holistically, at the level of the whole undertaking rather than that of its component parts – they get that the product is no longer an isolated entity, but a way of gaining access to content which might ultimately live elsewhere. The second is that getting this “product” right means accounting for your interactions with it across multiple channels, and even more importantly, over time.

In the iPod ecology, then, we have traditional industrial- and interaction-design concerns interwoven with elements which have more usually characterized the architecture of services. When you consider that such interweavings are becoming increasingly common in our day-to-day lives – you can grant an older cellphone entirely features by blowing updated firmware into it, while certain models of Lexus automobiles now come with a subscription to real-time traffic information – the time would appear to be ripe for a new kind of designer to take center stage.

What might we call such a person? Here’s a hint: it’s neither a “graphic” nor a “Web” nor even an “interaction” designer.

Toward the Total Experience

None of the shifts outlined above, mind you, have gone unnoticed by the broader digital design profession, nor has that profession been slow to recognize the potential opportunities involved. Over the past few years, the domain of practice known (if only briefly) as “user experience” has begun to accommodate the new realities on the ground, recasting itself as “experience design.”

Whether the emergence of a self-conscious experience design community reflects a canny land-grab on the part of a few visible and reasonably influential practitioners, an underlying recognition that our technosocial practices have transcended the rather limited model of the “user” ultimately derived from old-school human-computer interaction studies, boredom with a thoroughly mapped landscape, or something else entirely, it’s undeniably been a successful way of framing things.

As far back as 2001, no less authoritative a body than AIGA (“the professional association for design”) had lent its imprimatur to the fledgling field, with an AIGA conference defining experience design as being concerned with a product’s “entire lifecycle with a customer, from before they perceive the need to when they discard it.”

In the years since, the discourse of experience design has steadily gathered authority, offering as it does a way to wrestle and wrangle with the new complexity of the built environment and the objects we encounter in it. (In this, it parallels the emergence of actor-network theory in the academy, a line of thought that accounts for interactions between extended networks of people, ideas, technologies and artifacts. Something’s clearly in the air.)

On its face, this outlook has considerable appeal. There is still no better advice for design students than that offered by the 20th century architect Eliel Saarinen (father of Eero): that things should always be designed with reference to their “next larger context.” Experience design would appear to incorporate this recognition from the beginning, which would certainly better position it to respond to the manifold challenges of design for a networked world than more tactical arts.

But it turns out that there’s a serious flaw in this way of thinking. Ensuring that all phases and aspects of someone’s interaction with a product/service ecology align with the desired vision requires that something little short of total control be asserted over their choices. This, in turn, leaves little room for the self-evident (and lovely) messiness of our lives, not much in the way of flexibility should the scenario of use deviate to any significant degree from that contemplated at design time.

As it happens, another Apple product provides a perfect illustration of the potential pitfalls involved in such overly designed experiences – in this case, the cross-branded Nike+ iPod Sport Kit.

As envisioned, the Nike+ ecology consists of several physical products – a biotelemetric transponder, any of a range of Nike sneakers compatible with it, and an iPod nano – and an online environment where the results of one’s uploaded runs are subjected to a variety of mappings, visualizations and pseudo-statistical analyses. (The desktop iTunes application mediates the flow of data between device and Web site.)

One’s first few runs with Nike+ are smooth and pleasurable, replete with the kind of “thoughtful” touches that generally get lauded as good experience design – Lance Armstrong congratulating you every time your run time exceeds the previous personal best, and so on. But it rapidly becomes apparent that all the smoothness in the Nike+ experience comes at a cost, that it really clicks only if you and everything about the way you use the system conform fairly narrowly to an imaginary ideal.

These insightful comments from Nokia’s Chris Heathcote are spot on:

Designing for one person creates tight end-to-end services. But few companies control the complete end-to-end, and in fact, customers (people!) are wary – it’s normally an excuse to bleed more money out of people more regularly (“we can sell a product and a subscription!”) and to lock people in (how do you get your data our of Nike+?).

He’s absolutely correct, on all counts. In fact, most users will find that their experience is constrained in several ways:

- For quite awhile, the selection of shoes available to prospective Nike+ runners was quite limited: not merely to Beaverton’s own shoes, but to one particular line among their offerings. If you wanted to try Nike+ with, say, a pair of Nike Frees that imitate the biomechanics of running barefoot, you were out of luck.

Although Nike recently announced that all of their shoes would henceforth be fully compatible with the system, it may not matter; as it turns out, hacking Nike+ so it works with non-approved shoes is a simple matter of duct-taping the transponder to whatever trainers you already have lying around the house. That the system works equally fine with its input taped to an old pair of Adidas is an indication that this particular dimension of control was not definitive of the experience. This is a point to which we’ll be returning.

- The sense of needless constraint is, perhaps, equally imposing on the Apple side of the house: of all the available models of iPod, only the nano works with Nike+. Given that other models come equipped with the appropriate connector, there’s no obvious justification for this decision either.

- Nike+ motivates the runner by announcing the achievement of incremental performance goals – you’re reminded of elapsed run time at five-minute intervals, for example, in addition to when you’ve hit the halfway point. Apple has thought things through enough to realize that different people are motivated by different triggers, so they’ve at least provided a choice between male and female voice actors.

But the voiceovers are such an intimate presence that any offness in them registers disproportionately. Since the system affords no way to upload alternative motivators – a coach or drill instructor, a personal hero, a lover – this is likely to remain a sore point.

- What about users, and uses, of the system outside the envelope imagined by its designers? Nike+ feels unnecessarily over-optimized for a single kind of runner, and a single kind of run. (Heathcote nails it: “I can see the persona on the flipchart now,” and anyone who’s worked in the field for more than about ten minutes knows precisely what he’s talking about.)

There’s nothing in the system’s technical capabilities that prevents it being of utility to walkers, for example. They may not necessarily be as sexysweaty as the users featured on the Nike+ site, but would surely appreciate being able to take advantage of its pedometer and calorie-tracking features. Why exclude them, literally by design?

- Perhaps the deepest question facing the Nike+ online experience is that of the t dimension. Manufacturers like Sony and Nike who rely heavily on complicated, Flash-driven experience sites for their products often find the sites hard to maintain or update over anything beyond the short term.

By contrast, of course, for a great many of its adherents, running is a lifelong activity. Where will they turn in three years if Nike decides there’s no longer any percentage in supporting Nike+, or if the latest release of iTunes fails to mediate smoothly between device and site? Will they be forced into an expensive, exhausting cycle of multiple upgrades and compatibility hurdles, or, still worse, find themselves in a technological cul de sac? The more the desired brand experience relies on a concatenation of closed systems from different manufacturers, each of which is subject to revision (to say nothing of a realignment of corporate priorities), the less likely it is to survive intact over time.

As Heathcote suggests, many of these problems could be obviated by opening up the Nike+ platform, allowing people to swap in shoes and other components of their choosing, or even to build custom mashups of their own with the data it generates.

This is, admittedly, not likely to be terribly appealing advice from the point of view of those stakeholders committed to a heavily-branded experience. From this perspective, it’s an offering of Nike and Apple: why on earth should they design it so shoes or music players from other manufacturers work equally well?

But if the choice is between an overcontrol that will predictably result in an eventual breakdown, and a flexibility that admits other players but also affords more satisfying long-term outcomes, which would you rather have your brand associated with? In the final analysis, about all that can be said about end-to-end control of a multi-touchpoint customer interaction is that it results in a perfect experience….except, of course, for when it doesn’t.

Fast train to nowhere

Several years ago – and it was one of the first occasions I personally recall hearing the phrase “experience design,” now that I think about it – design firm IDEO presented their work on the design of Amtrak’s then-new high-speed service, Acela.

At the time, IDEO’s work on Acela could fairly be regarded as exemplary. They surely had the right instincts: originally engaged to design the cabin of a railway coach, they understood that the actual design challenge before them was significantly broader, that the form of the coach was merely a small part of what travelling by train is all about. Still more insightfully, in accordance with Eliel Saarinen’s wise counsel, they had situated that portion of the journey during which a customer was travelling on rails as merely the central segment of a far longer experiential arc.

IDEO divided this arc into ten distinct phases; their conception of an Acela trip began even before passengers had necessarily settled on travelling by train, accounted for the rituals of arriving at the station and purchasing tickets, and followed until they had transferred to another mode of transportation upon arrival at the destination.

The clear intention was to ensure that the customer interaction inscribed in each of these phases was designed to the same high standards as an IDEO mouse or shopping cart. But with the best of intentions, this way of thinking led Acela into error.

The assumptions embedded in the plan are too tightly coupled to one another. They feed from one to the next – remember the word – seamlessly, like brittle airline timetables so tightly scheduled that a delay anywhere in the densely-interwoven mesh of connections cascades through the entire system. When it all succeeds, it’s magnificent, but if any aspect of it fails, the whole thing falls apart.

That the whole thing has, in fact, fallen apart will be readily attested to by anyone who’s taken the Acela lately. Conceived as a competitor to world-class rail services of long standing, like France’s TGV and the Japanese shinkansen, the level of amenity Acela offers its passengers simply doesn’t even come close. From the frankly broken ticketing process, to the tatty waiting areas (it would be stretching credibility to call them “lounges”), to the flickering, dysfunctional arrival/departure screens, to the occasional surliness of onboard personnel, Acela is a system that has failed to uphold the minimal standards seasoned travellers expect from a would-be global contender. Even Korea’s KTX offers a more refined and a more pleasant intercity service.

Notice that these pitfalls have a commonality, that of maintenance. As originally devised, each of the components of the Acela proposition made perfect sense, but they have been allowed to degrade over time. Those that have defaulted drag down the perception of those left behind, until any clever touches there may be in the design of the train cabin or the station signage no longer even register against the net impression of hassle and irritation.

This tends to be a particularly acute issue wherever a designed ecology brings human beings face to face with one another: as things now stand, experience design’s Achilles heel is that contemporary American customer service standards are nowhere near the level of refinement routinely achieved by product and interactive designers. A combination of low wages, disinvestment in training, habitual recourse to offshoring, and deeper cultural factors has left American businesses without a large pool of workers motivated to provide customer service at the level routinely specified by designers. The result is that experiences seamless on paper break down badly the moment a human being enters the loop; the necessary follow-through simply isn’t there.

The suggestion here is not that these crucial interactions be left to chance, to design by committee or to the exigencies of the moment. But there are real limits on what a design organization can reasonably expect to achieve. Designers may well be able to specify the degree to which a seat reclines, the font in which a sign is set, or the sleek lines of a uniform – but not the behavior of the person in that uniform, and ultimately, that’s far more likely to determine the tenor of any experience. Acela’s lesson for experience designers is simple, one that most of us learned in childhood: don’t bite off more than you can chew.

Pumas for Achilles

People, of course, aren’t always the weakest link in a product/service ecology. Puma’s Trainaway line provides us with a perfect illustration of some the pitfalls that await when total experience designs cannot, for one reason or another, be carried through.

Ambitious in conception, Trainaway is positioned as sleek, lightweight running gear for whatever’s left of the jet set, specifically designed to help people maintain their fitness routines while travelling. In addition to the shoes and clothes, the ecology comprises a series of cardkey-sized, plasticized maps to running routes in major cities worldwide, slickly-produced SoundWalk MP3 audio guides, and alliances with suitably aspirational partners, such as the W hotel chain.

One of the most appealing aspects of Trainaway is that it’s clearly been conceived not simply as an integrated system of products but as a coherent experience. The trouble, as we’ve seen, is that such things are delicate, and delivering on them depends vitally on the smooth coordination of heterogeneous and inherently unstable components. In this instance, that smooth coordination is missing in multiple ways.

We’ve already seen how a lack of adequate employee preparation and training can undermine an experience proposition. When Puma’s own retail personnel don’t know how to explain or merchandise the Trainaway components on their own shelves, the augurs are not good, and indeed, it only gets worse when you visit a W hotel in an attempt to extend the Trainaway experience: the desk staff at New York’s W had never heard of the tie-in with Puma, and had absolutely no idea what if anything it required of them.

Such breakdowns in customer service are, by now, sadly predictable. But even at the raw level of product design, the necessary degree of follow-through is missing. The jacket has fittings and pockets for an integral fiber-optic safety lighting system that would admittedly be innovative, if the light source were anywhere to be found. (Despite being called out on the Web site as a product feature, neither customer service contacted via the site’s email form nor, again, the staff at Puma’s retail store were able to explain just how this feature is supposed to work.)

And then there are the blunders that only a self-conscious “experience” designer would make. The Trainaway shoe features an outboard slot for storage of your hotel’s cardkey; anyone who actually runs – even most nonrunners who spend a few minutes contemplating the question – would have a vivid sense for how rapidly and thoroughly this slot is going to be gunked up with the vile muck of street, path and trail. Given every possibility offered by an integrated collection, why on earth choose the bottom of the shoe for storage? This is the kind of too-clever-by-half “solution” that only someone trying to force-fit components into an imagined ecology would have introduced into the product development process.

Finally, the online components of the experience don’t appear to have been thought through with any particular clarity. However lavish, the audio guides are the kind of thing you listen to once, at most. A map of the Tiergarten does me little good should my travels happen to take me to Manila or Buenos Aires. And whatever other mistakes Apple and Nike may have made, the hassle involved in manually entering a long alphanumeric authorization code to download these goodies makes you positively nostalgic for the plug-and-play integration of Nike+.

Is Trainaway a complete disaster? No: at the end of the day, what you get for your money is still a perfectly serviceable array of running shoes and clothes. But it’s unclear, at best, if there’s actually any enhanced value to the consumer as a result of all the experience-design trappings. When so much time and effort are lavished on product, on advertising, on the design of a Web site, on maps and audioguides and other collateral, shouldn’t the ROI on tying these things together be more self-evident?

More fundamentally still, if the entire aim of the product/service is allowing you to maintain your fitness routine while travelling (“[m]ost often, even the best intentions result in gear that’s left idle, never making its way out of the suitcase”), we should ask ourselves whether design is even an appropriate response. This may simply be an issue that’s beyond the ability of an experience designer to affect.

So what might a more approproate ambit for design look like, in the context of complex networked product/service ecologies? How might someone interested in providing people with consistently high-quality experiences address the problems of overly brittle planning suffered, to different degrees, by Nike+, Acela and Trainaway? Some useful hints might be gleaned from domains as close to design as architecture – and as seemingly distant as cybernetics.

Conversations, not control

We’ve seen that highly designed experiences tend to suffer from a consistent range of limitations: physical components that are brittle, unreliable, or not delivered to specification to begin with; difficulties integrating those components with online environments, with desktop or mobile applications, and with human participants; and finally, the inherent unpredictability of any attempt to maintain consistent feel across technosocial systems of heterogeneous type and nature.

Could it be that more headway will ultimately be made when designers conceive of desired experiences as overarching but essentially open narratives, into which individual consumers can insert or demount components at will?

In architecture, the idea of maintaining precise control over the specification of an infrastructural framework, while ceding control over local circumstances to the user, is one with a respectable pedigree, so much so that it has historically appeared in a variety of places, times and guises.

The “kit of parts” approach – in which theoretically endless cities are generated by plugging housing, recreation, and production modules into circulation networks, like the pieces of some gigantic children’s construction set – is most often associated with the delightfully high-flying British collective of the 1960s known as Archigram. Similar tendencies characterized the work of Archigram’s direct Japanese contemporaries, the Metabolists.

Other architects went further still. Constant Nieuwenhuis’ New Babylon, Yona Friedman’s Spatial City and Cedric Price’s Fun Palace all envisioned immense open bays in which finer-grained control of the environment was left to individuals, or small groups. Meanwhile, Reyner Banham and the other prophets of “non-plan” architecture proposed that all but the most vestigial urban planning be done away with, the better to allow a community to find its own most vibrant mode of spatial expression.

There will be a great deal that contemporary experience designers can take from these examples, especially their sense of the continual, shifting, delicate negotiations between the overall perception of an ecology, and how that perception is locally inflected by the input of participants. (Similar ideas can be found in the thought of cybernetician Gordon Pask, who constructed human-computer interactions not as sterile control and feedback loops, but as “conversations” among a shifting retinue of observers and participants both technical and human.) Implicit in many of these visions is a stance that only in a loose and forgiving framework – what we might think of as an “underspecified” one – can the really valuable experiences happen.

There’s a tacit model underneath what is being proposed here, and if it seems familiar, it should: it’s the Internet. Years of working with the Internet and with the World Wide Web built on top of it have accustomed us to a logic of “small pieces, loosely joined,” in which the network is open-ended, effortlessly extensible, and robustly resilient to the failure of individual system components. Finally, this logic has begun to filter out into our experiences of the physical world – and imagine how much better offerings like Nike+ would be if they fully embraced it.

If absolutely top-shelf design organizations like IDEO and Apple are unable to fully encompass the challenges of everyday life in the real world, how much less so their less able peers? How, for example, would the Nike+ experience feel if its various touchpoints had been devised by Microsoft, the same institution that brought you Clippy, the Blue Screen of Death and the DRM-hobbled Zune? Isn’t it better, then, to open these systems up – to provide the APIs and other hooks that would allow people to configure them to their own liking?

This goes beyond William Gibson’s oft-quoted and unimpeachably correct observation that “the street finds its own uses for things,” toward the recognition that designers cannot, even in principle, encompass at design time the full range of uses to which their work will be put. In some respects, too, this is what human-computer interaction guru Don Norman is alluding to, when he argues that the person formerly known to experience design as the “user,” “customer,” or “consumer” needs to be understood as a human being before designers can do their work properly. Any other approach, he reasons, risks treating this person as an instrumental component, not as someone capable of fully participatory co-creation.

Norman is, of course, right, as far as he goes, but he doesn’t go nearly far enough. Truly making room for human prerogatives in the context of heavily-designed product/service hybrids means that, wherever possible, such systems ought to allow people to swap their own desired components in and out at will, to pull data out in a useful format, and to preserve value even where one or more component has broken down.

Does this mean that there is no justified role for the experience designer? No, of course not. Ultimately, though, the best solution may be to plan for people configuring their own experiences – the same distinction reflected in the title of Dan Saffer’s recent book (Designing for Interaction) vis à vis that of Bill Moggridge (Designing Interactions). This may seem like semantic pedantry, mere quibbling, but the difference is crucial: people are already organizers and designers of experience par excellence. Why not let them continue to be?

And this leads us, finally, to the concept not of the seamlessness of designed experience, but of “beautiful seams.”

This term was coined by the late Mark Weiser, a pioneer of ubiquitous computing and the Chief Technologist at what was at the time the Xerox Palo Alto Research Center. Instead of the discourse of smooth, distinction-obliterating, disempowering seamlessness which was then (and is to a significant degree still) dominant in discussions of ubiquitous information processing systems, Weiser wanted to offer users ways to reach into and configure the systems they encountered; ideally, such seams would afford moments of pleasure, revelation and beauty.

Regrettably, Weiser never fully developed this notion, but others have taken it and run with it. And this in turn suggests a valid and a valuable, if relatively minimalist, role for the experience designer: crafting the seams between the distributed components of a product/service, such that they enhance the perception of the whole. This means limiting the ambition of the designer to those aspects of the experience most likely to be definitive, which most require and would best benefit from expert guidance and intervention.

In the long run, providing for high-quality experiences in a deeply networked age means having the humility to know when our efforts are most welcome…and when, as designers, we must let go.

via speedbird.wordpress.com

A brilliant article!

Martin Jacques: Understanding the rise of China (TED)

2011-09-22T12:46:00.001+08:00

Flash

via youku.com 《TED演讲集：马丁·雅克谈了解中国的崛起》

Windows 8 Unveiled at BUILD

2011-09-22T11:29:00.001+08:00

via channel9.msdn.com

Windows Division President Steven Sinofsky shows off the "reimagined Windows" with the preview release of Windows 8 during the Day 1 keynote. Also see how Hyper-V will be enabled in Windows 8 and check out the Windows 8 Fast Startup Mode.

Apple's design process - BusinessWeek

2011-09-22T00:29:00.001+08:00

Apple's design process

Posted by: Helen Walters on March 08, 2008

Interesting presentation at SXSW from Michael Lopp, senior engineering manager at Apple, who tried to assess how Apple can ‘get’ design when so many other companies try and fail. After describing Apple’s process of delivering consumers with a succession of presents (“really good ideas wrapped up in other really good ideas” — in other words, great software in fabulous hardware in beautiful packaging), he asked the question many have asked in their time: “How the f*ck do you do that?” (South by Southwest is at ease with its panelists speaking earthily.) Then he went into a few details:

Pixel Perfect Mockups
This, Lopp admitted, causes a huge amount of work and takes an enormous amount of time. But, he added, “it removes all ambiguity.” That might add time up front, but it removes the need to correct mistakes later on.

10 to 3 to 1
Apple designers come up with 10 entirely different mock ups of any new feature. Not, Lopp said, "seven in order to make three look good", which seems to be a fairly standard practice elsewhere. They'll take ten, and give themselves room to design without restriction. Later they whittle that number to three, spend more months on those three and then finally end up with one strong decision.

Paired Design Meetings
This was really interesting. Every week, the teams have two meetings. One in which to brainstorm, to forget about constraints and think freely. As Lopp put it: to "go crazy". Then they also hold a production meeting, an entirely separate but equally regular meeting which is the other's antithesis. Here, the designers and engineers are required to nail everything down, to work out how this crazy idea might actually work. This process and organization continues throughout the development of any app, though of course the balance shifts as the app progresses. But keeping an option for creative thought even at a late stage is really smart.

Pony Meeting
This refers to a story Lopp told earlier in the session, in which he described the process of a senior manager outlining what they wanted from any new application: "I want WYSIWYG... I want it to support major browsers... I want it to reflect the spirit of the company." Or, as Lopp put it: "I want a pony!" He added: "Who doesn't? A pony is gorgeous!" The problem, he said, is that these people are describing what they think they want. And even if they're misguided, they, as the ones signing the checks, really cannot be ignored.

The solution, he described, is to take the best ideas from the paired design meetings and present those to leadership, who might just decide that some of those ideas are, in fact, their longed-for ponies. In this way, the ponies morph into deliverables. And the C-suite, who are quite reasonable in wanting to know what designers are up to, and absolutely entitled to want to have a say in what's going on, are involved and included. And that helps to ensure that there are no nasty mistakes down the line.

via businessweek.com

Chrome starts fast (hammock) - YouTube

2011-09-21T11:55:00.001+08:00

via youtube.com

fast no lie.

Wisdom on Crowds: What CEOs Need to Know About the Social Web - Buzzwatch - WSJ

2011-09-20T17:38:00.001+08:00

via blogs.wsj.com

TED - Where do good ideas come from? by Steven Johnson

2011-09-18T16:22:00.001+08:00

via v.youku.com

Chance Favors The Connected Mind

The Little Match Girl - Gediminas Pranckevicius

2011-09-16T17:01:00.001+08:00

via features.cgsociety.org

The Little Match Girl
Painter, Photoshop
September 2011

The Birds

2011-09-16T16:57:00.001+08:00

via features.cgsociety.org

„The Birds“
Photoshop
August 2007

CGPortfolio - Gediminas Pranckevicius

2011-09-16T16:51:00.001+08:00

via imperioli.cgsociety.org

REMBRANDT
Painter, Photoshop
November 2007

Wells Illustration

2011-09-16T16:37:00.001+08:00

via wellsillustration.com

Friends May Be the Best Guide Through the Noise - New York Times

2011-09-13T19:19:00.001+08:00

CATHY BROOKS is a typically unapologetic Silicon Valley Web addict. Last week alone, she produced more than 40 pithy updates on the text messaging service Twitter, uploaded two dozen videos to various video sharing sites, posted seven photographs on the Yahoo image service Flickr and one item to the online community calendar Upcoming.

Her friends, similarly peripatetic in their Web journeys, also liberally sprinkled photos, videos, blog items and news-article links across the Internet.

But they all followed one another’s activities in one place: a buzzy, online water cooler called FriendFeed that lets people funnel all their online activities into a single information broadcast, and then blast that broadcast to anyone who wants to listen in.

“It’s a great catch-all way for me to have all my stuff in one place, and it lets me see a more comprehensive view of the ecosystem of my friends,” said Ms. Brooks, 39, a business development director at an online video start-up company in San Francisco.

Companies like FriendFeed — and there seem to be a growing number of them these days — are trying to solve a problem that the Internet itself created. The proliferating number of blogs, user-generated content services and online news sources has created a dense information jungle that no human could machete his or her way through in a lifetime, let alone in an afternoon of surreptitious procrastination at work.

Search engines like Google, so effective for general information hunting, do a poor job of cutting through these thickets of user-generated material. For the Internet-addicted, the problem is further intensified by “lifecasting” services like Twitter and the Google-owned Jaiku, which let people use their cellphones to fire off Haiku-length text notices, both profound and mundane.

“The question from our standpoint is, how you find signal in the noise?” said Peter Fenton, a partner at Benchmark Capital, which recently invested in FriendFeed. “If you assume the volume of information continues to grow exponentially, it is going to keep getting harder and harder to figure out where you want to spend 30 minutes to two hours online.”

That’s where the sites like FriendFeed, Iminta, Plaxo, Readr, Mugshot and others try to harness the wisdom of friends. They let their users choose whose feeds they want to follow — the relationship does not have to be reciprocal — and allow them to restrict their own feeds only to people with whom they feel comfortable.

Following the feeds of people you like and admire, these companies say, allows the serendipitous discovery of needles in the information haystack. “Friends are likely to have some similar interests and tastes. Just the fact that your friends find it interesting should make it more interesting to you,” said Paul Buchheit, one of FriendFeed’s four founders, all of them former Google engineers.

Last week, for example, Mr. Buchheit’s followers on FriendFeed were treated to what he himself had discovered and found valuable online: links to interviews with the investor Peter Thiel in Reason magazine and the Google co-founder Larry Page in Fortune, an article about Justice Antonin Scalia’s views on torture on a political Web site, and a YouTube video of nine kittens moving their heads in rhythm to a song, among other Internet ephemera.

One benefit of the feed sites is that they make conversation around online media both less voluminous and more meaningful. For example, YouTube users left an impenetrable 728 comments, many of them trivial or nonsensical, on the dancing-kitten video. Mr. Buchheit’s friends left two comments about the kittens — perhaps the right amount for a video that speaks for itself. They left 14 thoughtful comments about the Justice Scalia article.

Facebook, the popular social network, was both the early inspiration for these services and has since become one of them. For the last year and a half, Facebook has given each of its users a news feed that offers updates of friends’ activities on Facebook itself.

Last month, bowing to the appeal of feed services, Facebook began to let users share their activities on other sites, like the photo services Flickr and Picasa, and the review site Yelp. The company says it plans to continue to link more Web sites to the social network.

The feed sites work better when people use them circumspectly, following only a few like-minded Internet friends and ignoring the Me Media gluttons who gum up the works with a frivolous blog posting or Twitter text every few minutes.

MS. BROOKS, the FriendFeed user, says she tries to follow people who strike just the right balance between the quality and quantity of their Web musings.

“I usually stop following people not because they are twittering and uploading pictures all the time,” she said, “but because I find what they are saying has no value to me.”

The vital challenge for FriendFeed and its ilk is a familiar one to Silicon Valley start-ups: how to evolve from a service fora relatively small user base of techno-enthusiasts and into a tool valuable for commoners who think that “twittering” is something best left to birds.

Aaron Newton, founder of Iminta, based in San Francisco, says that active Internet users are already authors of personal newsletters every day in the blog postings they write, videos they watch and articles they read. The key, he said, is making that newsletter easy for people to share and for others to find and follow.

"If you buy into the notion that we all make interesting discoveries on the Web as we go about our day, then the market for a product like ours is really as wide as everyone who uses the Internet,” he said.

via nytimes.com

Do your friends make you smarter? Exploring social interactions in search

2011-09-09T18:39:00.001+08:00

Do your friends make you smarter? Exploring social interactions in search

View more presentations from Brynn Evans

Breaking Down E-Commerce APIs

2011-09-09T15:39:00.001+08:00

via blog.programmableweb.com

social objects for beginners | gapingvoid

2011-09-09T14:29:00.001+08:00

via gapingvoid.com

The Simplest Thing that Could Possibly Work - A Conversation with Ward Cunningham, Part V

2011-09-09T11:59:00.001+08:00

by Bill Venners
January 19, 2004

Summary
Ward Cunningham talks with Bill Venners about complexity that empowers versus complexity that creates difficulty, simplicity as the shortest path to a solution, and coding the simplest thing when you're stuck.

In the software community, Ward Cunningham has a reputation for being a font of ideas. He invented CRC Cards, a technique that facilitates object discovery. He invented the world's first wiki, a web-based collaborative writing tool, to facilitate the discovery and documentation of software patterns. Most recently, Cunningham is credited with being the primary inspiration behind many of the techniques of Extreme Programming.

On September 23, 2003, Bill Venners met with Ward Cunningham at the JAOO conference in Aarhus, Denmark. In this interview, which will be published in multiple installments on Artima.com, Cunningham gives insights into wikis and several aspects of Extreme Programming.

In Part I: Exploring with Wiki, Cunningham discusses using wiki for collaborative exploration and the tradeoff between wiki authors and readers.
In Part II: Collective Ownership of Code and Text, Cunningham discusses how he designed wiki to be a model for collective code ownership, collective incentives for pride of ownership, and how to deal with disagreements by eliminating the cost of making mistakes.
In Part III: Working the Program, Cunningham discusses the flattening of the cost of change curve, the problem with predicting the future, and the program as clay in the artist's hand.
In Part IV: To Plan or Not to Plan, Cunningham discusses using the programming language, rather than the whiteboard, to design and communicate ideas.
In this fifth and final installment, Cunningham discusses complexity that empowers versus complexity that creates difficulty, simplicity as the shortest path to a solution, and coding the simplest thing when you're stuck.

Complexity that Empowers

Bill Venners: What is simplicity? How do we recognize it when we see it? And why should we strive for it?

Ward Cunningham: I actually enjoy complexity that's empowering. If it challenges me, the complexity is very pleasant. But sometimes I must deal with complexity that's disempowering. The effort I invest to understand that complexity is tedious work. It doesn't add anything to my abilities.

A friend of mine once said that there are problems and there are difficulties. A problem is something you savor. You say, "Well that's an interesting problem. Let me think about that problem a while." You enjoy thinking about it, because when you find the solution to the problem, it's enlightening.

And then there are difficulties. Computers are famous for difficulties. A difficulty is just a blockage from progress. You have to try a lot of things. When you finally find what works, it doesn't tell you a thing. It won't be the same tomorrow. Getting the computer to work is so often dealing with difficulties.

The complexity that we despise is the complexity that leads to difficulty. It isn't the complexity that raises problems. There is a lot of complexity in the world. The world is complex. That complexity is beautiful. I love trying to understand how things work. But that's because there's something to be learned from mastering that complexity.

Simplicity: the Shortest Path to a Solution

Now, what is simplicity? Simplicity is the shortest path to a solution. Say somebody does a proof for a mathematical problem in 20 pages. You study those 20 pages, and finally you say, "Oh, I get it." You get a reward as the result of understanding that proof, because the proof was a solution to an interesting problem, not just a difficulty. Later, somebody else comes up with a 10-page proof for the same problem. Maybe the new proof uses a branch of mathematics that you might have to study to master, but once you master that branch of mathematics you can use it. And a 20-page proof becomes a 10-page proof. You'd have to say it's simpler, because it's a shorter path. Maybe it's longer if you have to do a digression to actually learn a new branch of mathematics, but let's assume that over time we realize that this branch is important to know in general, so we all become familiar with it.

What we're really trying to do in software is find a way to make it easy to get value from having solutions to problems. How do we do that? When we work the program, we put in what we think is the shortest path to a solution. When we discover that the problem is different than we thought, we rewrite. And then we rewrite again. We work the program. That process is just like doing the proofs over and over. Sooner or later we discover that instead of doing something in 30 lines of code, we can do it in 15 lines, because now we have another capability that fits in. It really is just the right capability, so the work done there we don't have to do here. We'll just invoke that capability from here. That makes our solution easier to follow. Plus the effort you expend today to understand the code will make you a more powerful programmer tomorrow. So that simplification is very valuable.

If you write a lot of programs, and you're used to squeezing them all the time, you find that it's easy to write a program that's simple. A lot of it is having a clear sense of what you want to say—writing the proof by choosing what to prove, and being clear about that. In programming, a lot of simplicity comes from knowing what matters and what doesn't matter. A lot of times a program is made complicated because it's attending to details that aren't needed, or could have been avoided, or could have been relegated to something else.

Someone says, "You should always check your arguments to see if they're in range." Someone else says, "Half the statements in this program are checking arguments that are intrinsically in range." Have they made the program better or worse? No, I think they've made it worse. I'm not a fan of checking arguments. On the other hand, there ought to be a fail fast. If you make a mistake, the program ought to stop. So there is an art to knowing where things should be checked and making sure that the program fails fast if you make a mistake. That kind of choosing is part of the art of simplification.

Einstein said, "As simple as possible, but no simpler." He was being accused of being complex, and he was saying "Yes, simple is important, but..." He'd taken a body of observable fact that was unaccounted for, and accounted for it. So yes, his theory, his models were more complex than Newton's, but they did more. They were worth studying. He was saying, "Look, I made them as simple as possible, but no simpler."

So today, let's write a program simply. But let's also realize that tomorrow, we're going to make it more complex, because tomorrow it's going to do more. So we'll take that simplicity and we'll lose some of it. But tomorrow, hopefully tomorrow's program is as simple as possible for tomorrow's needs. Hopefully we'll preserve simplicity as the program grows.

What's the Simplest Thing that Could Possibly Work?

When Kent Beck and I were playing with Smalltalk, we found it amazing what Smalltalk would do compared to anything either of us had used before. And it really seemed that Smalltalk wanted us to try things. A lot of times, we would just try to see if we knew how to program something. We'd be talking about something, and say, "Gosh. Do you think we could program that?" And we'd just jump in and start programming. And sometimes the programming was almost effortless, as if Smalltalk had been made to write that program. It was amazing. But other times we'd be programming away, and we'd say, "Now, wait a second, what are we working on here?" We'd just get stuck. And if we were stuck more than a minute, I'd stop and say, "Kent, what's the simplest thing that could possibly work?"

It was a question: "Given what we're trying to do now, what is the simplest thing that could possibly work?" In other words, let's focus on the goal. The goal right now is to make this routine do this thing. Let's not worry about what somebody reading the code tomorrow is going to think. Let's not worry about whether it's efficient. Let's not even worry about whether it will work. Let's just write the simplest thing that could possibly work.

Once we had written it, we could look at it. And we'd say, "Oh yeah, now we know what's going on," because the mere act of writing it organized our thoughts. Maybe it worked. Maybe it didn't. Maybe we had to code some more. But we had been blocked from making progress, and now we weren't. We had been thinking about too much at once, trying to achieve too complicated a goal, trying to code it too well. Maybe we had been trying to impress our friends with our knowledge of computer science, whatever. But we decided to try whatever is most simple: to write an if statement, return a constant, use a linear search. We would just write it and see it work. We knew that once it worked, we'd be in a better position to think of what we really wanted.

So when I asked, "What's the simplest thing that could possibly work," I wasn't even sure. I wasn't asking, "What do you know would work?" I was asking, "What's possible? What is the simplest thing we could say in code, so that we'll be talking about something that's on the screen, instead of something that's ill-formed in our mind." I was saying, "Once we get something on the screen, we can look at it. If it needs to be more we can make it more. Our problem is we've got nothing."

I think that that's a breakthrough, because you are always taught to do as much as you can. Always put checks in. Always look for exceptions. Always handle the most general case. Always give the user the best advice. Always print a meaningful error message. Always this. Always that. You have so many things in the background that you're supposed to do, there's no room left to think. I say, forget all that and ask yourself, "What's the simplest thing that could possibly work?"

I think the advice got turned into a command: "Do the simplest thing that could possibly work." That's a little more confusing, because there isn't this notion that as soon as you've done it, we'll evaluate it. People ask, "Well, how do you know it's the simplest?" In my case, we didn't know. We were just going to get it on the screen and look at it. But as soon as it becomes a command, then we have to analyze it and ask, "Is that the simplest?" And all of a sudden it becomes complicated. What is or isn't simple?

There's been an awful lot of discussion about what is or isn't simple, and people have gotten a pretty sophisticated notion of simplicity, but I'm not sure it has helped. It might just confuse. Sometimes you think, "Gosh, you know, I'm such a wimp, I can't even understand the discussion of simplicity." It scares people.

Coding up the simplest thing that could possibly work is really about this: If you can't keep five things in your head at one time and make a decision, try keeping three things in your head. Try keeping just one thing in your head, and see if you can make a decision. Then you can think of the next thing. And amazingly, when you write some of this dumb, straight-ahead code, it often turns out that it was all that was required. It works great. When a second programmer comes back later and reads the code she might say, "The people who wrote this are morons. They just wrote a simple linear search here. This thing's ordered, so they could have done a binary search. They could have used a hash table here. Why are they doing a linear search?" Well, because a linear search worked. And when the other programmer looked at the linear search, she understood it in a minute.

Next Week

Come back Monday, January 26 for the next installment of a conversation with C# creator Anders Hejlsberg. If you'd like to receive a brief weekly email announcing new articles at Artima.com, please subscribe to the Artima Newsletter.

Talk Back!

Have an opinion about the design principles presented in this article? Discuss this article in the Articles Forum topic, The Simplest Thing that Could Possibly Work.

About the Author

Bill Venners is president of Artima Software, Inc. and editor-in-chief of Artima.com. He is author of the book, Inside the Java Virtual Machine, a programmer-oriented survey of the Java platform's architecture and internals. His popular columns in JavaWorld magazine covered Java internals, object-oriented design, and Jini. Bill has been active in the Jini Community since its inception. He led the Jini Community's ServiceUI project that produced the ServiceUI API. The ServiceUI became the de facto standard way to associate user interfaces to Jini services, and was the first Jini community standard approved via the Jini Decision Process. Bill also serves as an elected member of the Jini Community's initial Technical Oversight Committee (TOC), and in this role helped to define the governance process for the community. He currently devotes most of his energy to building Artima.com into an ever more useful resource for developers.

via artima.com

Derek Powazek - Meaning-Making Machines

2011-09-06T17:24:00.001+08:00

via powazek.com

If You Liked This, You’re Sure to Love That

2011-09-04T08:39:00.001+08:00

By CLIVE THOMPSON

Published: November 21, 2008

THE “NAPOLEON DYNAMITE” problem is driving Len Bertoni crazy. Bertoni is a 51-year-old “semiretired” computer scientist who lives an hour outside Pittsburgh. In the spring of 2007, his sister-in-law e-mailed him an intriguing bit of news: Netflix, the Web-based DVD-rental company, was holding a contest to try to improve Cinematch, its “recommendation engine.” The prize: $1 million. more...


	Samantha Contis for The New York Times Chris Volinsky (left) with Robert Bell working out Netflix algorithms at the AT&T research labs in New Jersey. via nytimes.com

Social Design Reading List

2011-09-01T17:10:00.001+08:00

via emdezine.com

Why some social network services work and others don’t — Or: the case for object-centered sociality :: Zengestrom

2011-08-29T16:12:00.001+08:00

via zengestrom.com

excellent article! highly recommended.

Marc Andreessen on Why Software Is Eating the World

2011-08-29T11:50:00.001+08:00

via online.wsj.com

Metrics for Healthy Communities

2011-08-28T12:00:00.001+08:00

via horsepigcow.com

Great post!

Business rules.

2011-08-27T09:49:00.001+08:00

Start-Up Stories: Max Levchin

2011-08-26T10:48:00.001+08:00

Anonymity and Online Community: Identity Matters

2011-08-25T08:03:00.001+08:00

via alistapart.com

Social Media Marketing By the Numbers [INFOGRAPHIC]

2011-08-18T07:45:00.001+08:00

via mashable.com

Dilbert: Work at Home Conspiracy [COMIC]

2011-08-15T19:54:00.001+08:00

via dilbert.com

funny & truthful.

Photo Album - Imgur

2011-08-13T14:05:00.001+08:00

via imgur.com

amazing!

New York vs. San Francisco: The Cost of Operating a Business in the Valley and the Alley (Infographic)

2011-08-12T18:29:00.001+08:00

via focus.com

sneak peek: armin blasbichler | Design*Sponge

2011-08-12T15:58:00.001+08:00

via designsponge.com

How Small and Midsize Businesses Are Key to Growing the Economy

2011-08-12T15:37:00.001+08:00

via good.is

Most Interesting Bookstores of the World

2011-08-11T16:47:00.001+08:00

via miragebookmark.ch

HOW TO ACHIEVE THE PERFECT TIE DIMPLE

2011-08-10T23:25:00.001+08:00

via parkandbond.com

A $20 Kit Lends Any Paper Plane An Electric Motor

2011-08-07T22:53:00.001+08:00

via fastcodesign.com

Cool! A power module converts your paper-crafted glider into a supercharged flying machine.

xkcd: Python

2011-08-03T05:17:00.001+08:00

via xkcd.com

funny!!

Flashback: Google's Sergey Brin Isn't the Real Google Guru on "To Tell the Truth" [VIDEO]

2011-08-02T16:40:00.001+08:00

via mashable.com

hilarious!!

The Greatest Developer Fallacy Or The Wisest Words You’ll Ever Hear?

2011-08-02T02:45:00.001+08:00

via skorks.com

As A Software Engineer, Do You Really Like Your Job? | Agile Zone

2011-08-02T02:42:00.001+08:00

I love how things happen. First, I ask for feedback on the blog Facebook page about what types of posts people would like to see. Someone asks for more career advice for senior level people, and then two other blog posts appear that make my job a lot easier. There are a lot of topics to talk about when you look at career advice for seasoned veterans of industry. Today, I wanted to focus on making sure you, as a software engineer, were doing the right thing for you. Basically, software engineering is difficult work and typically high stress. So, if you don’t really like your job, you need to do the right thing and find one that you can like or even love. The real question is how do you know it is time for a change?

Erik Petterson has a really interesting post where he compares job satisfaction to a coffee table. It is a very good post that gives you a nice overview of how to check if you still like your job:

My advice to those disenfranchised with their jobs. Inventory their job satisfaction coffee table. Ask yourself, “Am I getting paid reasonably? Do I like what I’m doing, who I’m doing it with, and whether the good times seem like they’re gonna continue or not?”

There are plenty of websites where you can check the average compensation for a software engineer in your geographic location. So, you should make sure you are at least near the average or above it.

The team that you work with is also very important, because they can make a job much more enjoyable. I have had some jobs where I had no interest in going to happy hour after work with a large group of coworkers. On the other hand, I have had teams where the people are almost like family and working with them became enjoyable even if it was stressful. Ask yourself, do you really like the people that you work with? You spend at least 40 hours per week with them, and probably another 10 hours per week thinking about them when you are home. Not liking them will just make your home life more difficult.

Job stability is a bit of a misnomer in our current industry. Even the giants like IBM, Microsoft and even Google have laid off people in the past two years. If you work for a smaller company, stability is always a question. The problem is that you have bills to pay, so a steady paycheck is required. What you want to do is figure out if the company itself is somewhat stable. Have they had a lot of people leave for other jobs in the area? Does the company have an increasing customer base? Are they cutting little perks like free coffee or bottled water? Also, how happy are the employees on average? All of these point to the general health of the company, and can tell you whether you should be looking for a new job in order to protect your financial well-being.

Lastly, and probably most important for software engineering is, do you really like what you are doing? For some people, love of their work can override any deficiencies in the other areas. That is not always a good thing, unless you are already wealthy and the paycheck does not matter to you. At some companies, the work will always be really interesting and a lot of fun to work on. However, there are not a lot of those types of jobs, but there are plenty that you can like. How do you know if you do not like your current job? Merlin Mann wrote a fantastic post about cranking. His descriptions of cranking are probably all too familiar to some of you:

I didn’t have time to think about my family. Not now, right? No, I had to keep working… So, I’d type and type. I’d crank and crank. I’d try and try… I would do my job until I hadn’t the slightest idea what time it was or what bullshit I was typing or what my crank was ever meant to be attached to in the first place. But, even when my shitty little crank was not attached to anything, I did keep cranking. Because, Dads do their job. It’s what they do. They crank. They crank and crank and crank and crank.

Have you ever been in that type of position? No matter how much work you do, you have that much more to do. If the work is not interesting, then it really is just like turning a crank on a bed. Eventually, you go to work, do whatever is needed and collect a paycheck. There is no joy in this life, and enjoying your job is very important to your overall happiness. If you have found that you dread going to work, without even knowing if there are problems, then you are probably just cranking. Merlin has an excellent quote in that same post on what you need to do:

It’s now become unavoidably clear to me that I’ve been doing each of these things poorly. The job, the making, the pleasing, and, yeah, the being at home. And I can’t live with that for another day. So, I’ve chosen which one has to go.

You have to remember that you can change a lot of things. You can change how you do your job, and maybe make your company a better place to work. If that is not possible, what else can you change? Maybe it is time for you to change your job, unless you really like that crank.

References

Reference:

As A Software Engineer, Do You Really Like Your Job?

Your rating:
0

I am a software engineer, database developer, web developer, social media user, programming geek, avid reader, sports fan, data geek, and statistics geek. I do not care if something is new and shiny. I want to know if it works, if it is better than what I use now, and whether it makes my job or my life easier. I am also the author of RegularGeek.com and Founder of YackTrack.com, a social media monitoring and tracking tool. Robert is a DZone MVB and is not an employee of DZone and has posted 54 posts at DZone. You can read more from them at their website.

via agile.dzone.com

Interesting article.