MUSIC Spces 0.0 [jjl1]
JJ Lay
csjjlay@knuth.mtsu.edu
Sat, 17 Apr 1993 22:46:04 -0500 (CDT)
Greeting MOOSErs!
I unfortunately could not clean up my specs before Friday as promised.
Who knew planning a wedding was so much work! In order to get some
feedback, I have mailed you my original specification in hopes to get
some ideas. this is by no means a rough draft. that would be
exagerating! Read over it and let me know how you feel. This is a week
old... Enjoy (I hope)
MUSIC
Multimedia USer InterFace
Copyright JJ Lay April 1993
REVISION 0.00
10 APRIL 1993
09:00 PM CST
Permission is given to use the ideas presented in this
document without prior permission from the author under the
condition that it is not for profit, monetary or otherwise.
I. INTRODUCTION
A. SCOPE AND PURPOSE
The following document will cover all aspects of a human-
computer interface, and is meant to serve as a definitive
guide for programmers. There are two reasons for this: all
programs using written for this interface will have a common
"look-and-feel" resulting in a smaller learning curve for
users. Secondly, development time for programs should be
drastically reduced becuase of the underlying assumptions
built into the interface.
B. OVERVIEW
The objective of this MUSIC (as it will be called from here
on) will be to provide an user interface that is easy to use
for both user and programmer. Historically, most interfaces
have been one or the other. For example, a text oriented
interface is easy to program but rather cumbersome for an
end-user. An advanced graphical environment such as
OSF/Motif is somewhat complex to program in, but is easier
for beginnners to learn based on my experience. There is
one exception - Microsoft Windows - which is difficult for
everyone to use.
There are two extremely important philosophies on which
MUSIC is built.
The first: The end-user is more concerned with getting a
job done and producing results. A computer is a tool. She
is not concerned with how the tool works, but with what it
produces. An example: a journalist wants to type his news
article. He doesn't want to worry about which word
processor to use or which looks the slickest. He wants his
article typed, formatted, and printed. The interface should
hide as much about the inner-workings of the program as
possible and make intelligent assumptions when needed. This
type of assumption could be a "document-oriented" approach
versus a "process-oriented approach." Contemporary
operating-systems makes the user worry about which program
to use, if the files will be compatible, etc. Who cares?
The second assumption: Certain end-users have specialized
needs. MUSIC will not be able to meet all users' needs.
Therefore the user should be able to replace those parts of
the interface with components that better meets his needs.
It should be "customizable to its atoms." Equivalent
components can be exchanged without any side-effects.
C. SYSTEM REQUIREMENTS AND CONSTRAINTS
The basic hardware requirements are as follows:
a 386DX operating at 33MHz with 2Mb of RAM and 80Mb of
external storage (the term hard disk was avoided because of
alternative media such as flopticals and network devices).
The video quality for a graphical interface (GUI) is
recommended to be a VGA monitor and adapter (640 x 480
resolution) with 1 Mb of RAM capable of 256 colors. Text
quality can be as poor as a text-only dumb terminal. Input
can come from a number of various devices. Currently,
keyboard and mouse are considered the main input channels.
MUSIC will have no such prejudice. It will be built
assuming anything can give input. The same will hold for
output.
II. INFORMATION DESCRIPTION
A. OVERVIEW
The user will have a variety of information which needs to
be processed. Therefore MUSIC should handle it all. Basic
input can take the form of keyboard commands, mouse motions
and clicks, and voice commands. Complex input can be in the
form of hand motions using a PowerGlove type device, video
and audio from a camcorder mounted on the monitor, or
thoughts from some unknown device. Other inputs not known
should also be handled. Similarly for output, standard
output is text on a screen, icons and graphics, audio in the
form of beeps, horns, and simulated voice. Full motion
video and audio or perhaps 3-D holographics. Information to
and from users will be shipped to processes through "ports."
B. SAMPLE APPLICATIONS
A simple example but one that can not be ignored is the user
with a word processor. A keytboard takes the information
and the output is produced on the screen or the printer.
Building on that, the user is stuck, so he clicks on help,
and window opens with a video complete with audio that
demonstrates the proper sequence to perform whatever task is
needed.
Assume the user is blind. Input comes via voice. The
computer generates responses with audio. No video or
keyboard is required.
The extreme example, virtual reality. The user uses a
helmet and suit that gives the user senses of "being there,"
and input is taken from the motions of his body. ("Look and
feel" takes on whole new meanings here.)
C. EXAMPLE INFORMATION
Information can come in all forms:
Audio
Video (camcorder)
Keyboard
Motion (mouse, joystick, body movement)
Text
Graphics
Physical Analog (temperatures, pressure)
Processes
D. REQUIREMENTS
Information has the nature that it can easily be converted
from one type to another. This will be the key to MUSIC.
Text can be easily converted to audio and vice versa.
Unfortunately, the same cannot be said for more complex
information types such as video amd other graphical forms.
This will be one of the limiting fasctors for now. Basic
types must be identified and will be termed "basics." The
following basics are proposed:
- text
- audio
- graphics (computer generated mainly)
- video
- motion
Keyboard input takes the form of text input. Mouse would
fall under motion. Camcored input could be a combination of
audio and video.
III. DEVELOPMENT
A. OVERVIEW
Before serious code can be written, the process of
converting basics to other basics must be developed. Once
this is completed, other work can begin. There is much
discussion going on as to which is better: a GUI or TUI
(text user interface). Both are. But as shown in previous
examples, so is an AUI (audio user interface) and so on.
Certain design criteria should be put down as to what the
interface will do with input once it is accepted from the
user and how it will deal with output from processes. From
here on out, to avoid the concept that the interface will
deal only with keyboard input and CRT output, the user will
be considered to "experience" the interface.
B. PORTS
Input and Output will travel through bi-directional PORTS.
It is a continuous stream of information that has a
beginning and an ending with no breaks inserted by the
system. PORTS can take both input and output, and it is up
to whatever is on the two ends to decide if they want
whatever is coming through. Examples of PORTS include: A
window on the screen which the user makes active and sends
her audio input to and receives results from the process on
the other end. A PORTS could be a virtual connection to
between a thermometer that gives a continuous reading of the
temperature anda process that monitors it. Or a PORTS could
be a connection between two or three processes. This
implies that some form of interprocess communication will
need to be developed early on.
C. PARTITIONING
At first glance, it appears that the interface will
extremely complex and bulky. By using object-oriented
programming and design and the concepts of modularity, this
interface could be oparting in very little time.
1. Concentrate on the text and motion basics. This will
give keyboard and mouse capability at the very minimum.
2. Concntrate on the graphics basic. This will give both
text and graphical outputs capability.
3. Build the basics manager. It will manage how basics are
given to the user and received from her.
3. Go back to 1 and start over until everything works
perfectly. Once we have the "simple" basics down, we should
be able to crank out the others in no time.
4. Fgure out how to convert between the various basics
developed thus far. This will give some insight into how
the others should work.
D. SAMPLE CODE
class BASIC {
private:
protected:
convert_to (BASIC)
public:
BASIC(initialization)
~BASIC()
INPUT(PORT)
OUTPUT(PORT)
}
class TEXT is a BASIC {
private:
BYTE *information
protected:
convert_to(BASIC) {
stuff to handle conversions
}
public:
TEXT(BYTE initial_strings)
~TEXT()
INPUT(PORT) {
get bytes until eof or whatever
and store them in information
}
OUTPUT(PORT) {
write the data to PORT
}
------
JJ LAY
------------------------------------------------------------------------
JJ LAY CENTER FOR HISTORIC PRESERVATION
COMPUTER SPECIALIST MIDDLE TENNESSEE STATE UNIVERSITY
csjjlay@mtsu.edu MTSU BOX 80
(615) 898-2658 Murfreesboro, TN 37132
------------------------------------------------------------------------
"Marriage is a noble institution... If you want to be institutionalized
the rest of your life!" -Dr. Paul Hutcheson, MTSU Computer Science Dept