OpenSource Usability Labs

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.

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!

With the new version – Mialena – of Tine 2.0 out, it is time to take a look back at the feedback you provided to us in the past version.

As you know we ask you – our users on the log-in screen to participate in short surveys. They all have one common goal: to assess your impression of the quality of Tine 2.0. So, how do you like Tine 2.0?

The overall impression of Tine 2.0 is good (about 2.4 on a scale from 1 (excellent) to 7 (needs improvements)). The rating of the individual applications varies with addressbook and calendar leading with approximately the same value as the Tine 2.0 overall impression. The other important applications (Tasks, Email, Admin) follow, getting good to above average ratings while still leaving some room for improvements. Only sales, phone and voipmanager get below average ratings.

So, with Mialena we decided to improve the basic concepts in Tine 2.0 further. Most application now have a proper filter- and favorites concept. We hope this will better your impression of most of the applications. We also decided to move the navigation from the Outlook-like-app-pile to a modern Tab-interface. I am curious how you like this! We also spent some love to calender, email and syncing (my N900 now works fine!) – and of course some more which you should not hesitate to find out!

For a lot improvements we did your free comments inspired us a lot. We believe that we managed to fulfill about 50% of the free suggestions you made in Mialena now. So thanks for that input and keep on going like this. It really hepls us a lot to get even better!

We also asked you a couple of other questions about your context of use (mainly business, but also for other private purposes, managing between 1 and 800 users) and the necessity for a handbook (about 40% would like one) or seminars (about 25% would like one). Even though we need to get better in documentation on our wiki and other resources (so you told us!), most of the users are quite satisfied with the documentation and help they can already get.

So, please check out Mialena and continue to participate in our surveys – and in any other way you like. We desperately seeking for designer wanting to contribute to the look and feel (esp. icons need to be done), volunteers working on documentation and in the forum – or how would you like to participate in the Tine 2.0 development?

As a reminder for all who are interested in Usability and Open Source – and are at the LinuxTag tomorrow. We will have a very informal meeting from 9 to 12 am in Hall 7, 1a,  Workshop Room “New York 2″.

You are very welcome to just drop in if you like!

LinuxTag 2010, anybody?

We invite you to take part in an informal meeting to share thoughts, experiences and other information covering the topics Usability and User Experience in the Free Software world. The meeting is organized by Björn from OpenUsability.org and Christoph from the OpenOffice.org User Experience Team.

You should join if you are interested in:

• Integrating User Centered Development into the development of your FOSS project
• Wanting to add your UX expertize to a FOSS project
• Wondering how to take benefits out of community work with real users
• Some usability tips for your FOSS project
• …

We are looking forward to see you at LinuxTag in Berlin, Germany!

Go ahead and find more information on the Informal Meeting Wiki page.

Cheers,
Björn

Thank you all for the great participation in the challenge… As we hoped everyone would have some fun, there still is a serious goal behind it: Defining the new frame for Tine 2.0 and getting you – our users – into the boat. So now we have come up with what we would call the final prototype. Final in terms of: if you do not find anything bothering you and telling us so, we will start to implement it.

More information?

Find the whole challenge here

Find the final prototype here

Please comment in the Tine 2.0 Forum on this and rather not in my blog – so we only have one discussion!

We always try our new paths in user participation in the development of Tine 2.0. Inspired by the great ideas Thasmo had in our forum, we decided that we want to try to integrate our users even more into the process of re-designing the Tine 2.0 applications-frame. So we ask you to provide and discuss ideas with us and the other users. Please have a look at our

Tine 2.0 community mock-up challenge.

Have fun!

It is really great to see how many of you already took part in our KMail-Icon-Test. A lot of questions arrived my by mail or in my blog, so I thought I would just explain a little about testing icons…

We do this testing, because icons are useful and beautiful – they save place and people can recognize them faster than they can read text. Practically icons work via a visual-metaphor. If that metaphor, however, is not understood by the user, (more…)

Thank you, to all you those about 30 Tine 2.0 users who have answered our survey accompanying the last beta phase. Your participation is very welcome!

As you will have noticed, we introduced a new welcome / log-in screen to Tine 2.0. On that screen you will get informed whenever we start a new survey. This way we want to better get in touch with the users of Tine 2.0 – and we want to understand in how we can make Tine 2.0 better for them. In the past we had the problem that by our means of publishing the surveys, we mainly got responses from Tine 2.0 admins, who have a real reason to visit our homepage. The opinion from them helped us a lot, but we need to get more feedback also from less technical users.

In this light I would like to say thank you for your trust. The results of the survey (more…)