GEM-NI and the MACE interface were implemented as a branch NodeBox 3. For convenience, I chose NodeBox 3 as a foundation because of the many provided features.
has been previously used for visualization and generative art [101]. This choice enables the potential use of my results in a wider spectrum of applications, compared to a tool more targeted at a single domain.
Unsurprisingly, NodeBox 3 was not designed with supporting alternatives in mind. The code follows, what Terry and Mynatt [106] refer to as, the single state document interaction model which recognizes and requires a document to be in one, and only one, state at any particular time. This is a poor match to the non-linear, experimental processes characteristic of creative endeavours [106]. To work around this limitation, I had to implement the features of GEM-NI and MACE in an intrusive manner, where I sometimes had to violate good software-engineering principles. E.g., each method that affects the state of the document had to be modified to push changes to all alternatives. This was further made worse by the fact that some alternatives may be idle. Global undo adds another layer of complexity. As a result, the implementation was not efficient. Because NodeBox 3 follows the single document state model, I also had to introduce UUIDs for the nodes to distinguish the states of nodes in different alternatives. In hindsight, this approach is only suitable for retrofitting into existing systems.
A better approach is to design the system from scratch by including support for alternatives from the start. One example of such an approach, currently work-in-progress, is the Shiro21 dataflow programming language designed to be embedded into applications that support reuse and the exploration of alternatives. The language provides designers with syntax to describe alternative designs or analysis solutions. In Shiro nodes can be subjunctive, i.e., exist in multiple states. This allows a cleaner implementation with less shared data. This approach should be considered by those re-implementing GEM-NI’s approach in their application domain.
NodeBox 3 utilizes the standard undo manager from javax.swing.undo. To enable undo history duplication, I created a custom undo manager, which supports duplication of the undo stack. This functionality is used when creating branches and alternatives from
history. To support global undo, I use another stack, which keeps track of every undoable operation that was done and the alternatives that were affected by this to enable me to identify potential undo conflicts and to clear the global undo stack if such a conflict occurs. This is a simplified implementation that may not handle all use cases. Yet, in the user studies, global undo was used only infrequently, also because participants did little parallel editing. Thus, I currently see little need for a more sophisticated global undo/redo-method in a system such as GEM-NI. The majority of the participants focussed on one design at a time, and if necessary, re-integrated ideas from previous work through merging. Thus, I believe that one area for future development in GEM-NI should focus on better methods for post-hoc merging, e.g., by coming up with visualizations that identify which parts of the merge could not be completed.
During the workshops some participants pointed out that GEM-NI’s interface is unintuitive with regards to parallel editing. In a future re-implementation parallel editing should be offered as an option rather than imposed on the user. Passive alternatives should appear only when desired explicitly by the user and not by default. This will leave merging as the main mechanism of pushing changes. To make the merging mechanism more versatile, future implementations should introduce the concept of a timeline and allow the user to merge the timeline of one alternative with that of one or more other(s). The history mechanism is currently limiting in that it only permits the creation of alternatives from history and not the merging of parts of history. Also history is based on undo and, as a result, the history of edits from earlier application sessions is not available, as the undo stack is currently not preserved during saving and re-opening.
Finally, there are limitations in NodeBox 3 that future implementations should address. One example is the inability to embed recursion into the data-flow programming model that is employed in NodeBox 3. As discussed in Section 4.5.5 this prevented me from taking full advantage of the GEM-NI’s comparison features when relating networks with recursive nodes to each other. Moreover, NodeBox contributors decided to abandon the support for the “tweaking” of existing nodes since version 3. In NodeBox 2, it was possible to directly
modify and display the python code, which stands behind each node in the system. Although I acknowledge that this may not be a feature that the majority of designers must have, I disagree that it was necessary to remove this feature from the latest version. Power users generally appreciate such a feature and use it to solve many interesting problems. In addition to that, I could have added in GEM-NI the ability to merge differences between different alternatives directly in python code. Then, I could also have augmented the MACE interface to perform difference visualization also on the code of the python-based nodes.