I. Definitions
   A. Distributed interaction occurs when an interface is being used 
      simultaneously at multiple sites
   B. Collaborative vs. Non-Collaborative Interaction
      1. Collaborative interaction: multiple users collaborating on a piece
         of work, such as a drawing, text document, or spreadsheet, or
         participating in a shared activity, such as a game
      2. Non-collaborative interaction: users performing separate, independent
         activities, such as shopping on an e-commerce site.
      3. Mixed: users may collaborate at certain times and interact 
         asynchronously at others. Social networking sites are good examples
         of mixed use.
II. Collaboration
   A. Types of collaboration
      1. Asynchronous: team members work at their own time with no tight
         coordination with others. Example includes email.
         a. Advantages
            i. Does not tie down resources while others are thinking, planning,
               or obtaining other information
            ii. Eliminates overhead of synchronizing people's schedules (e.g.,
                finding common free times for meetings)
      2. Synchronous: team members are engaged at the same time on the same
           work product (e.g., phone call).
         a. Advantages: 
            i. rapid exchange of information 
            ii. brain-storming
            iii. shared common understanding
         b. Disadvantages: waste some participants' time while others focus
            on topics that do not require certain participants' skill sets
     3. Message-based versus data-based
         a. Message-based: medium of communication is the message--data may be
            attached (email/instant messaging)
         b. Data-based: members view shared data--communications revolve about
            shared view of data (shared documents)
   B. Identity: Buddy lists and/or user names are used to identify participants
        and to limit access
   C. Access: Same issues as file protections
      1. Who gets to see what? For example, in a collaborative work environment
         everyone should probably see the same data objects. However in a game
         setting you may see different screens because of different locations
         in the game and also to prevent opponents from viewing privileged
      2. One solution is loosely based on Unix notion of individual, group,
         and world permissions. Different groups can be created for different
         viewing purposes. For example, lab staff might be one group for
         viewing network configurations while your team might be another group
         for viewing work documents. In a team game, your team might comprise
         a group.
      3. The unit of sharing will often be objects. Objects can be organized
         hierarchically just like file systems. For example, a game might have
         a game board, displays for personal items, like energy levels and
         possessions, and communication objects, for communication between
      4. One cautionary note: many hierarchical file systems confuse naive
         users because they might make a file accessible to all users but
         not realize that access is still blocked because a higher node in
         the tree has a more stringent set of access protections.
   D. Floor control: Determines who can modify an object in the interface
       (similar to a write permission)
      1. Often one person will be a moderator and grant floor control
      2. Many multi-user interfaces allow only one user to modify the interface
          at a time, but a finer-grained interface would allow different users
          to modify different objects. That would allow different groups to
          coalesce around different objects, effectively holding side-meetings.
   E. Snooping: It is often good to use a mechanism such as the Secure Socket
       Layer (SSL) to prevent snooping by outside parties.
   F. Awareness
      1. Need to alert other users to changes made by a person (e.g., the
         tracking tool in MS word)
      2. Change approval: In many applications, changes are not finalized 
         until others have considered them (e.g., source code control, 
         preparation of legislation, changes to a word document)
   G. Device consistency
      1. Different computers may have different configuration environments.
         For example two computers may have different versions of Java installed,
         or one may have OpenGL and another may not. As another example, one
         computer may use different font sizes, resulting in different 
         formatting of the data.
      2. Users might employ different devices. For example, one might have a
         laptop and one might have a handheld device.

Ways to distribute the interface in the MVC model (see Figure 17.3): Typically there is one server and many clients, although peer-to-peer computing is changing that model. We will focus only on server-based applications I. Pixel/Event distribution: operates at the screen level after the application does its work on the server A. How it Works 1. Every client sees exactly the same set of pixels--there is no customization 2. All events go to the server, which draws to its "windows" 3. Pixels are copied from the server's windows to the clients a. new pixels are copied via a paint image at location (x,y) command (this command allows updates to the client's frame buffer) b. pixels changed by scrolling or other non-pixel writing commands are copied from one rectangle to another on the client's machine (this command copies pixels from the client's frame buffer, thus saving network latency) B. Changes to the screen 1. Issues a. get the pixels from the frame buffer b. determine what has changed i. diffs of the entire frame buffer are slow if resolutions are high ii. window system can help by providing damaged regions. In this case no comparisons may be needed. The server simply ships the pixels in the damaged region to the clients c. shipping changes to clients at a rate comparable with network speeds i. one approach is to use a timer and update the screen at each specified time. This has two disadvantages. It could overwhelm the network if the network is busy, causing changes to queue up. It also may batch client changes, which may be undesirable. ii. the more common approach is to perform changes when an event occurs, or the client requests an update. If the network gets jammed, changes or requests are batched and a composite change is sent C. Race conditions: What to do if two clients start launching two different streams of events on two different objects. The interleaving of events could confuse the server. For example, user A presses a mouse button and starts dragging while user B jiggles the mouse. The mouse-changed events that come in will refer to different areas of the display and might confuse the server. Most pixel-based systems handle this problem by enforcing floor control with only one user at a time allowed to modify the application. D. Awareness: Often telepointers are provided so that users can see where each other is working on the screen. This can make it easier to see where updates are occurring. E. Advantages 1. Works with any application and developers of the application do not have to know it exists (this is how virtual ware systems can work) 2. Computers do not have to be compatible since they all show the same pixels (although depending on screen resolution, the application may appear larger on some screens than on others). F. Disadvantages 1. Computing changes to pixels can be compute-intensive. Moore's Law will probably eliminate this problem unless screen resolutions keep increasing as well, and there is probaby a limit to the eye's ability to comprehend increasing screen resolution. 2. Network traffic is pretty high and so users on low bandwidth connections may either see a back up in changes or else batched changes 3. Networking latency can be problematic since events must be shipped to the server and changes must be shipped back to the client. This can cause latency in operations like scrolling where the user expects immediate feedback. 4. Users must operate in lock step and cannot have breakout groups 5. Users cannot customize the application 6. It may be hard to use different devices or different forms of interaction II. Graphics package layers A. How it Works 1. Presentation calls, such as calls to the graphics object, are captured and sent to the graphics object on each client. 2. Input events are handled in the same manner as the pixel model B. Advantages 1. Reduces computational load of capture and analysis of pixel changes 2. Reduces network traffic because commands are being transmitted rather than blocks of pixels C. Disadvantages 1. Network latency is still an issue for operations like scrolling 2. Users operate in lock step 3. Users cannot customize the application 4. It may be hard to use different devices or different forms of interaction D. X-Windows is based on this model III. Programmable API A. How it Works 1. Downloads portion of the view and controller code to the client 2. Client can handle many interactive inputs locally without occurring network latency B. Past and Current Implementations 1. IBM 3270 smart terminal: Server sent a screenful of text and notified the terminal which text was editable. User could move among the changeable areas, edit text, hit an enter button, and the changes would be shipped back to the user. 2. Display list graphics: Before pixel-based models with frame buffers were used, displays used vector graphics and display lists. One early change that was made was to ship transformation matrices to the client and allow the client to compute the transformations on the display lists. As the mouse moved across the screen, the transformations could be used to compute simple feedback, such as rubber-banding. 3. NeWS: Used a Postscript drawing engine and added input event processing and windowing to handle simple input. However computers at the time were too slow to interactively render postscript so it was not widely used 4. WWW interaction a. uses static pages with formatting performed by html. links provide a primitive form of interactivity by allowing users to navigate among pages b. forms elements combined with CGI allow simple client-side editing in the spirit of the IBM 3270 smart terminal. Changes are shipped to the server, which generates dynamic pages that are shipped back to the user. This is a crude form of interactivity c. Java applets download Java code to the client and allow a good deal of feedback handling and some local computations (e.g., error-checking input) d. AJAX (Asynchornous JavaScript and XML) and Javascript provide a smaller, nimbler way of handling simple dynamic formatting of web page content. JavaScript can provide event-handlers for various HTML tags, especially form elements, and hence do simple client-side checks, such as error-checking. AJAX also allows for a portion of a page to be updated without having to reload the entire page IV. Model Semantics Distribution A. How it Works 1. Network is placed between the view/controller and the model. Client performs command immediately (optimistically) on its copy of the application and forwards a command object to the server. The server sends command objects to client models and the client models cannot tell whether the command objects come from the network (server) or their controller a. A command object is an object that encapsulates a procedure 2. Each client has a copy of the application and virtually all interaction takes place in the client. This has excellent local performance, but it requires installation of the application on all machines. It works well in collaborative applications where the users are likely to spend a great deal of time with the applicaition. It works less well in single-user applications, such as shopping on e-commerce sites, where the interaction may be more of a one time endeavor that does not warrant the downloading of the application or the time required to make sure that the configuration settings are correct B. Synchronization: How to deal with race conditions 1. Ignore it and let users deal with it. The premise is that they are cooperating so they can perform the synchronization. Requires a cooperative, rather than adversarial (e.g., game) setting 2. Use a collaboration server that manages the ordering of commands a. Every command received by the server is assigned a sequence number b. When a client performs a command it assigns that command the next sequence number and sends it to the server i. The command is retained in a history list in case the command is rejected ii. Need to save sequence number so that in case of rejection you can undo any commands that get optimistically performed after this command c. If server agrees that a received command's sequence number is the next one in order it: i. confirms the command to the client that created it ii. adds the command to its server history iii. distributes the command to the remaining clients iv. increments its sequence number d. If the server already has a command with that sequence number, it rejects the command and notifies the client of the rejection e. Client actions i. receipt of a confirmation: discard the command or save it for undo ii. receipt of a command object: execute and increment sequence number iii. rejection: undo all saved commands up to and including the command with the matching sequence number f. Advantage: can perform commands optimistically by having the model locally and thus reduce latency V. Data Layer Distribution A. How it Works 1. Have the clients change data rather than issuing lower-level commands. It has higher level operations than the model distribution B. Advantage: Can solve some synchronization issues associated with showing intermediate changes when two people trying to change the same piece of data C. Disadvantage: You still have to deal with race conditions, such as someone changing a piece of data and another person deleting it.