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.
Without any serious interest from users, progress on these fronts will be slow. Here are some new features we have in mind, however.
Button Copying, Killing, and Yanking
There is as yet no means of transferring explicit buttons among buffers. We realize this is an important need. Users should be able to manipulate text with embedded buttons in ordinary ways. With this feature, Hyperbole would store the button attributes as text properties within the buffers so that if a button is copied, its attributes follow. When a buffer is saved, the attributes also will be saved.
Koutliner View Mode
This will complement the Koutliner editing mode by using simple one character keys that normally insert characters to instead modify the view of a Koutline and to move around in it, for ease of study. Switching between view and edit modes will also be simple.
Direct Manipulation
Hyperbole is designed to let you rapidly navigate and manipulate large, distributed information spaces. Being able to directly manipulate entities in these spaces will accelerate understanding and production of new information. Already Hyperbole lets you drag buffers, windows, files, and directories and place them where you like. But there is much more that can be done to allow for higher-level browsing and information organization.
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.
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 multimedia
files.
Button data external to source file
Files can be displayed and Currently, attributes for
printed exactly as they look. a whole directory are
No special display formatting locked when any button
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). Nowadays you could just use a screen sharing program.