MUSIC [jjl1] [far29]

[Francois-Rene Rideau]

(consider my reply to [jjl2] as far28)
(BTW, about languages, if there is an isomorphism from code to
data that maps GOTO into pointers, why not use this isomorphism
to map all known methods that eliminate GOTO (that is, if I wasn't
mistaken, exceptions in loops and other structures) into methods
to elimnate pointers ? Why not map from one to the other (code/data)
everything we know in the first and don't currently have in the
other ? Have anyone got the paper where the isomorphism is exhibited ?)

(To jj: why do you use such format for your messages, moreover with
page feed characters ? It's not easy to quote, etc)

>>                                         MUSIC
>>                               Multimedia USer InterFace
>> 
>>                              Copyright JJ Lay April 1993
>> 
>>                                     REVISION 0.00
>>                                     10 APRIL 1993
>>                                     09:00 PM CST
>> 
>>             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.
 If it's possible, I'd like the interface to be the same for programmers
and users: programmers are only lower level users (again, see the HP28/48
calculators for the beginning of this concept).
 Moreover, we should not conveive independently the interface and what is
to be intefaced: the Mac and/or Windows offer a splendid interface; but
as it was not designed to be an interface to anything in particular, it
is found to be an interface to nothing at all. On the opposite, Unix
was conceived without interface; the most immediate interface (=text) was
thus choosen, then X-Window can do nothing to this and is not adapted to
any Unix utility.
 Finally, the interface should be generic, (as the HLL); that is, you
can build an interface to generic arrays; then, when you have an 'a
array object, the interface is immediately defined from the 'a interface
(which, if no interface is ever given by the programmer/user, will
ultimately be built from atomic types interface). Of course, there is
no reason to be only one type of interface to an object. Then, a given
object may have a default interface separate from its type default. This
leads to object comments: how should comments on an object should be
implemented ? This issue is important, as it links interface to language
and object implementation (=outer kernel).

>>             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.
Text interfaces are also cumbersome for the programmer; however, nobody
managed to build a graphical interface that satisfied programmers: none
had powerful enough expressibility, or else wasn't portable (/ported)
at all.
Text is good (=known symbols, etc);
plain, linear text is bad.
We can now have structured non-linear text.
Of course, for ultimate portability reasons, plain text can be used
as an intermediate coding for data exchange between foreign systems.

>>             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?
 Again, programmers ARE users; they use a language environment; and they
seldom are but programmers; for example, they can use mail utilities :-)

>>             The second assumption: Certain end-users have specialized
>>             needs.  MUSIC will not be able to meet all users' needs.
 It may, with genericity combined with modularity and late binding.

>>             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.
(THAT's modularity)(the user being able to do that is late binding)

>>             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.
 That may be requirements for the first implementation of it. But remember
we want to be PORTABLE.


>>             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."
 As other input devices that don't exist will appear, we have to be as
IO device independent as we can get. Let's not assume even the screen/keyboard
assumption until really necessary (however, this can be the DEFAULT assumption
for now)

[examples skipped with full agreements]
(I'd also like to thank Mr. Kahn at Borland for his user interfaces,
which are good examples, too -- however limited to subsystems, not a
full OS)



>> 							JJ LAY


	   ,
	Fare

P.S.: congratulations for your contribution !
P.P.S.: my phone company is happy: more than one hour from Brittany to
Paris answering my mail by minitel !