the user can resolve the conflicts). As WebGME supports multiple custom visual editors for nodes in the model, collaboration in this environment can have the unique property of occurring between different editors operating on the same data. Collaborating users can be working on a project in which the content may actually appear differently within their respective editors (although the underlying project data is the same).
SLIM provides an alternative, simple approach to collaborative modeling [129, 5]. Un- like the previous approaches, SLIM avoids resolving conflicts by ensuring that they cannot happen by locking parts of the model that are already being edited by another user. This simple technique guarantees that there will not be any conflicting actions. It cannot be used when collaborating with offline models (as in [38]). Unlike the other approaches, this enables users to collaborate on separate parts of large models but ensures no conflicts by prohibiting collaboration on the same parts of models. This approach certainly will be effective when the models are large and there are fewer users (and the users are working on disjoint parts of the model). This will not allow users to collaborate on the same parts of any models as allowed by the other approaches to collaboration in visual programming environments.
can easily discover the behavior of blocks; clicking on a block will execute it. Running scripts can also be edited and modified during execution. Although the liveness of this environment is unconventional, it provides immediate feedback for novice programmers and promotes the potential for exploratory learning.
Although a lively programming environment can promote learning, it introduces com- plexities when synchronizing the project content. As it is always running, there is not a clear distinction between the project content and output as is present in many other en- vironments. Specifically, the program output is constantly evolving due to both program execution and user interaction. Consequently, synchronizing only the project code will not guarantee that both users will have the same program behavior or output, which may be somewhat counterintuitive.
Figure 69: Block Execution in Lively Environment
Figure 69 shows a script which moves a sprite in a circle indefinitely. The faint highlight around the blocks indicates that the script is currently executing. In a lively environment, these blocks are still editable during execution. This allows the user to make modifications such as increasing the input to theturnblock and immediately he/she will see the effects of the given modification. The user could also modify the execution by dragging the given sprite to another location during execution (although this may be difficult if the sprite is moving quickly). Stopping the execution will stop all executing scripts but there is no concept of an initial state to which the project execution state can be restored. Furthermore, stopping the execution does not prevent scripts from responding to future events or user actions; it simply terminates all currently executing scripts.
Networking support in a lively environment introduces another dimension of complexity with respect to collaboration. When the entire program execution is restricted to a sin- gle device, the program execution has virtually no side effects on external applications nor dependencies on other applications. This is not the case when building a distributed ap- plication. As the program may be sending and receiving messages from other clients, the execution of a single program can impact the behavior of other executing programs.
As lively environments are always in a state of execution, collaboration results in multiple instances of the given project being executed simultaneously. When collaboratively editing a Role in a distributed application, this can be particularly problematic as it will result in the execution of multiple instances of the same Role. As the distributed application was likely not designed to support multiple instances of the given Role, this will likely lead to unexpected behavior.
Figure 70: Collaboration in a Distributed Application
An example of unexpected side effects when executing multiple instances of the same Role is provided in Figure 70. In this example, the users are developing a Tic-Tac-Toe game with two Roles: “X” and “O.” Suppose that each Role alternates in waiting for the given user to make a move and then the Role sends the “move” message to the other Role. When a Role receives the “move” message, it will record the move and update the game board accordingly.
Although this approach will be effective generally, it will not behave as expected if there are duplicates of at least one of the Roles. Currently, “X” is occupied by a user named
“brian.” Two users, “steve” and “john,” are collaboratively working on the second Role,
“O.” As the environment is lively, this means that there are actually three running Roles in this distributed application (one Role is running for each user). The application will no longer behave as expected. Suppose the “X” Role moves first. “X” will play locally and send the “move” message to the “O” Role. As “john” and “steve” are both occupying the “O”
Role, they will both receive the “move” message and each will individually play in response.
However, this will result in two (potentially conflicting) “move” messages being sent back to the “X” Role.
Under these circumstances, the other Roles in the Room no longer behave as expected.
Multiple Role instances only exist when users are collaborating. Programming a distributed application to be robust to the side effects of collaboration should not be a design consider- ation for the novice programmers developing these applications.
4.2.2 Technical Challenges
Visual programming also presents its own technical challenges as it is fundamentally different from textual programming. These environments have a different underlying data structure. Whereas text can be represented as a “growable array” [74], each script in a blocks- based programming environment is a tree. This provides a unique challenge for collaboration as this data structure is more complex and some more recent approaches to collaborative editing have been shown not to be applicable for this type of structure [72].
Supporting collaborative editing in a tree data structure is quite complex as the elements in the data structure are not independent of one another. The data structure is a directed acyclic graph with the global constraint that each node can only have one parent. Addi- tionally, in a block environment, the blocks can only be placed in an input slot of another.
This corresponds to an underlying tree data structure where the input blocks are the child nodes of the containing block. Unlike most tree data structures, the nodes in the tree have a fixed number of uniquely named edges to their children as a block’s inputs are unique and can only be occupied by a single block at any given time. These uniquely named edges can only be occupied by a single block at a time and introduces yet another constraint on the underlying data structure and further complicating concurrent editing.