Infinite Web Design

Following my rant about marking links to PDF files clearly I have decided that it is only right to offer some solutions to those of you who may need them. As such I am including a number of options for the icon I recommended using next to PDF links and a CSS solution for placing them there easily.

The icons are:

In order to get them to display properly you can add some simple css to your style sheet and a class to the PDF links. (Or to a div containing many PDF links)

a.pdf:link{
background-image: url(../images/icon_pdf.gif);
background-repeat: no-repeat;
padding-left: 18px;
background-position: left center;
}

This will set the background image of a link with the class of “pdf” to show the PDF icon (icon_pdf.gif), and to pad the text 18px (the width of the icon + 2) from the left.

OR you can use

.pdf:before {
display: marker;
content: url(../images/icon_pdf.gif);
}

This will place the PDF icon before the link with the class “pdf”. However, this doesn’t appear to align the icon vertically with the text as well as the previous method.

These techniques appear to work fine in FireFox 0.9 while failing gracefully in IE 6 by simply having no effect. I’m working on a solution that will appear in all browsers but this is a start. If anyone knows how to make this work in more browsers please let me know.

I am so sick of clicking on a link thinking it will take me to another web page only to have Adobe Acrobat pop up and force me to wait for 20-30 seconds while it freezes my browser and starts up. So please, I beg of you, before I have to punch somebody in the neck, mark your PDF files clearly.

Whenever I post a link to a PDF file I always, ALWAYS include an icon to the left of the link and a note at the end indicating that it is a PDF file and giving the file size. If you’re feeling really nice you can throw in an estimated time to download to help people with slow connections.

This is not a small or uncommon problem and I think it is a real usability issue on many sites. If users cannot easily predict what a link will do when they click on it you make them hesitant to take advantage of the information at the other end of that link. This means that the text in a link should indicate where it will take you and it also means that you clearly mark non-HTML (or XHTML) files. If you are posting PDFs, Excel spreadsheets, or any other odd sort of file for people to download, do your users the courtesy of telling them what to expect when they click on the link.

I have been thinking about the reasons why usability is valuable to an organization. Why should a business invest a bunch of time and money into testing and designing systems? I don’t see a lot of discussion of this among designers but it seems like we should be able to articulate our value to others better than we do. How do you explain to a manager or a client that doesn’t understand that spending two days doing job shadowing that it is not just you sitting around for two days? How do you convince them that getting real users to test a system is need in addition to the user personas that you created?

I have seen a number of articles discussing how to calculate the ROI on usability. But that really isn’t the obstacle that I see as most pressing. I think that a lack of awareness and understanding of what usability designers (or whatever title you prefer) do is the big problem. A common response from those first encountering the idea of usability is ‘okay, let’s tell the developers to make it more usable’. It takes a lot of detailed explanation to convey why that isn’t really the way things work.

So do we sit people down one at a time and walk them through the many fields of study that come into play and the understanding of testing methods, design techniques, coding standards, and other things that go into our jobs? How do you convey the value of usability efficiently?

The truth is that I’m still trying to sort this one out. I understand, after spending inordinate amounts of time on the subject of usability over the last few years how and why it is valuable. But I think I’ve spent so much time getting into so many details that I’ve lost sight of how to explain the big picture, that I accepted long ago, in a way that others can grasp quickly.

Perhaps it is something as simple as ‘I test and design systems so that they will be simple and intuitive to use while retaining their functionality and usefulness’. How do you explain usability?

Today was my first day of Menlo’s High Tech Anthropology 101 course. I have to say it was well worth the time. It covered some ideas and techniques that I was familiar with and others I was not. In both cases I learned something new. We looked a variety of methods for conducting user interviews, job shadowing, creating use cases and scenarios, and modeling information for later use.

It was great to hear both the new perspective provided by the instructor and the different experiences of the other participants in the workshop. Additionally, there was a great deal of practical advice based on Menlo’s extensive work experience that provided insights into how to best communicate with users, developers, and customers.

One technique that I hadn’t previously used was developing a glossary during the course of interviews and other information gathering and analysis to ensure that everyone understands the terms being used. This means the glossary should be included in most reports and other work products and you should go over it with the people you are communicating with.

The other method that I really liked was the creation of a matrix of Use Cases and Actors (various types of people involved in the use cases) indicating the general frequency with which each type of Actor will perform each Use Case. This helps to prioritize development and justify decisions on what to focus on to others in a clear and understandable way. It can be a great tool for explaining the business case for a decision.

I’m looking forward to the next two days there and I’ll be sure to post more of what we cover each day.

I had an interesting experience today trying to define and describe usability, usability testing, interface design, user testing, and other related terms. It was actually rather difficult for a number of reasons. First, I didn’t have any feedback on the level of detail to which I should delve. Should I go for a top level, non-technical definition or a detailed, lengthy exploration of all the subcategories and related ideas that go fall under the broad categories of usability and user testing?

It’s odd, I have a really good understanding of what usability and testing and such things are about, but I have not forced myself to succinctly define or describe what I do for others. Sometimes I ramble about various aspects of it to my friends and family and they gamely humor me as I go on in excruciating detail about some technical point they couldn’t care less about. However, I haven’t had to go justify such things to my clients or bosses, either they already understood it or they gave me such wide latitude in my actions that I didn’t have to justify my decisions to anyone else.

So here are a few of my attempts to define these terms and if you have suggestions and refinements I’d love to hear them.

USABILITY – A field of study dedicated to creating intuitive, simple, elegant, and functional products. The quality of being usable, or easy to use.

USABILITY TESTING – The process of testing a product or system to improve usability. An umbrella term for a wide variety of activities including user testing, heuristic evaluations, GOMS, surveys, focus groups, and other testing activities.

USER TESTING – The process of testing a product or system with actual users to locate problem areas and gain insights into actual user tasks and actions. This allows developers and designers to locate problems that they would not anticipate or locate using techniques such as a heuristic evaluations that do not incorporate real users into the testing.

INTERFACE DESIGN – The process of incorporating information from a wide variety of sources into a simple, elegant, intuitive, and functional interface for a system. Interface Design requires an understanding of use cases, user experience, business goals, user goals, visual design, development methodologies, and many other areas and the ability to synthesize and incorporate all of that information into a single unified design.

Over at Whitespace there was a recent discussion about the communication breakdown between Movable Type and their users. I think that this could help inform my post about small changes. I use Movable Type to publish this blog and I’ve been pretty happy with it. However, their many loyal users were largely kept in the dark about the new licensing scheme for version 3.0. I don’t really want this to be about Movable Type. I want to think about what we can learn from their mistake. Anyone can learn from their mistakes, but a wise man learns from other people’s.

In this case Movable Type was planning a change to their licensing scheme that was potentially disruptive, confusing, and upsetting to their users. Any time you start to charge for something that was free this is bound to happen. However, they failed to adequately prepare their users before the change was made and they failed to explain the changes adequately afterward. This meant that users were both unprepared and confused when Movable Type launched their new product.

How could this have been handled better? They could have announced the change before launching version 3.0. This could have been done by engaging their users in a dialog that explained their reasons for considering the new licensing model (which does include a free version still), and asked users for input on the change. By making users a part of a potentially difficult change the trauma and providing them with adequate time to prepare both technically and mentally Movable Type could have eased the mental and technological transition for their many users.

After the launch information on what had changed, how it had changed, and why it had changed was scarce. This meant that those same users who were caught by surprise were left confused and frustrated when they tried to understand the new licensing model. This further compounded the users feelings of hurt and confusion during a time of transition. Change is hard for people, a lack of information leads to negative feelings and makes it harder.

I don’t mean for this to a be a post bashing Movable Type, I think they provide a fine product at a reasonable price and they deserve to be compensated by those using it for larger commercial applications. They are asking reasonable prices and still provide a free version for smaller blogs. However, during the transition they made a number of mistakes that we can learn from and hopefully not repeat in the future in our own projects.

I’ve been looking at jobs at some very large places of late and I’ve been spending some time thinking about how small changes to an interface that is used by many thousands of people for a long time can cause large problems. I don’t mean changes that are bad, I mean really well thought out, well conceived changes that we perceive as ‘fixes’. If many users, who are uncomfortable with technology and computers in general, are accustomed to ambiguous labels or seemingly random icons they may react very badly to a change, even one that seems to be for the better.

Some of this can be fixed with training, but one of the goals of a good interface designer and all of that usability testing we do is to avoid creating designs that need a ton of explanation and training. If a new design requires retraining 10,000 employees or users to deal with the new labels and icons the redesign may not be worth the trouble.

So how can we deal with users that can’t deal with change? In a system with a lot of new users the redesign may make sense because it will allow them to pick things up with out having to learn to deal with all of the poor design earlier users did. On the other hand if you have many long term users with little turn over you must weigh the cost of the change and their ability to adapt to the altered interface against the benefits of the new interface.

So far in my design career I have dealt mostly with systems that I can change at will. Once I have identified the problem I am free to figure out the best way to change it and I go ahead, if the change is big or potentially confusing to existing users I provide an explanation of the changes and how to handle them. This was how I handled the redesign of the CIMdata web site. It was a drastic overhaul so I posted a notice on the front page advising that changes were going to happen soon, what they were, and why they were being made. After the launch of the new site I left a notice on the homepage for a month explaining all of the changes.

I find this to be an interesting problem in usability and one that has the potential to hold back many useful changes for fear of the disruption they will cause. As a result I’d like to explore in more detail how established, non-technical users respond to interface changes and how effective various methods are in dealing with their anxiety, confusion, and frustration in such a situation.

I had an interesting discussion today where the topic of theory and practice came up. It is so easy to get bogged down in the day to day practice of our jobs that we forget to spend time on research and theory. When we are pressed to meet deadlines and produce results quickly we find ourselves with little time for reading, hypothesizing, and experimentation. I think that is a shame.

I have been fortunate in the last few years to be both working and going to school so I have been able to balance learning and exploration with practical application. In looking for full time employment I’ve discovered that some companies recognize the value of exploring new ideas while others are focused entirely on the here and now. I’ve noticed that the organizations in the former category seem to be coming up with the best products and services, despite their employees spending time on something besides the projects at hand.

I know that I am never satisfied with what I know. It’s not that I think I am hopelessly behind on mastering useful skills or that I can’t get my work done. It’s a matter of curiosity and wanting to learn more, to understand more, to gain deeper insights into the fields I am interested in. As a result I spend hours reading weblogs, and tutorials, and research papers, and whatever else I can get my hands on. I’m also looking for new ways to expand my horizons. I’ve started searching out other people in the fields of usability and web design in user groups and professional organizations. My hope is that by sitting around discussing ideas we can perhaps come up with something new and exciting.

I see finding the time and energy to explore new, novel ideas as more of challenge when you are working full time. So I’m curious, how do others go about finding the right balance? Do you spend your time online, at meetings, reading books? Where do you look for new ideas and inspiration? How do you rise above the day to day work to look at what is happening in the field of usability?

Usability is often regarded as a nebulous concept or ideal. This is the natural result of usability professionals developing their own odd little language with their unique acronyms and buzzwords. Outsiders are sometimes left with just a fuzzy notion of usability. Part of the difficulty lies in distilling down usability into something you can describe to the uninitiated at a party or in the first 30 seconds of a meeting. People come away with ‘you make things easier to use’.

In some ways this works to the advantage of usability designers. We retain some of the aura of power that practicing a mysterious discipline imparts. It’s hard to explain how varied and complex the activities involved in our jobs are. What does GOMS mean to a client or manager in another department? It means you know something they don’t. It also means that usability is something removed from people. That seems odd. Usability is supposed to be about making life easier for people everywhere, every day. It’s about removing the little frustrations and inefficiencies that slow people down and hold back potential productivity gains.

It is easy to lose focus while going through the many detailed activities in our jobs. We can lose sight of the message we are sending to the people around us. The message we are sending to the people that use our systems. As usability professionals we need to involve the people we are designing for to help us reach our goals. We can do that by keeping channels of communication open. By listening to what users want to tell us. When people are frustrated they want to vent. We can channel that by telling people that they can vent to us. They can tell us what frustrates them and why. We can and we should enlist users as partners in our efforts to improve usability in systems throughout organizations.

I thought I’d take a few minutes to talk about the outsourcing trend that has taken hold in so many industries and how it affects usability in information systems. Of course I may be a bit biased since I am part of the group whose potential jobs are being shipped overseas, but as with other issues in life I think it is possible to get past those personal biases to look at the issue from many perspectives. In this case I think we need to stand back and ask why we would want to move our designers overseas. What value is to be gained and what is lost in the process?

Usability and user experience design is part science and part art. It requires a great deal of knowledge, understanding, and attention to detail. It requires interaction with real users for testing and information gathering. And it requires that usability people be part of the design process. As much as we might like to if we separate code from design we are doing something wrong. Code is written to perform functions that help users complete tasks. It must be tied to the interface so that everything runs smoothly. Creating software is an intricate, iterative design process and usability designers must work closely with many other team members throughout the process to ensure the users’ needs are truly being met.

Cheap programmers in other countries are removed geographically, but the Internet shortens that distance considerably. They are also removed by language, culture, and many other factors that affect usability of applications. Interestingly, I think this same argument can hold up for work done in the U.S. and exported to other countries. Our finely crafted interfaces can get destroyed when Asian or other character sets are stuck in them. I’m not speaking in absolutes, but I think it is important to explore how short sighted, greedy executives can act contrary to the interests of a company. By breaking up the design team, outsourcing coding tasks to distant programmers they are risking the usability of the applications they are creating. This can lead to lost productivity in the design process and for users of the applications. There are real costs to outsourcing expertise and talent that go beyond a programmers salary.