The Tunes User Interface Subproject

(Last modified Saturday, February 18th, 1995 @ 4:00PM PST)

NOTICE

If you are accessing this page from the chharris/ui.html link, beware: this link will be removed in a few weeks! Please instead use http://weber.u.washington.edu/chharris/ui/

If that warning won't convince you, I just noticed that some of the links depend on using the "good" address, so it might be worth your while after all....


This page is a mess

This page is a real mess at the moment, due to my current juggling of how to organize things. If you have any suggestions, plesae let me know!


Project scope

The UI project is devoted towards changing the way individuals interact with their computers, so that it becomes a more productive and enjoyable experience. The scope of this project, then, is very broad. It includes such "traditional" UI topics as developing interfaces and abstractions to existing paradaigms, but also finding two paradiagms that are more user-friendly. Basically, this project is dedicated towards giving Tunes users the absolute best using experience possible with their availible hardware. (Every occurance here of user also applies to developer--we find no difference between the two.)

Project Members

Project coordinatior: Chris

Members:

Mailing List Archive

We now have a mailing list archive set up! To access it, click here.

Internal UI Developments

Have a very rough draft UI paper availible here.

External UI Devopments

Jecel (jecel@lsi.usp.br) has been working on an interesting interface for his Merlin project. For more information, click here.

Anyone know of any other links? I'm sure there's more out there, and this looks quite bare.


Items within these horizontal lines are in complete disarray; don't rely on them to save your life.

And the purpose is...

Welcome to the wonderful world of the TUNES UI subproject! Our purpose here is to create a (set of) intelligent user interface(s) that is (are) easy and powerful for the user, while at the same time reduce the amount of work required to develop application programs.

The way things are looking now, this is will be done through a clever seperation of mechanism and policy. Rather than having the application programmers specify the exact pixels at which the buttons in a dialog box should be displayed, for example, the programmer might ask the UI(s) to display the user with a set of options, and return one. Aside from being less work to program (making things easier to debug and faster to make), this also provides the user with a more coherant UI no matter what way they are accessing the system, be it textual, a 2d windowing system, a 3d world, or whatever.

These ideas were inspired by Fare. To see his original thoughts on the subject, click here.

Some of the goals include:

If you have any additions/subtractions/multipications/divisions, please let Chris know.

UI Current Events

We're still getting organized around here, so we don't have a formal agenda yet. Probably the most helpful thing at the moment is the begin considering the various input and output devices we may want to one day support, and what features they do or do not have in common. At the same time, we should be figuring what particular class of apps, if any, we are catering to, and what features these programs most commonly need. To see a very basic document about this (I'm sure its related somehow), click here.


Click here to return to the Tunes home page.
Page maintainer:
Chris -- chharris@u.washington.edu