Perspectives

Concur supports multiple model inputs feeding into one view:

This is convenient for a number of reasons:

• It supports division of responsibility in model code by enabling different parts of the code to maintain different models.

• It supports code reuse by enabling different applications to present different data items, all of which contribute to the view.

• It enables data pertaining to the application domain to be separated from data pertaining to the user interface. For example, the former might be the text of a document, while the latter might be the positions of scroll bars.

• It enables views to diverge among participants, where some but not all of the model inputs are shared.

The inputs feeding a particular view are typed, because the view needs to be able to understand the structure of the set of inputs and of each input individually in order to understand the data embodied therein. Type matching is performed by the infrastructure at run time, to ensure that only valid view computations are constructed.

One of the contributions of this work is to propose a variation of the Model- View-Controller[KP88] (MVC) paradigm, which I will name Model-Perspective-View- Controller (MPVC). This adaptation of MVC identifies a sub-class of models called

perspectives, which have the following characteristics3_:

• Perspectives may have arbitrary structure, but they are typically small and simple.

• Perspectives are not accessible to the model code of an application. That is, perspective values cannot directly affect application logic.

• Perspectives are, however, accessible to views. Any influence a perspective may have on a model will come via the view and controller.

• Views specify which perspectives they need, but they do not allocate their perspectives. This task is performed by the infrastructure.

• Since perspectives are associated with views rather than models, they tend to have a shorter lifetime than models. They are not persisted beyond the lifetime of the view definitions referencing them.

• Perspectives may have certain basic collaborative services provided by the in- frastructure, such as floor and access controls.

• Perspectives are shareable among multiple views, just as models are. However, if they are not being shared, they can optionally migrate to the host running the view code using them at the moment (i.e., the central master is not maintained, and the local replica becomes the master). If no view replicas referencing a perspective exist at some point in time (e.g. during a mobility transition), or if an unshared perspective becomes shared again, it migrates back to the central server. Perspective migration makes fast local interaction possible.

• Since perspectives are separate units of data that can be individually supplied to views as inputs, they represent units of coupling and divergence, where different users can either share or diverge on each perspective. The same is true for models, but they are less likely used as a unit of divergence independent of perspectives.

• Perspectives can be grouped so that they can be shared or diverge as a unit. This is useful, for example, for specifying whether a group of perspectives defining a user interface state are shared or not.

Taking this model/perspective distinction into account, Equation 4.7 becomes, for models M and perspectives π:

V =v(Mi|i∈ {1..n}, πj|j ∈ {1..m}) (4.8)

Perspectives are useful for implementing a broad range of single-user and collabo- rative capabilities. Some of these are listed in Section 3.4.3. Many other possibilities exist for the use of perspectives. These are only listed as representative examples.

In summary, perspectives help to separate application domain code from the user interface, promote collaboration unawareness in applications, enable a wide range of divergence among views of the same data, facilitate group awareness, support local feedback that can be shared as needed, and support tentative manipulation of model data.

Given this background on perspectives, it will be instructive to list and discuss examples of the kinds of divergence supported by Concur, and how these are related to changing the view function v and the representative model and perspective inputs

M and π, respectively. These examples are summarized in Table 4.1. Consider the following equation:

V0 =v0(M0, π0) (4.9)

This is the baseline equation, to which we will compare all possible combinations of differences in v, M, and π.

Now consider Equation 4.10:

Equation Examples and Comments

V =v(M, π) WYSIWIS. Model, perspective, and view function all shared.

V0 =v0(M, π) Digital and Analog Clocks. View functions (formats) diverge, but model (time) and perspective (time zone) do not.

V0 =v(M, π0)

Viewing the same geographical map independently. Model (map) and view function (format) are identical, perspectives (scroll bars and se- lections) diverge.

V0 =v(M0, π)

Scheduling an appointment with the same UI. View function (format) and perspectives (date & time selections) are shared, models (calendar entries) are not.

V0 =v0(M, π0) Spreadsheet and graph of same data. Model (data) is shared, view functions (format) and perspectives (scroll bars) are not.

V0 =v0(M0, π)

Scheduling an appointment with different UIs (e.g., Outlook vs. Any- Time). Perspectives (date & time selections) are shared, view functions (UIs) and models (calendar entries) are not.

V0 =v(M0, π0)

Code sharing of drawing editor with different drawings. View function (UI code) is shared, models (drawings) and perspectives (UI state) are not.

V0 =v0(M0, π0) No sharing. Completely different applications operating on different data with no perspectives to synchronize interaction.

This equation is identical to equation 4.9, so it represents WYSIWIS collaboration (Figure 4.6). That is, if both users share the same view function v and inputs M and

π, they will be sharing identical projections.

Figure 4.6: Same Model, Perspective, and View

Equation 4.11 represents sharing the same data (both model and perspective), where the view function computed on that data differs (Figure 4.7).

V1 =v1(M0, π0) (4.11)

In this illustration the time of day represents the model, while the time zone (Chapel Hill) represents the perspective. Another example of this type of divergence would be viewing strip plots of the same data with a shared horizontal scroll bar, but with different views of the data (bar chart and line graph).

The next equation (4.12) diverges in the perspective, but not in the model or view.

V1 =v0(M0, π1) (4.12)

This is illustrated in Figure 4.8, where the map (model) and the view function are shared, but the perspectives (scroll bars and selections) are not. This is a very common divergence scenario, other examples of which include viewing a 3D model from different viewpoints, maintaining separate UI state (e.g., menus), and viewing the same time via an analog clock from different time zones.

Figure 4.8: Same Model and View, Different Perspectives

Equation 4.13 represents an unusual scenario.

V1 =v0(M1, π0) (4.13)

In this case, the model differs while the view and perspective remain the same. Fig- ure 4.9 shows an example, where John and Kevin are looking at their own calendars (models) from the same perspective (date and selected time), in order to schedule a meeting together. Another example would be a quartet, where each of four musicians sees his own music (model) in a common format, and the point in time in the piece (perspective) is synchronized. A third example might be a card table, where the positions of the cards on the table are represented by perspectives, and the values of

the cards are represented by individual models for each user. In this way, cards a user should not be able to see can be represented by the model for the back of the card, so that the model data representing these cards is never sent to that user’s computer.

Figure 4.9: Same View and Perspective, Different Model

Equation 4.14 specifies that the model is shared, while the view and perspective differ.

This is a common way of viewing the same object in different formats, since per- spectives often make sense only with respect to a particular format. Figure 4.10 demonstrates this scenario in terms of stock data and a corresponding stock chart. Another example is to view the same time (model) from different time zones (per- spectives) via analog and digital clocks (views), respectively.

Figure 4.10: Same Model, Different Perspective and View

Like equation 4.13, equation 4.15 is unusual because the model diverges while other aspects are shared.

V1 =v1(M1, π0) (4.15)

In this case, the perspective is shared, but not the view. To envision this scenario, examine Figure 4.11, which is a variant of Figure 4.9 where John and Kevin use different view software (Outlook and AnyTime) to view their own data, but share the date and time selection in order to schedule a meeting.

The next scenario, Equation 4.16, is much more common.

Here, the model and perspective are different, but the view function is the same. There is really no sharing in this scenario except for code sharing of the view. This is illustrated in Figure 4.12, where two users are using the same drawing editor to edit different drawings.

The final equation (4.17) is extremely common, but uninteresting.

V1 =v1(M1, π1) (4.17)

In this case nothing, not even code, is shared. In Figure 4.13, the users are using different applications to view different data, and there are no shared perspectives for synchronization.

Figure 4.13: Different Model, Perspective, and View

This concludes our tour of divergence scenarios. Of course, there are infinite possibilities, since there can be multiple models M and perspectives π, which can be shared or not shared, independently.