Category Archives: Usability

Call for Goal DSL

Frontend Software Engineering Usability

We found out that we don’t yet know a good way to write down our Personas and their Goals in a coherent way. There is also a problem in teaching the ways of Goal Oriented User Interface Design (GUIDe) to new interaction designers.

On the Internet other people than myself have also been considering the process how GUIDe can be

http://blog.extremeplanner.com/2006/01/goal-driven-user-interface-design.html

which are very similar to my thoughts about integrating GUIDe and Extreme Programming: http://pharazon.org/publications/GO-XP.pdf

However, the Extremeplanner’s article didn’t mention any way how to describe the Personas and Goals. I think we should create a Domain Specific Language (DSL)  to make it easier to write realistic goals that leave the design (workflow) open for designer to re-invent.

The power of Goal Driven UI Design comes from freedom to redesign the technical solution within the limits of current technological possibilities – the designer should be as open minded as possible to find out the what possibilities there are to use “teleportation”, “magic” or “zen” in creating a design that employs 0 steps to achieve the Goal.

Published by:

Jidoka Error Recovery

Software Engineering Usability

Recently I’ve been working on two legacy projects, which contain a substantial amount of stinking code. Actually the reason why I’ve been assigned the projects might have been the fact that the code bases have become unmaintainable for the previous developers (who seemingly have been selected for their low cost, and consequently, low skill). However, there is never a project that you couldn’t learn more on, nevertheless the otherwise poor coding practices in use.

On the second project I have been wondering about the overall error management philosophy utilized. Although being full of duplicated code, long methods and security vulnerabilities, the error management seems to have been written by someone who wants to avoid errors from being communicated to the user up to the last possibility. Although that under the hood there might be (and are) multiple exceptions raising for example from missing server connectivity or some errorous SQL, the system uses multi-layered try-catch structure to prevent any errors from being directly shown to the user (however, in the most serious bugs even that is not enough). It makes me to wonder the nature of the organizational culture of the software company that forces the low skilled coders to improve their skills up to the extreme on error management rather than keeping up the quality in the first place…

Anyway, since the approach of error management in this project is so different (I’ve been always happily throwing errors to the users), I thought there might be something to learn about the approach. From the user experience (UX) point of view, things seem to be actually going rather smoothly, since system seems to almost never have any problems, at least on the surface. When you learn the system more deeply, you start to notice that the results produced are not quite right, but it takes months and deep domain level expertise until you notice the problems. I thought that this would be also generally a better approach for error management than just throwing everything to the user, who might not know (unless he is a programmer and a system admin) what to do about them. In fact, the error messages I’ve been traditionally writing are more related to debugging than giving useful information to the user, how to recover from the problem.

In the end there are many non-debugging related problems that might need user involvement. Typically these kind of exceptions are more related to the external connections and environment of the software rather than internal operations (where you need debugging messages). For example your internet connection or database might be down, which cannot be fixed by the developers or software alone. What then would be a better approach to manage error messaging than the extremes of just throwing errors directly to the user, or suppressing them in all cases giving no information of the problems?

Jidoka 23 Steps of Autonomation

Shigeo Shingo has described the 23 stages of autonomation, how a system can manage errors. On the first level the system does not detect or react to any errors, but needs a human operator to constantly monitor the system for irregularities. On the highest level of automation, a system can both detect and fix errors by itself, continuing operations and minimizing need of human involvement.

Quote from Wikipedia: “Jeffrey Liker and David Meier indicate that Jidoka or ‘the decision to stop and fix problems as they occur rather than pushing them down the line to be resolved later’ is a large part of the difference between the effectiveness of Toyota and other companies who have tried to adopt Lean Manufacturing. Autonomation, therefore can be said to be a key element in successful Lean Manufacturing implementations.”

Thus it seems that a better way of error management would be to use Jidoka-style error recovery. For a computer program detecting problems is usually quite easy, by using the try-catch -statement. The difference comes from what to do the next. The traditional options are to pass the error forward on the next level (user), to suppress it, or to log it for debugging and sysadmins to fix later.

Sheigo suggests that when feasible and cost-effective, the system should try to repair itself and recover from the detected error. One bug that I’ve been recently fixing is related exactly to this. It occurs only in the rare situations when the client software looses connection to the server. The try-catch -statements detect the situation, and the recovery process includes passing the input back to the user. However, the problem is that though by quick inspection the return “looks like” being correct, it is missing vital added-value information provided by the server. In addition the recovery process introduces a (duplication) bug. Thus the recovery process is both errorous and recovering wrongly. Initially, when fixing the problem, I thought that it would be enough just to fix the bug that I was assigned to fix. However, when doing automated test cases, I noticed that since also the recovery process was functioning wrongly, another approach should be used than “seemingly recovering”, but not actually recovering from the missing server connection.

How could the missing server connection be remedied? I was thinking a few approaches, firstly the client-server connection wouldn’t need to be synchronous, an asynchronous queue and messaging system could actually handle the recovery better. A monitoring system should be set up to notify the system administrators of missing DB or server connectivity, or other environmental problems. The system could queue (and not block) the messages until the environment has been restored. The particular situation where the issue arises is actually doing development while commuting without Internet connection. The development environment issues could be also remedied by using mock services simulating an operational server.

Facebook has actually built an automatic remedy system for infrastructure caled FBAR.

Conclusion

The original idea for the automatic recovery become from refactoring legacy code by automated tests, so we support using the approach for all projects – automated testing surfaces issues that are otherwise easily bypassed. Also, I find the idea of automatic recovery important from both User Experience and error proofing (Six Sigma) point of views. When you are catching an exception, do not pass it forward, or suppress it, but initiate a recovery process that tries to fix the situation. The remedy process can for example contain asynchronous messaging system, monitoring or mocks. The users and admins should be notified only when the recovery process also fails.

Published by:

Custom PuTTY to avoid UX inconvenience

Usability

We did a few patches to PuTTY SSH client to reduce user experience (UX) inconveniences for heavy duty users (like us :). The problem rise when you are using the old (0.62) version on a laptop, 3G connections and have connections open to 20+ servers. When you sleep or hibernate your laptop, all the connections drop and previously you couldn’t distinguish which session was which to reconnect (all 20+ windows just said “inactive”). In addition, reconnecting the sessions was previously a burden. However, we fixed it 🙂

1) You can now reconnect an inactive session in PuTTY by pushing enter, like on SSH Tectia client.

2) When the session disconnects, you don’t get anymore the annoying OK -dialog.

3) The title of the window shows the IP of the server also when the session is inactive, unlike before.

You can download our custom build PuTTY from here. It’s build based on the 0.62 sources, compiled by PHZ.fi using Visual Studio 2010.

Published by:

The Inmates are running the Agile Asylum

Management Software Engineering Usability

Here is a great interview of Alan Cooper, the designer of Visual Basic & Visual Studio and the author of the Goal-Driven Design (GDD), a close relative to the GUIDe by Sari A. Laakso:

http://www.infoq.com/interviews/Interaction-Design-Alan-Cooper

Agile is not about productivity, it’s about the core of motivation of the developers. The traditional management of the software projects usually lack understanding what is going on, set unrealistic objectives, drive for low quality and make the work of the developers miserable. While the industrial-era management doesn’t really understand what’s going on, the developers have filled out the vacuum by managing themselves. Instead, the knowledge workers are not motivated by money or following the schedules, but doing good (or great) work. Thus the rise of the Open Source, over there people can do as good products as they wish 🙂 If the industrial management techniques makes this impossible by managing the knowledge workers as industrial workers, then the developers are not pleased either. Because nobody is really managing the development work, the Agile has risen from the ranks of the developers to fix the management problem.

Alan Cooper claims that the process of the interaction design is quite similar to the agile ways. The key process is to reflect on the business problem before day zero of the start of the development. The key thing is to have deep and profound understanding of the business process.

Tasks are not Goals

The important thing is not what tasks the users do, but what is the end state. The design process is to redesign the tasks so that the goals can be achieved easier. By designing based on the tasks the result will be a Dancing Bear :). It dances, but not very prettily. The objective of the interaction design -school / GDD / GUIDe is to make the bear to dance well!

In software there is no economics of scale

In the old times the main driver of the business was to get the unit costs down. However, in the software industry the maintenance costs are zero or very low, but the development cost is rather high. The economics of the software are profoundly different to the economics of the manufacturing. Driving the cost down just drives down the desirability of the design. The most important thing is to worry how you can elevate your number one goal. The business managers should think only about how to increase the business value and quality instead of reducing the cost.

Published by:

What Usability Really Means?

Usability

Usability seems to be a very illusive concept that draws in experts from many fields. Unfortunately, it seems that despite the very assertive guidelines and opinions, the experts from many fields such as cognitive psychology seem to lack the fundamental agreement what the usability really means.

One usability company gives such guidelines. The traditional (paper) media has a bad user interface featuring
* static form – users can’t adapt the representation form to their needs
* linear representation

etc.

A good design on the other hand features:

* user centric design – user chooses how and when he uses the page
* usage of small icons and grouping them

etc.

This reveals the fundamental lack of understanding of the essence of the usability – the offered guidelines are able only to scratch the surface of the topic offering some quick (and false) heuristics that are not applicable to most of the design situations.

Let’s start from the fundamentals, why do we need user interfaces and usability in the first place? For the suprise, usability is not at all that important what the common conception suggests. The basic property of all artifacts is the utility, not the usability, meaning what goals can you achieve with the object or service. A goal is something that is desirable by the user. Most often the goals are indirect, you need to work only because you want to feed your family. Personally you would like rather spend most of your time with your friends and family, or with your hobbies such as playing golf. Several different solutions allow you to fulfill the goals, such as greeting your mother on her birthday. The old fashioned solution is to take a train and visit her. An alternative solution to achieve the personal goal of remembering your mother is to take the cellular phone out of your pocket, select her number from the phone book and calling her. The difference which device you will choose is in the usability – the cost of achieving the utility (or your goal). Nowadays, when the time is money, most of us will choose the mobile phone to minimize the spending of the very limited temporal resources. Another equally important and related resources are the mental energy for learning new things and the monetary cost of using the device. One reason of the bad usability of the early computer-based solutions is the novel utility – you don’t need usability if there is no alternative ways achieving it, or if they are even more cumbersome than the computerized version. However, the situation changes dramatically when someone else designs a competing computerized solution.

When one reads an old fashioned news paper that has evolved over hundreds of years to fulfill the goals of the subscribers, the importance is not on the dynamic or static form of the media, but on how well the media is able to fulfill the hunger for news of the readers. The problem of a newspaper is not in that the the user can’t see the tv-guide or cartoons on the front page, but has some internet-based competitor been able to publish the same news earlier making it uninteresting. The high contrast and large page size out competes any screen in it’s ability to visualize information. From the usability poin to view the situation is the contrary, if the web page designer does not know which goals the web page is supposed to serve, he can outsource the understanding and analysis to the user by saying “the user knows the best what he needs, so let’s make the user interface dynamic and customizable so that he can modify it himself”. Unfortunately it seems that even smaller number of users (than the number of so called UI experts) are able truely to design user interfaces, so making the UI customizable is not the solution for usability problems, it is only passing the buck when the designer does not know what the usability truly means. Instead of forcing all users to spend their time in moving the boxes around, the designer should focus the development efforts in analyzing deeply what are the true user goals, what is the context of use and in which priority the goals should be served.

A second widely propagated false belief and design practice is that when you serve a new user goal or add a new functionality, you should make compromises in the design so that reaching of all goals are equally difficult, or adding a new functionality makes the reaching of the primary goal more difficult. One of the most desperation causing example of this design fallacy is the dismissal of the Navi-key by mobile device manufacturer Nokia. Once this leading phone manufacturer was the most easy-to-use phone on the market, it had only one key for all functions and the market share sky-rocketed. However, then came the so called smart phones and by the result of a sad design story you couldn’t anymore use only one key for both answering the phone and calling to your grandmother. The compromised design, the enemy of all usability was born once again.

During my first master’s thesis I created a new concept called marginal usability, which is the utility divided by the sum of cost of time to use, mental energy and money. This simple model encompasses the most important design guidelines in an easily understandable package. To reach the highest marginal usability, you need first to select a highly desirable goal that you want to fulfill. If you wish, you can choose a few more and prioritize them by their benefit for the user. According to the GUIDe -design method by Sari A. Laakso, the first design step is to take the highest utility goal and design an user interface that makes it possible to reach the goal by the least number of physical and mental steps. Most often this goal can be reached trivially by single or even by zero actions. Take an example for the newspaper. The scoop that you see advertising the tabloid papers implements exactly this purpose by zero clicks, you need to just walk by a news paper counter and you will be almost unavoidably be exposed to the scoop of the day! You don’t need to even take the paper to your hand, open the front page, or buy the paper to know of the latest plane crash or celebrity affair. A true marvel of the user interface design, that is easily reachable also for any site or software! The only thing you need to do is to forget all excess waste and steps on the path of fulfilling the true user goal, such as the intro-pages and registration phases. Challenging the tacit assumptions of the industry leads you easily in revolutionary innovations, you don’t need even to look very far away. Remember also to question the technical constraints by challenging the strongest bastion of bad usability – the developers. If you bother to spend a few minutes on your goal analysis, you quickly realize that you can save substantially in development costs by dropping all the unnecessary screens and functions that are not really needed for any goal. The ultimate design is reached when you can reach a very high value goal by zero clicks. A few examples of these transparent user interfaces include an open doorway (you can pass it without much effort) and an internet infrastructure router. You will notice the best designs by the fact that you can’t see them, and the cash flow from outperforming the competition.

Antti Hätinen
Pharazon ab
Concept & User Interface Designer

Published by: