F. Future Work

This appendix is included for a number of reasons:

• to better allow you to assess whether to work with Hyperbole by providing sketches of possible additions:
• to direct further development effort towards known needs;
• and to acknowledge known weaknesses in the current system.

Note that due to a lack of volunteers to further develop Hyperbole, much of this work may not be done. So if you want to see these features, encourage qualified people to volunteer.

Button Copying, Killing, and Yanking

There is as yet no means of transferring explicit buttons among buffers. We realize this is a critical need. Users should be able to manipulate text with embedded buttons in ordinary ways. This will probably be implemented only for versions of Emacs 19 and higher. It will store the button attributes as text attributes within the buffers so that if a button is copied, its attributes follow. When a buffer is saved, the attributes also will be saved.

Trails

Trails are an extension to the basic history mechanism presently offered by Hyperbole. Trails will allow a user to capture, edit and store a specific sequence and set of views of information for later replay by other users. Conditional branching may also be supported.

Outliner View Mode

This will complement the outliner editing mode by using simple one character keys that normally insert characters to instead modify the view of an outline and to move around in it, for ease of study. Switching between view and edit modes will also be simple.

Storage of button data within button source files

The current design choice of storing buttons external to the source file was made under the assumption that people should be able to look at files that contain Hyperbole buttons with any standard editor or tool and not be bothered by the ugly button data (since they won't be able to utilize the buttons anyway, they don't need to see or have access to them).

In many contexts, embedding the button data within the source files may be a better choice, so a provision which would allow selection of either configuration may be added. Here are some of the PROs and CONs of both design choices:

POSITIVE NEGATIVE Button data in source file Documents can stand alone. All edit operators have Normal file operations apply. to account for file structure and hide Simplifies creation and internal components. facility expansion for structured and multi-media files. Button data external to source file Files can be displayed and Currently, bdata for printed exactly as they look. whole directory is No special display formatting locked when any bdata is necessary. entry is locked. Button-based searches and database-type lookup operations need only search one file per directory.

Forms-based Interfaces

This will allow one to create buttons more flexibly. For example, button attributes could be given in any order. Entry of long code sequences, quick note taking and cross-referencing would also be made easier.

Collaboration Support

From the early stages of Hyperbole design, collaborative work environments have been considered. A simple facility has demonstrated broadcast of button activations to a number of workstations on a local area network, so that one user can lead others around an information space, as during an online design review. (This facility was never adapted to the current Hyperbole release, however.) We shall do some work in specific collaborative mechanisms, but we also expect that others who concentrate in collaborative work will provide more extensive capabilities.

This document was generated by XEmacs shared group account on December, 19 2009 using texi2html 1.65.