[p2p-research] can design by committee work? (item for p2p blog)

[Michel Bauwens]

Dear Eric, thanks for your comments,

Chris, I tried to input this today, but the blog was not accessible, and I
will now be 4 days in a conference,

Could you put it in our blog with a little intro phrase:

"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 article:

* The Case For Open-Source Design: Can Design By Committee Work?
(
http://www.smashingmagazine.com/2010/09/01/the-case-for-open-source-design-can-design-by-committee-work/
)

is authored by Mushon Zer-Aviv.

Eric Hunting:


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.

Eric Hunting
erichunting at gmail.com



On Sep 1, 2010, at 10:36 PM, Michel Bauwens wrote:

> Interesting challenge to extending peer production / FLOSS to the
interface design world:
http://www.smashingmagazine.com/2010/09/01/the-case-for-open-source-design-can-design-by-committee-work/
>
> Any publishable comments on this for the p2p blog would be very welcome,
>
> Eric?
>
> Michel
>
> --
> P2P Foundation: http://p2pfoundation.net  - http://blog.p2pfoundation.net
>
> Connect: http://p2pfoundation.ning.com; Discuss:
http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org
>
> Updates: http://del.icio.us/mbauwens; http://friendfeed.com/mbauwens;
http://twitter.com/mbauwens; http://www.facebook.com/mbauwens
>
> Think tank: http://www.asianforesightinstitute.org/index.php/eng/The-AFI
>
>
>
>




-- 
P2P Foundation: http://p2pfoundation.net  - http://blog.p2pfoundation.net

Connect: http://p2pfoundation.ning.com; Discuss:
http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org

Updates: http://del.icio.us/mbauwens; http://friendfeed.com/mbauwens;
http://twitter.com/mbauwens; http://www.facebook.com/mbauwens

Think tank: http://www.asianforesightinstitute.org/index.php/eng/The-AFI
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20100906/32aa7006/attachment.html>