DAHN Design Spec

This page specifies the design of the Dynamic, Adaptive Holon Navigator (DAHN) for the prototype.

DAHN Client Tech Stack

This iteration of DAHN will be implemented in TypeScript, using the Angular framework and the following additional components: <Thomas: please supply these>

Iterative Development

DAHN depends upon robust Metaspace and HolonSpace capabilities that don't yet exist. For now, we need to bootstrap some elements that will eventually be replaced by DAHN.

Nevertheless, the prototype offers the opportunity to begin to flesh out some DAHN elements:

• DAHN Visualizers -- DAHN specifies six types of visualizers: Canvas, Action, Node, Property, Graph and Collection. The wireframes for the Prototype suggest that the first four of these six types of visualizers will be needed. Therefore, initial (basic) implementations of Canvas, Action, Node and Property visualizers should be developed in the prototype.

• Design System. A minimalist design system based on Material 3 will be used for the prototype. A DesignSystem class will be used to store elements of the design system.

• Visualizer Object Model --

Presentation Tier Design Tradeoffs

• Favor working code over "reach" features. For the prototype, an overarching goal is to get something working as soon as possible. We will learn a ton about both the problem and solution options by just getting stuff working. Subsequent iterations can then incrementally add functionality. Of course, this means that periodic re-factoring of the code will be needed and is to be expected. That's OK.
• Dynamic Visualizer Selection. The core of the DAHN design is a visualizer selector function that dynamically selects visualizers at runtime. This is an essential capability that it is important to design carefully. So exploring this design space early will be valuable in guiding on-going design. However, the prototype will initially be built using a static set of visualizers. The intent is to support a very basic selector function (with simplistic, perhaps hard-coded, rules) for choosing visualizers.
• Explicit vs. Continuous Saves. Many commercial apps now support a continuous save feature that protects people against lost work resulting from forgetting to frequently hit the SAVE button. This is really effective at lessening frustration -- especially for apps supporting complex, open-ended work like text editing, graphical design, etc. However, the prototype use cases offer fairly small, discrete units of work (creating/updating a TypeDescriptor). Furthermore, supporting continuous save requires a fair amount of mechanism. And the prototype persistence mechanism (holochain) is not well suited to lots of small stores (e.g, after every keystroke). Therefore, the prototype design will adopt an explicit save approach. In other words, TypeDescriptor information will only be persisted when the human agent hits the Submit button following a series of edits.
• Undoable Commands. The ability to support undo/redo is an important usability feature that is relatively straightforward to implement if designed in from the outset. Therefore, the prototype will support undo/redo at a command level. Initially, the commands will be relatively coarse-grained. Finer-grained commands (supporting finer-grained undo) can be adopted later, if desired.
• Internationalization. Designing for internationalization is out of scope for the initial prototype.
• Accessibility. Designing for accessibility is out of scope for the initial prototype.
• Responsive Web Design. Responsive design is out of scope for the initial prototype.
• Material 3 Design is specified for DAHN and its use is preferred for the prototype. However, Material 3 components are not scheduled for release until late 2022, so Material 2 is the fall back.
• Web Components is specified for DAHN and its use is preferred for the prototype.
• Design Tokens -- are specified for DAHN and their use is preferred for the prototype.