4.1 Language Conception
The main difference of visXcerpt to most visual languages is the fact that the visual graph structure is no longer made up of edges and nodes. As long as the structure of the data to be visualised is a tree, nesting of elements is used to represent the structure. If the data structure is not expressible as a graph, a graph is constructed from a spanning tree with the missing edges moved into the hyperspace. This approach has proved to be powerful for large structures. If structures are represented by graphs based on nodes and edges, they tend to become so cluttered that they are unreadable. Various graph layout algorithms exist trying to maximise the readability by reducing the amount of line crossings. Unfortunately the computational complexity is usually high and the document size (its extension in its visual dimensions) often grows rapidly depending on the number of edges.
A drawback of a hyperlink-based approach is the difficulty of grasping printed representations. For established use of modelling languages this would be a major drawback, because their documentation nature often makes printing necessary. For a query and transformation language, the interactive requirements are not a drawback. Further aspects, like the template-based instantiation of new content, enforce the interactive use for the sake of "learning by doing".
With XML documents as data to represent, various mechanisms for graph construction are given:
- ID/ID-ref mechanism
- internal links based on XLink
- the use of XPath expressions
- RDF
- external links in a XLink base.
While the first three methods imply a spanning tree on the graph data, methods 4 and 5 do not imply a spanning tree structure. Because usually more than one spanning tree can be derived from a graph, further investigation would be necessary to find out which one to use as spanning tree for a visXcerpt document. The ranking of potential spanning trees is likely to be application dependant. Another approach could be to provide an editing mechanism to interactively extract a spanning tree.
4.2 Editor Conception
The editor concept proposed for visXcerpt documents in this thesis is a simple adaption of the copy-and-paste paradigm. To a certain extend the editing process of visXcerpt documents can be expressed in terms of prototype based object oriented languages. An element copied can be seen as the prototype of a new element pasted. The template document is like a library of prototypes. In contrast to prototype based object oriented systems the relationship to the prototype is lost. Modifications of an element are not reflected as differences to the prototype of an element. Research in the field of editing prototype based object oriented knowledge bases could be enlightening in the research for further editing mechanisms.
Extending the set of editing operations has to be handled with caution. While more features may provide easy handling of special use cases, the overall handling gets more complicated. The easy handling of user interface menues is indirectly proportional to the amount of operations located in a menu -- short menues can be grasped quicker. In the HIG (GNOME Human Interface Guidelines) [benson02hig] it is suggested to restrict menues to 15 entries and to group the content to groups of 2-5 entries. The values are empirically founded. Because editing operations are accessed through a context menu and because their use is frequent, good menu design is a major concern. A good editing model should hence consider balancing the length of the menu with the complexity of the editing process.
Another amelioration of the editing step is the improvement of the template document. A dynamic template, based on a generalisation of the edited document, is likely to be a useful tool. This is due to a tendency to reuse the same elements with slight modifications more than once in the same document. A dynamic template mechanism could provide copies of elements found in the editor document, without child elements or with fixed depth. Those elements with cropped sub-trees are comparable to an empty form that can be filled with new content. Generating templates based on schema information is a more powerful template mechanism, because thus many valid elements with arbitrary complexity can be provided.
4.3 Prototype Conception
The use of browser technology for the prototype was advantageous because no effort was necessary to lay out the visual components -- the render engine of the web browser fulfills this task. The transformation aspects, actually implemented using XSLT, are interesting to implement using Xcerpt (or excangeably visXcerpt) as soon as the required features are available in the Xcerpt prototype. Nevertheless, a reimplementation in Xcerpt should reach beyond the current state of visXccerpt and introduce a type system for the lXr annotation mechanism. Many features can only be implemented satisfactorily based on a type system. Some of those features are:
- variables in attributes
- horizontally arranged elements in a disjunction
The reason is that the concerned components are treated differently depending on their parent context. Because the lXr annotation mechanism can generally be used for any XML application, a generic type system, comparable to XML Schema, should be included. The editing operations must be re-implemented to be type-aware. Cutting and deleting content must be prevented, to avoid schema violation. Content pasted may need transformation to be valid at the given context. An lXr schema must therefore be enriched by prototypes or constructors for visual element representations.
A further important feature that is not implemented in the prototype, is the support of graph structure based on references. The implementation aspects can be compared to those used for the variable handling. A generic graph handling mechanism also relies on a type system, because knowledge about reference element types or reference attribute types needs to be specified. Variables should be reimplemented using that a graph mechanism for the sake of code factorisation.
4.4 Need for empirical evaluation and user feedback
An evaluation of visXcerpt by non-computer scientists or programmers is advisable. This is the only way to rate one of visXcerpt's goals -- the orientation towards casual users. A short informal discussion with some interested non-scientists about this thesis led to the conclusion that either people are not aware of structure in databases, or that they are fixed on an imperative programming style and have problems with the semantics of rules and variables in visXcerpt. The first category are consumers that browse the web, use E-Mail or write text documents. Those people are used to fill in prepared forms or search fields in WWW search engines. They are used to get the result presented in a predefined and fixed way. Searching consists of providing key words, structure is a given feature of the query result or a given query form. Consumer evaluation of visXcerpt should be focused on using and altering predefined query patterns, hiding aspects like joins, disjunctions/conjunctions, resource locations and chaining. For the result presentation an aspect to evaluate is, how far the generic visualisation of semi structured data is comprehensible to consumers.
Second category of potential casual users are those people who have some experience in using computers, but no experience in using logic programming languages. Those users usually have problems to understand the nature of variables in logic programming, because their view to variables is tainted by the imperative paradigm -- variables are names for storage areas, values can be read and assigned. To solve the problem, metaphors have to be found that describe the behaviour of visXcerpt variables in a less abstract way. The unix concept of pipes is a salient example for a good metaphor. The word pipe intuitively indicates flow, blocking behaviour if one end waits, buffering and disastrous consequence, if one endpoint is removed (or killed in unix terminology). For Xcerpt and visXcerpt the following abstract concepts are candidates to be aliased with new metaphors:
- variable
- as-construct
- chaining (forward or backward chaining)
Even different metaphors for different use cases or user communities are likely to be useful. This approach and a methodology for its visualisation is explained in [fishwick00aesthetic]. The choice of spicy metaphors are considered by some as syntactic sugar and as an exchangeable feature, but they are of major importance for comprehension of the underlying semantics and certainly support wide acceptance. Comprehension leads to trust and trust leads to acceptance. Even if an indispensable property of query, programming and transformation languages is the executability on a machine, we may not forget that programs have to be understood by humans.