Plenary Session Summary

PORTING

• Short-term:
  1. Rensselaer Polytechnic Institute to set up an AsTeR server for use in a remote client-server arrangement with emacs interface.

     COMMENT: this is probably the most exciting proposal that emerged over the two-day symposium. It is concrete and therefore implementable. It can show results in the short-term, but also has considerable potential in evolving into a client-server talking library system over the long-term.

     I see the following challenges:

     • Design and implement the server: Will require some work to build a server front-end that can interface with AsTeR ---this should be easy. The server should eventually be able to serve documents as well as format a document supplied by a client. This means that server will eventually end up looking like a library front-end. This could be a challenging research problem.
     • Client side: The easiest thing to get off the ground is a client that assumes the user has a dedicated Dectalk-like device for speaking the audio-formatted text, i.e., if the user also wishes to use a screen-reading program, such a screen-reader will speak through a separate synthesizer. This constraint will make the design of the initial set of clients feasible in the short-term, and allow us to demonstrate proof of concept.
  2. Oregan State University porting AsTeR. Begin working on porting ASTER to another version of LISP.

     COMMENT: AsTeR is currently implemented in Lucid Common-Lisp and CLOS. Porting to other lisps, especially a public-domain lisp will allow AsTeR to be ported to multiple platforms, including PC's. We envision AsTeR running on a PC running a version of UNIX, e.g. LINUX, along with a version of lisp-clos.

     Other options include:

     • Schemetoc: Will require porting AsTeR to Scheme. This would require considerable effort, but the result would be equivalent to having ported AsTeR to C, something which would have required far more effort.
     • CLICC: Common Lisp to CC. This is a public-domain lisp-clos to C convertor. It's available on the internet, and according to the documentation is capable of translating lisp-clos programs to C. The resulting C code can be compiled on any machine.
  3. Mid-term: Create an on-line manual for use and extensions of ASTER.

     COMMENT: I think this needs to go in with the short-term goal. At present the only documents describing AsTeR are my thesis (which is comprehensive) and my conference publications. A user-manual should be derivable from the thesis which is itself written in LaTeX.

  4. Long-term: Port to language independent of LISP and UNIX, preferably C or C++ language.

     COMMENT:Yes, a long-term goal. Unfortunately, it could take a long time.

The bit about RFB setting up an AsTeR workstation to record books or journal articles is missing in the comments section. I think it is something that should definitely be done in the short-term in order to give us all more experience in using AsTeR.

USER INTERFACE

Comment: I have one global comment for this entire section, which also expresses my most serious concern. Both at the symposium, and now as I read the executive summary, it was/is unclear as to what the interface we were designing would interface to. Is it AsTeR as it stands? Is it something that will follow AsTeR? Is it something radically different, and if so, who is going to build this radically different beast whose interface we are designing?

I agree fully with everything that has been set forth as desirable in this section. However, very little has been said on how these goals will be achieved. What we have defined below is the holy-grail of user-interfaces, something that every computer company would love to have, but does not know how to build.

1. User interface should be consistent across all platforms. The control and navigation of the user interface should be simple and easy. COMMENT: See above. 1.1 The development of the user interface should follow a set of guiding principles, such as those developed by Dr. Abraham Nemeth for the Nemeth Braille Code. COMMENT: See above. 1.2 User interface should include a complete suite of features that are found in modern on-line search and retrieval systems, including sophisticated search, navigation, placemark and notetaking capabilities. COMMENT: See above 2. Output modality should include but not be limited to formatted audio, text to speech, non speech audio, graphics (sound graph), scalable large character display, hard copy output (Braille and print), and refreshable Braille. This should remain open and extensible for further modalities. COMMENT: See above 3. Interface should facilitate communication between people without regard to disability, for example enabling simultaneous use by a student and a teacher. COMMENT: See above 4. Interface should be interactive (read, write and edit). Input should be supported from keyboard, and alternative adaptive equipment, e.g., 6 and 8 dot Braille input, etc. These input devices should also be usable for navigation. COMMENT: See above 5. Undertake the development of a Braille output module that will interact with the ASTER front end. COMMENT: See above 6. Research the techniques for synchronizing the focus of the currently presented object in various output modalities. COMMENT: See above

DATA STRUCTURE

1. Write guidelines for providing the semantics behind the LaTeX macros. COMMENT: A good reference is the final section of the chapter on recognizing document structure in my thesis.
2. To determine its strengths/weaknesses, experiment with the ISO 12083 math fragment as an input to ASTER. COMMENT: I'm waiting on this. As soon as I get a sample, either a latex document generated directly from a document encoded using ISO 12083, or something equivalent, I can run AsTeR on it.
3. Educate publishers and other content-providers about the need for well-structured files. COMMENT: A very worthy goal, and a suggestion that I fully concurr with. Process documents and send taped ASTER renderings to the provider for review. COMMENT: Yes.
4. Create a qualification test to determine usability of structured document files. COMMENT: Yes. We should be able to do this once we have an AsTeR machine set up at RFB. 4.1 Determine the test's suitability for use by other organizations. COMMENT: I'm unclear as to what this means.
5. Work with ISO 12083 committees on the semantic additions to 12083 and user defined semantic constructs. We need to participate in those extensions. COMMENT: Do this within the framework of ICAD and HTML+.

GENERAL RECOMMENDATIONS

1. Develop, disseminate and maintain a resource list of products, components and research efforts currently underway. COMMENT: Good idea. Let's go do it.
2. Encourage the development of an accessible graphical calculator. COMMENT: Find someone to do it, and get it done (if we have the resources).

   Conference Feedback Form

   Physical arrangements How were the hotel accommodations ? COMMENT: Very Good. What can be done to make the hotel accommodations better? COMMENT: Would help if the hotel rooms had Braille on the door. Also, a more efficient voice-mail system, and a setup where the phone gives an audible indication of voice-mail messages. How was transportation from the hotel to the meeting site? COMMENT:Very Good. How can we improve transportation from the hotel to the meeting site? COMMENT: No suggestions. Was the conference room satisfactory? COMMENT: Yes. What can we do to improve the conference room? COMMENT: None. Please comment on the catered lunches at the meeting. COMMENT: Good. Please comment on the reception cuisine. COMMENT: Good. Please comment on InterNet availability and telephone access provided during the conference. COMMENT: Perhaps we could have a couple of talking computers setup and connected to the Internet? Is there anything that the staff could have done to better assist you? COMMENT: The staff were wonderful throughout the conference. Conference Organization Were the goals of the conference clearly defined? COMMENT: Yes. We owe the success of the conference to this fact. Was the meeting agenda in keeping with the goals of the conference? COMMENT:Yes. Was the open, flexible structure of this conference conducive to a working meeting? COMMENT: Considering how much we achieved, the question is redundant. Was there adequate time for discussion in the break out sessions? COMMENT: Yes. Were the break out group recommendations captured and documented sufficiently? COMMENT:Yes. Was there adequate time for collective discussion of break out group findings? COMMENT: Yes. Were the collective recommendations captured and documented sufficiently? COMMENT: Yes. Was the length of the conference (in days) adequate? COMMENT: Yes. In the future should the conference be kept small by inviting only working group participants? COMMENT:Yes. What benefits can be gained by inviting non-working group participants? COMMENT:Nothing much, other than adding to the signal-to-noise ratio. In the future, would you advise a two day conference? COMMENT: Yes. What can we do in the future to improve the conference? COMMENT: No suggestions at present.

   ---

   raman@crl.dec.com
   Last modified: Wed Jun 1 15:14:09 1994