abbott@aerospace.aero.org (Russell J. Abbott) (07/01/89)
The current focus of the Aerospace Computer Aided System Engineering & Integration (CASEI) project is on developing a new, user-friendly front end to computing environments. Our immediate goal is to build a prototype substitute for Unix shells on Suns and the Finder on Mac II's. I'm not sure that this is the place to discuss it, but I'd like to start a discussion of the kinds of things one would want in a up-to-date front end. The following provides an example of the sorts of things we are thinking of. In general, the new front end will be visual (like the Mac) and "object oriented." When one logs on, one's directory/folder structure will be displayed as a tree in a window. (Actually it will be an arbitrary directed graph. There is no requirement that it actually be tree structured.) Each node of the graph corresponds to one directory/folder. The name of the node, i.e., the directory/folder name, will be displayed, but files/objects stored at a node will not be. When a node is clicked, a sub-window will pop up displaying the contents of that node. The directory/folder graph will actually include all directories/folders in the system, and perhaps on the available(?) network. One can examine the entire file system (permissions permitting) by traversing the graph. Some of the leaves may be "intensional directories." An intensional directory is a directory whose contents are specified by an expression rather than by a set of pointers. (A Unix path expression e.g., ~/abc/de*fg, is a simple example of a expression that may be used to define intensional directories.) The range of possible expressions is yet to be defined. Most likely it will never be fully defined since there is no reason to prevent users from writing their own interpreters for directory expressions. One intended use of intensional directories is to allow a more flexible structuring mechanism for one's files. For example, when doing software development one may want a single directory to contain source code, object code, and documentation for a module. Yet, one may also want a single directory or directory structure that contains all the documentation for an entire system. Intensional directories facilitate this by letting one build multiple structures over a base structure -- more or less as one does with "views" in database systems. Another reason we are interested in intensional directories is that we want to build a service through which users can find out about programs, tools, models, etc. in their environment. It is not clear exactly what sort of information retrieval or database service will eventually be built, but whatever the service is, it will presumably have a query language. Expressions in that language will be acceptable as intensional directory expressions. We'd appreciate any comments, suggestions, or recommendations of other work to examine. Russ Abbott & Nick Lubofsky abbott@aerospace.aero.org lubofsky@aerospace.aero.org P.S. We have also started a mailing/discussion list of potential users of the system. To get on the list, write to: abbott@aerospace.aero.org. To send a message to the entire list, write to: casei@ses.aero.org.
lubofsky@aerospace.aero.org (Nick Lubofsky) (07/07/89)
CASEI (Computer-Aided Software Engineering and Integration) may not be
the best name for what we're doing here. I prefer to call the project
Front End.
I envision Front End as a tool that is sitting on a computer when an
arbitrary person walks up to it. I want it to be attractive, obvious,
and easy to use so that people that are afraid of computers can walk
up to it and use it (like the computer interfaces they have at some
malls.) This is seriously lacking in computer/user interfaces I have
seen.
However, an advanced computer user should be able to walk up to the
Front End and quickly get to where he wants to. Often a person is in
the middle of one or more sessions of programming environments. They
should be able to get right back into them. This part already exists
in computer/user interfaces.
Front End should have both. Also, both the beginning and the advanced
user should have an interface for finding something. This is what Russ
Abbott was talking about. Systems are cluttered with arbitrary folders
and directories sprawling about in arbitrary ways. A higher level of
organization would save some frustration.
An ideal scenario would be: A person with no prior knowledge of
computers needs to see a diagram or picture of something, say a
blueprint of a truck or airplane. He should be able to walk up to a
terminal, and using Front End with no outside help, either locate the
specific diagram, or perhaps find out that such a picture doesn't
exist on that system. He should easily be able to browse through
related things on the system, and find out about related things on
other systems.
Currently, we have begun creating a prototype in Smalltalk. I am not
convinced that Smalltalk is the best environment to develop in, but it
is somewhat portable system to system. Does anyone have any ideas on
that?
By the way, does anyone know if the name "Front End" is being used for
any piece of hardware or software?
____________________________________________________________________________
Nicholas Lubofsky | lubofsky@aerospace.aero.org | The Aerospace
(213) 336-5454 | {decvax,ihnp4}trwrb!aero!lubofsky | Corporation
VoiceMailbox 3064 | Life is precious, Love is so rare... | Los Angeles
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~shf@well.UUCP (Stuart H. Ferguson) (07/09/89)
(originally on comp.cog-eng) +-- lubofsky@aero.UUCP (Nick Lubofsky) writes: | I envision Front End as a tool that is sitting on a computer when an | arbitrary person walks up to it. I want it to be attractive, obvious, | and easy to use so that people that are afraid of computers can walk | up to it and use it (like the computer interfaces they have at some | malls.) This is seriously lacking in computer/user interfaces I have | seen. This sounds nice, but it doesn't seem like a sufficient design goal. I want all my systems to be easy to use and powerful, but what is it supposed to DO? It soulds a little like this system is meant to "do-anything," but do it in a good way. So what it is it then -- is it a UI toolkit, or a UIMS, or an operating system shell, or ... ? | Front End should have both. Also, both the beginning and the advanced | user should have an interface for finding something. Ah, but finding what? Would this be more like a browser or a database query tool? What you want to find can profoundly affect how you go about searching for it. | [...] Systems are cluttered with arbitrary folders | and directories sprawling about in arbitrary ways. A higher level of | organization would save some frustration. No doubt. A "file" is a an extremely poor mechanism for storing anything, since it needs to be labeled and stored in a known location in order to be retrieved. Just managing the keeping track of the files in a large computer project can easily become a full-time job, even on a home computer where you're the only one doing it. I would still argue though, that how you want to look at data depends on what data you're storing, and that you might want to look at the same data in many radically different ways. Could a single front end allow for them all in a useful way (not files) and still present a consistent interface to the user? | An ideal scenario would be: A person with no prior knowledge of | computers needs to see a diagram or picture of something, say a | blueprint of a truck or airplane. He should be able to walk up to a | terminal, and using Front End with no outside help, either locate the | specific diagram, or perhaps find out that such a picture doesn't | exist on that system. He should easily be able to browse through | related things on the system, and find out about related things on | other systems. Now this sounds like hypermedia. What you describe here are "hypergrams," "hypermaps," and, of course, "hypertext." If this is what you're refering to, then the scope is probably still too large to result in a concrete design. Hypermedia is more of a philosophy than a product. Xanadu appears to be the most ambitious hypermedia system so far, not because it has anything flashy to show, but because of the epic scale of the project. Xanadu is an information system designed to replace file-structured data storage altogether, rather treating a whole network as one giant mass of linked data. Turing the hypermedia concept into software is a really interesting problem. If that's what you're group is doing I'd be curious to hear more about your specific purpose, and how you plan to procede. | By the way, does anyone know if the name "Front End" is being used for | any piece of hardware or software? Xanadu's FEBE protocol stands for "Front-End Back-End," but I think it's more of a generic term than a specific piece of software. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
stewartw@warpdrive.UUCP (Stewart Winter) (07/21/89)
In article <54027@aerospace.AERO.ORG> lubofsky@aero.UUCP (Nick Lubofsky) writes: >Currently, we have begun creating a prototype in Smalltalk. I am not >convinced that Smalltalk is the best environment to develop in, but it >is somewhat portable system to system. Does anyone have any ideas on >that? The prototyping tools we have been using for a similar type of product (managing file systems and odbs) are: a) HyperCard b) Smalltalk (on a Mac) c) Actor (a smalltalk-like language running under MS-Windows) d) Prototyper (Macintosh) e) Bricklin Demo (PC) (for terminal based interfaces) None of these tools seems to do a great job ... all have strengths and weaknesses, but Hypercard seems to have the edge for a Quick-and-Dirty prototype. Stewart -- Stewart Winter Cognos Incorporated S-mail: P.O. Box 9707 VOICE: (613) 738-1338 x3830 FAX: (613) 738-0002 3755 Riverside Drive UUCP: uunet!cognos!stewartw Ottawa, Ontario "The bird for the day is .... crimson rosella." CANADA K1G 3Z4
strub@cogsci.ucsd.EDU (Hank Strub) (08/09/89)
You didn't mention what your user community will do with your front end, their training, etc. Visually representing one's directory may be a great approach. However, it might be inappropriate. Happy July 4th, Hank Strub UCSD Institute for Cognitive Science strub@cogsci.ucsd.edu