Another Useful Blog

Annoying Bug in OS X Mountain Lion Reminders Application

2013-09-28T00:05:00.001+02:00

Changing the reminder date for an item in the respective application under OS X Mountain Lion seems to be pretty straightforward:

Double-clicking the desired item brings up a panel
In the panel, click on the date, which brings up the calendar control
Specify the new date by double-clicking on it (which also closes the calendar control)

While this works in some cases, it leaves the date unchanged in others, which can result in erroneous reminders if the bug goes unnoticed. The problem occurs each time the new date lies in a different month than the date that is currently set but is accessible on the same calendar “page”.

The following screen capture illustrates the problem by using a single click to select the new date (so that the calendar does not close afterwards).

Until Apple fixes this bug, you might want to double-check your reminders when modifying their dates.

UXpsychology - Separate Blog

2013-05-26T16:46:00.002+02:00

In order to keep my main blog "tidy", I moved the UXpsychology pointers to a separate blog at http://UX-psychology.blogspot.com

You can also follow on Twitter @UXpsychology

Steve Jobs Lost in Translation

2011-12-08T13:35:00.000+01:00

This post will be especially interesting for readers who understand English as well as German. (For those of you who do not understand German, I included some explanations to give you an idea of the things I'm talking about.)
Most of you know that after the recent events, the Steve Jobs biography by Walter Isaacson was rescheduled and published earlier than initially planned. This led to rescheduled international publications that of course had to be translated first and then rushed to the market. Unfortunately, in case of the German translation (done by six translators) this shows all too clearly with issues ranging from "weird" to just plain wrong translations. So here are some "highlights".

The translation of "silicon" as "Silikon" has already been widely discussed (e.g. in the German Amazon reviews). For the English-only readers: "Silikon" is the stuff that, e.g., breast implants are made of (see the Wikipedia entry on Silicone), whereas the correct German translation should be "Silizium". Since the silicon-Silikon pair is one of the common examples of "false friends", it's surprising to see this mistake in a translation by professional translators.
In other cases, it would have helped if the translators had some basic IT knowledge. Or how else could one explain that "Heathkits came with all the boards and parts color-coded" (English version, p. 16) was translated to "Die Bretter und die anderen Teile in den Heath-Baukästen waren alle farblich codiert" (German version, p. 35)? For English-only readers: seen in isolation, translating "boards" with "Bretter" would be OK, but since "Bretter" in German mainly refers to wooden boards (or planks), the translation seems rather weird in context and should rather have been "Platinen" or "Leiterplatten".
Another instance of a translation that would be correct seen in isolation (and without background knowledge) can be found in the chapter on the Apple Retail Stores: "His name is listed as the lead inventor on two patent applications on the staircases" (English version, p. 375) became "Er ist namentlich als Haupterfinder auf zwei Patentanmeldungen für die Treppenhäuser genannt" (German version, p. 443). In German, "Treppenhaus" rather refers to a separated part of a building that contains the stairs (see, e.g. this picture of a "Treppenhaus"). Since the staircases are integrated parts of the Apple Retail Stores (instead of located, e,g. behind a wall or doors), the better translation for "staircases" would simply be "Treppen" - which is the translation that is used in other sections of the German version (e.g. p. 268) that probably have been created by one of the other five translators.
An example of a translation that is wrong in the sense that it means exactly the contrary of what is actually intended can be found next to photograph 19 in the middle of the book, where the German caption says: "Sie ist unberechenbar, und sie ist das willensstärkste Kind, das ich je getroffen habe. Es ist wie eine Belohnung." ("Belohnung" can be translated to "reward".) So what about the English version? It says: "She's a pistol and has the strongest will of any kid I've ever met. It's like payback." Steve Jobs is (ironically) referring to the strong will of his daughter in the sense that he has met his match in her, which can be seen as a payback by destiny, so to speak. So, the German version should rather use words like "Rache" or "heimzahlen" instead of giving the ironic remark a completely different sense by saying that the strong-willed daughter is a "reward".
And finally, for an example of a translation that is completely mysterious and actually makes no sense whatsoever, one can look at page 326 of the English version, where it reads: "Gates likewise was embarrassed when he saw the videotape of the event. 'I didn't know that my face was going to be blown up to looming proportions', he said." A translation of the second part that would have kept the meaning intact would have been: "Ich wusste nicht, dass mein Gesicht auf bedrohliche Ausmaße vergrößert werden würde." ("looming proportions" - "bedrohliche Ausmaße") But what does the German translation actually say? "Gates war ebenso betreten, als er die Videoaufzeichnung der Veranstaltung sah. 'Ich hatte keine Ahnung, dass mein Gesicht auf lemmingähnliche Proportionen aufgeblasen würde', sagte er" (p. 384). And yes, the English-only readers may have guessed: "lemmingähnliche Proportionen" would mean "lemming-like proportions" in English. As I said, it's a complete mystery how this translation came to be.

So is this picking on translation errors nit-picky? Hey, it's Steve Jobs' biography! If you can be nit-picky about a biography, then it's this one. So let's see what the second edtion of the German version will bring.
English edition: Isaacson, W. (2011). Steve Jobs. New York: Simon & Schuster.
German edition: Isaacson, W. (2011). Steve Jobs. München: C. Bertelsmann.

Forget About the Details in UX Design

2011-11-21T13:01:00.000+01:00

The title of this post may strike you as weird. After all, we know how important details are for UX, right? There are lots of descriptions of design details and the impact they had, and, not least, Steve Jobs' obsession with details is legendary. (See, e.g., “The Tweaker – The real genius of Steve Jobs”.) So why this post?

Well, because there is a right time for everything, and this also applies to dealing with details. Or, put differently: just because you are obsessing over details does not mean you are contributing to UX in a significant way, quite the contrary may be true.

Obsessing over details too early

Take, e.g., a CEO who is obsessed with the way a certain button looks like. Iteration after iteration he drives visual designers insane until they come up with a look that pleases him. For him, that may be an expression of his perfectionism. This may very well be. But at the beginning of a project it may be more simple: refining the look of one individual button over and over again may just be a case of bothering with details that are absolutely insignificant, which is likely to prove a waste of resources. Without knowing where one wants to go with a user interface, what experience one ultimately wants to offer, there is no conceptual framework against which design decisions can be validated. In such a context, obsessing with details is a useless intellectual or aesthetic exercise.

Discussing details is easy…

But why is there this tendency to obsess over details (even when someone does not want to emulate Steve Jobs)? Because it’s easy! – This should not be misunderstood in a sense that solving a detail issue is easy, but engaging in discussions about details is easy because such detail issues can quickly be communicated and everyone can form an impression on what they are about, even with little contextual information. (Leaving aside for now that missing or diverging contextual information may cause problem of its own.) It’s not hard to understand that the detail is the look of a button, the alignment of a label or the hover state of an interface element. Those details can be discussed much easier than, e.g., how to optimally match an implementation model to the user’s mental model. Team members can quickly grasp a detail issue and engage in discussions about it. And those discussions may provide a fake sense of project efficiency: “We have lively discussions about the user interface, so we must be doing good.”

In addition, thinking in terms of user interface details matches the tendency of some organizations or project teams to conceive user experiences in terms of features. Both can often be discussed in isolation of other aspects of the user interface while being “agnostic” towards overarching concepts or ideas that cannot directly be mapped on individual details or features. This approach to user experience, however, ignores the fact that UX is much more than the sum of design details – one cannot create an Excel sheet made up of design details and then, as discussions on individual details are settled one by one, track the progress from 0% UX up to 100% UX.

…Measuring even more so

Details also often lend themselves readily to measurement. Decide about button size? Do an A/B test! Label? Same! Shade of blue? Google already worked that one out. Testing details is easy because one can quickly come up with variants while one does not have to change the overall context. So what could possibly be wrong about having real quantitative data regarding details?

For an answer, see above: the best quantitative data is useless when it concerns irrelevant details of the user interface. Statistics are no tool for generating good designs, they can only provide information that helps in evaluating designs. When evaluating details, you can get relative information regarding detail alternatives (e.g. click rates based on button sizes), but if your overall design vision is flawed in the first place, statistics on design details won’t show you how to achieve good (or better) UX.

A detail that is worth exploring in this context is the difference between statistical significance and practical relevance. Basically, with a sufficient number of trials, every difference, no matter how small, can become statistically significant – so knowing that there is a statistically significant difference between to detail alternatives does in no way mean that choosing “the better” detail alternative over the other(s) is equal to choosing good UX vs. bad UX. It may still be a local (detail) optimization that has little (if any) impact on actual UX.

So what should be done about the details?

So how should detail issues be addressed? As said at the beginning: there is a right time for dealing with details. Roughly speaking, as a UX design project progresses, details become more important. After the foundations have been laid and you know where you are heading UX-wise, deal with the details in order to make sure that they optimally support your overall plan. Discuss them, test them, but be aware that you cannot assemble great UX just from details. Details can make or break UX, but often, the “making” part is way overrated in early stages of a project.

A Cynic's View on the UX Community

2011-09-12T13:31:00.000+02:00

Twitter and other (largely) public online forums are used by the UX community to publish thoughts, exchange ideas and discuss current issues. But of course, the audience consuming all that information is not limited to UX professionals. Anyone who wants to gain some insight into the UX community can tap into this constant stream of information, which is especially easy on Twitter - just filter for the #UX tag and there you go.

On the downside, tweets have to be short, leaving little room for context or differentiation. In addition, there's also a tendency to make messages "stick" by phrasing them in a strong and simplistic way. In some cases, this tendency continues in the sources the respective tweets point to.

Suppose "outsiders" (e.g. potential clients) go online and sample some of this information, would they have to be very cynical to arrive at some (or all) of the following conclusions regarding the UX community?

UX people think they are experts on human psychology because they know that recognition trumps recall and that people can be motivated by awards and competition. OK, there's more to these issues and they do not hold true in this generality, but that does not seem to bother most of them. Maybe it's more about giving UX design a scientific touch by using what seems appropriate and ignoring the rest of scientific research.
After all, without that scientific basis, the whole UX design thing seems to be more of a mythology than something real. That becomes obvious, e.g., when they claim that they're "designing memories". (Seen "Inception" a little too often?) Wouldn't designing user-friendly interfaces be more helpful? Or is this too profane for them?
But then, they do not even agree on what they do. Ask two of them, what "UX design" actually is, and you are likely to get three opinions in return. How do clients know what they get when they hire a UX designer?
For a lot of them, UX design seems to happen primarily on the web, rendering UX design more or less synonymous with web design. Could it therefore be that "UX design" is simply a new label to market old stuff/services better? And who do clients turn to when they need a redesign for their non-web ERP system, which is not about sign-up forms or conversion?
The good news is that it should be rather inexpensive for a client to just try out, because a lot of them don't seem to be in it for the money. You can hear them talking about (or writing about, respectively), making users lives easier, providing joy of use or creating memorable experiences. But in their quest to make the world a better place, they don't even seem to think about money at all or consider what they do to be a business. This lack of consideration could backfire when a client actually wants to improve the bottom line by hiring UX designers. Could they be convinced that "making the world better" is not a goal in itself for most clients and that making money is a legitimate objective? Do they know how to handle those business issues or it simply about everyone having that warm, cozy feeling?

In the end, on the web, one has little control over who consumes the information that is put out there. But at least, the UX community should keep in mind that one is not simply preaching to the choir online. There are also parties who are interested to learn about UX but do not have much background, which can lead to them taking simplifications / partial information at face value.

And even regarding communication within the UX community, being a little more rigorous can be a good thing, e.g. clarifying the scope of arguments or defining the terms one uses. This can benefit discussions because the "UX community" is as homogenous as the "community of people who work in a hospital" (which also includes, as we all know, the janitors) and therefore you might not even be preaching to the choir when you think that you are doing just that.

Oscar Wilde on art, criticism and usefulness

2011-08-15T16:28:00.000+02:00

"It is the spectator, and not life, that art really mirrors. Diversity of opinion about a work of art shows that the work is new, complex, and vital. When critics disagree, the artist is in accord with himself. We can forgive a man for making a useful thing as long as he does not admire it. The only excuse for making a useless thing is that one admires it intensely."

(From the preface to "The Picture of Dorian Gray")

We are doing this for over 20 years...

2011-05-23T14:01:00.000+02:00

When redesigning a user interface (and all the more when creating a completely new one), it is a good idea to conduct user task analyses, contextual analyses and the like in advance. This helps immensely in gaining a deep understanding of the domain, users, their requirements and their workflows. For usability engineers who are regularly engaging in these kinds of activities, the benefits are obvious. Project teams that already work in the respective domain for a longer time and that are not accustomed with these analyses, can sometimes be doubtful and react with statements like "You know, we are doing this for over 20 years, we know exactly how this should work".
But then, as this TED Talk by Terry Moore shows, just because you are doing something for 20 years or more does not necessarily mean that you are doing it right or in the best possible way. Challenging assumptions from time to time and being open to learning new and unexpected stuff can make all the difference.

(At Least) Two Sides to Every Story

2011-05-04T13:01:00.000+02:00

Twitter is not only a constant source of information, but also a constant source of opinions. With the way Twitter handles dialogs, you may at some times receive only one point of view, e.g., a link to a piece about the benefits of wireframing, but you may miss out on the other side of the story, in case it is contributed by people who you are not following.
It can often be valuable to reflect on both sides of a story, regardless of which side of the fence you are standing on. Therefore, I collected three examples from the field of UX design, which each one including two points of view that I conveniently subsumed under a catchy (i.e. simplified) heading and classified as “pro” or “con”, respectively. The individual sources are more nuanced, of course, but the headings and pro/con-distinction provide some starting point.
If you stumble across any more “UX design pro/con” stuff, let me know.
"Cognitive Load Should be Reduced"
Pro: http://uxmag.com/articles/cognition-the-intrinsic-user-experience
Con (or rather, more diffentiated): http://www.solidstateux.com/interaction-design/think-like-an-instructional-de...
"Wireframing is a good thing"
Pro: http://sixrevisions.com/user-interface/wireframing-benefits/
Con: http://www.attackofdesign.com/why-wireframes-can-hurt-your-project/
"UX designers should be jacks of all trades"
Pro: http://www.uxforthemasses.com/what-makes-good-ux-designer/
Con: http://www.elisabethhubert.com/?p=1229
"UX and marketing go along well"
Pro: http://uxmag.com/strategy/a-designer-and-a-marketer-walk-into-a-bar
Con: http://www.adaptivepath.com/blog/2010/11/18/the-pernicious-effects-of-adverti...

There is no particular mystery in UX Design...

2010-12-17T12:20:00.000+01:00

"There is no particular mystery in animation.., it's really very simple, and like anything that is simple, it is about the hardest thing in the world to do."

If you replace "animation" with "UX design" in this quote from Bill Tytla, there is still some truth to the statement.

There is no "secret knowledge" regarding good UX design to be acquired from hidden sources - there is a multitude of books, websites etc. devoted to the topic. Yet, knowledge alone is not sufficient: talent, experience and perseverance are amongst the "other things" it takes to deliver great UX design.

Very much as with animations.

What You Always Wanted to Know About Eye Tracking - Part 3: Terminology

2010-09-14T14:00:00.025+02:00

In part 1 and part 2 of this series, some fundamental aspects of the eye tracking technology that affect data gathering have been covered. The next parts will cover more advanced conceptual-methodological topics, related to data analysis and data interpretation. Being aware of these issues is important because we are still far from having a unified framework for analysis and interpretation of eye tracking data.

Problems can already arise when it comes to terminology.

Problems caused by a lack of shared terminology

Working in a scientific context goes along with using a specific terminology, which includes a shared understanding of certain well-defined objects/phenomena and the terms that refer to those.

Especially in relatively new disciplines and concerning relatively new methods, a standard – and shared – terminology has not yet been established, which bears the danger of implicit misunderstandings when communication partners use the same terms, but have different concepts in mind. This is also true for the eye tracking domain, where the same words in different studies do not guarantee that researchers refer to the same concepts.

This was also observed by Jacob and Karn (2003) who assembled an overview of eye tracking studies in the context of usability engineering. They defined "gaze duration" as "cumulative duration and average spatial location of a series of consecutive fixations within an area of interest. .... A fixation occurring outside the area of interest marks the end of the gaze" (p. 581). They point out, however, that "some authors use 'gaze duration' differently, to refer to the total time fixating an area of interest during an entire experimental trial (i.e., the sum of all individual gaze durations)" (p. 599).

Besides the homonym-issue (same word for different things), there is also a synonym-problem (different words for the same thing). Jacob and Karn point out that other authors also refer to the described "gaze duration" concept, but use different words to do so: "Authors cited ... have used 'dwell', 'glance' or 'fixation cycle' in place of 'gaze duration'" (p. 581).

It is obvious that, when different eye tracking studies shall be compared, such terminology issues can cause problems when one is not aware of their existence. In the worst case, false interpretations of results are the consequence.
It is therefore recommendable to explain the terminology used when reporting eye tracking results. Until a terminology is established that is shared throughout the eye tracking community, this is the only way to avoid (implicit) communication problems.

References
Jacob, R.J.K. & Karn, K.S. (2003). Eye tracking in human-computer interaction and usability research: Ready to deliver the promises. In J. Hyönä, R. Radach & H. Deubel (Eds.), The mind’ s eye: Cognitive and applied aspects of eye movement research (p. 573–605). Amsterdam: Elsevier.

What You Always Wanted to Know About Eye Tracking - Part 2: Data Accuracy

2010-07-16T16:57:00.013+02:00

After discussing the issue of fixation detection in the first part of the series, this post will provide some additional basic knowledge about the eye tracking technology before diving into some more advanced conceptual aspects of eye tracking in part three.

An essential part of the eye tracking setup is the camera that captures light reflected by the eye in order to analyze the information and, on that basis, determine the gaze direction. If the eye tracker is not head-mounted, the camera is often positioned statically, e.g., above or below a computer monitor on which the "test material" is displayed.

Head Movements and Chinrests

The precision of measurement is influenced by movements of the head. Movements of the head towards or away from the camera can - temporarily - move the captured image out of focus, until the auto-focus of the camera has corrected the situation. Until this has happened, accuracy of data can be impaired.
In addition to movements of the head towards or away from the camera, sideway movements can, obviously, make the camera lose the image completely, which is usually addressed by making the camera follow the captured image up to a certain extent ("camera tracking"). When the head movement exceeds the range that camera tracking can compensate for (due to larger movements of the head), the camera can either remain at the position where the image was last captured or return to a default position. As soon as a reflection is captured again, the data acquisition continues. In the meantime, no data can be collected.

Head movements are especially likely whenever the person whose gaze is tracked deals with interactive systems, i.e. does not only sit passive in front of a screen, e.g. only reading, with as little movement as possible. This means that, with interactive material, head movements and the corrective mechanisms described above are likely to come into play. This also implies that, until the respective corrections are completed, there can be "impurities" in the data collected, i.e. either inaccurate data or missing data points.

One approach for improving measurement precision consists in fixating the head, e.g., by using a "chin rest". While this effectively eliminates most head movements, it also results in an even more unnatural situation for the person whose gaze is tracked. (Imagine sitting in front of your computer without being able to move your head.) In addition to being fixated, talking is hardly possible with a chin rest, which limits the kinds of studies that can be done.

Systematic Error and Implicit Required Fixation Locations

In addition, even with fixating the head, measured data can contain errors. While unsystematic "noise" can usually be reduced through averaging, systematic errors (i.e. a systematic offset in the measured data points) cannot be eliminated through calculating averages (because the errors of the individual data points don't cancel each other). Such systematic errors are described, e.g., by Hornof and Halverson (2002), who dealt with ways of addressing this error type: „Some systematic error can be identified and manually removed if, when fixations superimposed on the visual stimuli are studied, a consistent pattern of systematic error can be identified from trial to trial. But systematic error cannot be reduced by averaging across gazepoints“ (p. 592). Such systematic errors can exist even right after calibration has taken place: „Even after calibration, eye trackers often maintain a systematic error such that fixations are recorded a small distance from the fixation point“ (p. 592). In addition, measurement precision can deteriorate during measurement: „Drift error may result from, for example, head movements and changes in the position of eye glasses and contact lenses“ (Surakka, Illi & Isokoski, 2003, p. 478). „As with most instrumentation, the initial calibration may deteriorate during an experiment“ (Hornof & Halverson, p. 593). On the basis of such insight, Hornof and Halverson state that formal criteria for eye tracking studies are recommendable, which allow insight into data accuracy and also enable decisions regarding new calibrations that are triggered during measurement whenever the desired level of accuracy is in danger: „An objective verification step and criterion contribute to the accuracy and usefulness of the data recorded, the confidence in the conclusions drawn from the data and the reproducibility of the experiment“ (p. 593).

As one approach for doing so, Hornof and Halverson describe "implicit required fixation locations" to identify systematic errors and - if required - automatically trigger a re-calibration:
"Implicit RFLs can be used to monitor eye tracker calibration in real time and to invoke recalibration when necessary. Task requirements, when combined with human perceptual and motor characteristics, often constrain where fixations will occur. In many human-device task executions, there are a number of locations that the participant must fixate in order to accomplish a task. .... The target of a mouse movement, if small enough, would make a very good implicit RFL. .... Incorporating mouse movements into an experimental task on a computer provides an opportunity for implicit RFLs." (p. 594)
This means that for a given task, areas of the screen (or parts of the "visual scene" that is relevant for the task) should be determined that are very likely to be fixated for the person to successfully complete the task. These can, e.g., consist of text that has to be read, as it is likely that the text has to be fixated (in contrast to perceiving it parafoveally).
Hornof and Halverson made use of two Implicit RFLs in their experimental setting. To initiate an experimental trial, participants had to click a button to start it, which served as Implicit RFL 1 to check accuracy of calibration and trigger a new calibration in case accuracy was below a pre-determined threshold. During each trial, participants had to find and click on a target stimuli, which also served as Implicit RFL 2. Implicit RFL 2 was not, however, used to be able to trigger a new calibration, but instead to check for the accuracy of the calibration that had taken place previously.

What should have become clear from the aspects discussed in this post is that, just because eye tracking provides insight into an - otherwise mostly "hidden" - aspect of human behavior with a very high temporal resolution, this does not necessarily mean that it is per se an accurate method. As with every kind of measurement, data accuracy is an aspect that must explicitly be taken care of by the researcher. When conducting eye tracking studies, data accuracy should therefore be

"arranged for" with proper calibration
monitored during measurement
improved by triggering a re-calibration in case accuracy drops below a pre-determined threshold
reported with the results

After covering some basic aspects of "eye tracking mechanics", the next part of this series will focus on conceptual issues around eye tracking measurements.

References
Hornof, A.J. & Halverson, T. (2002). Cleaning up systematic error in eye-tracking data by using required fixation locations. Behavior Research Methods, Instruments & Computers, 34(4), 592-604.

Surakka, V., Illi, M. & Isokoski, P. (2003). Voluntary eye movements in human-computer interaction. In J. Hyönä, R. Radach & H. Deubel (Eds.), The mind’s eye: Cognitive and applied aspects of eye movement research (p. 473-491). Amsterdam: Elsevier.

Lost in Translation

2010-04-02T22:55:00.000+02:00

My German-speaking readers will not need an explanation to understand the rather awkward translation in the Google Mail user interface that is shown below.

For all others: What Google calls "Flaky Connection Mode" in the English version of the user interface is called "unzuverlässiger Verbindungsmodus" in German - which translates to "unreliable connection mode". Since "unzuverlässiger" is not capitalized, it comes across as an adjective that merely describes the type of connection you are likely to receive via that option: an unreliable one. (The English version capitalizes the first letter in "Flaky" to show that the word is part of the name.)

Users might rightfully wonder why they should click on the link at the bottom in order to switch to a "unreliable connection mode".

Simplicity in Communication

2010-04-02T00:12:00.000+02:00

In his talk at TED conference, Alan Siegel talks about simplicity in legal communications. But then, the kind of simplicity that he describes is desirable for a lot of areas of life and work.

"I define simplicity as a means to achieving clarity, transparency and empathy - building humanity into communications."

Of course, these thoughts resonate with UX professionals. Our job, ultimately, is about humans. And this does not only include the users of the interfaces we are designing, but also all the people we are cooperating with in this endeavor. So, we should not only be "building humanity" into communications with users, but also strive for that goal when communicating with clients and other stakeholders - also to allow them to have empathy for users.

Therefore, when creating deliverables (whether the final user interface or the intermediate deliverables that get us there), we should have this concept of simplicity in mind in order to optimally support the respective communication partners. And we should also keep in mind that simplicity is not the same as (over-)simplification. To say it with Einstein: "Things should be made as simple as possible, but no simpler."

User Interfaces and Self-Esteem

2010-03-29T23:25:00.007+02:00

The Bloomberg Terminal and Self-Psychology

An article at UX Magazine that appeared a few days ago deals with the – unmastered – challenge of redesigning the Bloomberg Terminal. One central argument that is brought forward regarding the reason why the interface will not be redesigned any time soon, is that “users take pride and find highly rewarding to handle a painful interface“, with the reward consisting in „feeling and looking like a hard-core professional”.

Norman’s thoughts regarding the “reflective level” of design come to mind [PDF]. But of course, he is not the first to describe how objects and activities that are relevant to us affect our (psychological) selves. Take, e.g., this description of “selfobjects”, a concept brought forward by Heinz Kohut:

„Selfobjects are external objects that function as part of the "self machinery." In other words, they are persons, objects or activities that "complete" the self, and which are necessary for normal functioning. Observing the patient's selfobject connections is a fundamental part of self-psychology. For instance, a person's particular habits, choice of education and work, taste in life partners, may fill a selfobject-function for that particular individual.”
http://en.wikipedia.org/wiki/Self_psychology#Selfobject

While interacting with the Bloomberg Terminal may not be “necessary for normal functioning” (who knows?), changing that interaction by simplifying it may nonetheless affect self-esteem in a negative way.

Self-Esteem Regulation Through User-System-Interaction – Some Thoughts

Perspectives like the one described in the UX Magazine article serve as reminder that there is more to “user experience optimizations” that initially meets the eye. Efficiency of a user interface in getting one’s work done is only one aspect of user experience. Efficiency in regulating one’s self-esteem may be another.

Whether interaction with a system is relevant to self-esteem regulation and in what way depends, amongst other things, upon users’ personalities and the context in which the interaction takes place.

In cases in which users are likely to define themselves by the work they are doing (see the remark on selfobjects above), and the user interface allows them to get their work done in the end, the counter-intuitive effect of the Bloomberg Terminal may be observed: the – complex – way of reaching the desired goal is a value in itself for users – whether the user interface accurately reflects the complexities of work or whether it is unnecessary complex.
In other cases, users are more likely to define themselves by the goals that can be reached by using the interface and not by the way of getting there. Therefore, getting the task done efficiently is more important to ones self-esteem than showcasing the complexities of arriving at the goal. This is probably often the case for consumer applications (or: “status symbols”).
Remark: Games could be a notable exception here, because with them “the way is the goal”. Hence the slogan: “Easy to learn, hard to master”.
And then, certain interactions may not affect self-esteem in a significant way. Rather brief interactions that are more or less routine, e.g. setting an electronic alarm clock, are probably not very relevant to users’ perceptions of their selves and their overall goals. Again: as long as the interaction can be completed successfully.

One could also imagine that with time, a user progresses from stage 1 to stage 3 as he grows more familiar with a system.

In any case, if the goal of an interaction cannot be reached, self-esteem might be affected negatively in all of the three prototypical cases listed above.

Another factor influencing whether an interaction is relevant for self-esteem, is the existence of observers while it takes place. In case observers are present, especially peers, even small and otherwise insignificant interactions may become relevant for self-esteem. Who wants to have interaction problems while their peers are looking over their shoulders?

Knowing about the conditions that affect the relevance of a user interface, or the interaction with it, respectively, for self-esteem will help in gathering a more complete picture of users needs and motives and ultimately finding out how the user experience relates to users’ selves. The ideas sketched above may serve as a basis for additional and more detailed thoughts.

What's The Name of Success?

2010-03-11T23:44:00.000+01:00

Quick! Name three types of Apple MP3 players!

...

That was easy, wasn't it?

Now you might wonder what the sense of this exercise was. - Well, during this year's CeBIT I visited 3M's booth to check out their new multi touch LCD monitor. Afterwards, I browsed their website to get some more information - I had to browse because I could not remember the name of the monitor to search for it. It turned out that it's called "M2256PW" - sexy, isn't it? Other 3M touch screens are called "M1500SS", "M1700SS", "C1500SS" and "C1700SS".

The first experience we have concerning a product is often its name, e.g., when friends tell us about it.

When I was referring to my visit at 3M's booth, I always had to say that I had a look at "this new touch screen that 3M presented" or simply "the touch screen" - not very catchy. Which is kind of sad because the screen is not bad, and a catchy name would make referring to it in conversations much easier.

Now, I'm not saying that the name of a product is THE factor for success, but it certainly is a factor that should not be neglected. If you spent considerable effort on designing a product or service that shall provide the optimal user experience, you should give it a name that is unique and easy to remember in order to also provide an easy way of talking about it, because talking about a product or service is part of the "extended user experience" - and you want to make it easy for people to spread the word.

To sum it up: good usability makes the memory of interacting with the product stick in a good way. A catchy name makes it easier for the storys user tell about your product to stick, too.

(Oh, and keep the name short, so people can tweet about it easily.)

Implicit Assumptions - Or: Not Every Misunderstanding is ImmediatelyNoticed

2010-02-01T12:26:00.000+01:00

In certain cases, communication is not endangered by obvious misunderstandings, but by misunderstandings that may at first go unnoticed because they result from implicit assumptions: the parties involved use the same words and don’t realize that their respective concepts do not match.
In his talk, Derek Sivers provides some examples of some seemingly straightforward concepts, e.g. “address”, which of course includes providing a street name and house number, or does it?

From time to time, some “implicit assumptions hunting” may be in order as it keeps us aware of the fact that common terminology does not necessarily mean common understanding. This may be especially true for relatively young “concepts in the making”, such as most of the stuff that UX people are dealing with.
(see also the related post on “Language Barriers in the UX Profession”)

Brief Thought: Language Barriers in the UX Profession?

2009-11-23T16:39:00.000+01:00

What’s the name of the biggest conference for usability professionals in the German-speaking world? – „Usability Professionals“! (For you English-speaking people, that translates to „Usability Professionals“…)

And what is the German chapter of the UPA called? – “germanUPA” of course.

Makes you think about issues of cross-language communication as well as “UX-Pro – UXPro” vs. “UXpro – client” communication.

Could it be that (unconsciously) creating language barriers leads to problems with adoption of UX practices, e.g. in non-English speaking countries? How real is the danger of using English terms as “usability” or even (gasp) “user experience” so naturally when communicating with non-professionals that we are not aware of (implicit) misunderstandings and the trouble that they can create?

Translating and Sorting

2009-09-04T11:18:00.000+02:00

This is a nice one: I can switch languages, but countries are still sorted according to their English names. So where do I find "Deutschland"? Under "G" of course...
http://www.google.com/support/calendar/bin/answer.py?answer=37226

What You Always Wanted to Know About Eye Tracking - Part 1: Fixation Detection

2009-09-02T23:48:00.020+02:00

Since the topic of eye tracking keeps drawing people’s attention – it’s a silver bullet for some whereas others see it as a complete waste of resources – I thought a series of posts that focus on the methodological aspects of eye tracking research would be in order. As such, the posts will not focus on particular (usability) studies that have been conducted with eye tracking but rather shed some light on implicit and explicit assumptions, caveats etc. of the method itself. Ideally, readers will find some information to make up their own minds regarding the appropriateness of the eye tracking method for the examination of diverse questions.

Before exploring more advanced conceptual aspects of the eye tracking method, it is worth noting that there are basic technical aspects that must be kept in mind when conducting or interpreting eye tracking research.

Variability of Fixation Detection Algorithms

Eye tracking is basically the measurement of the gaze direction with a certain frequency. After a calibration procedure, gaze direction can be mapped onto coordinates, e.g. on a computer screen, in order to determine how the user’s gaze moves over the display.

Eye tracking hardware varies in the frequency with which data is gathered. Starting from ca. 60 measurements per second and going to 1000 Hz or even more. Usually, these individual measurement points are not the focus of the research – instead, fixations and saccades are the measures of interest. These have to be determined on the basis of the raw data (i.e. the individual measurement points). Salvucci & Goldberg (2000) note that “though widely employed, fixation identification and its various implementations have often been given short shrift in the eye-movement literature” (p.71) Fixation identification is a two-step process, with the first step consisting of cleaning up the raw data. When the subject blinks, e.g., the raw data gets contaminated and the respective measurement points have to be excluded before further data processing occurs. In the second step, the cleaned up data is then subjected to an algorithm that aggregates the raw data to fixations. As a user of eye tracking (or recipient of the respective studies), one should be aware that there is more than one algorithm to do so. Salvucci & Goldberg, after examining the practical implications of applying diverse algorithms to the same sets of eye tracking raw data come to the conclusion that “the choice of identification algorithms can dramatically affect the resulting identified fixations. By describing their chosen algorithm … researchers can better communicate their analysis techniques to others and thus provide more standardized and understandable results“ (p. 78). What is clear from this conclusion is, that there is no absolute „truth“ concerning fixations that is somehow revealed by applying the eye tracking method. In the worst case, there are as many „truths“ as there are algorithms for fixation identification. Now, that is not to say that this fact renders eye tracking useless – one should, however, be aware of the fact that doing eye tracking is not as straightforward as measuring temperature: the data concerning a subject’s fixations that is gained during eye tracking has already undergone heavy processing and is influenced not only by the behaviour of the subject, but also by the algorithm implemented in the eye tracking hard-/software. This does not necessarily imply that the conclusions drawn on the basis of fixation data gained with different algorithms (from the same raw data) will also diverge, but the question would be worth systematic exploration in a practical context.

The next part of the series will discuss another technical aspect of eye tracking: influences on measurement precision.

References
Salvucci, D.D. & Goldberg, J.H. (2000). Identifying Fixations and Saccades in Eye-Tracking Protocols. In A.T. Duchowski (Eds.), Proceedings of the 2000 symposium on eye tracking research & applications (p. 71-78). New York: ACM Press.

Instant Usability: Microwave Controls

2009-06-11T13:40:00.006+02:00

The picture shows the control panel of the microwave at work. It’s hard to figure out at first glance whether the microwave really has that much functionality or whether a limited set of functions is presented in a rather complicated manner. (At least the manufacturer seems to have thought of the pizza aficionados.)

Issues With The Control Panel

The upper knob is interesting for at least two reasons.

The knob and its “scale” seem to imply some sort of continuum on which a certain value can be adjusted. In fact, it’s no continuum at all. The user can choose one of six options by turning the know to the respective position. In addition, it’s not even one single dimension that can be adjusted here: the knob is used for controlling the microwave functionality and the integrated grill.

The symbology used for those two functionalities is the second noteworthy thing: the wave-like symbols refer to…the grill. The first three symbols from the right indicate: upper&lower heat, lower heat, upper heat. If you mistake those for the microwave functionality, you could be in for a nasty surprise when preparing a foil-sealed microwave meal.

Apart from using better symbols to refer to the two functionalities, it would be an improvement using a different control for setting them in order to avoid the impression (and false mental model) that the main purpose of this area is setting the degree/intensity for one single parameter. An approach could consist in providing two distinct controls, one for setting microwave and one for grill, and allowing the user to combine the two settings as required. One would have to make sure that invalid combinations are properly communicated or avoided, respectively. Adding some labels could help, too. (For manufacturers, the charm of symbol-only panels lies in the fact that they don't have to be localized, of course.)

Other Examples of Microwave Usability Issues

As it seems, there's still enough reason for usability engineers to get active in microwave oven design. Some other examples for microwave usability issues can be found in the following places:

Microwave Usability (Raymond Cassick)

Microwave Oven Usability (Steve Krause)

Microwave Usability (Tammy Green)
Office Microwave (Max Steenbergen)

UX-Designers-Developers - Good? Bad? ... Existent?

2009-05-20T14:00:00.014+02:00

While doing some browsing, I came across two blog articles concerned with the question of whether UX designers who are also able to code are beneficial or detrimental to UX design.
Lukas Mathis mentions that, for a UX-designer-developer, a kind of self-censoring can occur, where optimal user experience is not attained because the developer restricts the realm of design options based on technical considerations when it would be better to leave more room for design creativity and think of technical implementation afterwards. Mike Rundle, on the other hand, explains why he thinks that it is helpful for a UX designer to have development skills. The thoughts on the issue are interesting and the articles by Lukas Mathis and Mike Rundle on the topic are worth reading.
Another interesting question that comes to mind in that context is: to what extent is it possible to be a UX-designer-developer? The answer to that heavily depends on your notion of “user experience”.

Being a UX Designer-Developer: Extended Range of Competences

I agree with the notion that that UX designers and developers are not necessarily two disjunctive groups. Developers are often responsible for system characteristics that significantly affect user experience. A nice looking interface with solid interaction design does not achieve much regarding user experience if the implementation is crappy and slow. So, developers can also create for user experience, even if they don’t do wireframes or work with Photoshop and the like. From that point of view, a UX designer having knowledge about implementation aspects would seem as beneficial, since his knowledge of “user experience factors” extends beyond the “mere surface” of visual design, interaction design and the like.

Being a UX Designer-Developer: Limited Range of Platforms and Projects

But I also think that user experience design is such a wide field, that, in most cases, the idea of one person having all the skills for creating an outstanding user experience is unrealistic. It seems that, quite often, when people talk about UX, they mostly think of a web-context, but of course, UX design is not limited to that area, but includes all kinds of systems/products.

For the web context, it is true that one can often find very small to “one man / one woman companies” that provide UX design and all required services, including coding, for their clients. But if one looks at an area like user interface design for a complex ERP suite, it is unlikely that you can find one single person who can “do it all”, including user research, interaction design, visual design and coding. This can be a problem of expertise, but it is also an issue of sheer workload that makes it impossible to be a “UX design team of one” in those contexts.

So, if, in order to be a really good UX designer, it was required to have knowledge about coding (or: implementation), this would mean that the UX designer was limited to a certain set of technical environments, namely those he has good working knowledge of or at least to those that are somehow similar/analogous to the environments he is skilled in. In addition, he would also be be limited to projects that do not exceed a certain size.

UX Design as a Field

Looking at the field of UX design, it becomes clear that “UX designer” is by no means a clear-cut job description. It involves all kinds of activities performed by people with diverse educational backgrounds. People proficient in web technologies and visual design are one breed of UX designers. People with a background in, e.g., cognitive psychology who are skilled in doing user research and transforming the results into sound interaction designs are another. UX design is about bringing people with strengths in the required areas together to create the optimal user experience.

Cooperation of UX Designers and Developers

This means, that cooperation is a key factor in designing for user experience. This includes, e.g., developers cooperating with other members of the UX design team. As a consequence, one important question in UX design is which factors influence that cooperation.

The blog post by Lukas Mathis mentions circumstances that may impair the cooperation between developers and other parties during the process of UX design: he quotes Joel Spolsky stating that “programmers tend to respect programmers a lot more than non-programmers, no matter how smart they are”. So this would be where a UX designer having coding skills would be beneficial for UX design: not necessarily because he would have to make active use of those skills, but because they help him in gaining respect in the team. But if it is not the direct impact of development skills and rather a matter of respect, the same goal can be achieved by a change in attitude – if one assumes that the statement about developers is true in the first place, which, from my experience, is not necessarily so: there are developers who know what their core expertise is and who respect and value the skills of a seasoned UX designer – as much as a user experience designer should value the skills of a developer.

One important insight that can contribute to achieving a respectful cooperation is that development as well as UX design involve specific sets of expertise that go beyond merely applying a set of guidelines and heuristics. This seems trivial for development: it is rarely thought that a UX designer can become good-enough in development by receiving some “quick tips” from a developer. UX design, on the other hand, sometimes seems to considered as a “cookbook approach” that does not require much knowledge or experience. Bill Buxton mentions this point in his open letter in BusinessWeek.

Overcoming misconceptions like these is one of the first steps in enabling members of a team to to appreciate the individual skills each of them brings to the table. This, in turn, helps them in respecting the others judgment and, based on that, in leveraging their own individual skills in the best possible way. Ultimately, the kind of cooperation that can arise from this approach is one of the things that makes UX design a wonderful profession.

Convenient Visual Design

2009-04-30T00:21:00.007+02:00

While shopping a few days ago, I noticed the packages of convenience food shown in the picture. The upper product seems to be a newer version (product 2.0, so to speak), and I assume that the lower one will be phased out.

The contents are basically identical for the two versions; the difference is mainly one of visual package design.

The first striking difference is the toned down colouring scheme for the upper package. Instead of using vivid colours, the package is mainly black, with colours mainly used for logos and product name banner.
The opening in the package is smaller for the upper one in order to have more space for graphics and text. (It’s not a picture of the product being shown, it’s the actual contents, sealed with a foil.) Size of graphics and text are not increased, though. Instead, they are reduced in size, to allow for more white space (or in this case: black space), which results in a more balanced and uncluttered appearance compared to the lower package.
Finally, the label “gourmet” has been dropped for the upper package, probably because the class of the product shall be communicated via the visual appearance instead of merely declaring it via a label.

So, with content and interaction design remaining the same, it’s the change in visual design that distinguishes the two products. Which is appropriate, since there is no chance to taste or “handle” to product before buying – the user has to judge the book (or in this case: chicken) by the cover.

Back again

2009-04-26T10:25:00.008+02:00

This blog has been on hiatus for quite a while. I have not been idle, however, and you can find some articles that I have written in the meantime at Centigrade's company blog.

I am going to maintain this private blog more regularly again and use it to document "usability stuff" whenever it comes to my mind.

The length of posts will mostly be somewhere in between the rather elaborate articles I'm writing for the Centigrade Blog and the microblogging that is happening at Twitter.

So, as always: if you have questions or would like to discuss, feel free to leave a comment, drop me an email or follow me on Twitter.

Usability of Universal Remote Controls - Rich User-Generated Data

2008-10-16T18:37:00.002+02:00

Stephen Fry describes his experiences with universal remote controls in his blog. Basically, the article has it all in a nutshell:

persona: "I yield to few in my love of gadgets: let a new gizmo arrive in the post or be brought back from the shops and you will see me fall on it like a lion on an antelope"
basic scenario: "We sit hunched on our sofas while a lapping tide of remote controls surges towards us, threatening to flood every spare square inch of surface. Why not unite them into one remote?"
use cases: "The configuration processes, whether by code look-up table, online software connection or IR 'learning'"
and insight regarding the user experience, of course.

If one does not want to wait for someone to come up with an article like that, similar information can be gathered - even in more detailed form - in a diary study, where participants are asked to keep a diary on their experiences with a product, their expectations, thoughts etc. This can be a good starting point for a design project because of the rich data that is gathered and that can be used to "get in touch" with the users, be inspired and evaluate strategic decisions. That this kind of data also is a good basis for discussions can be seen from the reader comments on Mr. Fry's blog.

Game Usability, or: Usability is Good For Your Health

2008-05-08T00:04:00.018+02:00

An exploratory study at East Carolina University’s Department of Recreation and Leisure Studies investigated the influence of “Casual Games” on stress. The results hint at a stress-relieving effect of this kind of game.

Two Dimensions to Games

One characteristic of casual games that is mentioned at Wikipedia is “Extremely simple gameplay, like a puzzle game that can be played entirely using a one-button mouse or cellphone keypad”. This description actually contains two factors that affect the user experience. The first one is game content: the task to master is simple in the sense that it is easy to figure out exactly what the objective of the game is and how it can be achieved. (Note that "easy to figure out how to achieve" does not equal "easy to achieve".) The second factor is, well, game usability or more specifically: interaction design. The interaction options are streamlined and “slimmed down” so that they do not act as a block between the user and the game. One could envision the two dimensions “content” and “interaction” as shown in the following diagram. Also shown are a few examples of different game types and their location on these dimensions.

Casual Games, as described, are easy to interact with and the content is easy to grasp.
Point-and-click adventures, on the other hand, are also relatively easy to interact with, but their content is more complex, since it consists of a lot of tasks, micro-tasks and dead-ends, which have to be figured out by the user.
Simulations can be challenging for the user on both dimensions, when a lot of interdependent parameters have to be manipulated to achieve a desired result (content) by interacting with a complex interface consisting of diverse screens, panels, switches, etc. (interaction).

Extending the Scope of Investigation

It would be interesting to investigate whether these two factors can be empirically validated and what their weight regarding the influence on stress levels is. To get the complete picture, user characteristics such as computer proficiency and gaming preferences would have to be included in the studies. And finally, also the gaming context will probably have an influence on the overall user experience and influence on stress level: for the hardcore simulation gamer, a casual game might only be acceptable in a context that does not allow for his preferred game type, for example due to time restrictions. So, for the “health aspect”, the “traditional” usability factors of content, interaction, user and context might also be relevant and should be examined as the understanding of health benefits of games grows.