Stephen W. Draper
GIST (Glasgow Interactive Systems cenTre)
University of Glasgow
Glasgow G12 8QQ U.K.
Antonio's approach corresponds to (5), and could be described as much more user centered than most other approaches. Traditional database work used tables to visualise all data whatsoever, which is "general" but ignores everything about the data and everything about the user. Our own Iconographer work allowed the user to choose the visualisation, but otherwise is in the old "general" approach. Most work on automatic generation of visualisations beginning with Mackinlay (and also present in Iconographer) selects visualisations based on properties of data types. This means it takes notice of the metadata, but not of the collection (e.g. how much data there is in the database or in each relation), and not of the particular query. Which approach is right?
We know that an enormous amount of programming time in applied database work is in fact spent in customising general database software to particular applications, and that much of this is spent in designing "forms": both the standard queries that will be used in that application AND the screen layout that will be used in presenting the results of that query. This is strong evidence that all the generality of the underlying DBMS does not help real users, and all has to be undone and made specific by other programmers in order to produce the software that is actually used in most applications. This might be evidence in favour of a query-centered approach to visualisations, which would then not have to be hand-written as it often is now. On the other hand, as someone said in discussion, query-specific visualisations may confuse the user because if they modify the query slightly the visualisation may totally change. However a slight change in a query may cause an enormous change to the size of the set returned, and few visualisations (whether a text list, a set of icons, or some virtual reality display) can really be the same from the user's point of view when they change from showing 6 items to 600 items. In most cases, suddenly the display changes in some way to do scrolling with most items off screen most of the time. Thus in reality, all approaches probably change the display in ways important to its usability when the query changes.
Another striking feature of Antonio's approach is that, as he revealed in
answer to a question, his software may introduce an extra layer of structure
into the display of the reply if the returned set is too large for the
visualisation (e.g. too big to display as doors along a single corridor). This
is comparable to what scrolling does: just as a printed book divides the text
into pages and then into lines that are usable subdivisions of the material but
do not correspond to meaningful structural subdivisions, so scrolling divides
screen displays. We are thus used in both books and computer screens to having
two independent hierarchies of structure: the hierarchy of the material (e.g.
chapters and sections and paragraphs) and the hierarchy of the display medium
(e.g. lines and pages). Antonio's approach merges these two, using a single
decision or design process for both. This sounds obviously better in
principle: or is it really better to leave the user with the independent local
controls that scrolling give?