Jeff Atwood’s post yesterday stroke a very sensitive chord. He claims that nobody hates software more than software developers, because they actually know what’s going on. This is probably not true for every industry, but certainly something that rings true. So who is going to protect us from incompetent software developers?

I’ve never met somebody who hasn’t had issues with software (even Mac users, yes :P).
As Scott Berkun so aptly states:

If you look deeper, you’ll find that when people say “this sucks” they mean one or more of the following:
* This doesn’t do what I need
* I can’t figure out how to do what I need
* This is unnecessarily frustrating and complex
* This breaks all the time
* It’s so ugly I want to vomit just so I have something prettier to look at
* It doesn’t map to my understanding of the universe
* I’m thinking about the tool, instead of my work

Unfortunately, people who create something are also very sensitive about it (well, yes, I did recently get my teaching evaluations, why do you ask?). This is the part where it’s sometimes more useful to let anybody but the creator do the user-testing. When testers can only express their frustration through “This sucks” and “I hate the way it works” it can be very helpful to have a translator at hand. So, contact your friendly user-experience expert and ask them to help you out here, because apparently the feedback is so bad that all you can do is become defensive.
While this isn’t really the reason I started in Human-Computer Interaction, I do have to say it’s one of the more challenging and satisfying aspects of the ‘job’.

As stated, the PhDs from VCR sent an email to HR to inquire about certain monetairy aspects of our lives. We finally got an appointment (to which I didn’t go, since there are 6 people on the committee, and all 6 of us might have been too much) but we tried not to expect too much.

That was a good idea, since we didn’t get much either. HR emphasized that this un-increase in gross salary was a one-off (but no promises for later either, or whether it would be made up since that will depend on the economic crisis). HR also mentioned that they wouldn’t tell people in the future to expect such a pay-raise (although how they want to keep it equal with the university is unclear). Furthermore there are apparently new contracts which should address this, but we’ve been unable to see them. We’ll just have to ask the next PhD student to come in whether we can see their contract, I guess. Actually, the HR people seemed somewhat pissed off that we dared to ask for our promised increase because while we got half, they didn’t get anything. Of course, they probably are on a higher pay-scale than we are anyway, so an increase might not make such a big difference for them.

HR also felt disinclined to discuss guidlines for managers, so we’ll have to see how we’re going to approach this and whether we need a different set for managers and for supervisors. The problem is that the only people we can be consistently certain of that new PhD students will see are the HR people. So we would need their cooperation to distribute these kind of papers. Maybe it’s time to find out who the real diplomats amongst us are.

Last week, four out of the seven days I spent being sick and hanging around in my home. Being sick of course doesn’t prevent one from reading or writing email, although friday was a rather low point and the laptop was turned off as much as possible. However, students still emailed.

Wednesday was the introduction to the course I’m coordinating this semester, and not everything went as smooth as I hoped. First, a student emailed that she couldn’t find the literature in the handouts. Well, no, since the literature was hosted elsewhere on the internet. Location: specified in the syllabus, obviously. (Acutally, there were more emails in that vein, but an announcement on the intranet took care of that.)

Second, we recently received an email from our students (and it’s still unclear to me whether these are the bachelor or the master students) concerning mandatory attendance, grading exams and level of the lectures. All of it rather positive actually, since they mentioned they would like the staff to keep track of attendance, return grades within the specified time (in my alma mater, if grades weren’t returned on time everybody got a pass, period), and make sure lectures were tailored to the appropriate level. Well, huray, rejoiced I! Students care about education and show they care!

So I mentioned the letter in the introduction, but unfortunately several students took this to mean that the mandatory attendance in our course was because of this letter. Uhm, yeah… so not, giving that letter way too much credit. Of course, this has to be rectified, since it’s rather unfair for the student who sent of the letter to get this  kind of blame from collegea student.

These appear to be some of the side effects of me opening up my mouth in lectures without thinking through beforehand what I will or won’t say. Obviously, there’s still much to learn in that corner. But at least it didn’t deter me in showing up, or feeling quite good about being able to coordinate a course for the first time.

Learning point: carefully think through notions and consider consequences before opening mouth to say something to students!

Recently, while sitting at the airport with two friends who’ve already obtained their PhD, we were discussing current research plans and opportunities for the future. While announcing that I officialy had gotten a co-lecture position for a course on cognition, one of them looked at me and said “You volunteered to teach?! But that’s the last thing a self-respecting academic should do!” Half-joking, half-serious, that remark, I could tell, but still serious enough to make me want to stand still and reflect.

Yes, I volunteered to teach (not just TA), because teaching makes up quite a big chunk of life in academia. If trying teaching now gives me chance to find out whether I like it or not, why shouldn’t I do so? So far, supervising MS students is the other experience, and that has also proved to be invaluable. Mostly, with regard to the selection and management process (I really detest micromanagement!), but also with regards to insight into the kind of questions really interested students ask.

So, spring semester of 2008 I helped out in a course on cognition, gave 3 lectures myself, came up with exam questions for said lectures, graded the exams, helped with coordinating discussions and graded posters. The only thing it did was make me hungry for more, give me ideas on how to reorganize, which other books to use, find more articles for examples to make the students as curious about the world of cognition and psychology as I am.

As a result, the lecturer in charge asked me to cooperate again with him this semester, and gave me responsibility for a group-based actions of the students. He won’t claim responsibility for it either, and I get my share of the evaluations. I think, if I survive this semester, it will have given me a good grounding in how to prepare a syllabus (how to write one up to) and hopefully I’ll still love teaching. Also, this might very well steer my decisions about post-docs. Ideally, my first post-doc would give me a couple of years experience abroad and let me test my hands more fully in the waters of academia: i.e. not only research and publications, but how to share the research with students, be the undergrad or graduate ones.

by Edward R. Tufte

In january I attended his workshop, and I was really very impressed by the way he manages to capture your attention and keep it. The chance to observe him form close-up (we got a spot in the first row) was something we loved. On a critical note, they way he explored his format didn’t allow for a lot of discussion. Granted, there were far too many people to make a discussion very practical, but once the tutorial is over you have to get out there and make it on your own two feet. So how could I manage to impress on my managers that powerpoint can be a really inappropriate format sometimes?

One of the follow-up things for myself was initiating the discussion about how we communicate within Research. Most of the time, one has to make one-page statements and such. Those one-page statements then have to fit on a powerpoint slide… Not my favourite program for any such things. Also, a lot of stuff that goes top-down only comes in ppt, like they think we can only understand things when they come in bullet-points. Myeah, that’s we all at least have a Masters in something or other! There’s a time and a place for everything, and I wish that upper echelons would be more conscious about their communication methods.

Direct quotes from the book:

Graphical integrity is more likely to result if these 6 principles are followed:
1. The representation of numbers, as physically measured on the surface of the graphic itself, should be directly proportional to the numerical quantities represented.
2. Clear, detailed, and thorough labeling shuld be used to defeat graphical distortion and ambiguity. Write out explanations of teh data on the graphic itself. Label important events in the data.
3. Show data variation, not design variation.
4. In time-series displays of money, deflated and standardized units of monetary measurement are nearly always better than nominal units.
5. The number of information-carrying (variable) dimensions depicted should not exceed the number of dimensions in the data.
6. Graphics must not quote data out of context.

Revision and editing principles:
Above all else show the data.
Maximize the data-ink ratio.
Erase non-data-ink.
Erase redundant data-ink.
Revise and edit.

Pugin: “It is all right to decorate construction, but never construct decoration”

Maximize data density and size of data matrix, within reason.

Graphical elegance is often found in simplicity of design and complexity of data.

Chartjunk is Tufte’s name for unintentional optical art, such as created by Moire effects. Grids can also be seen as chart junk, because a lot of the time they don’t contribute to understanding, especially when you have to crane your head in all directions to be able to make sense of the written stuff in a graphic.
For grids, he definitely recommends a muted form (grey instead of black, for example), which I’ve used with much success since, although not all figures have made it into the final drafts of papers.

Multifunctioning graphical elements, are, as the name says, elements that convey more than one piece of information. Using these, you can use less elements and still say the same thing. Or you can give redundant information in such a way that you don’t double your elements but try to make everything crystal clear.
To maintain clarity within this chaos, you should try and use graphical methods that can organize and order the flow of graphical information. So no pie charts! They aren’t useful, the information you can put in there is usually easier understood when in a table or in a form where you actually can compare and contrast small-sets of data. Techniques that might prove useful are multiple depths for viewing and multiple angles for viewing (although I’m not sure how to achieve this yet). One thing is for certain, you should succeed in showing the architecture of your data to the viewer.

Another way to see if you are actually showing a lot of information is by looking at data density. Data density can take advantage of the fact that the human eye can detect a large amounts of information in small spaces (although I’m not sure how applicable this is when using a beamer, or a low-resolution screen, considering that paper still has more possible options to put more ink in small spaces than a screen).
A formula to use for data density is to divide # of entries in the data matrix by the area of the data graphic.

A very practical way of using data density is by shrinking your graphics, and portraying them into small multiples. Especially when you want to compare graphics this can be very effective, while using the same template for every graphic is also very efficient. It can communicate narrative content also very well. So far I haven’t really used this optimally, because I was worried for data labels. I’ll putter around with this in the near future and if I come up with something useful show it here. MPhD (co-student) has done some useful stuff with this, to compare results from simulations which are graphs without names or necessary numbers.

However! Sometimes, a super-table can also be useful as a reference, especially when it is easier to read information rather than look at a 100 little bar charts. Elements need for super-tables are organized and sequential detail & a reference-like quality.

Now, on the integration of data and text. Anybody who’s ever written anything in Word knows how difficult this can be. I’ve used Adobe InDesign for lay-out as well, and it’s such a joy when you put your figures in and they don’t move, no matter what you do to the text. In effect, it should be possible to have your figure next to the paragraph where you’re talking about it. The graphic is part of the paragraph!
One thing Tufte cautions about is the difference in use for graphics. You can use graphics to communicate and illustrate a finding, and then you can tell viewers what they are reading. If you’re showing an exploration of your data though, only tell them how to read your design because they will want to make up their own mind. This is very much in keeping with academic tradition, as I see it. Give people the space and time to question and be critical, how else will you learn to appreciate the space of their brain?

Then there’s the proportion and scale issue. How large? Conic? Horizontal? Circle? Tufte proposes to give graphics a horizontal slant, so give your graphics greater length and lesser height (humans are very comfortable with divisions around the Golden Section; so as a rule of thumb you could think about moving towards graphics that are 50% wider than that they are tall). Another point is that cause is often on the x-ass and the effect on the y-ass. Might as well exploit that! Although I have to have a critical look at how I can achieve this every time.

Maeda’s book is in keeping with one of his own tenets: don’t make things too long or overly complex. He actually manages to say all he needs within a 100 pages. Nevertheless, it took me a while to get through “Laws of simplicity”, because it’s a lot of information, densely packed.

He summarizes his laws of simplicity as follows:

  1. REDUCE: the simplest way to achieve simplicity is through thoughtful reduction.
  2. ORGANIZE: organization makes a system of many appear fewer.
  3. TIME: savings in time feel like simplicity
  4. LEARN: knowledge makes everything simpler
  5. DIFFERENCES: simplicity and complexity need each other
  6. CONTEXT: what lies in the periphery of simplicity isn’t peripheral
  7. EMOTION: more emotions are better than less
  8. TRUST: in simplicity we trust
  9. FAILURE: some things can never be made simple
  10. THE ONE: simplicity is about subtracting the obvious and adding the meaningful
  • AWAY: more appears like less by simply moving it far, far away
  • OPEN: openness simplifies complexity
  • POWER: use less, gain more

In a way, what to take away from reading was fairly easy to start with. Think about the things you design, and think about them in a meaningful way:
Why is that function there? Why does it function the way it does? Could it be made easier, simpler? Or will it be worth it for users when they learn what the function does and learn it well? In other words, is the learning curve worth the effort needed to get to know your design, and if so, how will you convince users to go through the learning curve?

Executing this kind of thinking at all times isn’t easy though. It means that you have to reflect on your design, keeping in mind your users all the time. Not only that, if you work in a team, you have to convince everybody else of this too.
Keeping everybody focused on simplicity (or at least relative simplicity if you can’t make things simple) is a hard task to execute. So, just because you are trying to keep things simple, doesn’t mean it’s easy to achieve.

Considering that I don’t really design products, how to apply these principles for me? Well, they can also be applied to writing papers, and blog posts. Externalize reasonings, ask ‘why why why’ all the time and make it explicit. You know why, but you cannot assume that readers do. And sometimes, when you explain why things cannot be that simple, people take the time to follow through your complex reasonings.

Or why is usability and user experience so important for softwere developers and engineers, and how do you convince them it’s so bloody important?

The inmates are running the asylum, by Alan Cooper

This reads like a business-book, which is what it aims at. It does give a good feeling for what’s important when you develop software for people that aren’t you, especially when it comes to working through specifications (no matter who the specs are given by). Features of your software are not what is important, rather that users are able to reach their goal. So one should work goal-oriented and put in features that help users reach their goal, not put in features just because somebody thinks it’s interesting (think pointy-haired boss).

Engineering methods don’t work to solve engineering problems, because you’re blind to your own problems. A different method will probably work better. Also, it’s difficult to do both back-end and front-end design so separate both but they still have to work together. There is a conflict of interest between what the programmer wants, and what the user wants. So you don’t let a programmer referee whether a program is doing what the user wants (unless it’s something she designed for herself to use, obviously).

Bribery can work to find out what programmers are doing, but you shouldn’t have to resolve to it. On the other hand, maybe you can train some sense into them that way. Or present it together with a rational, defensible reason. In terms an engineer can understand.

Bottom line: you can listen to your users, but it’s even better to observe them. If you only listen, you’ll end up trying to sell them a 12-headed dragon.