Forum OpenACS Q&A: Response to Open Source and Usability

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. "