What's Wrong With Today's UIs and What We Can Do to Help

(Last modified Sunday, April 9, 1995 @ 8:50PM PST)

Introducation

User Interfaces have come a long way since the days of punch cards. But there is still a long way to go. Today's User Interfaces do present people with more computing power than ever before, but bla bla bla....

What's Wrong With Today's UIs?

The user perspective

In most modern OSs, the user is presented with a system, wherein he/she is allowed to run various applications. While applications, and their linear nature, are perhaps easier to program for, their whole idea really puts a drag on the user's productivity and enjoyment of the system.

First of all, the human mind is non-linear, and the linear nature of applications goes against some natural (things). Well-designed applications, in a well-designed UI environment, can "fake" being non-linear, but this oftentimes requires all too much work by the programmer, and is still oftentimes not intuitive to the user.

Secondly, today's user interfaces are inconsistant. A command run in one application may have no relation to the same command in a different app. Even the way to run the same command in two different apps can vary widely (ie X windows).

Thirdly, to provide a halfway okay interface for an application, the programmer is forced to use abstraction, to hide the "real" system from the users. Such abstractions take much time to create, and also lead to inconsistancy. If the system had a more modular, non-linear nature from the start, such a degree of abstraction would not be necesary.

Finally, the large, clunky nature of applications make users dependent on developers to provide decent interfaces for their applications. There is nothing an "average" user can do to make an ugly program look better, or to make a small, productivity-enhancing change, unless the program's author has put in all-too-much effort to make his/her program customizable.

The programmer perspective

Current UIs are a pain to program for. Not only must the devloper concentrate on program logic, but he/she must also provide painstaking details to the interface. In a windowing system, for example, the programming cannot simply ask for the user to select one item from a list, but must instead display a window, draw each button seperately, and track their individual pressing.

Current UI APIs are monolithic, not broken down in smaller, more useful and replacable components.

Many OS/UI vendors, such as Apple Computer, provide rigerous standards for an application's look and feel to conform to, but provide little or no software assistance to developers for implimenting such standards.

Due to the non-OO nature of most UIs, a helpful (UI) subroutene developed in one application may require changes in the logic of another program, should this other program's developer wish to incorporate it.

How TUNES will be different

Concentrate on how users work with the system, not how the system can work with the user ("Ask not what you can do for your operating system, but what your operating system can do for you.")

Using = programming, just in a real-time sort of why. Users aren't stupid; they just don't have time to muck around with all the silly details of programming. For them, we should have easy-to-use scripting language, for intelligently automating stupid tasks.

Every component in the system--seen from both the user and programmer mindsets--should be replacable. This, done through object-orientation, will make replacing individual, outdated pieces of the OS as painless as possible.

To make different copies of Tunes compatible with one another, there will exist a set of standards that all Tunes systems should support in some way or another. Such standards should allow for IO of a number of different data types.

These standards should concentrate on specifying what should be done, and not how to do it. Instead of specifying the interface with which a user can input a certain data type, a program would ask the interface for a certain type, and it would input it in a user-selectable way.

The APIs will be modular, so that you can access and interface with only the parts that you need for a certain job.


webmaster@tunes.org | Last updated 2001/09/04 00:28:45 by dem | Changelog