MIND THE GAP!

Reading papers and reports I often see diagrams that are used to visualize values of different categories – e.g. the average hours spend for university-work per week of students of different subjects. It seems rather intuitive for me to use a bar chart: One category (e.g. subject), one value (e.g. 34 hours) and one height of the bar to visualize the value.

However, I often see line graphs being used for that purpose.

same data; two visualizations

In the example below, the line graph suggests that there students who study partly Computer Science, partly Media Arts and that these students work roughly 35h per week. As well one could assume some kind of order or continuous value on the x axis like one is used from diagrams that put the time on the x-axis.

So I see no reason to use line graphs for values-by-category-visualizations. They rather confuse and mislead the reader.

Easing the interaction by using visual interface elements instead of a syntax that needs to be learned and remembered is a fairly common principle ("recognition rather than recall") It is a major step forward if the interface is (hopefully) self-explanatory instead of having to read the ***** manual – first for learning and hereafter for remembering, if you did not interact with the system for a while.

However, recently an improvement that took away the burden of the syntax brought me other problems in exchange. And not the nerds were complaining. Actually it was the very opposite.

For improving our faculties Mediawiki, I did research on common problems students have when using it. After observations and questions with several users a distinct pattern emerged: editing in Mediawiki-Syntax was a major problem, especially when it came to code that triggered functions (make a link, use a picture – in contrast to merely visual changes like making a word italic or the like)

I was  happy to  see that the current Wiki-Editor has dialogs for inserting a picture. They are fairly simple, having no visual selection for a media library. But instead of remembering the Syntax, one can put in the file name and caption and generate the link to the picture from that.  So what I thought want along the lines of this: The user often forgets the syntax (as my tests strongly suggested) so I would like to take the need for this. The dialogue shows the possibilities of the syntax, you need just put in your values, click o.k. and there it is without the hassle of recalling the syntax.

The dialog that is *not* for drag'n'drop-uploading

So I did some tests. And it turned out it had some side effects: The simple interface that ought to suggest putting two values in and clicking o.k. to get a correct link generated was thought to have some more capabilities. Seemingly the dialogue suggested other stuff too, namely uploading pictures by drag and drop – which did not work at all, and left the users wondering about it.

Seemingly, the functions of flickr and facebook already established drag and drop fairly well (brief remark: it is not very practical actually imho, as you need to rearrange and call up two windows). And they combine upload and image use, making these two steps one.

So my idea to add some visible, interactive representations of (existing) functions were not wrong. But they were mistaken for being far more. That they did not work this way was the cause of trouble. So the overall usability may not have been improved at all and one problem was put in place of another. But as the idea still makes sense, I'll redesign the dialogue to make it's capabilities clearer and to anticipate it's use as a upload dialogue.

Testing Interview Analysis

As I found out in the research on last term's class, some things were easy and enjoyed by the students, while some were difficult, like analysing interviews. So I tried out way I explain interview analysis : I recorded a short interview and let people analyse it after explained it to them. I just wanted to see if it was used like I expected, so I did not have a control group or the like; it was more design testing than sciency testing. Nevertheless I was quite happy when people were able to grasp the basic concept and apply it. All were able to listen through the interviews, extract meaningful pieces and to connect those in a way that revealed some data-based insights for them.

...and the Workbook

In the class I use some self-written a workbook to remind the students of important things when preparing, doing and analysing user research.It is not a long document, so I asked people to read through it while telling me what they think. This is basically a think alout-usability test.Others may call it a live-proofreading Like usual proofreading it was incredibly useful: I wondered how some sentences ended up being written in such a difficult-to-get way. As well different people pointed out different problems, so it was good to have several looking at it. To sum it up:  I applied  usability-methods to teaching-materials and it turned out to be quite similar to what happens when you test software.

During the last months I was designing a class for Human Centered Design. I try to practice what I preach, so the class is designed with human centered methods itself. (Pretty meta, hmm?)

So I started the project by doing  interviews with students of a former HCD class. As well I incorporated student's self-documentation and my observations during that class. So I ended up with a large amount of data that needed to be organized. I choose to create an affinity diagramm. Such a diagram is created by printing out every piece of data that can meaningful stand on its own on little notes. Than they are sorted after common topics they concern. If a topic is identified it gets a kind of heading on a note in a different color. It is pretty helpful but takes a lot of time and energy and space. Anyhow, I now hope that I have a clearer look on the former participants activities, motivations and problems.

Part of the affinity-diagram

It turned out that data analysis was a problem. Few students managed to get something out of the interview data that made sense for them – except for what was  accessible directly from  interviews itself. This gives me some room for improvement, though I am not surprised. In many occasions I saw, that upfront user research is hard to get across, not to mention to do for a newcomer. In addition, even "rapid" ways that are described in books require a team with some experienced members and quite some resources. On the other hand, if this kind of research is described in brief, it is usually on one page and such suggestions often skip analysis. 

I hope that using techniques like role-playing, giving well crafted examples and explaining how one can organize findings will result in an improvement here.

Prototyping on the other side seemed to be a highlight among the class activities. It was told to me in the interviews that it was a lot of fun. So possibly I try to get them do prototypes earlier in the process. Less pondering, more creation! I hope this can relieve common problem of deigners as well that I was occurring as well: fixateness on ones own design.

Imagine you are a painter and a salesman tells you that you should get rid of your tools in order to have more space in your studio. "Your workspace is not cluttered by all the other things like brushes and colors. What matters is the painting, not the tools!"

This seems silly but it is analogue to what is popular in GUI design nowadays. Freeing the space for what you want to see or create seems reasonable. But the goal of somebody is not to just see something but to see what is interesting and to create great stuff. In offering the functionality to do that a visible GUI is superior in terms of efficiency and learnability to many alternative ways like hidden elements, edit modes or gestures.

But with the rise of the touch driven mobile devices the design decisions that were made for these devices are spreading. And screenspace is very, very scarce there, and it was tried to eliminate as much GUI as possible. But since mobile touchscreen devices and applications have the reputation to be instantly easy to use we apply their designs to other domains. On touchscreens – regardless of their size – we invent complex multitouch gestures and on big displays we get rid of scrollbars

GUI for a good reason: common WIMP Interface (Free Software; ImageSource)

But they ground on a conception of a GUI that merely takes away space for triggering actions that can be accomplished with hiding them via modes or using gestures instead. What should software do is to enable us to reach our goals. We want to read the right stuff and we want to create content efficient and without learning about gestures and hiding places of functions. The conventional select-command GUI paradigm does a pretty good job in doing so, even in contrast to other established techniques. But whether you use the trusty old WIMP paradigm or alternative approaches: don't hide the tools!

UPDATE (7.4.2011):
The unity design team came up with a solution for scrollbars that does save screen real estate and offers visibility. I strongly recommend to have a look at their design!

When you knead clay, you have a direct experience of what you are doing. You feel the clay on your skin, its resistance and its smell. But there is more to it than just senses. Action equals changing something here in its very physical appearance.What you do and think is  embodied and takes place in the physical world.

by Soyer Isabelle (http://nl.wikipedia.org/wiki/Overleg_gebruiker:Soyer_Isabelle) under CC-BY-2.0-BE (http://creativecommons.org/licenses/by/2.0/be/deed.en)

Technology in contrast is often very different. Devices need interfaces, enabling you to communicate with it. There is no unified experience. Input and output can be in different places and different times, feedback is not necessary immediate. Good designs simulate the unified experience of the physical world, but the communication between us and the world of technology needs to be carefully crafted, the media does not support it in a special way. The difficulties start not with digital technology. Appointments and schedules are not graspable either.

I don't argue that we went horribly wrong with technology. We can learn how to deal with the system, new conventions and ways around pitfalls. Technology enables us to satisfy our needs and help us to solve problems. But I argue that we need to adapt to these things as they don't match our natural way of thinking.

But the idea that we are embodied in a physical space and that our interaction with this physical world shaped our brains in nature and nurture is often forgotten or replaced by the idea that we have our bodies to carry our precious brains around to make them access new data.

Having in mind that our cognition is shaped by the experience on acting in the physical world can help tremendously to understand design principles: often these rules guide us to mimic what would be present in the real world and that determines our thinking.

I am involved in organizing a lecture/workshop series (so called "Werkmodul") that aims for teaching interaction design at the Bauhaus. This is done in cooperation with Mozilla who contacted some great people and asked if they could mentor the students. I was very happy to hear that Cennydd Bowles, James Kalbach and Eric Reiss are with us for that – but I was even more exited that Eric and Søren Muus, who work together at FatDux, would even come for a real-life mentoring on the 27 of January.

What shall I say? The students and I, as well as Eric and Søren had a really good day I think. The mentoring was great for the students: problems in the details and high level questions like motivations and aims of the students were looked at and we got a bunch of hints and new ideas!

A break in the mentoring was made for Eric's guest lecture about his Web Dogma that was joined by many interested students from other courses as well. (and will be available at Mozilla's webpage soon)

After an incredibly interesting afternoon we ended the mentoring session the head full with possible improvements and Eric, Søren, me and a fellow student went out for having drinks, (crazy) ideas and dinner.

So: thanks to you, guys!

Eric Reiss' talk at the bauhaus

Since the iPhone introduced capacitive touch screens to the consumer market we have touch gestures all around. Gestures are movements that are recognized and trigger a function. Web OS uses this heavily e.g. for closing applications, Apple uses them e.g. for making buttons for deleting mails visible.

It is invisible in current gestural/touch interfaces that gestures can be done and it is invisible what they do as well. Users must know how to use this gestures beforehand. The “natural user interface” that it proclaims to be, sucks. Don Norman wrote about this already a time ago, so actually I don't tell anything new.

There are no ways I know of that introduce visibility to touch-gesture-interfaces. So I made up my mind.

First the user needs to know that a gesture can be done and in which way. For signifying this, I used an element which is already a standard for mouse based interfaces: On scrollbars and at the corners of windows a "rough" structure shows that these elements can be moved. This has been around for some time. So in my designs this visual expression as signifier for elements a gesture can be performed on. Note that this as well indicates the direction of the gesture as the riffle runs opposite to the movement's direction.

what it looks like

Now the user still does not know what the gesture will cause – e.g. does it delete an item or starts reordering elements? – and when –  is a short movement that will cause the action or a longer one? I don't have a solution to show this beforehand. But at least this can be shown directly after the gesture is initiated: Close to the element but not obscured by the finger a button is shown – first transparent, after further execution of the gesture in greater contrast. When the distance threshold is exceeded, the button appears to be pressed. This again draws on the experiences with common interfaces and standards. Try it yourself: demo.

I am not totally satisfied: The gestures can't be more advanced and the result is not clear before the gesture is started. Any ideas?