The VisTG Reference model consists of a series of feedback loops that connect the user and the functional elements within the computer. Each loop is concerned with information at a different kind of level of abstraction.
|
| Fig x.1 The VisTG Reference Model in its canonical form. The "Understanding/Acting–dataspace" Loop is supported through the "Visualising–Engines" loop, which in turn is supported through the input and output devices (the I/O loop). Each of these canonical loops can represent several individual functional feedback loops in any practical system. |
The outer loop connects the dataspace within the computer with the human's ability to understand and act on those data. For the human, understanding or acting on the dataspace in the computer is often only an aspect of dealing with a real-world situation, some aspect of which is represented in that dataspace.
The middle loop of the VisTG Reference Model connects the human's ability to visualise with what are loosely called "Engines" in the computer. Visualising is one intermediary process in the human brain that assists understanding. Logical analysis is another. If logical analysis were to be included in the model it would be shown as a loop parallel with the "Visualising–Engines" loop, connecting with other Engines in the computer, and with the same "Understanding/Acting" level of abstraction in the human.
The third, innermost, loop is shown as passing through the input and output devices of he computer. These are the means by which the human physically communicates with the computer, such as keyboards, microphones, video cameras and the like on the input side, and screens, force-feedback controls, and loudspeakers and headphones on the output side.
To reiterate, these loops are considered in three categories: Most concrete are those concerned with the displays and input systems and the representations on them (I/O loops). Next are those concerned with selecting and manipulating the data or influencing the system's operations (Engines), and most germane to the human user are those that are concerned with the user's task-oriented interaction with the dataspace (Understanding the world represented by the dataspace).
Engines are perhaps the least obvious component of the VisTG Reference Model, and in practical attempts to apply the model seem to have caused the most confusion. Simply put, an "Engine" is a (usually) software component that manipulates data from the dataspace or from the human user and either reports the manipulated data to an output device or to the dataspace.
In many cases the human communicates with an Engine to tell it what data to manipulate or to provide some instruction as to how the data should be manipulated. According to their primary purposes, Engines may be categorised in an open-ended manner. For example, "search engines" accept some criteria from the user, and see out data in the dataspace that conforms to the criteria, and report the findings to other engines that manipulate the findings into a form that can be displayed to the user. "Navigation engines" allow the user to "move" around the dataspace, observing "regions" of the dataspace. A Navigation Engine is a conceptual possibility only if the data can be conceived as being "located" (See Chapter xxx), since the displayed representation necessarily includes data that are in some definable sense near each other.
"Selection Engines" are related to Search and Navigation Engines. Selection Engines allow the user to select from among various possibilities offered by the system, either in selecting data to be manipulated or manipulation algorithms to be employed. Many engines are Algorithmic Engines, which perform some operation on the dataspace to create new entries in the dataspace. One algorithmic engine might, for example, project the trajectory of a missile in a dataspace of real-time radar signals; another might generate a list of the trends in the prices of critical supplies in a country under a peacekeeping regime, while another might generate an optimum 3-D representation of the similarities among the contents of documents in a library.
Engines come in a variety of forms.
In any moderately complex task involving visualisation, several different types of engines are likely to be employed, among them:
It can be seen, then, that each apparently simple loop in the basic diagram of the VisTG reference model is in fact a complex. The complex consists of several parallel basic loops, each concerned with one task. Especially at the Visualisation–Engine level, these tasks may assist or interfere with one another. Assessing those support and interference structures may be the most difficult aspect of designing a system to aid understanding through visualisation, or of evaluating it once designed and built
A "Basic Loop" in the model is like an atom in chemistry. All materials are built from the relationships among atoms with simple definable properties. Closely linked atoms often create properties that might be hard to predict from the properties of the individual atoms, much as caustic and reactive sodium goes together with poisonous chlorine to create an essential nutirent, common salt. Less tightly linked atoms, however, can give rise to properties that could easily be predicted from the properties of the constituents, as, for example, the strength and toughness of a fibre-composite material might be expected from the strength of teh individual fibred and the flexibility of the material in which they are embedded.
In a similar way, basic loops may be tightly or loosely coupled. If they are tightly coupled, it may be necessary to treat them together, and to be concerned with the properties of the compex, as one might be more interested in the properties of salt than in those of sodium and chlorine individually. However, loose coupling is likely to be common, in which case, the basic loops may be considered individually, and the behaviour of the system deduced reasonably accurately from the behaviours of the individual loops.
 |
| Fig.x.2. No matter how the loop is supported, it has the same constituents. A perception of the current state of some aspect of the environment is compared with the desired state of the environment, and a decision made on action to make the actual state closer to the desired state. But there are both intrinsic and extrinsic impediments to making accurate observations and to generating the most effective actions. |
The key to any use of the VisTG Reference Model as a whole is to discover the purpose of each loop. "Purpose" refers to a stateof the world that the person wants to bring about.Another way of saying "the Purpose" is "the objective to be achieved", as is shown in Fig x.2. Presumably the current state of the world is not the desired state, so what matters is the relationship between what the person observes and the desired state.
If the user is, for example, searching for some item in a database, the objective is that the item should be shown in some way that identifies it as the sought item. Perhaps it is to be shown by itself, perhaps it is to be highlighted, perhaps it is to be spoken, but however it is to be shown, it is to be displayed. If the user cannot currently identify the desired item within the display, then some action is required to change the display.
One must next ask whether the user can perceive what could be done to increase the likelihood that the display comes to include the desired item. Perhaps the answer is as simple as creating a query in the language of the database (but does the user know that language?), or perhaps it is more complicated, such as manipulating a view of a virtual database world and "flying through" it until the desired item comes into view.
Often, to achieve a simple purpose, several things need to be done, in sequence or in parallel. Each of those things is a subordinate "objective to be achieved" and each represents another loop of the same character as the higher-level loop it supports. It is from the sets of parallel loops that the possibility of "molecular" complexes of tightly coupled basic loops arises. For example, two things that need to be done in parallel may both require the use of both hands. They interfere absolutely, More subtly, however, two things may need simultaneous attention from a novice user, but not from a practiced expert who performs each task as unconsciously as simultaneously "walking and chewing gum."
 |
| Fig x.3. Any one loop having one global purpose is likely to be supported by several lower-level loops, and to be just one of a set of loops operating in parallel in support of a higher purpose. Each of the lower level loops is concerned with the state of some local aspect of the environment that contributes to the perceived global state. |
Fig x.3 schematizes the analysis of one loop such as that of Fig x.2 into a set of lower-level loops that support it. Any observation of the global state of the environment consists of the integration of lower-level observations. For example, if a commander looking at a map is concerned with ensuring that a formation is in a position useful for advancing the mission, the objective (the desired state) is that (s)he can see whether this be the case, and the observation must be the degree to which it is the case and the potential reasons why it might not be. One could conceive this loop as one of possibly many that support a loop involving the commander's assessment of the military/political situation, and in which the actions consist of orders issues to the troops.
The single observation of the fitness of a single formation probably includes observations of the geographic context, the relation between the formation under consideration and related friendly and enemy formations, and not least, the logistical and morale state of the formation. At a global level, there is one observation, the suitability of the formation for the advancement of the mission, but this "Global Perceived State" consists of a multiplicity of disparate interrelated observations linked by the commander's knowledge and experience.
Figure x.3 shows the loop under analysis with dashed arrows. In using the model, the single loop (outer in the diagram) should be the analyst's concern. The supporting loops (and any loops that this one supports) can and should be treated separately, on their own merits.
Following the same example as above, the system analyst asks whether the commander is able to see the data in a context that would allow an assessment of the fitness of the formation for the mission. If not, the analyst asks what changes would allow the commander to make that assessment (not what commands the comander might issue to improve the unit's fitness for the mission, which is the purpose of a higher-level loop that this one supports).
Fig x.2 shows more than just the simple loop that is expanded in Fig x.3 to show a few supporting loops. It shows also that perhaps not all is perfect within the loop.There may be limitations on the intrinsic ability of the user to observe what is necessary. For example, the commander may not have access to information about the morale of the formation in question, or may not have the intellectual quickness to absorb and integrate all the different factors that go into an assessment of the fitness of the formation in question. Or the presentation system may require the commander to hold too much in memory, and not provide sufficiently interlinked representations of the different important factors. Next, there may be external influences on the timeliness or accuracy of information the observation requires. The staff may be hesitant about passing on bad news if it is from an unreliable source, or the enemy might have compromised the information systems on which the commander relies.
Similar considerations apply on the Action side of the loop. There may be intrinsic limitations on the ability of the user to act so as to affect the observation. For example, the system designer may not have allowed for the possibility that the commander wants to see the morale status of the formation while its location is displayed in geographic and tactical context. And there may be extrinsic impediments to the user's ability to act, such as the bouncing of a command vehicle that might make precise control of a display difficult, or noise that might inhibit accurate voice recognition of commands to the system.
Not only may there be intrinsic difficulties and influences from outside that diminish the effectiveness of any basic loop, but also there often are interactions among the parallel loops that support a higher-level purpose. These interactions may be mutually beneficial, but more often they interfere.
In considering any real system, the analysis of any one loop has to consider the possibility that it acts in parallel with other loops in supporting some higher-level purpose or objective. Parallelism implies the possibilities of mutual support and of mutual interference. Whereas the analysis of each of the parallel loops individually may suggest that each can work very well, either their observations or their actions may be incompatible. A complete system analysis must take these interactions into account, in much the same way as the chemical properties of molecules are not those of the constituent atoms, but in principle can be derived from them.
The implication of the above is that the analysis of a higher-level loop either must be kept strictly at its own level (can the necessary observations be made and actions performed, without at that point analyzing reasons for difficulty) or must take into account the interactions of lower-level parallel support loops. Either way, if the lower level is to be analyzed, the analyst must not that certain loops offere the potential for mutual assistance or interference.
A mundane example of the interaction problem occurs with dialing an in-car telephone while driving. If one is looking at the phone keyboard, one cannot be looking at the traffic, and whereas each action is easy in itself, the two are incompatible. Speaking the number or name to be dialed removes the incompatibility of eye gaze direction, but still involves a shift of attentional focus from the traffic to the telephone, which no doubt reduces the accuracy of one or the other without involving a simple incompatibility like that of the differing gaze directions.
A more subtle interaction may arise when the skills of the user (or the processing bandwidth of the electronics) are in question. Many observations, particularly at higher levels, depend on the user's background knowledge, and often on the short-term memory for an evolving situation (otherwise known as situation awareness). If the observational (or action) task is near the skill limits of the user (or if the electronics cannot act fast enough), then working through two or more parallel loops may be impossible, whereas for a more skilled user (or faster electronics) there might be no difficulty.
The analyst must therefore always consider what skills the user must bring to bear in making an observation or in performing an action. The greater the skill, the less external data need be supplied in making the observation, and therefore the fewer parallel supporting loops there will be that might cause mutual interference. Skilled intuition is what allows effective visualisation with data that shold theoretically be inadequate.
Whether the analyst is evaluating an existing system or is in a design-evaluate-redesign loop for a future system, the user's requirements have to be specified. What is the system intended for? What will the user want to achieve with it? If the system is a generalized support system for many tasks, these questions will have many answers, but if is a single-purpose system, there will be only one answer. Regardless of how many answers there are, each implies the existence of one loop that should be susceptible to analysis.
In analyzing a loop, there is a set of canonical questions to be asked. The first question is "What is the objective to be achieved?" or equivalently, "What is the purpose of the loop?" or "What is the goal state?" In the example above, the goal state is that the commander can visualise the fitness of the formation in question to the mission at hand.
The next obvious canonical question is "Can the current state be observed sufficiently well that it can be compared with the goal state?", or equivalently "Can the necessary observation be made?". In our example, the question is "Can the commander visualise the current fitness of the unit to the mission?". The answer to such a question depends critically on the commander's skill as well as on the charactersitics of the display. Let us imagine that to answer the question demands that the commander be aware of the terrain, the locations of friendly and enemy formations with which the unit might come into contact, the unit's supply situation, and its morale. A skilled commander who knows and trusts the subordinates may have no concern about morale, because if there were any problems, he knows he would have been told. In that case, that element of the observation would come from the commander's memory, not from the situation display. A different commander, perhaps equally skilled but new to the position, might need that morale status to be displayed so as to determine the likelihood that the unit would be able to do what it would be asked to do. Should the display show the morale status as a component of a tactical map display of the locations of friendly and enemy forces? Or should there be a supplementary alphanumeric listing of logistical and morale status for the different formations? Which gives the commander the ability to visualize the situation in a way that suits him/her? The answer probably depends on the commander.
And that leads to the next canonical question "Can the user affect the environment in such a way as to bring the observation nearer to its desired state?" In this example, the question is whether the commander can affect the display in such a way as to make it more likely that (s)he can determine the fitness of the formation for the mission (not "Can the commander act so as to improve the fitness of the unit for the mission?"). If the commander finds alphanumeric listings congenial, can the relevant listings be readily called up? If it is better that they be displayed symbolically on a map display, can the commander cause that to happen?
There are thus three basic canonical questions associated with any one loop:
The diagrams of Figs x.2.and x.3 suggest several supplementary questions, which can be combined into two:
It may sometimes be important to consider each of these two questions in two modes, firstly when considering the loop on its own, and secondly, if a higher-level loop analysis has shown this loop to be part of a potentially interacting set of parallel loops, then the relationship with the other loops in the parallel set must be considered. Each mode, but in particular the second, may lead to answers in terms of user expertise and training, rather than in terms of systemic or environmental limitations.
One additional question will be developed later, but can be mentioned here:
This last question is most relevant when the observation is of a fluid and dynamic situation and there are several parallel loops. It really asks how the user's attention may be drawn to this particular loop when some condition predetermined to be of interest occurs. But it also has another implication. In a large dataspace, there are too many data elements, and far more relationships, than the human user can be expected to remember or visualise at any one time. If a particular pattern is of interest, can the user's attention be drawn to the data that embody the interesting pattern?
Design and evaluation present two different, but related problems. If a system exists already, the evaluator has at least three kinds of approach:
For detailed examination of existing systems, the VisTG Reference Model can be used in any of the three modes, separately or together, though other methods may be quicker and easier to use for rough and ready evaluations of the suitability of systems for the tasks at hand. If the system does not yet exist, and must be designed, only the first of the three options is available. The evaluator must examine the system design, relying on prior understanding of human limitations and abilities, and must be able to assess the degree of training and prior knowledge a user will require when the system is completed. The designer does much the same, but uses a sequence of intuitive or formal evaluations to evolve a completed design.
The first stage of the evaluation begins with a question that is deceptively simple to ask, but not necessarily so simple to answer: What is to be evaluated?
To illustrate the problem, consider VITA, one of the candidate systems offered to IST-021/RTG-007 for evaluation. As offered, VITA is a complete system that allows the user an unusual view into the relationships among documetns and their contents on a Web site.
 |
| Figure x.4 A sample VITA display. A complex query concerned many concepts (green cylinders) which were found in many documents (blue disks). The relation of the concepts to the documents is shown by the red lines, and the commonality among the documents by their locations on the base plane. The user can interactively alter the viewpoint freely in 3D space, which gives a much clearer perception of the 3D image than can be otained from a static 2D image. The current viewpoint seems to be from within the plane of green cylinders. |
But as part of the complete system, VITA incorporates a choice among commercial search engines, and the part that is specific to VITA merely analyzes and displays the results returned by the chosen search engine. The dataspace that the user is trying to understand is the entire Web site, or that part of it relevant to a task. In this sense, VITA is an Engine.
When one considers VITA as an Engine, it becomes clear that the same Engine could be used in contexts quite different from the examination of Web sites. The dataspace need merely contain complex entities that might share commonalities of content. For example, instead of the pages of a Web site, it could be the records of packets arriving at and being sent from the set of computers on a network, where the task is for the analyst to discern potentially dangerous patterns of activity.
As a System, VITA reports its data to the screen of the computer on which it runs. Its capability is limited by the processing power and graphic real-estate of the physical device, as well as by the quality of the data returned by the Search engine that scans the Web site. Google, for example, returns only whether certain keywords exist in the pages of the site. Other search engines might return results that indicate the neighbourliness of those keywords, or their relative locations within the text of the page. An evaluation of the system might find deficiencies that ought to be ascribed to the search engine or to the processor, rather than to anything unique to VITA.
As an Engine, VITA is still constrained by the hardware on which it runs. VITA creates a 3D display with which the user interacts, and the speed of that interaction when the display is complex may limit the effectiveness of the VITA display. The method of interaction could be ideal, but seem cumbersome when implemented on an inadequate processor. Conversely, interaction problems could be inherent in the technique, regardless of the implementation. The evaluation might or might not be required to take account of the software and hardware implementation.
Another way of considering VITA is as a display technique, ignoring the question of where its data come from. As a technique it can be considered conceptually, or as implemented in a particular processor. When considered conceptually, the analysis can deal with potential constraints imposed by screen real-estate, processor speed, and interaction technology, without allowing the evaluation to be influenced by the limitations of a particular implementation. One can assume ideal conditions for the acquisition of the data to be displayed,
Considering all the above, there is no a priori answer to the question "What is to be evaluated?" The answer depends on the reason why the evaluation is being done in the first place. Is it to see whether a system that might be purchased will be adequate to perform a prespecified task? Is it to see whether the VITA concepts are worth deploying in a variety of different systems for different purposes? Is it to see whether there might be easy changes to a particular implementation that would enhance the value of the display concept?
When we deal with more complex complete systems, the question often has multiple answers. A battlefield situation display system, for example, may be intended for planning and for briefing, and for use by different elements of the command staff. Each of those uses and users may demand a separate analysis, based on a separate answer to "What is to be evaluated?"
The next basic question to be answered is "Who is the user?" Again, the question is deceptively simple. For VITA as an implemented system, the user could be anyone who wants to know something that could be determined from the relationships among the pages of a Web site based on the concepts mentioned on those pages. But for VITA as an Engine, even as an implemented Engine, the range of possible answers is much wider. It encompasses anyone wanting to use information about the relationships among the contents of complex objects in a dataspace. And that is too wide a range of potential users to be seriously contemplated when attempting an evaluation.
Quite apart from identifying the users by what they might want to do with VITA, the question "Who is the user?" also implies that the evaluator needs to know the user's skills. Is the user accustomed to other kinds of display of the same sort of information, or is VITA the first encounter? Is the user good at visualising 3D structures, and practiced at manipulating them? Has the user practiced with VITA itself? All these answers,.and more, will affect the way the evaluator answers the six key questions that apply to each loop being analyzed during the evaluation.
Both the foregoing questions apply globally to the entire evaluation. The evaluation procedure, however, works through individual "atomic" or "molecular" basic loops, and in evaluating these loops, the answers to the global questions must be kept in mind. For each loop, six canonical questions were adduced above. Each must be considered, if not fully answered, for every loop included in the evaluation (and not all of the active loops need be evaluated; some may be taken for granted as immutable or of little interest).
In the spirit of the two global questions, the first canonical question can be paraphrased as "What is the task?" of the loop. If that question is asked of the outermost of the loops to be evaluated, it becomes a third global question. It asks what the system is to be used for, and especially if the system is an Engine, it can have more than one answer. The number of answers define the breadth of intended utility of the system. A special-purpose system will provide only one answer, a general-purpose Engine, many answers. When one answers the first global question "What is to be evaluated?" one is deciding how much of the breadth of possible utility of the system to investigate. One is providing a guide to the possible answers to "What is the purpose of the outermost loop?"
In evaluating VITA, as with any other system, the first global question is "What is to be evaluated?" To limit the scope of the evaluation, let us choose to evaluate VITA as an Engine, and ignore the specifics of the Input-Output level (while providing guidance as to issues that might arise involving the I/O elements of the system). The VITA engine consists of a technique, or rather a series of techniques, for displaying in a 3D space the relationships among the user's interests as expressed in queries, the complex elements of a dataspace, and the contents of those complex elements. To illustrate VITA, however, one must use an implemented version. The evaluation, then, must be careful to segregate issues of implementation from issues central to VITA as an Engine.
VITA has had different incarnations over time. The image in Fig x.4 comes from VITA-epsilon, whereas for the example evaluation we will use VITA-delta (Fig x.5), which has an older and perhaps more stable implementation.
 |
| Fig.x.5 A VITA-delta display resulting from separate queries about "fuel cell, aircraft, turbine" and about "engine." (red cylinders), the concepts implied by the queries (green cylinders on the second plane, and the documents that refer to those concepts (blue cylinders -- green when highlighted by the user) on the bottom plane. |
.Who is the user? For the purposes of this example, assume that the user is familiar with the kind of structure of the elements of the dataspace, but knows nothing of their actual content. The user knows how to pose queries, and is competent at viewing interactive 3D displays on a screen.
What is the task? VITA as an Engine could support many different tasks that would be represented in the outermost loop of the VisTG Reference Model, but those tasks are not the task of the Engine. The task of the Engine is to take data supplied by a selection Engine acting in the dataspace (in the example, Google acting on the pages of a Web Site), and to provide an interactive 3D representation to the I/O system. Going back, then, to the question "What is to be Evaluated?", the answer can be refined. What is to be evaluated is the success of the VITA Engine in creating a display that allows the user to visualise the relationships among queries, dataspace elements, and the contents of the elements.
After the global questions have been answered, the next move is to decide on some particular goal that defines a task for the user within the framework of the evaluation. "Within the framework of the evaluation" means that since the decision has been made to evaluate VITA as an Engine rather than as an implemented system, the evaluator does not analyze the outermost loop in which the goal is to understand something of the structure. Of course, the analyst ought to keep in mind that such goals exist. They drive the Engine-level goals. At that level, the user-side part of the VisTG Reference Model indicates that the user is tryng to "Visualise". The analyst's question, then. might ask what the user is trying to visualise, given the stated objectives of VITA as an Engine.
Clearly, the user is at one level trying to visualise the 3D structure displayed, so as to see where in space the differently coloured cylinders lie with respect to each other, and what cylinders are connected to what other ones by the interlinking lines. That level must be analysed. But there is another, higher, level at which the user is trying to visualise the relationships among the queries, concepts, and dataspace elements, and a yet higher level at which the user may be trying to visualise which elements deserve closer inspection. Any one of these levels could be selected for the start of the evaluation.
The same set of six canonical questions may be, and in a full analysis should be, asked of the basic atomic or molecular loops at every level. Other loops may well be discovered as a consequence of analysing the loops that are initially apparent. Conversely, one of the assumed loops may turn out to be better analysed as an aspect of some other loop, or to need its purpose refined from the analyst's original assumption. The better the analyst's intuition, the less likely is the latter to happen.
Any level of loop may be chosen to start the analysis using the canonical questions. For a mid-level loop, the purpose implies that there is an outstanding "Why" question that will be answered by the analysis of some higher-level loop supported by the one being analyzed. Similarly, the analysis of the mid-level loop is likely to spawn "purposes" for one or more lower-level loops. To illustrate, we analyze the middle of the three levels mentioned above, the loop in which the user's purpose is to visualise the relationships among the queries, concepts and dataspace elements.
First, we consider the three basic questions, then the supporting questions.
Question 1: What is the Purpose of this loop?
Answer 1: The User wants to visualise the relationships among the queries, concepts, and documents in the dataspace (Web Site in this analysis).
Commentary: The answer given is very vague. One may be tempted to give an answer such as "The User wants to see whether any documents conform to ill-defined search criteria", but this would be wrong, That kind of answer belongs to a question at a higher level. It is why the user needs to visualise the relationships, not the purpose of the loop that allows the user to visualise the relationships. Engines that support a variety of possible uses are likely to have vague purposes.
Question 2: Can the necessary observations be made?
Answer 2: The user can see linkages among the concepts and the documents, but if there are many concepts and documents, as in Fig x.3, it can be confusing to see which concepts are linked to which documents. To reduce this problem, the user is able to alter the viewpoint in 3D space (which provides a "purpose" for at least one supporting loop). However, if the concepts arrange themselves in such a way that for some documents the links go to concepts widely distributed within the concept layer, no suitable viewpoint may exist. This is a problem of scaleability, as the interference from the multiplicity of widely distributed links scales roughly as the product of the number of concepts queried and the size of the dataspace.
Commentary: Is the problem (that interference among the many linkages makes it difficult to see which documents contain which complex of concepts) intrinsic to the VITA concept of cross-linking elements depicted in three parallel planes, or is it a problem of the display technology. For example, would the problem still occur if the display were in an immersive 3D environment? Probably it would, because the primary issue is that linkages that cross wide ranges of the space can occur, and when there are many concents and many documents, it is likely sometimes to be hard to see at a glance which concepts combine in which documents.
Could the problem be finessed so that the representation would scale well? Perhaps. The VITA display is to some extent self-organizing. At both the concept level and the document level, elements that have similar patterns of linkage tend to cluster together. If the dataspace does contain groups of concepts or of documents whose mutual similarities lead them to cluster together, then the display might be made hierarchic by presenting each cluster as an individual visual item which could be opened by the user for closer examination. Rather than allowing the user to see at a glance which documents were likely to satisfy the user's ill-defined criteria, it would allow the user to navigate the space toward areas in which interesting documents would be most likely to lie.
The notion of datamining through successive unwrapping of similarity clusters leads directly to Question 3.
Question 3: Can the actions be performed that would bring the observed state nearer the goal state?
Answer 3: In VITA-delta, the user has several possible actions. The most obvious is the ability to move the viewpoint from which the 3D network is seen. Provided that the relation between the control action and the display change is tight, this ability can greatly help the user to visualise clearly the locations of the entities and their linkage lines in the 3D space. To some extent, this ability reduces the scaling problem, but it does not affect the fact that the number of linkage lines scales as the product of the number of concepts and the numbers of documents.
A second action available to the user is "brushing." By moving the selection indicator (e.g. mouse-cursor) across a document, an abstracted version of the document can be displayed. This observation leads to further questions in a full analysis—at the higher level, is what is displayed adequate to give the user the desired understanding?, and at the lower level can the user perceive what is necessary in order to produce the abstracted version? Neither question has an answer at the present level of analysis, but as is often the case, answering a question at this level has led to questions that should be asked at other levels.
Commentary: One of the trickier aspects of using the VisTG Reference Model is to keep at the same level of abstraction through the analysis of a single loop. For example, in the previous paragraph, "brushing" is mentioned. This is an action at a different level of analysis than the loop we are considering. The correct description of the action at this level is that the user can choose to acquire some knowledge of the document content, without mentioning how this choice is implemented. That answer again gives rise to questions at the higher and lower levels with much the same import as those suggested above, but they may be phrased in a way that is easier to address, namely: Can the user perceive what is nessary in order to make this choice? rather than Can the user perceive what is necessary to produce the abstracted version. The latter formulation carries the implicit assumption that the method of making the choice is known, whereas the former makes explicit that the method of making the choice must be a subject of analysis.
Question 4: What external or internal influences affect the ability to make the necessary observations?
Answer 4: The answer to Question 2 implies the existence of internal influences, in particular the interference among the multiplicity of linking lines that can make it difficult for the user to see which documents are related to which concepts in a complex display. A generalization of this is that elements of each character (e.g. documents, concepts, linking lines) tend to obscure other objects of the same character if the viewpoint is near the plane in which those objects lie, or to obscure the elements to which they might be linked if the viewpoint is near orthogonal to that plane. When there are few elements in any one plane, this problem is minimal, but as the number of objects grows, it can make the entire display hard to interpret.
Another potential internal influence is a limit on the screen real-estate. At the present level of analysis, this translates into an inability to see at any one moment either a particular entity that might be of interest or the full field of entities. Again, this is a scaling issue that does not arise when there are few documents or few concepts.
Question 5: What external or internal influences affect the ability to perform the necessary actions?
Question 6: What provision is there for alerting the user to the current possibility of making a useful observation?