Linked by Nicholas Blachford on Wed 11th Aug 2004 07:53 UTC
Editorial Computers are complex systems but it's a mistake to assume they need to be complex to use. However, usability is not as easy as it may first seem. It is a different discipline from software development lacking the strict logic or having a "right way". There are only differing requirements and differing collections of guidelines. Making things easy is difficult.
Permalink for comment
To read all comments associated with this story, please click here.
Re: John Nilsson (IP: ---.hg.hs.bonet.se)
by John Nilsson on Thu 12th Aug 2004 22:54 UTC

The file selector was perhaps not the best of examples since it's only really relevant to an application-centric UI. Consider, instead, the code that draws the UI components like buttons and scroll boxes - unless you want that code to be reimplemented by everyone who writes an "application", then it hsa to be in a shared library somewhere.

I have been thinking about this alot lately. What I think is needed is "One UI to rule them all". That is everything connected to user interaction is controlled by the same system component. Systemwide MVC in a sence.

Stric serive centred applications, like games, don't fit in this paradigm though... yet =)

In the case of file data acess.

1. The user requests acess to a file through the file manager.

2. The filemanager identifies the file type.

3. The default view component for the file type is loaded. In old system this would be an application. In this design it's only a rendering engine.

4. In many cases the default view component (ie, the gecko engine) is rahter generic and needs another data type (ie xhtml). The systems finds an apropriate transformer component that transforms the data into something the view can handle.


I can imagine handling everything as xml, or keep the everything is a file.

In the file paradigm the datafile would be transformed into a filesystem before the view comes into play.


What is all comes down to is small transformation centric components, and a system to connect them all.


Another example, a game of chess (to return to the file handler part): Instead of spawning a chess process through the menu a chess game file is created. When this file is acessed a UI component to handle that file is the view. Now there is no reason to save the game state, the system will handle this automaticly.