We asked our friend Eric Hunting to comment on the following article about the limitations of free software in terms of designing user-friendly interfaces:
* The Case For Open-Source Design: Can Design By Committee Work?
is authored by Mushon Zer-Aviv.
I found this article rather peculiar. Mushon Zer-Aviv seems to be writing from a shallow perspective on the nature of software design, user interface science/theory, and the actual history of Open Source development, making rather broad assertions that don’t relate to the reality known to those actually familiar with open software. It begins with a very broad assertion that a fundamental failing of open software is inadequate user interface design, suggesting that the cause for this is that coders have no ‘incentive’ to create adequate user interfaces when they only create software for themselves and their nerdy friends. While this might be true for some individuals and certain classes of software, on the face of it the suggestion is absurd. It may be correct that open software has lagged in pace of user interface development with commercial software. And there may be a number of reasons for this. For one, open software is more concerned with function than aesthetic because it doesn’t have to ‘sell’ product and preserve market shares. Much user interface design in commercial software is less concerned with ergonomics and productivity than with ‘branding’ a specific product and carving out market shares by controlling copyrighted/patented stylistic features. There is no practical reason OSX and Windows look and feel different. They are deliberately different. Open software often works with a lower tier of commodity hardware requiring leaner software for good performance. Anything that adds fat to code has often been seen as superfluous window-dressing coming at a cost in performance. Another contributing factor is cultural. Until recently, some in the Open Source community proscribed to the idea that graphical user interfacing was not a user-empowering technology but rather a deliberate dumbing-down of the computer for the sake of limiting user freedom, discouraging computer literacy, and compelling the planned obsolescence of hardware by progressive software bloat. Though this point of view is debatable, a dogmatic insistence on the use of command line interface and a resistance to unnecessary graphics was regarded by some as a form of protest against this trend.
But perhaps one of the key contributing factors is that, until the advent of ‘professional’ design applied to web development, there really hasn’t been much participation -or interest in participation- by the design community in software outside of the venue of game software. They simply did not see it as an area of design of relevance to them. Until recently, there haven’t been all that many designers who could be called fully computer literate, let alone technically knowledgeable enough -particularly in ergonomics- to engage in meaningful design at a development level. Most -if not all- of the successful basic visual metaphors common to graphic user interfaces today did not originate with professional designers but with computer scientists and a rare group of artistically talented programmers able to bridge that gap. Perhaps some designers may have encountered that noted cultural resistance to the idea of any practical need for their talents. But we see a similar trend in design in general. Today technical/science illustrators are in desperately short supply with even government space agencies relying on the continual recycling of 40 year old artwork for lack of available illustrators. Industrial designers now commonly design with a complete disregard for engineering plausibility -or even the basic laws of physics. Few have the most basic eduction in science and engineering fundamentals. These things don’t seem to matter to industrial design theory anymore -or the schools that teach it. Reality-checking has become someone else’s department. How many people in the design community really comprehend the basic principles of Open Source? The vast majority seem to stand firmly with the corporate community in their perceptions of intellectual property theory.
But the fact of the matter is that open software is now fully engaged in graphic user interface development and has done well with it. It’s still sometimes stylistically/aesthetically a little behind the curve but the gap is narrowing as, frankly, the commercial software industry itself really hasn’t made any significant breakthroughs in this area of design for a decade -and squandered more than a few potential ones. It’s really hard to make a sincere argument today that there is much more than a cosmetic difference in user interface efficacy between OS X, Windows, and Ubuntu. It may not often match the visual ‘slickness’ of commercial software but one would be hard pressed to point out where equivalent open software really is still more difficult for the average person to use and that graphic design is the reason for that. The Open Source software community now fully grasps that the mainstream is its audience. It’s not pandering to an exclusive tribe.
Zer-Aviv then goes on from this initial assertion to construct a rather weird model of communication/collaboration that seems intended to suggest that there is no way to reconcile a designer’s visual linguistic process to the software development process of coders. In essence, designers and programmers speak fundamentally different languages and thus can’t collaborate -and that suggestion is just plain ridiculous. He suggests that a graphic designer must develop an entirely new visual language from scratch for every project while programmers adopt languages based on personal preference but which are, in themselves, fully standardized and conformed to the limits of a computer. The fact of the matter is that designers do not reinvent the wheel for every project but are constrained in exactly the same ways programmers are; by technology, by the topology and ergonomics of media forms, by culture and its visual linguistic standards, by ‘industry standards’, and by personal preferences. This compels them to recycle many design methodologies and visual metaphors.
And that last word is particularly significant for its omission in this article. Metaphors are the essential basis of visual user interface design. They define the architecture of the environment upon which graphical design and code converge and define the parameters both must operate within. The core elements of a visual language of a user interface is largely pre-defined by this -sometimes right down to the acceptable color pallet. Programming no longer deals in the one-dimensional realm of teletype ASCII. All complex software now relates to screen environments based on visual metaphors that vary stylistically -if not always that much architecturally- from one computing platform to another. Even in old fashioned command line environments you have software creating a complex multi-modal two or more dimensional screen environment whenever the user interaction calls for more than simple command-response communication. So almost all programming, beyond the level of ‘black box’ code performing low level activity, is commonly dealing in a realm of graphics. Where has Zer-Aviv been since the personal computer was invented?
Default user interface metaphors are usually imposed upon software developers by a platform’s choice of operating system. In this way the computer imposes the very same ‘inflexible collaborator’ on the graphic designer that it imposes upon the coder. You can’t just draft any kind of visual structure you like and have it work. The designer must adopt and adapt to a pre-established visual/ergonomic architecture in the same way the coder must deal with a specific software architecture. In a large scale collaborative development effort, such metaphors are the basis of structured collaboration. The graphic user interface metaphor and the sets of elemental standard derived from that are to software’s visual design what a kernal is to operating system design. It is the core architecture all graphic development relates to. This should be more-or-less obvious to any designer who has some basic comprehension of visual design theory. Even every comic book artist gets this -they deal in very specific visual metaphors in that medium, and it’s why -at least until the comics industry shake-up of the 70s- writers and artists commonly collaborated on comics creation with the architecture of their basic visual metaphors defining the nature of that collaboration. (today it’s much less common than it was because of the cultural rift that emerged between writers and artists during the peak period of exploitation under the old comics publishing moguls. But it’s still common for the longer-running comic book series today to be collaborative projects as artists will routinely burn themselves out trying to do both alone)
One might argue that one of the reasons for the less-than-slick appearance of some open software relates to the lack of maturity of the graphic architectures of latecomer GUIs in open OSes and also the lack of hierarchically imposed ‘branded styles’ as we see with commercial OSes. No question, bottom-up evolution of an OS and its user interface is a messier process. Certainly, designers talents can contribute greatly to improving this and I suspect today this would be more welcome than it perhaps was in the past. I would suggest that the current state of things is less the product of any sort of fundamental flaw in the nature of open development or communication between coders and graphic designers than it is, quite simply, that independent programmers, amateurishly, still don’t often think about a need for graphic design until a project is nearly done and designers, as a community, haven’t been interested enough in the software field to bother to participate -if its even occurred to more than a few of them that it might be something relevant to them. This is a cultural rift, not a cognitive gap. It gets bridged -with not a little friction- in the commercial software world because marketing people have long understood the point of visual slickness in market value (open software development tends to start with programmers mulling over flow charts. Commercial software development tends to start with marketing people mulling over screen shots…) and the brute force of money will make most anyone collaborate.