OSNews

I value a consistent desktop. I value having a degree of consistency between the apps that I regularly use. To a large extent I achieve this by using software primarily written with one toolkit and carefully choosing themes. I occassionally do use programs written in another toolkit-and of course these application don't look like the rest of the applications on my desktop. But this in and of itself is not a problem.

The fact that an application uses a different widget set/toolkit does not, by itself, negatively impact usage. But each and every application provides an interface between itself and the 'system' underlying the desktop. These interfaces are: file open/save dialogues and print dialogues. If I was given the choice between having a desktop with apps where each app had it's own toolkit/widget set but each app made use of the same file save/open and print dialogues vs. a desktop full of apps where each app had the same 'LAF' but differing file save/open and print dialogues, I would always choose the former.

Where I work I have 300 users. I have never noticed them having problems with apps which look different from other apps. But there is no end to the difficulties which popup when users are confronted with 5 different interface dialogues. The spacing of icons, the justification of application text, the coloring of the widgets-all of these things pale in contrast to the difficulties surrounding differing interfaces to the 'system'.


Where I work we used to provide both xpdf and the older adobe acrobat reader 5.0. This in the context of gnome-2.8 desktop with mozilla and openoffice. As such my users were forced to come to terms with 5 different sets of interfaces and this was the source of so many errors and so much frustation on the part of my users. The actual applications themselves were not that problematic-the widgets sets/toolkits in use by these application were each quite different but the the users had little difficulty adjusting to differing fonts, colors, icons etc. The problems were all caused by these differing interfaces.

With the older adobe acrobat one was confronted with a file open/save dialogue which a) routinely opened up in the /tmp directory misleading users to store their documents in /tmp and users searching in vain for their pdf's in the /tmp directory b) routinely selected the mozilla cache file name for the pdf which was some ungodly long string of meaningless charachters. The result was mayhem.

Occassionally I would take a look inside /tmp and find that people had been storing their documents there not understanding that each time the server booted the contents of /tmp were being deleted. Then there was the issue of the print dialogue. This issue was compounded by the fact that not only do openoffice, mozilla, acroread and xpdf but also too many of the gnome-2.8 apps each have wildly different print dialogues with apparently contradictory and contra-intuitive options.

Moreover none of the applications actually did any printing-all they did was hand over the postscript output that they produced to cups which actually does the printing. And of course with the exception of those apps which made use of libgnomeprint none of these apps new that there was exactly one printer available for the users which only printed to A4 and only printed single-sided. But invariably applications would end up fighting over the paper size. My users would download random word documents from the web-most written in english by americans who use letter size paper. Invariably Openoffice would try to send a letter sized document to our Hewlett-Packard Laserjet 4 plus. This invariabley caused the printer to crash-because there was no letter sized paper.

All of these applications came with print dialogues which listed a plethora of options which were simply meaningless. We only have one printer. We only support one paper size. That printer doesn't do color and doesnt do duplex printing.

Ideally each application would use the same print dialogue and this print dialogue would query cups to find out a) how many printers are connected b) which options are supported by which printers and c) when a printer was selected only those options which were actually supported by the printer were available.

These issues are also at play when each multimedia application has to be configured differently to work with the same physival devices (alsa/dvd/cd etc.)

Consistency between applications and the system with which the applications interface is of paramount importance. Nothing else is as confusing to new users who don't understand the complexities of the system-and these interfaces should exist primarily to hide this complexity. How often do inexperienced users save files and then spend hours looking in vain for what they just saved ? And this is a real problem on all platforms I have worked with and is just incredibly discouraging. Each of my users has a Desktop directory and I worked hard to get programs to default sto saving to that directory so that when someone downloaded a file of saved a newly created document that they might actually have a chance of finding it.

I love GUI aethetics as much as the next person. I really like it when all of my appliations have similiar menu structure, the same button order in dialogues and other such issues. But this stuff pales in terms of relevancy and importance in contrast to the issues involved in the interfaces with the system.

How does this stuff relate to Java and/or the specifics of Javas' LAF's-simple, Java applications are all guilty of the same fundamental mistake of presenting my users with interfaces which compound their difficulties in performing the mundane taks of open and saving files and printing. I really don't care if they look nice or have nice eye candy or even if they are dogged slow -I worry will my users be able to carry out their mundane tasks without getting lost, sidetracked or defeated by interface inconcsitency.