Just a Thought...: Tag users

How Many People Know How to Tag?

Berin Loritsch — Mon, 03 Dec 2007 14:42:00 +0000

I’m sure it seems odd for me to question this after I’ve doted on its merits and how easy it is to do. How many people use the bookmark tools like Ma.gnolia.com or del.icio.us? How many people have used something like Flickr, etc? When you think about it, the number of sites like this are surprisingly small. Even though there are a number of users, few are there because of the tagging. It’s because they get some value out of the site that they don’t get somewhere else. Flickr works because of the communities, where you can find groups to shoot the breeze or perfect your craft—whatever you want.

Even now, the only thing I use Ma.gnolia.com for is to manage the list of links on my blog. I don’t participate in the groups or anything like that. Quite frankly, I don’t have enough time to read a whole bunch of blogs or follow links like I used to. Tagging the links are less important in that case. Sometimes I want to find an old link, and I can use the tags to get back to the article I wanted. However, after you’ve applied the knowledge in the article a few times, there’s no real value in keeping it around. Yet, there’s effort required to go back and remove it. Since I only list the most recent X number of links on my blog, that’s usually enough for me.

There are some places where I really think that tagging would be the right solution to find things again. One example would be iTunes, or whatever you use to manage your music. Setting up play lists based on tags is a great feature, so I’ve kind of forced that model on iTunes. Of course, I fear such a feature would go wasted on a great number of people because they don’t really see the value in it. Once you get over a certain number of songs you are managing, you really do need a better way to sort and organize your music than just the artist, genre, album type information.

There are some common elements of tagging software such as all the tags are displayed on the right. Sometimes they are shown in clouds, and sometimes they can be combined to narrow the selection more. However, things can become messy when you have the common left side navigation elements along with right side tag information. What’s the right thing to do? Should you mix the functionality of bookmarking sites and information providers?

Honestly, since bookmarking sites make it relatively easy to integrate with other sites, I think that they should handle the bookmarking features, and what you are doing should work on the content. It can get messy quick. Really quick. Should you allow multiple identical tags on an object from different users? How do you display them? If someone deletes a tag, and it’s just their version that goes away and someone else’s tag is there, what should the app do?

Truth be told, tagging is still the realm of power users. I wish it weren’t, but there’s still a lot to be discovered about how people use tags, and the types of things you can do with them.

User Edumikashun--Design Problem?

bloritsch — Fri, 13 Jul 2007 14:28:00 +0000

How do you know if your design is any good? Some people will tell you that if the user doesn’t have to think about it and it just works then you’ve got it right. There is a lot of truth to that, but what if what you are doing is going to bend people’s brains in the beginning? It’s particularly an issue if you want to overcome a cultural barrier to free people from the shackles of their backward thinking. Once they get over this cultural barrier and they “get it”, then they can see the limitless possibilities ahead of them. The best way to illustrate what I mean is to use a case study.

Department of State

The U.S. Department of State has a messaging system that has been in place for several decades, and at the time they were very forward thinking. They had a set of Traffic Analysis by Geography and Subject (TAGS) keywords that can be associated with each message. It didn’t stop there, you could associate any word you wanted to with the message and it would be called a Term. Now, the confusion lies in the fact that both TAGS and terms were marked in the message by the heading “TAGS:”. Anyone who has done anything with web 2.0 technologies can immediately recognize that both these TAGS and Terms fit the concept behind tagging. The Department of State has been doing this for years. My company has developed a system to allow all the federal government agencies to find, tag (in the web 2.0 sense), and consume these messages. Ironically, most of our users are outside the Department of State. They don’t have the cultural bias as the Department of State.

Since the beginning of the project, we operated under the assumption that it was going to be primarily for the Department of State, and maybe a few folks from other agencies would be accessing the database. It didn’t turn out that way, and as Guy Kawasaki mentioned in his online presentation “The Art of Innovation” you don’t get uptight because different people are using your application than you anticipated. You work with it. None of our other users don’t have the Department of State background and baggage, so they don’t really get tripped up if you call something a tag or a term.

We made a conscious design decision for this version of the software, and that was we were moving to a more standard web 2.0 model. All our previous discussions on the matter confused things, and if the designers were getting tripped up over where to use TAG, Term, tag, etc., then what about our users? The truth of the matter is, we could view all the tags in the system as plain old web 2.0 tags. It’s just that some of those tags have special meaning to a large portion (but not majority) of our users. So when we implemented the rel-tag microformat, we added a note when a tag was important to the Department of State. This also opens up our system so that we can support other categorization systems for other government agencies.

As we got to a place of testing the system, we wanted to put some extra eyes on the new application. To do that, we put a version on the staging server and asked certain people to look at the preview version and give us our thoughts. I noticed something interesting, the people we have been coordinating with since the beginning have been educated all along and didn’t have any problems whatsoever. The one or two that handle support requests for the existing system had a hard time. In the “bug” reports he unconsciously kept referring to the web 2.0 tags as TAGS, and drawing the separation of TAGS and Terms and wondering why we mixed the two together, etc. We knew there would be some culture shock, but it didn’t take long to explain to him what was going on and he got it.

How to Edumikate Your Users

Educating users should not take too long. In fact, if you can’t do it in a short paragraph or two, you might be stretching things too much for them. We added a bit more explanatory text to help put user’s minds at ease. It was surprising to us that in two specific instances the extra words we used were confusing things rather than simplifying them. Our preview users said it made more sense to label the section where the tags were located “Tags” as opposed to “Tags used in these messages” or “Tags in this message” (depending on whether we were looking at a list or a single message). That’s a no-brainer.

We did find that the “rel-tag” microformat caused a little bit of a headache. We allow the users to narrow down the messages they are looking at by going to a certain geo-political slice, Department of State TAG, and/or a search term. When they clicked on the link to the tag (to go to the rel-tag space) they were expecting all those constraints to apply there as well. We chose not to do that, because we wanted to ensure that all people saw the same messages that are marked with the tag in question, regardless of where they came from. All that required was a little bit of explanation of what people were seeing on those pages, why we were doing it, and some reassurance that we didn’t forget about where they were.

We still know that we will have to help explain to our Department of State users why we made the changes like they are. The important thing is to be very up front about what is going on, what it means to them, and use plain language. You shouldn’t need a doctorate or background in cypher approaches to figure it out. Sometimes you can spread the user education throughout the application. That is one of the more subtle ways of making an application that doesn’t need a user manual. It at least tells the user how something is done. If it is short enough, experienced users will simply gloss over or ignore the instructions. Try not to make the user scroll past the instructions before they can do what they need to do—that will make them mad. If it takes a lot of instruction, you may have the wrong approach or you may need that help on a separate page. Usually you only need to look at it once or twice. I prefer to use the separate pages to educate on why we are doing things the way we are doing them, and what it helps the user do that they couldn’t do before.

To answer the question in the title, you will probably need to educate your users a little bit. Spreading the instruction out so that there is just enough so they know what to do is a good way to make the application self-documenting. They can throw the manual away without worries. When your screen starts looking like an instruction manual and you can’t find the controls, then you probably have the wrong design approach for your users. There is a threshold, but you’ll have to use your gut to find it for your application. Sometimes, it is worth a bit more user education to make a design choice that will help your users do more with what they have.

Technorati Tags: education user design validation

Are Your Users Dumb?

bloritsch — Wed, 21 Mar 2007 23:41:00 +0000

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.

Why I Hate Writing Microsoft Programs

bloritsch — Wed, 21 Feb 2007 18:11:00 +0000

First off, I don‘t dislike Microsoft for religious reasons or claim that the only true software is open source. I dislike Microsoft because they have made my life difficult on many occasions when it could have been easy. The one area where Microsoft is the most painful to use is when you write software. The first problem is the horrendous API documentation and how to articles. Before I provide anechdotal evidence, let me provide something to contrast against.

As a Java developer, there are a couple things I have come to appreciate about the Java‘s contributions to the world. The first is the first rate JavaDoc tool. If Sun did nothing else right, they spent the right amount of time to flesh out the JavaDocs for the core API, and even provided links to tutorials to help you understand how things are supposed to work together. Second, the Java community as a whole has contributed excellent articles on how to solve different problems with Java. I‘d love to see another community surrounding a language match the level of quality of the articles. As a result of all these rich resources, developing Java programs is far less of a pain than any language supported by Microsoft.

As a Visual C++ developer, there are a couple of things that I have come to loath about Microsoft‘s contributions to the world. The first is the abysmal API documentation, which has gotten worse with the advent of the .NET framework. The descriptions are barely useable and there is no clear idea of how to use some of the parts of the API. It might be forgivable if the remainder of the Microsoft community (including magazines and such) picked up the slack, but rarely can you find what you need and everyone wants money. You can‘t even evaluate if the magazine will be good for you without spending money on it. The second is the lagging IDE technology. Things that I take for granted in any Java IDE like refactoring tools are not to be found in Visual Studio (unless you pay for a third party plugin or a new version finally includes limited support for it). You can‘t really build anything without the IDE, but it is a pain when you do something as simple as rename a method to clean up the class signature.

One of the first events that really helped me to dislike programming Microsoft programs was when I had an assignment to add features to the print dialog. I searched the IDE help for how to do this, and all I could find was that it was “possible” but that was it. I had a coworker look through his several hundred dollar thick reference guides and they gave the same answer as the online help. I searched the internet and came up with the same answer. Eventually, I ended up just creating a new dialog box with just the controlls I needed and secretly controlled the printer settings behind the scenes. The printer settings are set by the dialog box which is required by Microsoft to exist — but you can instantiate it without making it visible. After I created the custom print dialog with just the controls we needed I finally found the answer I originally needed, sort of. It turns out you need to copy the Print Dialog resource descriptor from the API source code included with Visual Studio into your project and manually edit it with a text editor to add the controls you need. There were no instructions on how to edit the resource file, but at least there was some description of the process. Events like this repeated themselves ad nauseum .

Another event that solidified the fact that I didn‘t want to do .NET programming and spend time learning C# had to do with a copy of Visual Studio 2003 given to me by my company. Despite the fact that this IDE is supposed to be Microsoft‘s cutting edge offering, they didn‘t learn a thing from the success of Java. Java‘s success has nothing to do with the language! It has everything to do with the community surrounding it, and the attention vendors pay to making our lives easier. Visual Studio 2003 had zero refactoring tools. None, zilch, nada. The open source community did help in some respects by providing NANT and NUnit, but no refactoring plugins. Eventually JetBrains created one, and perhaps Microsoft has licensed it for the next version of Visual Studio. I asked the Microsoft rep about it the response was, “No, it doesn‘t have anything like that… but don‘t you think that being able to display a screen on the desktop or on the web with the same code is a useful thing?” I couldn‘t believe it. How many people do that? You either develop for the web or you develop for the desktop. Worse, despite the cool factor that might have, it doesn‘t make my life easier for what I do each and every day. Refactoring tools are useful even when there is no UI and you are writing a library.

There are some very clever things that Microsoft has done, but they are lost in a sea of irrelevant features and horrendous documentation. The documentation problem is made worse by the community of money grubbing publications filled with articles that are no better than what Microsoft provides. Will things get better? Not if they continue to stick their heads in the sand when truly useful innovations come around. Is Java the bees knees? No, but it is a useful tool if only for the fact that you can find a real solution somewhere on the web without having to shell out money just to look at it. For the record, I‘d really like someone to implement something as elegant as Microsoft‘s web service solution in Java. Of course, you lose that very elegance if you don‘t use the overpriced and underpowerd Visual Studio….