From: schluss@Athena.MIT.EDU
Message-Id: <9202201843.AA28322@e40-358-19.MIT.EDU>
To: lynne@Athena.MIT.EDU, webst@Athena.MIT.EDU, mtcasey@Athena.MIT.EDU,
        samalone@Athena.MIT.EDU, aspoerri@Athena.MIT.EDU, aybee@Athena.MIT.EDU,
        mory@Athena.MIT.EDU
Cc: schluss@Athena.MIT.EDU
Subject: notes on Applications Functionality meeting
Date: Thu, 20 Feb 92 13:43:35 EST

Following are some of the ideas discussed in the meeting regarding 
functionality for future Muse application.  The meeting was not 
attended by all interested parties and all ideas/issues are not fully 
flushed in this document ... thus, this is not a complete functionality 
spec.  Please let me know if there are other things to add or if you 
would like to meet so as to fully discuss other ideas you may have. 
By next Tuesday, I will have written these ideas in context instead of 
having them just listed as items.

					Evelyn

	************************************************

			FUNCTIONAL ISSUES
			------------------

MultiPlatform - should be able to run an application authored on a high 
end machine on another high end machine of different make or on a low end 
machine.

Graceful Degradation - since applications should be able to run on a 
variety of platforms geometry management and adjustment to different 
capablities and peripherals is necessary.

Authoring vs. Run Time versions of the Muse parser.

Two or more remote users should simultaneously be able to view the same 
Muse application and pass the control of the application to each other 
so that each user can show things to the others.

Ability to exchange data with other running processes: one vs two way 
communication. 	Should Muse include simple features for basic functionality?
		a) database
		b) 2-D, 3-D graphic package
		c) word processor
		d) spreadsheet
		e) simulation package
		f) MatLab, etc.

Support for cooperating Muse applications - for example a Muse editor should 
be able to interact with another Muse package.

Support for running a Muse application within a Muse application - for 
example, in the online documentation the user may want to copy and change a 
sample application and run it from within the documentation so as to try 
out options.

Compound data types vs Links - compound data types would be a way for creating 
a unit containing multiple medium which are tightly synchronized, such as 
video and sound coming from seperate sources.  The compound data types could 
be included in packages containing other elements and would function as one 
unit within the package rather than two (improving their synchronization).


Support for variable node granularity, i.e., Packages are big and expensive.  
We should be able to link to smaller units.  We need to determine what these 
smaller units will be.

Support for easy layering of data - each layer can stand independently, but 
you may want to see how these interact.  For example in the Dubos application,
there are 3 large categories of things which interact with the environment: 
Abiotic things(A), Biotic things(B), and Cultural things(C).  You may want 
to see each category seperately, but you may want to see how A and B 
interact, A and C, B and C, as well as A, B, and C.  Or another example, 
if you think of maps of a city at 100 year intervals.  Show one layer 
with all the buildings built beofre 1500.  Then overlay it with a map of 
all the buildings built between 1500 and 1600 in a different color.  
You now see all the buildings present before 1600 and can distinguish 
two periods.


Ability to save versions of applications, parts of applications and notes 
which can be "overlayed" at runtime (on network, CD-ROM).
		notes include: "post-it" text blurbs, highlights and graphic 
		notes and saved user-movements (see below) 

Saving user movements:
		a) create an active cursor which would save and recreate users 
			motion and clicks - automatic demonstrations for the 
			purpose of instructions, showing interactions to 
			illustrate bugs

Ability to design non-rectangular windows - by producing a pattern of clicks 
on a window you should be able to determine whether the pattern is 
transparent (allowing X events to happen on windows that are visible below 
the area) or of a different color. 

Some discussion took place on benefits of labeling packages to create sometype 
of structure or hierarchy - using text formatting as an example where sections 
of text can be labeled as chapter, section, sub-section, etc. Muse packages 
could find a labeling system to help structure material and facilitate 
communicating the structure to others.  This structure could also translate 
into a graphical representation of the components of an application.

Ability to incorporate data coming from multiple live streams - the data 
should not only be shown, but should have the ability to change the 
application's display.

Scrollbars and other output devices (e.g. dials, graphs) should be able to 
represent the value of EventScript variables as well as the value for a 
dimension's current position.

Better support for text:
		a) postscript display
		b) addressing by tag, sentence, paragraph, chapter and "images"
		c) determine which text format (e.g. italics) is selectable
		d) can use footnote like numbers to differentiate between 
			different usages of the same word - get a different 
			definition when select
		e) can include graphics, active displays (e.g. Muse packages) 
			as images

Graphics (including digitized still images and animation) -
 		a) importing data in standard data formats like TIFF, PICT, PCX
			BMP, PAINT and EPS.
		b) postScript data type for graphics as well
		c) image tagging = hotspots
			serves as a two way communication: sends message to 
			get more info and receives message to show tagged 
			image
		d) ability to highlight (use different colors), circle, input 
			text and draw arrows over all type of visual elements
			(text, graphics, video, windows); these could be used 
			as hotspots or for tagging purposes
		e) ability to select parts of a graphic image and save them 
			seperately for later manipulation


Better support for hypertext and hypermedia
		a) a new link data type
		b) lookup tables should ignore space before and after word(s) 
			and punctuation marks


Visual Effects:
		a) click on window to show path that a graphic, button, or 
			window should follow
		b) transitions - wipes, fades