Software Artisan

For us power users, the benefits of folksonomies are self evident. The metadata we apply to something , whether it is a picture, an article, a movie, or something else assists us in a variety of ways. It can be used to help us find that thing again, or it can help us understand what went into making that thing, or something that only benefits you. Of course, those tags can help other people as well, but that benefit is by coincidence and not necessarily design. However, for people who are completely new to tagging, the benefit is elusive. There is some user education that needs to go on. If a third party creates a cool thing that consumes a set of tags, that is enough to educate the newbies.

The wide disparity of user experience makes it hard to design systems properly. On one hand, there is a distinct education gap that needs to be there for the uninitiated. The folks who just don’t seem to get it aren’t necessarily Luddites (AKA technophobes). Just like anything, nobody is going to do something unless they get benefit out of it. Tags do help with refindability, notations, and integrating separate sites together via mashups.

The issue that social site designers face is balancing ease of use, education, and supporting all the baggage that seems to come with these sites. After all, there is a certain expectation that power users have of a “web 2.0” social site. They expect to be able to use their information across several sites, pulling data in through loose, but well defined interfaces. It’s also near mandatory to provide some way for users to find and talk to each other. All these functions have to be accessed in some way.

The danger in letting the power user define the user interface, is that they want nearly every feature at their fingertips. It’s just a physical impossibility. A screen has only so much real estate, and only a handful of features are necessary right there. Simplicity and negative space go out the window, and you get a crowded interface that will scare away any new users. You really need something that gives normal users the impression that they can use the site. Negative space is reassuring to people. Having only the right tools available at your fingertips also helps. I think that Flickr has done a good job for doing this for people sharing pictures, but borrowing the design wholesale for something completely unrelated probably won’t work so well.

The danger in designing to the lowest common denominator is that you provide an interface that is too restrictive, and becomes painful to do anything cool. You want to give your users the feeling that they can do cool things with your site. That includes the power users and the newbies as well. Too much negative space, and simplisticness don’t provide enough of a clue for what a user can do. Sure they get over the “I suck” stage pretty quickly, but they never reach the “I rock” stage. Worse, if it is too hard to figure out how to do advanced things your users will sink into the “you suck” stage and leave.

As always, the balance is difficult to work out—but not impossible. But to add to the design challenge is the nature of social interaction. When you design a site for social interaction at any level, you have to address a few issues. First, a community that is too small can’t sustain itself. People need to find other people that they can trust to help them improve in some way. Second, if a community gets too big, it will collapse under its own weight. When there are too many people the individual voice gets drowned out and people lose interest when their voice can’t be heard. Sure you might have a couple shining stars, but breaking the barrier to become a star becomes near impossible unless you started in that position when the community was small. It’s the nature of human interactions. When the only currency that you can trade is ego, we need to create a way for that currency to get you as far as possible. Just creating new groups for discussions isn’t the best. It’s hard to break the small community barrier. There needs to be something bigger than personality to generate interest. There has to be a common goal, which is more difficult to achieve than common interests. Sure you may like to see sunsets, but how much can you really talk about them?

Finally, I apologize for taking so long to post. I’ve been very busy with design meetings with my client. There are things we may not see eye to eye on, but we will eventually get to a happy medium where we can both be happy. That’s the longest part of the design process when the customer has their own opinions. At the end of the day we have the same goals, and we both want the users for the system to be happy. We just have different ideas of how to achieve those goals.

How do you handle disputes with design decisions? There’s a few different strategies, including drawn out discussions, giving them rope, or “I am god, hear me roar”. They all have their pros and cons. There are a few facts that can’t be denied:

• Design is a creative process
• One design does not fit all problems
• No matter what you choose, there will always be a better way
• There are drawbacks and risks to every design (submitted by Doug)

So, what about driving consensus with long, drawn out discussions? After all, if two heads are better than one can’t we avoid bad decisions by having everyone agree on a solution? This is what makes design by committee fail flat on its face. In essence, the consensus based design is driven by compromise and making the wrong people happy. The people that need to be happy are the ones using your software (not necessarily the same as the ones paying you to create the software). That’s another challenge that isn’t the same as today’s topic. The people that don’t need to be as happy with the user interface design are the people who write the software. Everyone has their own opinion and their own idea of what’s best, and when you try to please everyone you have a project that looks like Frankenstein’s monster. Worse, it works about as well.

Ok, so many times consensus among opinionated people doesn’t work out. What’s another approach? Well you can give people some rope to hang themselves with (and hence, the name of the article). One of four things will happen: the dissenting opinion will run out of energy trying to prove the point with code, the attempt to try something new will completely fail, one of the alternate solutions will succeed, or you will have more than one correct solution. But the point is you now have something more concrete than windbags throwing their weight around. If the dissenting opinion runs out of steam, or the idea fails, you have some experience pointing to the fact that the proposed alternate solution wasn’t a good idea to begin with. If the alternate solution succeeds, and the main solution fails, you are not stuck. If they both succeed, you can now choose the most elegant of the two and move forward. Of course, at this point you may have to resort to the last option…

We’ve all dealt with the type: “I am the design god, hear me roar!” I’m sure, if we were honest with ourselves, we’ve all been that person. Honestly, there are times where we need this person. A strong person to move the team forward with something . We all know that it’s not the best way because of the third point above, but it may be the best option right now . There’s going to be some dissension at different points, and there does need to be someone who will make the determination. This person should be fair and unbiased, choosing what is best for the project. The danger of the design god personality is that there is always the possibility of only pushing their own preferences, regardless of whether it is right for the project or not.

You‘re probably thinking to yourself what does people skills have to do with writing software? After all, isn‘t being a software engineer made for people with poor social skills? Consider for a moment that very few of us create software in a vacuum. Most of us write our software with a team, and that is where people skills matter. Listed below are some rough guidelines to good people skills in the context of a software team.

Critique the Code, Not the Coder

Most open source organizations have this nice cliché as part of their community rules. It‘s a good start, but there are different kinds of critique. If you liken it to the use of force, you have a couple of choices. You can use what amounts to nuclear attack with all of its collateral damage. You can also use a precision strike intended to address one problem. Believe it or not, there is place for every type of critique. The trick is to use the right amount of force for the offense. If it is someone‘s first attempt at bringing something new to the table, it makes sense to be gentle with the guy. If someone is trying to force their agenda through after being repeatedly told “no”, then it makes sense to take the gloves off.

Since email is usually the primary means of communication with dispersed teams, more care has to be taken when you write them. We infer tone from the language in the email, so what isn’t said is just as important (or sometimes more important) as what is said. When you use harsh language when it isn‘t warranted, even if it is toward code, the collateral damage takes out the coder as well. Communication is a tough subject. Try to put yourself in the person‘s shoes and judge whether or not you might be a bit heavy handed.

When a Decision is Made, it‘s Made

For better or worse, whether you agree or not, when a team arrives at a decision they need to follow through with it. When the decision isn‘t finalized yet and it is still being debated, you have a responsibility to add your input. If you are silent at that stage you will have lost any input later. Once a decision is finalized, like it or not it is the will of the team. You then have two choices: find another team, or swallow your pride and go with it.

There is nothing worse than a broken record constantly rehashing the same thing again and again. Why should a team have to keep justifying a decision to you? If everyone else is OK with it, or at least doesn‘t see any harm with it, what makes you so important that everyone needs to answer to you? One of the definitions of hostility is “opposition or resistance to an idea, plan, project, etc.“. No one likes hostile environments, or hostile people. The action of rehashing a decision because you don‘t like the outcome is creating a hostile environment. Should you continue pursuing that course of action, you will find yourself alone.

Mean People Suck, Play Nice

It shouldn‘t need to be said, but apparently it does. We‘ve all experienced someone who has the personality that grates your last nerve. It would be better to listen to fingernails scratching a chalkboard than being around mean people. How can you tell if you are being mean? Mean people insult, demean, and are otherwise critical and selfish almost all the time. If all that comes out of your mouth (or is written in email) is generally negative, you are a mean person. If you always have to ram your decision through no matter what, you are likely a mean person.

Playing nice means using a little give and take. Give props when they are due. It means being honest, but not brutal, with both yourself and others. If someone came up with something you wouldn‘t have thought of, but it really works or is cool, say so. If you have a question, ask it. When it comes to teams, it means looking at decisions with the perspective of what is best for the team. Sometimes it means letting a decision you may not like pass, as long as it doesn‘t damage the project. Ugly disagreements have a way of tearing up teams, causing more damage to the project than the decision you might not like.

Playing nice does not mean coating everything you say with sugar. No one trusts “yes men” or people who do nothing but pay compliments. They come across as suck-ups, and there is always the underlying fear of what they really think. The suspicion is that you have a hidden agenda. That is why you should be honest, but not be brutal about it. If you don‘t like something don‘t pretend that you do, but don‘t stand in the way if you don‘t have a good reason.

The bottom line to playing nice is having mutual respect for the members of your team. It‘s hard to be nice to someone you can‘t respect. It feels false and dirty. Try to find something about the person you can respect, and work from there. Building respect is a difficult proposition, so when it comes to people you don‘t know, extend the same amount of respect you think would be appropriate for you when you are new to a group. If they mess it up, that‘s on them. You do need a starting place other than zero to build mutual respect.

Just as fat molecules carry aroma to our nose, words carry ideas from one person to another. It‘s how we communicate. Computers don‘t care about words, to them they are just a series of bytes that they are told to store and barf back up to people. At the end of the day, a computer processes byte code, and even then the byte code that it is given to execute is further recompiled into a lower order byte code. The different programming languages are there for us. They exist because their roll is to translate our ideas into instructions for the computer.

That said, ever wonder why tags are called what they are, and not keywords? After all, in the past, you could mark your site with keywords and search engines would be able to find the pages. And then the porn industry abused that by putting every keyword known to man so they could get good page rankings. The idea has been around for decades, but it didn‘t really catch on until we used the word “Tag“ to reflect the concept. All the sudden it was couture to expose these words to the world, and let just anybody play with them. It‘s because “Tag” didn‘t seem to carry its own weight until it was shown to the world how they could practically make the world a better place. Sites like Flickr and del.ico.us used the tags in ways to make it easier to figure out how to find stuff you cared about.

From the machine‘s perspective, it doesn‘t care what tags you use. You could use obtuse tags like “rous286“ and the computer wouldn‘t complain one bit. It doesn‘t work to well for us, because the idea behind that obtuse name is lost. Are we talking about “Rodents of Unusual Size in February of 1986“ or “Release Operations in the U.S. for the Intel 80286“? We use words for our benefit. We might use a whole bunch of words, or just a couple. The ideas are always there, and there are only so many words that fit an idea. Tags work because of that very fact. When we have an idea and we want to search the world about that idea, someone somewhere probably had the same idea and had at least one word that matched what you were thinking of. It‘s just a matter of playing the odds.

Another case and point for words carrying a lot of weight would be the recent attempt to create a spec language. Instead of “Test First Development“, it was called “Spec First Development”. The activities you did were the same, but the language was different. You thought in terms of what something should do verses testing what it did. The specification is forward looking while tests are backwards looking. At least that is the concepts that those words carry. The fact that you use different words didn‘t change the underlying technology all that much. However, it does influence the way your wrap your head around things.

The last case of words carrying power is more of a sad and dark tale. Someone whom I greatly respect, who is a champion for caring about our users and understanding how they think, has been assaulted with words rather publicly. I‘d love to say she is a friend of mine, but I‘ve never even met her and have only exchanged an email or two with her. Nevertheless, from what I gather she isn‘t the type of person to create enemies wherever she goes. I don‘t want to provide any links to reignite any burning embers that might still be around. There are some people who chose to use threatening words toward this person, causing her to stop all speaking engagements and retreat from any sort of public eye. If words had no true power, then why are death threats illegal? The expression of intent, whether there is any true animosity or not, is enough to incite fear. I consider the acts taken to be completely reprehensible, and the people who participated in her harassment have no defensible position. They should be prosecuted to the full extent of the law. What they have done has caused far more damage than one person‘s mental well being. To cop out and say “it was only a joke“ is to trivialize the damage done to all of us. The person was a great asset to the world of computing, championing the cause of bringing the “human” back to human interfaces. She‘s still alive, but now she is trying to live much more quietly.

Words have power, and words have meaning. Tagging works because of this. Blogging works because of this. Unfortunately, threats also work because of this. We all have the power to change the world around us, even if only a little bit. People who put their reputation on the line and take unpopular stands are the ones who receive the most flack — but also influence the most change. You can only achieve what you risk. I‘d like to challenge everyone to not take the coward‘s way out. Sure there is a right way to approach those in charge, and I suggest you use an attitude of respect if you want to get anywhere. Good processes, good working environments, and good software can only be accomplished when people are willing to champion the cause. I‘m willing to be one of the champions, how about you?

Be careful how you answer that question. Think about it, we all have an opinion on who we expect to use our software. The two main problems that many designed user experiences suffer from are pandering to the lowest common denominator, and assuming too much from your users. Those who pander to the lowest common denominator justify it to themselves saying, “It makes it easier for everyone to use it.“ Those who assume too much justify it by saying, “They will appreciate the power later.“ As usual, the balance is hard to find. Both have valid points and bad assumptions, and both have no clue about the largest group of people who will be using the software.

There is a threshold where the lowest common denominator actually gets in the way of doing something useful. On the other hand, there is a threshold where most people will give up because they can‘t crack the “I suck“ barrier. If you can assume for a moment, and I know this is a stretch for some of you, that your users actually have two brain cells to rub together, you might be able to have more users that appreciate what you create. We‘ve all heard the horror stories of top level executives complaining that the cup holder in their computer is broken, or that they can‘t get to their email because the power is out. With stories like that, you would think that the following quote is true:

Technology is an arms race between engineers trying to build more idiot proof systems and the universe building bigger and better idiots. — Unknown

If there is one thing that I‘ve learned from playing basketball and pool is that people tend to play to the level of their opposition. If you are playing someone less skilled, you end up making mistakes you normally wouldn‘t. If you are playing someone more skilled, you step up to the challenge and become better. If you design a system for intelligent people, the people using the system will become more intelligent.

So can you go too far the other way? Yes and no. The trick is to know your audience. Chances are that unless you are writing a library or programming language your users are not programmers. Which means they won‘t think like you. Which means that what you think is a kick butt feature that makes perfect sense will have your users staring at you like you have three heads. As you spout on how awesome it is, they‘ll say something so profound like ”can‘t you make it so that when I click this button X happens?” As you learn more about how your users think, you‘ll appreciate how smart they really are, and how they think. It takes time, though.