MAR
7
2004

Usability Teams - A Problem or a Solution

Aaron has posted a blog entry about developes 'fearing' usability teams, I've replied to his post itself by a comment but I'd like to provide a fuller view of things here.

I think that having a separate 'usability team' is an unworkable concept in an open source project, what we need is a way to make the usability guys part of the development team. Sure, there will be discussions on a usuability list about the issues the usability guys are working on, but the primary communication about any usability driven changes should be with the people who are writing or maintaining the application.

Imagine first:

1. Developer announces on the devel lists that he's working on an app and puts it in kdenonbeta.
2. Usability guy offers to help by designing the dialogs for the app.
3. Between developer and usability guy the app takes shape.
4. Usability guy reviews and tidies up the main application for usability issues. He's also been involved in the apps development so he's hopefully been able to ensure there are no major problems already.

Or alternatively:

1. Developer has a long standing app.
2. The usability team discussess the app and decides on a way to improve it.
3. Usability guy codes up the results of the discussion and changes the application.

In the latter siutation the maintainer has now got to deal with the fact that any changes he has pending are probably invalidated eg. the because the new dialogs don't support the right options, he's also had someone he's never heard of modifying his application.

My point: Usability teams and development teams need to work side-by-side - if they don't things will get nasty.

Comments

This would be a good idea, *if* we were back in KDE 2.0, or KDE 1.x, when we were still continutously replacing applications with new ones. This does happen occaisionally these days (e.g, kolourpaint), but is not apt to happen more and more in the future.

Instead, these days, most development, including usability development, will have to go into long standing applications. This is because we are certainly more mature as a desktop environment than were back in KDE 2.0.


By smt at Sun, 03/07/2004 - 03:45

Sure we aren't writing new apps that much, but the same process can be applied.


By Richard Moore at Sun, 03/07/2004 - 11:32

i couldn't agree more... we still have to deal with the current codebase, but what you describe is very much what the aim of kde-usaiblity-devel is!

http://www.linux-usability.de/download/Draft_OpenUsability.pdf


By Aaron J. Seigo at Sun, 03/07/2004 - 19:51

Well, I think there are a few useful observations that cary this point further:

  • This isn't particularly different from any other development mechanism. You always have to discuss changes of significance with the maintainer -- it just varies whether that's the product manager or the primary developer or the research leader.
  • OSS is developer driven and lead. We're the managers in a sense and expect to be kept informed of progress relating to the stuff that we're responsible. And just like real managers we'll be annoying and/or stubborn at times (and very helpful at others).
  • The team with all but a few notable exceptions isn't a mature enough part of the community of developers to do such far-reaching cross-module work. The way that the usability stuff is being done in KDE at the moment seems to emphasize general work rather than what Rich is suggesting of usability guys establishing themselves as parts of an application team. This is in conflict with the traditional (and logical) practice of being around the project for a while and maturing in a niche before jumping into far reaching changes. It doesn't really matter if it's under the usability banner or not -- people tend to not trust folks that get a CVS account and the next day are committing to a dozen things that they don't maintain. ;-)

By Scott Wheeler at Tue, 03/09/2004 - 14:21

I think that the goals of the usability mailing-list are sometimes misunderstood. I don't consider it as a parallel work being made by a team, it is just a place where we can discuss about usability issues, that's all. I have never seen some work committed by the 'team' without agreement from project maintainers. Of course some (bad?) changes have already been made in the name of usability, but it does not mean that those changes were made by the usability team. They were personnal decisions. And it does not mean that the current situation is a broken concept, much on the contrary, this prooves that things should be discussed more often.

Hopefully we are seeing more and more developpers using the list. In my experience it is a really great way to solve problems, that's what I did while designing the new logout dialog, my original patch has been greatly improved thanks to the comments I received. I am also trying to create a new kcontrol and a new style manager in collaboration with usability people, although those apps are far from being complete. A real cooperative work between usability people and developpers is what we need, I totally agree with Rich on this point. That means the developpers should use kde-usability more often.


By Benoit Walter at Thu, 03/11/2004 - 15:51

I think part of the problem in this is defining who the usability team is. This is a general issue and not confined to usability, in open source many people take part in a lot of discussions but the boundry of the team is always going to be hazy. In this sort of environment it is easy for a group of people to convince each other that something is a good idea (which it may well be) and that it is safe to just plough in and fix it (which is where the problems start).

I think it is possible for kde-usability to be better integrated by acting more as a resource for the other developers in a similar way to the artists team. At the same time, where there is consensus that something should be changed on the usability lists (and preferably during the discussions) the maintainers should be talked to. The chances are that they won't have time to follow the usability list so they need to be told when their apps come up. A good way to do this is to use the bug tracking system as it knows who to talk to.


By Richard Moore at Thu, 03/11/2004 - 19:12