Forum OpenACS Q&A: Open Source and Usability

Collapse
Posted by Simon Carstensen on
Matthew Thomas, a Mozilla contributor, wrote something interesting about why free software usability tends to suck (via Joel on Software).

What's the community's take on these matters and how may we avoid these pitfalls?

Collapse
Posted by Don Baccus on
Here's a quote from the piece:
Many hackers assume that whatever Microsoft or Apple do is good design, when this is frequently not the case. In imitating the designs of these companies, volunteer projects repeat their mistakes, and ensure that they can never have a better design than the proprietary alternatives.
and a hypothesis:

The usability of most software sucks. I don't see anything unique in the free software world in this regard. While it's true that few open source software projects seem to have many usability experts on the team, how many commercial software projects do?

In fact, as an area of specialization, user interface design and the like are quite new in the software world.

There are certainly serious usability issues with the OpenACS 4.5 toolkit, but not for the reasons mentioned in the article. After all, we're still at the "port to PG without breaking Oracle, productize and deliver what we've inherited" phase of the project. The people who produced the code were paid by aD to do so. If the same people had written the code to be released by aD under proprietary license would they have done anything differently? I don't see why we should think that.

Note that I'm not trying to belittle aD folk (the ACS 4 toolkit was released prematurely IMO and given more time, the aD folk would've produced a much more complete product, regardless of license). Nor am I trying to minimize the usability issue. It's a serious one. I just don't believe the premise of the article, which is that open source software sucks in usability in comparison to proprietary software.

It's ironic to see such an article written by a Mozilla contributor, since I find Mozilla, with its tabbed browsing and pop-up turnoff features, more pleasurable to use that IE these dayes.

And this past weekend I had the pleasure of setting up GNUCash 1.6 for the first time. In an afternoon I figured out how to set up my consulting business records, including tax reports that can be imported into Turbo Tax. I find it's UI to be quite intuitive and straightforward.

On the other hand, if you've ever tried using the GIS program Grass you'll probably believe the premise that free software flunks the usability test :)

Unfortunately parts of the OpenACS 4.5 UI, especially in the admin portions, sucks and there's absolutely no doubt that we have to improve it. I haven't heard anyone disagree with that yet!

Collapse
Posted by Michael Feldstein on
I'm glad you raised this issue, Simon. I found myself agreeing with the article on most points. I have thought about this some and have a few suggestions:

  • Create a slightly customized version of ticket-tracker intended to implement Jakob Neilsen's heuristic usability methods. These are relatively easy to learn for all and lend themselves well to a community-based approach. Add some help or coaching text to enable people to learn this approach through the tool itself.
  • Create a (group-scoped) footer that turns on a link to the heuristic-usability ticket-tracker. This way, any portion of any OACS-based site can be put into a usability testing mode fairly easily.
  • Develop user-interface guidelines (such as the ones that Lars developed for ACS-Java) for the entire project. (In fact, somebody who is authorized to do so ought to attempt to contact RedHat and get permission from them for us to use these guidelines. AFAIK, the only reason we haven't thought seriously about adopting them here is conflicts with the ADPL.)
  • Pair non-programming UI volunteers with volunteer programmers. In fact, such a pair should be appointed to coordinate usability development on this project.

That's a start, anyway.

Collapse
Posted by Simon Carstensen on
Answering my own question...

Let me first comment a bit on the discussion Don raises. When bringing Microsoft (and Apple for that matter) into the discussion of usability, I find it important to distinguish between what you might label as "Microsoft Usability" and "Usability". What I mean by this is that there seems to have been created a sense among users - not so much developers - believing that how Microsoft products work is how computers work. They say, "my computer doesn't do what I want it to" forgetting the fact that it is Windows and the usability of its GUI keeping them from doing their work.
As the article mentions, GUI designers generally seem to imitate the designs of Microsoft Windows (looking at the last couple of year's development of graphical environments for Linux should be evidence enough). Afterall, this is how the user expect the computer to work. So the question is whether you want to better the usability of your application measured using so-called "Windows GUI Usability Standards" or the the scientific usability measurements based on for example heuristic usability methods.
A few thoughts inspired by Don's post. Ok, moving on to more OpenACS related topics.

Although the main goal at the current stage of the project is to port to PG, I think this time is as good as any to be talking about usability issues. But you are right, Don, the discussion should not be on usability in connection with licensing, but on how to work on the usability of OpenACS. Remembering this, I still believe the article raises some interesting points that we might learn from, or at least it ought to inspire a discussion on these issues. One I think is needed.

At this point in the development phase, we have programmers working on both the UI and coding. I find Micheal's idea of pairing UI volunteers with volunteer programmers to be extremely useful. I am not sure we need a customized version of ticket-tracker or footer links (at least such features seem secondary to the overall start of a usability effort). First step should be a usability team. We already have teams of development and testing, incorporating one of usability should be easy (and one of documentation, too, but that is a whole nother story). Simon Millward has expressed some disappointed with the level of activity over at the testing server and perhaps there's simply not enough volunteers available to create an independent team of usability testers?
Documentation on how to conduct usability tests should be created (it could be something as simple as a document of links to need-to-read material and a check-list for the usability testers), and a set of corresponding acceptance server usability tests. It would add to the workload of the testers, but the difference between the testing that's being done now and usability testing is vague in the sense that they both conduct tests on the UI.
Also, as simple useful tools for this work, a usability category should be added to the SDM. Or perhaps, even better, add a "Report a new usability issue" link along side "Report a new bug" and "Request a new feature".

Teaching people how to conduct these tests is one part of it, the other part is - as Micheal points out - outlinging a UI guideline. UI scheming. These are already available lying around on the aD server - although the docs are licensed under the ADPL, wouldn't it be possible to read these through alongside other documents on these issues and create an outline based on this information?

Trying to forget the premise of the article (open-source usability sucks as opposed to proprietary), here are some thoughts point-by-point:

  • Every contributor to the project tries to take part in the interface design, regardless of how little they know about the subject.
    This holds some truth in connection with OpenACS, in the sense that UI doesn't seem to be real issue, but moreso the underlying code. The UI is a product of what the programmer wants his code to do. On top of this, different developers through time, add new code to each package with same issues on mind.
  • Because they are hackers, they are power users, so the interface design ends up too complicated for most people to use.
    aD has always had a history of preaching simplicity (and certainly this has been succesfully ingrained into the ACS). This has left the UI of the ACS with that same simplistic look at large. I think that it's worth noting that with the added complexity to the admin pages as the parameters from the ad.tcl file were moved to the UI, has added some confusion it. Perhaps not so much an issue of simplicity, but moreso of structure?
  • Many of the little details which improve the interface are not exciting or satisfying to work on, so they get fixed slowly (if at all).
    Certainly a valid point. One that has already been pointed out by Lars:

    "When you're writing down user documentation, you'll probably become aware of things that are completely impossible to explain to any normal person.
    [...]
    File these as SDM bugs, please, so we can start cleaning up the user interface. It needs attention, and there's *tons* of low-hanging fruit, things where we could just add a page or two, or do really small things that'd help much. "

Regards,
Simon
Collapse
Posted by defunct defunct on
Its also worth noting that its very difficult to assess usability for a system that you've been developing. As with many popular software products, after a time you get used to them. Once that happens the UI limitations become largely irrelevant. Therefore if you've been closely involved with a systems development it becomes harder to spot the 'weak' points, because you are acclimatised.

I also noted the suggestion that we perform some kind of usability testing. I do agree with this is the academic sense, but what I think we might struggle with is exactly how we define it.

Let me use my favourite anecdote for this. I've used VI since I started university. Many people I know very quickly picked up emacs, or some even more elaborate development environement largely because of the all to familiar ' VI is hard to use, difficult to remember etc...'

One could argue that VI has poor usability/interface. However, some 8 years after gradutating and with a weath of tools and applications at my disposal, I still, ferevntly, use VI. I still haven't comne across anything more 'usable'.

I do concur with Don also in that I don't see ANY relationship between OS software and usability. I think its much more to do with that fact that a lot of OS software is not production quality (nor does it try to be) and therefore its unfair to lump all of it together as is it were the same thing.

Perhaps my earlier point explains why people think Microsoft is the 'way computers work'. Just like me and VI, most people are exposed to this first, anbd therefore the get used to it. This makes it easier to use it, and therefore, good UI or not, its easy.. and therin lies the answer. Perhaps usability is nothing to do with an objective measurement, but rather the compatibility with a de-facto standard.

Of course the danger in that argument is that we should probably make OACS more 'windows-like' if we want a widely accepted UI.(?)

Hmmm....

Collapse
Posted by Jade Rubick on
There are objective metrics you can use to determine how effective an interface is. Choose the top ten most common tasks on your system, and measure how long it takes a newcomer to accomplish them. That's one.

Then change your system, and measure again.

You'll need a sample size that's decent, but that works.

You can also define "user errors", and count the number of user errors. For example, clicking on the wrong link might be considered a user error.

Watching newcomer use your system can be very enlightening.

HCI folks have developed methodologies for dealing with these problems; unfortunately, computer scientists aren't given these skills during our formal education. How many computer scientists do you know that had to design a program FOR A PERSON while in school? How many people do you know that had to actually design something for person and get feedback, and then work on it some more. Unfortunately, most of us learn this in the trenches, so we lack a theoretical framework for understand how to best approach these problems.

Collapse
Posted by Simon Carstensen on
Of course the danger in that argument is that we should probably make OACS more 'windows-like' if we want a widely accepted UI.(?)

Yes, that was exactly the point I was trying to extract from my "Microsoft Usability" vs "Usability" discussion. It's interesting. But perhaps it's wrong actually calling this usability when what's really at state is the fact that the Windows UI has turned into a de-facto standard and users won't distinguish between the Windows UI and the computer itself in the sense that the Windows UI has become the standard, it is how you work with computers. When exposed to an OS like Linux they won't react to the lack of usability (if such is present), but they'll tell you it's ugly. Something a long the lines of "this is not how computers are supposed to look, this is not the standard".

From a perspective of making a system (could be OpenACS) compatibility with its users it might make some sense, apart from working on the objective metrics of usability, to work towards the "compatibility with a de-facto standard" the Windows UI seems to represent. It is not a thought I enjoy, though, being 19-year-old ideologist (sigh :). But on the other hand, the users of the system being mostly highly educated developers, I don't see the need to strive towards compatibility with an OS most of us don't use anyway (for development).

Can we learn something from this discussion? Perhaps in terms of conventional webdesign vs current simplistic design. I frequently get users telling me that the simplisity of the OpenACS UI is boring, that this system looks old and outdated. I'm sure you've heard the same. It's not a discussion of usability, though, but of "compatibility with a de-facto standard".

On an entirely different note. Gatekeepers, and perhaps also Simon Millward, can the current community handle the added work load of starting up coordinated teams working on documentation and usability?

Collapse
Posted by Michael Feldstein on
A couple of thoughts...

Jade, although the usability testing methods you list are all
perfectly valid and effective, they require fairly extensive direct
observations of end users and thus are not well-suited to the
kind of distributed, volunteer development that goes on here.
Heuristic usability testing is probably more practical.

On the topic of "Windows usability," while the point that OS
companies often don't do the right thing is well-taken, the fact of
the matter is that an interface convention that is well-known to
users has usability value, even if the design itself is bad. People
don't have to learn the convention because they've already
learned it. And, of course, the goal of HCI design is to minimize
the amount of cognitive work the user has to do in order to utilize
the software. So, while we certainly don't have to be slaves to
desktop UI conventions, we can't afford to throw them out either.
(I don't think anybody here is necessarily suggesting that we can,
but I want to make the statement just to be perfectly clear about
it.)