Picking views are invisible graphical objects overlaid on visible ones, but that still react to user events. The first figure shows the “display view” of a hierarchical menu (top left) and the corresponding picking view when the user is navigating in the menu (top right). The (transient) triangle laid over the menu in the picking view enables reaching the sub-menu entries while avoiding submenu folding. Similarly, the picking view of the scrollbar displays as many shapes as spatial modes (thumb, arrows and spaces between thumb and arrows). In the examples, picking views are displayed with unique color. This enables to use a pick-by-color algorithm to to retrieve the corresponding Controller with an associative array.
Picking views have two benefits. First, they help manage the dynamic of the states of the interaction (e.g. the transient triangle), as opposed to the graphical state of the display. Second, they enable to avoid analytical computation of spatial relationships (e.g. the movement with a direction below 45°, or the position of a click with respect to the thumb) by using Enter/Leave events generated by the underlying graphical toolkit. Picking views actually reify spatial modes of interaction. A spatial mode is the spatial equivalent of a temporal mode: different behavior in function of space, versus different behavior in function of time.
Graphical transformations are functions that transform the conceptual model into graphics. MDPC uses two graphical transformations: one for the display view and one for the picking view. Fig. 3 shows the affine transforms applied to the model of a horizontal scrollbar (two values between 0 and 1) to generate the display view and the picking view. Computing the inverse transformations enables translating a graphical interaction (say a drag of the thumb) into operations on the model (translation of values).
There have been multiple attempts to improve modularity by using an appropriate architecture. In particular, the application of the separation of concerns principle on interactive code led independently to PAC [5] and MVC [2]. In retrospect, we can analyze PAC, MVC and MDPC as a distribution, to a set of components, of five concerns: management of the data state, display of the view, picking, translation of user actions into operations on the data state and the management of the interactive state. PAC and MVC explicitly deal with the first two concerns, but did not identify or address the last three (the “rest”).
The Model component from MVC and MPDC, and the Abstraction component from PAC all deal with data state.
PAC did not try to separate display, picking and translation since they seem to be so tied. A compound Presentation component is in charge of those concerns, leaving interactive state to the Controller.
The View component of MVC deals with display, leaving the Controller in charge of picking, translation, and interactive state. This makes it difficult to actually decouple the Controller and the View:
"The first Swing prototype followed a traditional MVC
separation in which each component had a separate model object and delegated its
look-and-feel implementation to separate view and controller objects. [...] We
quickly discovered that this split didn't work well in practical terms because
the view and controller parts of a component required a tight coupling (for
example, it was very difficult to write a generic controller that didn't know
specifics about the view). So we collapsed these two entities into a single UI
(user-interface) object."
Java Swing Designers, http://java.
sun.com/products/jfc/tsc/articles/architecture/, retrieved 2011-09-22.
Often, the resulting code actually mixes V and C (V+C) and fails to fulfill the modularity objective. The V+C component is almost the addition of the P and C components of PAC, which means that developers pretending to architecture with MVC are actually using a bad PAC decomposition (this is especially true with Web-like architecture: the browser is a P).
MDPC reifies each concern into a component. The Display view
component is the graphical transformation and deals with display, the Picking view deals with picking, the
inverse transformations deal with translation, and the Controller deals with
interactive state.
This makes the Controller code much simpler (the same as PAC) and almost eliminates the
apparent impossibility to decouple the Controller and the View.
It also makes Views and Controllers invariant from geometrical and layout
transforms. This also improves modularity since the Controller can be made more
general and reusable. For example, the same Controller can be used for various
species of scrollbar (e.g. arrows at both ends, at one end, at the thumb ends;
horizontal, vertical and radial layout). Finally, it can facilitate specifying
and implementing graphical interaction [3].
Note: PAC also applies a separation of concerns with a hierarchy to decompose even further the code. This is not discussed here: we only discuss a leaf of a PAC hierarchy.
In [4], Dragicevic & Fekete introduce the MVzmC architecture. They notably introduce "zones", which correspond to the picking area in the picking view. Though they recognize that zones can change dynamically, they did not show how far they can change. Hence they did not use their architecture to implement layout-independent interaction, transient picking views such as menus and even scrollbars, or non-widget related interaction such as drag and drop and guidelines. Furthermore, they did not try to make their Vz use transforms and inverse transforms which are key to usability of programming (especially with complex interaction such as a calendar). They also did not discuss usability of specification and implementation.
D&F analysis of the MVC architecture make them split the Views in Zones (picking views in MDPC) and View-Model, which has no correspondance with an MDPC concept. Their analysis help them understand why the V and C were often tightly coupled. However their analysis is different from mine: I recognized that I was applying separation of concerns down to the controller, and I identified those concerns (managing state of interaction, inverse translation of events, picking). Picking is not discussed in D&F nor is managing the state of interaction.
Historical notes: I attended IHM99, but as far I can remember, this architecture did not come into my mind when I devised the MDPC architecture to implement model-driven widgets (though this might have happened inconsciously since the idea was "in the air"). Still, I acknowledge that the idea of splitting views into zones in order to gain modularity was first devised by Dragicevic & Fekete: Redde Caesari quae sunt Caesaris.
MDPC has been shown to make possible entirely “model-driven” implementation of scrollbars, sliders, range-sliders, hierarchical menus, drag and drop with hysteresis, magnetic guidelines and calendars [3].
See (and look at the code of) a running example of Google Calendar implemented with MDPC, javascript and HTML canvas.
MDPC has not been shown to be able to describe any graphical interaction. In some situations, scalability is a concern. Furthermore, devising a full transformation from data to graphics and its inverse can be a difficult task. For example, the code below (inverse) transforms a time into a wrapped calendar-like application.
function multiplex (sss) {
//multiplex:
// y for seconds,
// x for day (24x3600 on y),
// y for week (7 days on x),
// x for month (5 weeks on y),
// y for trimester (3 monthes on x),
// x for year (4 trimesters on y)
var x=0; var y=0;
// year
x=x+Math.floor(sss/(7*5*3*4));
x=x*3;
sss=sss%(7*5*3*4);
// trimester
y=y+Math.floor(sss/(7*5*3));
y=y*5;
sss=sss%(7*5*3);
// monthInTrimester
x=x+Math.floor(sss/(7*5));
x=x*7;
sss=sss%(7*5);
// week
y=y+Math.floor(sss/(7));
y=y*1;
sss=sss%(7);
// day
x=x+Math.floor(sss); sss=sss%(1);
return [x, y]; } |
function invmultiplex (x,y) {
//multiplex:
// y for seconds,
// x for day (24x3600 on y),
// y for week (7 days on x),
// x for month (5 weeks on y),
// y for trimester (3 monthes on x),
// x for year (4 trimesters on y)
var year = Math.floor(x/(7*3));
x=x%(7*3);
var month = Math.floor(x/(7));
x=x%Math.floor(7);
var day=Math.floor(x);
var trimester=Math.floor(y/(5)); y=y%(5);
var week = y;
var res = Math.floor(day+7*(week+5*(month+3*(trimester+4*year))));
return res; } |
