OpenSource Usability Labs

As Akademy / Desktop Summit was in Berlin this year, I took the chance to participate. I probably wouldn’t if it had been somewhere else – and I have to admit: It was a great decision to take part (and a big mistake not to do so in the years before). A big praise to the organisers!

Everyone with a slight interest in KDE or Gnome should join this conference. I will hopefully be able to attend next akademies again. And hopefully there will be more people with a similar background to mine, doing user resaerch, usability or UX work. We do need you!

Personally I have been talking to dozens of people about better ways of integrating users into the development. My thesis was basically:

The way users are integrated into the projects at the moment is frustrating and (trying to find a nice word) ineffective for both, users and developers. It thus does not bring in the desired amount of new blood nor innovation into the projects.

Interestingly enough, I found no-one who really disagreed with this. On this basis I did talk to developers of a lot of different projects, but also to representatives of the KDE e.V. and user representatives about the problem and how we could use the usability and user-driven-innovation tool we are currently developing to improve the situation. I also managed to do a BoF about it, to get in touch with some people from Gnome and I talked to Michael Meeks from LibreOffice about it.

As a result of these talks, we will start creating user panels for individual projects, by simply popping up a layer that will be asking users to join the panel after some time of usage. We will use this panel to ask usability and demographic questions, but also to motivate users to get – step by step – involved deeper into the projects. A lot work to be done…

As we are entering virgin soil here, we will obviously (need to) gain experiences. If you want to join this ride with your project or just your experience or opinion, you are happily invited to mail me or comment below.

The first user research survey for LibreOffice has just been closed. About 5400 participants exceeded our hopes and expectations by far.

A big THANK YOU to everyone who participated!

This success shows us that the LibreOffice users are more than interested in giving feedback. They want to take part in the further improvement of LibreOffice. We can, should and will take this seriously! A series of follow-up surveys is planned and will be coordinated with the development.

At a first glance it shows that the most used applications (on an activity scale from 1=never to 5=daily) are LibreOffice Writer (3,92), Calc (3,22) and Impress (2,41). A lot of the participants (76%) see themselves as experts in dealing with computers and spend a lot of time at the computer during the day. Thus, using the computer is very important for most of them (78%).

We will analyse the results in greater detail now and keep you informed about the findings. A big part of the survey dealt with the preferences in using software. It looks like we found quite some interesting results. For example, a question about ribbon interfaces polarizes the users: while 23% of the users strongly prefer ribbon interfaces, 20% reject them (extreme values on a semantic differential). A fact we will evaluate further, so stay tuned!

If you want to join us in the user research team, simply subscribe to the LibreOffice Design Mailinglist. We can give you the opportunity to look at the results personally on Usability-Methods.com, where we conducted the survey.

Read more about the results soon. Thanks again to everyone for your support!

… I would be very happy to talk to you!

My interest is to find out how to make better use out of the users of a software. If you are interested what this could mean for you, join me on a BoF or simply ask me when you see me, e.g. on the pre-registration event tonight

I am looking forward to my first:

In April 2011 we ran a quick survey regarding time tracking in Tine 2.0 — thanks to the great community for spreading the links and to everyone taking 5 minutes to answer our questions!

We don’t want to bore you with a lengthy discussion of all the available statistics, but instead give you an overview of the most interesting results.

One of our concerns was the actually used number of Timeaccounts within an installation of Tine 2.0. The aggregated results indicate that we need to support the complete variety – from only a handful to more than 50 Timeaccounts. This surely sounds like a challenge to any user experience architect but, contrary to our expectations, the comments imply that users currently do not face any serious problems selecting the appropriate Timeaccount.

Regarding the length of a single task that is entered into the Timetracker we found a quite surprising pattern: Most of users’ tasks are either between 15 minutes and 2 hours; or up to one or more days. We’ll have to see how to tackle this in any upcoming changes to the interface.

We also gathered some popular or recurring feature requests from the forums and bugtracker and let users prioritize these according to their personal preference. Aggregating these personal priorities results in a nice graph that shows which features are important to most users:

A quick entry of Timesheets is the most important “feature” that we have to tackle in the next iteration of the Timetracker. Furthermore the assignment of Timesheets to Tasks and vice versa is a very popular idea that we haven’t found a solution for, yet. The same applies for repeating tasks, e.g. holidays or tasks that take more than one day. We already have a couple of ideas for indications of deviations from a standard work time and a better overview within the application, but according to the survey there are more important features.

Regarding a stop watch feature, that would allow users to press a button when starting and stopping a task, we can conclude that there is much disagreement between users. There is a small group of users that highly want this feature and others that do not need it at all. As you can see from the graph the majority of users would probably not benefit from that this feature.

So, that’s it — curious where the future development of Tine 2.0 is heading? Interested in a deeper analysis?

Discuss with us in the comments!

We just started a quick new survey for our ongoing project Tine 2.0.

Please help us gathering feedback on the application’s general development as well as capturing your habits of time tracking.

Take the survey now!

The relationship of developers and designers is full of misunderstandings. Projects fail, e. g. due to the struggle among different views on the same subject. Communication can be frustrating for both sides. But there is hope. In this article I want to share and discuss factors that facilitate a ‘Designer with Developer’ rather than a ‘Designer vs. Developer’ in FLOSS projects.

Background

You need to know that I am a psychologist. I see myself rather as a designer than a developer, because I do not actually write code. But I also do not do graphic-design. My approach to design is not to create pretty pictures – it is to understand people and design solutions for their needs.

My company Apliki is intentionally called “Psychological IT Consultancy”. In our work we build the necessary foundations for projects and bridge the gap among the different worlds in a project (developer and designer are not the only relevant groups in a project – e. g. understanding the user is another central part of our work). In my non-commercial FLOSS work for OpenUsability.org I do the same. After more than ten years in the business I have worked with very different people and projects.

Recently there have been some discussions on the LibreOffice Design mailing list about the rights and duties of developers and designers. I actually do not want to contribute anything specific to this discussion. It is already valuable and fruitful but sometimes I need external impulses to do something I wanted to do for a long time: share my experiences about factors that facilitate good cooperation in projects especially from the design perspective and hence lead to successful and satisfying projects.

So here we go:

1. Respect

Successful projects are based on respect between developers and designers. They show respect by taking time to talk to one another and explain their ideas.

Often designers will say something like: “This solution has the better usability”. Developers tend to answer: “But it is too expensive to code”. This kind of conversation is the best starting point to build up an oppositional feeling in a project  – and I have seen many good ideas failing this way.

My grandfather sometimes says: “You didn’t experience war so you cannot understand it”. This always upsets me. I do understand a lot of things, but my dialogue partner needs to take the time to explain them to me. Taking time shows respect and helps establishing mutual trust.

2. Reasons

In a successful project developers and designers explain why something is better or more expensive, and take the time needed to address the objections of one another.

Giving a good reason is not easy. Neither hierarchical position (or the FLOSS equivalent ‘length of contribution to the project’) nor a vote (“5 out of 8 think this is good”) are good reasons. In Non-Free projects they are more likely to be accepted, but in FLOSS projects most people invest free time.  There is a psychological concept called cognitive dissonance. It helps to understand why people volunteering in FLOSS projects need not only good, but excellent reasons to continue with their involvement (Because they have to self-justify their involvement all the time).

The worst, but still often heard reason is, of course, extortion: “If you do not accept this, I will stop my contribution”. The fact that it is still heard quite often, shows how tiring it is to discuss the relevant issues. Especially in FLOSS projects, where non-native speaker discuss mainly via mail, chat or the like.

3. Foundations

In successful projects design is understood as an engineering discipline, with a common and clearly articulated set of values for all relevant parameters. This sets the frame for the optimization of interfaces.

To be able to address objections, a team needs a common understanding. In my experience, developers are much more sophisticated in this matter than designers. Programmers tend to make fundamental decisions very early. They agree on technical frameworks, architecture of the software, code repositories and so on. This allows them to provide good reasons why, for example, something is expensive to do. This usually leads to the situation that different developers will provide similar answers for a question (as long as this question is technical).

The situation in design could not be any more different from that. Discussions occur about even the smallest issues. This is partially due to everyone being an expert when it comes to using things (see Parkinson’s Law of Triviality for some interesting thoughts on that). But the main reason is that the common ground is missing.

Interface design is often misunderstood as an art. While it definitely has artistic aspects, it mainly stays an engineering discipline. Unfortunately most people working on interfaces think they are doing arts. The problem is immediately evident: Art may be interpreted, but never needs to be justified. And this is where the arts approach to interfaces almost surely fails. If various people work on the same interface, they will need to justify what they do, convince others why their ideas are so great and so on. The more people, with a variety of backgrounds, are involved into this process the more problems will occur.

The only solution is to focus on the engineering aspects of interface design. Engineering is the opposite of art. All it does is:

1. Find out all the parameters that are relevant,
2. try to find reasonable values for them, and
3. iteratively optimize the solution within the given parameters.

This looks like a very boring approach for most people working in design, and it is hence very hard to establish. In the end it is the only way to lay the foundations on top of which problems can be solved. Additionally it is very close to the developer’s thinking and eases communication among different parties.

4. Trust

In successful projects an aura of trust allows new ideas and new people to grow to the benefit of the project.

Once the foundation for the design work is laid, the team can start to build up trust. Development teams rely on code reviews. Good development teams only check whether the code complies with the common foundations. Even though the more experienced developer will sometimes know more elegant ways of solving a problem, generally any improvement will be accepted. The team shows the trust that  all members will learn and accept that they are not perfect yet. They accept that the product is always “in process”.

Again, design teams tend to miss this generosity. As a result of missing explicit foundations, details are discussed in great depth involving a large group of people. Also these discussions often try to find the ultimate, all-time-end-of-discussion solution for a problem (that has not been described in full detail). These discussions can be frustrating, especially for willing new design contributors.

Since usually some sort of interface already exists, an implicit agreement on the foundation exists as well. New contributors therefore either do marginal work or will most likely fail with anything more ambitious. Both ways do not facilitate to build up trust in the new members. The old ones feel responsible for everything. New ideas and fresh personnel has a hard way to get into the project.

5. Communication

In successful projects communication is well structured, facilitates work and does not prevent it.

A potential lack of trust inevitably leads to extended communication. In FLOSS and therefore often voluntary projects people do not find the time to work anymore, because they are stuck in administrative issues (following the different discussions). This is frustrating and will lead to people leaving the project (see concept of cognitive dissonance above).

Also developers are not willing to participate in the debate, or even look at the discussions, because they indeed have better things to do. The gap between design and development increases.

Additionally we should not forget that developers and designers speak different languages. Developers talk about technical issues sometimes with the same words, designer use for describing interactions. Add the fact that people contributing often do not use their mother tongue and the communication chaos is perfect. Astonishing for a psychologist to say, but talking about it is not always the best solution.

6. Facts

In successful FLOSS projects all contributions are welcome (they may be rejected though) and discussion always takes place on the current objective, not on what single people did.

To reduce communication it will be necessary to accept facts. FLOSS development evolves gradually and not always in the shortest linear way. Sometimes things even get worse. This is not really a problem, as such things will get corrected after a while. These faulty developments can also help to clarify the foundations or to show how conclusions can be drawn on them.

It should not be subject of any discussion when someone has done something. Remember, people are spending their spare time. If they have to justify that they have done something they are likely to leave the project (did I mention cognitive dissonance before?). And what is worse? A wrong turn in the project or the loss of a motivated contributor?

7. Structure

In successful projects structure facilitates the cooperation of different disciplines.

The acceptance of facts is a non-commercial FLOSS-only approach. In every commercial project the opposite is true, because in commercial project structures are more natural. FLOSS projects tend to refuse structure with reference to the bazaar. But even on a bazaar not everyone trades everything and there are rules and structure.

Structure prevents turning facts into the wrong direction in the first place. Design has to provide a structure in two ways:

1. Contact and support for developers willing to work on a certain topic, and
2. a road map of topics the design team considers urgent.

If this structure is provided, development does not need to follow the design team very closely. Points of contact are clearly defined and help getting the work done.

Closing words

Design in FLOSS projects still is in its childhood. Unlike in development, structure is often seen as an opponent to or a restriction of freedom. The opposite is true.

Structure is a necessary enabler of freedom. It enables people to decide into which project they will invest their time. It enables consistency, the prerequisite of any usable or even desirable product. So do not waste your time in discussions about problems – invest it into discussions about a suitable structure for your project.

What do you think? Do you agree to my point of view? Let me know in the comments below.

In long discussions with Christoph (who was one of the most active UX people in OpenOffice) I always said that I think OpenOffice has no future. I came to this conclusion because I think Free Software will not work if the community is basically not allowed to submit code or to steer the direction of the project, but is degraded to do everything the owner of the project does not want to pay for.

So you can imagine how excited I was about the raise of the truly independent initiative “The Document Foundation”. I had to change my mind concerning the future of what once was StarOffice. We suddenly have a prosperous and truly Free project.

It is a pity that it needed a fork to achieve this. On the other hand forking seems to be some sort of fashionable in office software at the moment, as most of KOffice developers chose to fork the project to Calligra Suite. But mechanisms of Free Software development are hard to understand for some people.

So at the end of last year I had another very interesting and long talk to Christoph, who is now one of the most active UX people in LibreOffice. And I decided I want to join the project and participate in facilitating the User Experience for LibreOffice user. This has some selfish reasons, as I am one of the partially annoyed users myself. But it also has to do with my ambition to create a set of desperately needed Free Software, that is not only usable, but astonishingly good. An office suite definitely is part of this set, as it is one of the most basic tasks people want to do with their computer.

On the other hand: I am a bit scared seeing the size of the project. I joined the ux mailing list, where Christoph told me “you will get one or two mails per day” and I now get more mails per day than I can even count (making it worse: KMail currently has a bug resulting in not filtering incoming mails!). I still wonder how we can get work done with this amount of noise on the list.

To get going, I have decided to keep myself out of a lot of things I do not feel I can contribute to. I am not an artist, so I do not talk about icons and such.

But I was very happy when Cederic asked for some help in redesigning the “Fields Dialogue” in writer. I happily said I will jump in, even though I cannot say I have achieved much so far. But one thing I do understand: This dialogue really needs more than a face lift. It is hard to understand what this dialogue is actually used for.

My personal highlight of this dialogue so far: You can count the amount of words in your document in letters. If you have three words in your document, the field shows you a “C” (you can choose whether you want to have the “C” in lower or uppercase). See what else I will find in there. But things like this don’t make it easy to understand what is actually going on in there – or even how to sustainably improve the dialogue.

Summing it all up:
Hello LibreOffice, I glad you are there and I am happy to join. Let’s have some fun and rock the Office world.

A couple of days ago I visited an expert´s forum concerning Universal Design:

“Universal Design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.” (Ronald L. Mace, 1988)

Thinking about this definition of Universal Design, I have two critical points to make: Who is meant by all people? And why is no need for adaptation a goal at all?

In the first place I regret the fact that the debate was dominated by speeches NOT referring to ALL people at all! Organized by the German Family Ministry it focused on generation fairness rather than the UNIVERSAL aspect of Universal Design.

By far the best contribution at this event was made by Peter Glaser – regarding him as an excellent speaker and a bright mind, I should pay more attention to him in future: He was about the only one there to understand that a UNIVERSAL claim cannot be limited to elderly or disabled people here in Germany or other first world countries – UNIVERSAL needs to imply ALL people on our planet.

If I understand the idea behind Universal Design correctly, I think it is one of the most important ideas around: Do not discriminate against any people anywhere in the world by means of technology, products or services.

But with my personal (free-) software-specific view on design I am puzzled about the rejection of adaptations in the definition by Ronald L. Mace.

I am convinced that the exact opposite is true. To me GOOD Design makes it extremely easy to adapt a product to the special needs of the user(s). This believe is one impulse behind my commitment for free software. The mechanisms of free software encourage people to derive special solutions for their needs on the basis of developed technology standards.

Some examples:

• The GNU Linux kernel is an example for a good software design. Based on it there are heaps of derivatives for special needs.
• The KDE desktop exists in a ‘normal’ and a ‘netbook’ variant – more hopefully to come.
• There are many different variants of a single underlying GNU Linux distribution, e.g. Ubuntu, KUbuntu, Edubuntu, Mythbuntu, etc.
• Kontact as a PIM-suite originally designed for the KDE desktop is being adapted to a mobile use-case in the ‘Kontact Touch’ project.

Do you have any other examples?

To sum it up: I believe free software is a good – if not the best – approach to achieve the noble goal of creating non-discriminating technology for all, or Universal Design. We are on a good path, even though it is still too complicated to actually do the needed adaptions today, especially if you are not a software-developer. We can still do better.

Shouldn`t we always keep that in our minds, when we create free software?

We have just finished another survey for Tine 2.0. Thanks to all participants for showing their support and helping us to make Tine 2.0 the best groupware around. We are very pleased to report that this survey — in terms of the number of participating users — has been the most successful so far.

After looking at the answers we conclude that the overall impression of Tine 2.0 is positive and seems to be improving over the different versions — a trend we hope to continue during the next releases. Users seem to appreciate the simplicity and general user interface provided by Tine 2.0.

We also realized that the Addressbook is one of the most used applications and that we need to be cautious about handling upcoming adjustments. We hope users will be willing to discuss possible user interfaces with us in the forum.

We have already put in some usability work into the Calendar application which — as the data of this survey suggests — has improved since the previous release of Tine 2.0. Sadly users perceive the Email client as one of the worst core applications. We are quite aware of the technical limitations and are just putting on the finishing touches to resolve these as well as to clean up the interface.

A lot of users rely on the Timetracker, but the feedback suggests that it still needs improvement. We hear you and promise to make this a higher priority — maybe someone is even interested in sponsoring the next iteration?

We greatly appreciate the comments we got during the survey. Overall it seems that most users are in need of proper connectivity support (CalDAV and WebDAV coming up!) and at least a basic document management system. From a usability perspective the overall speed of Tine 2.0 is also of concern. Until we can tackle this, administrators should have a look at this thread in the forum.

In other news we are still puzzling about how to reach even more end-user of Tine 2.0 in our surveys, i.e. someone like our Personas — Any ideas? Let us know in the comments!

We just have published a new version for Kontact Mobile on Maemo. I would like to encourage you to tell us how you like it.

Why should you try Kontact Mobile and give feedback?
Kontact Mobile is doing really well. It is a promising product, feature rich, free software, KDE and it is here to stay. But the current project of porting Kontact to the mobile world is – what it looks like now – only supported till the end of this year. So we really need your feedback now.  Next year we will not have the same power as now to let your wishes go into the project. So, please try it right away, spread the word and do not forget to

take part in our survey!

Let us K(DE)onquer the mobile world.