OpenSource Usability Labs

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…)

First of all:
A BIG thank you to all the 143 participants that took all the way of our survey! Your feedback helps us a lot, because we are doing Tine 2.0 only for you! If you missed participation this time: join us on our mailing-list for Tine 2.0 surveys!

Let’s take a look at the main results:

What shall we do next?

We asked you to sort a couple of ideas we have on what features we could work on next. It showed no real winner, so I guess all our ideas have to be integrated in Tine 2.0. Still some points that seem to be more important are:

• Dashboard
• Birthday in Calendar
• Attachments
• Editable Notes
• Linking

These 5 were the winners and we will gladly consider your voting in our feature-plan.

Also we got a lot of comments on features you would like to see. Of course, we will discuss your ideas and  in the next survey we will ask how relevant they are for all of you!

How do you like and use Tine 2.0?

(more…)

There are many directions for the Tine 2.0 development we are discussing at the moment. But in the good tradition of our development we really want to know what you - our users and potential user - want us to do. So we decided to start a short survey and kindly ask you to participate - it will cost you less then 5 minutes and helps you and us to make Tine 2.0 the most rocking groupware around!

Tine 2.0 user survey

(The survey is powered by usability-methods.com)

I want to thank everyone who was interested in taking part in the Usability calendar tests. Unfortunately I could only invite people from Berlin, because the tests had to be conducted in person. So a special thanks to all the testers that came!

In the test I focused on the Tine 2.0 calendar. The tasks included creating a shared calendar, creating whole day and recurring events, inviting, copying data from the address book to the description of an event, accepting an invitation and moving an appointment to another calendar.

These are the top 5 problems the testers had:

1. For moving an appointment to another calendar, nearly everyone tried to drag and drop this appointment. (#1460 in the Bugtracker)
2. When inviting people, 2/3 of the testers expected to find the accounts, they shared the calendar with, to be first in the invitation menu. (#1522)
3. When creating a recurring event, 2/3 of all testers found “Every 1. month” irritating. A proposal for redesign is attached to the issue in the Bugtracker. (#1524)
4. Accepting or declinig an invitation is not obvious and fast enough. Two thirds of everyone struggled to complete the task. They couldn’t find said invitation without knowing at which day it was and then didn’t expect to have to open the Edit window to accept. (#1440)
5. When copying data from the business card area in the address book, more than half of all testers tried highlighting and then right clicking to copy. This didn’t work. (#1422)

Including the above problems there will be a priority list handed over to the great guys at Metaways and we’ll hopefully see most of the things already included in the next release of Tine 2.0.

If you have questions, please email me or write a comment.

To the nearly 200 (173, to be exact) participants in our icon test: Thank you all for taking part! We got great results in terms of the quality of the Tine 2.0 icons (which are, in fact from the Oxygen Iconset). Also, we would like to thank you for all the comments you gave: Many of them were really encouraging, we got many compliments, but also some valuable criticism and tipps.

How did the icon test work?

We not only recorded which icons were chosen for which terms, but also how long it took you to decide.

From that, we could calculate three values:

• “Strength of association” (Indicates what percentage of the users assigned this icon with this term.),
• “Discriminatory power” (Indicates wether and how often this icon was assigned to other terms as well.) and
• “Conspicuity” (Indicates how fast the icon was chosen by the user in proportion to the average.)

In the pictures below you can find the three values on the left in the above order. The three values together give an overall Rating between 0 and 10. After a few tests we conducted, we can say that only icons with a rating above 8 can be seen as perfect for a term.

What is very apparent in all the results: The Oxygen Icons are not made for Tine! From the few terms we wanted to find the perfect icon for, only “User” got a rating above 8:

The weakest rating was achieved for “Today”, which is very interesting, because I expected this to be the most evident one:

Here are the results of all the other terms:

Add Appointment:

Add Calendar:

And Resource:

What do we learn from that?

First of all, we need icons that fit better to the special Tine 2.0 terms. Of course, the Oxygen Icons are a great start, but they just don’t fit all of our needs.

That’s why we want you, our community, to contribute!

• If you use Tine 2.0 and you see an icon which you think doesn’t fit: Tell us!
• If you are an icon designer and love to play with pixels: We need you!
• If you know how to visualize complicated things with as little complexity as possible: Write us!
• And even if you just know someone of the above (or know someone that knows someone :), we would like to hear from you!

Please write your ideas and suggestions to: tine.calendar@gmail.com or post in the Tine forum.

We planned it for the Linux-Tag, but then there wasn’t a good Internet connection -

So we ask you now: Which are the best icons for Tine?

Please take part in this very short test where we would like to find out which icon fits best for some of the Tine parts like “Ressources” or “Today”.

To help us make Tine 2.0 even more user friendly, please click here and choose you preferred language:

http://tiny.cc/icontest

Plus: Calendar testers needed!

We still need testers for our Usability test in two weeks. If you live in Berlin, or happen to be there in two weeks, please give me a shout at: tine.calendar@gmail.com

We are looking for Tine-experienced people but newbies are also great.

The test itself will take place in Kreuzberg for about an hour and your effort will be rewarded, of course.

Thank you very much!

Today I found an article by Sam Dean who asks for a Centralized, State-of-the-Art Open Source Usability Lab. He refers to a cnet article by Matt Asay in which he postulates what Open Source can learn from Apple. Both articles point out that there is need for a shifting view in Open Source. Open Source needs to be more user-driven and less developer-centric - in other words there is a need for usability in Open Source work.

Well, there are good and bad news for both of them:
It is not as easy as they think but we have already come much further than they think!

To explain this I would like to clarify some myths on Open Source Usability:

Usability plays no role in Open Source development.

The OpenUsability.org initiative has provided Usability guidance to hundreds of Open Source projects for more than 5 years. We have worked with various  projects from big ones like Wikipedia or KDE to very small ones. Many projects have developed their own Usability-Community like the OpenOffice Renaissance or the KDE Usability project. Celeste Paul - one of the members of OpenUsability and KDE Usability - has just recently been elected into the KDE e.V. board.

So there is a community willing to assist Open Source projects on the user front and their work is been widely accepted.

Additionally our service, the OpenSource Usability Labs,  provides professional usability support to commercial Open-Source projects and traditional usability companys have detected Open-Source as a market by now.

Commercial Software always has a better Usability than Open Source Software.

First of all: the quality in commercial software varies as much as in open source. There are products with excellent usability around and there is just the opposite. In both cases the bad products die sooner or later.

So what we need to think about is: “What is possible for Usability in Open Source development?”

There are numerous Open Source projects around that provide excellent usability. Firefox challenges the Microsoft Internet Explorer. Think of projects like gallery, KDE4 or Tine2.0. All have undergone rewrites in order to enhance their usability and all have proven to be successful in relation to the age of the project.

So there is prove that Open Source projects are capable of a really good user experience.

Open-source software ends up being written for other developers.

This argument used to be true. Back in those good old days Open Source was successful, because developers could directly influence and change the software. If the software did not match their needs, they simply took the code and changed whatever they did not like. Projects split up, died, new ones were started - they evoluted. And by this they also evoluted a perfect usability - perfect for software developers which happened to be the main target group. In other words: those products evoluted perfect usability.

Nowadays that the user-base shifts, the goals in development differentiate. Projects that need to be used by average Joes and Janes build up user-feedback channels, integrate usability experts into the development and do regular user testing. They get designed for the average Joes and Janes.

Usability is a matter of a centralized lab.

This is actually not a special Open Source myth, but it is nevertheless wrong. Good usability can only be reached through a user-centric development process. A lab can be very handy during this process, but it is not the backbone. Usability experts need to be tightly integrated into the processes - from the definition of requirements, the evaluation of user goal, setting the information architecture to actually testing the products.

This is possible even in those distributed  and self-motivated development-teams you usually find in Open-Source projects. By tying it all into a single, centralized lab, as Sam Dean suggests, you would loose the strengths of this distributed development - just think of the requirements arising from different cultural needs.

Even more: Open-Source software is much more capable to integrate their users then a single lab would allow. Our experience is that Open-Source user are very willing to give feedback to the developers. While customers of commercial projects often ask: “What do I get, when I contribute?”, Open-Source users feel it is a good chance to say “Thank you” to the developers for providing a great piece of software.

By collaborating via the Internet it is not only a dream to activate this potential - it is reality. For example, we have just started an Icon Usability-Test for the new Oxygen k3b-Icons and we got more then 2000 participants within just 2 days.

Summing it up

The evolutionary process that stands behind Open Source development has already adopted to the idea of user centric development. Just as it will adopt to any other upcoming need in software development. And Usability on the other hand has started to understand the needs and the potentials of the Open Source idea, and makes great advances in activating them for the good of the projects.

For sure we are just at the beginning of a long journey. But we are already on the road. Articles like the ones from Sam and Matt show the increasing public demand for more usable Open Source products. I am sure the community notices these signals and will just speed up. The foundations are being laid…