Detailed History of the MediaGrid

Before turning to further implemented visualizations, it is appropriate to describe in detail the history that lead to the current version of the SuperTable in the form of the MediaGrid.

As we saw above, a very long development phase preceded this state, including the two EC funded projects INSYDER and INVISIP. The first step was taken within the INSY-DER project. Different visualizations, chosen in dependence on the application domain, were used in the system. These include

• the ResultTable (Figure 3.6),

• the RelevanceCurve, included in the ResultTable (Figure 3.6),

• the ScatterPlot (Figure 3.8),

Figure 3.18: A single row is enlarged to the maximum, while all other rows stay in the lowest level, displaying a single line of text.

• the BarChart visualization (Figure 3.6),

• the SegmentView (Figure 3.7), available in two versions as TileBars and Stacked-Columns, and

• the BrowserView (Figure 3.8).

The advantage of visualizations in supporting the information-seeking process is cur-rently well known. Nevertheless, the way of presenting the information still differs from system to system. This variant was a first step in a direction that leads to a very effi-cient implementation of an information-seeking system. The proof of this statement is shown by evaluations which assessed the idea as good. Further improvements entailed an ongoing development phase, again including a lot of tests. With the exception of the rel-evance curve, which was included in the ResultTable directly, all visualizations coexisted in INSYDER. The screen was divided into two main parts, where the upper one con-tained the ResultTable, the BarChart, and the SegmentView visualizations, the lower one the BrowserView and the ScatterPlot. This variety helped in viewing the same data from different perspectives, but a hard context switch was necessary when changing from e.g the table to the BarChart view. Thus, the main shortcoming of INSYDER was detected and an initial solution was sought.

All visualizations achieved within INSYDER could be adopted into the INVISIP project.

Nevertheless, adaptions had to be made. The idea of providing various visualizations was retained, but the kind of presentation underwent a radical change. Although the applica-tion domain changed from a web search to a search on geo meta-data, the main concept stayed the same. The VisMeB framework, which became the internal project name for the system implemented for INVISIP, went one step further. While INVISIP was con-ceived for the visualization of geographical meta-data, the idea of VisMeB was to allow arbitrary databases and application domains to be examined. Therefore, the former

IN-VISIP project was integrated as one possible scenario for the VisMeB framework. As a result, a systematic revision of individual program parts and conceptual adaptions had to be fulfilled to cope with the generic tasks. The main difference from the INVISIP project was the strict separation of visualization and the underlying data model, following the Model-View-Controller pattern (see [GHJV93]) . This enabled a parallel development of INVISIP and VisMeB because the visualizations used stayed the same, only the data model had to be adjusted. Thus, if we talk about INVISIP or VisMeB the only difference lies in the base data model, while the concept, the appearance, and the features do not dif-fer. Its domain-independence is another milestone in the development of the SuperTable.

Because the system itself is not restricted to a specific application domain, only small adaptions have to be made for each scenario. This can be done by the Visual Configura-tor, which will be presented in appendix A.

The first step in improving the INSYDER concept was to create the SuperTable. Its first version, the LevelTable, included hitherto separated visualizations in a single tabular lay-out. Thus, the BarChart visualization for presenting the relevance value for all query terms was included in single columns in the table, as was the segment view in its stacked col-umn version. No context switch was necessary; additional information was still visible.

ScatterPlot and BrowserView coexisted in parallel. Because it was impossible to provide all the information given by the different INSYDER views in a simple table in a meaning-ful way, the granularity concept was introduced to let the user find all information, now displayed in diverse levels of detail, but without the necessity of leaving the context of the familiar table. This was the first main advantage of the SuperTable over the INSYDER ResultTable. Changing from one detail level to another caused two effects: The table rows’ height was magnified and in certain circumstances the number of columns altered, depending on the number and kind of meta-data to be presented. This fact of variable column numbers made inevitable the need to always move the complete set of data from level to level.

The GranularityTable describes the next step that lead to an improvement. So far, three visualizations were necessary in the LevelTable version of VisMeB: the ScatterPlot, the BrowserView, and the LevelTable itself. A further integration of the Browser in the Gran-ularityTable reduced this amount to two (main) visualizations - the ScatterPlot and the GranularityTable (additional visualizations were implemented as alternatives, such as a 3D ScatterPlot or a Document Universe, but this had no effect on the original idea). How-ever, there was another drawback still to be remedied. Up to this SuperTable version, it had only been possible to get more information for the complete data set (in the Lev-elTable) or for a single data set (in the GranularityTable). The opportunity of seeing more details of an individual meta-data was always connected with the intrusion of possibly less relevant information in all other meta-data.

This drawback lead us to the MediaGrid. Here, the selection of a single cell made it feasible to get details of just the desired item. Although an automatic magnification of cells in an orthogonal table without distortion leads to a magnification of the complete

Figure 3.19: The evolution of the MediaGrid: the origin lay in the INSYDER system; a first advance was the LevelTable, followed by the GranularityTable, and resulting in the MediaGrid

row, the main focus stays on the cell and thus makes it wider. All other columns shrink as long as the focus is not moved.

The history of the MediaGrid shows the long period of development and the necessity to take one step at a time. Although the idea was conceived at the very beginning, it took more than one single stage to reach the current version of the SuperTable. A complete overview of the different development steps, and the improvements made at each stage, can be seen in Figure 3.19 and Table 3.4.

Up to now only a set of visualizations was presented. But a very important question has so far been neglected: what is the advantage of this approach? How do these visual-izations work together to reach better results?

The coordination of multiple views is a principal focus of this thesis. This point will therefore be examined in detail in Chapter 5. The use of MCVs in combination with the granularity concept leads to further complications, but also have advantages that must be considered. Coordination becomes more complicated, though the variety of interac-tion possibilities increases. However, before concentrating on this aspect the granularity concept itself has first to be introduced in the following chapter.

Table 3.4: Advantages and disadvantages within the MediaGrid history

This chapter gives a general introduction to Multiple Coordinated Views (MCVs) and the visualizations used in the VisMeB approach implementing the MCV concept. After a definition and short overview, a guide for selection and use of multiple views is provided.

It encapsulates the question of whether it is meaningful to use MCVs, as well as decision criteria about which visualizations and what kind of interaction between them to choose.

Different models for formulating a formal and consistent approach to coordination are delineated. The second part concentrates on the visualizations implemented within the VisMeB framework. The single views are characterized without a detailed insight into the field of interaction and coordination. This will be the topic of Chapter 5, ”Interaction Between Granularity-Based Multiple Coordinated Views”.

One important aim in information-seeking is to set the focus to something interesting. If you have found a special item, you want to know more about it and to find out if it re-ally meets your needs. This can be done in different ways like opening a further window to present details, linking to another webpage, etc. A base function implemented within the granularity concept is the technique of zooming. The concept’s additional features and significance is described in Section 4.3. To get an overview of the possibilities pro-vided by zooming, a short introduction to diverse zooming techniques and behavior will be given in the following section.

4.1 Zoom Introduction

Zooming is a widespread technique for giving the user a more detailed insight into infor-mation. Therefore, diverse techniques exist for presenting the particular area of interest.

The context of the respective zoom area plays an important role and thus has to be made visible in specific situations. Again, this can be done in various ways. Plaisant et al.

[PCS95] and Rueger [Rue98] provide a classification of zooming view opportunities that serves as a basis for the following overview.

• Detail-only view: This method is most common in systems like Microsoft Windows or similar user interfaces. A fixed section of a larger image is displayed in a single window. Panning is used to navigate through the information space, often imple-mented with the help of scroll bars. The global view is not visible, mainly because of the small zoom factor. Imagine a zoom factor of two, then a quarter of the whole image is visible at one glance. Orientation by navigation is quite easy, the problem of being ”lost in information space” is very small. However, if the zoom factor increases, orientation becomes more and more difficult. In this case another tech-nique should be used to support the user. Figure 4.1 shows a cut-out of a Microsoft Windows Explorer window.

105

Figure 4.1: Windows Explorer displaying a Detail-only view

• Zoom and Replace: First, a global view of the required image is presented. A rect-angular area is defined by the user and is displayed in magnified form and replaces the original view. Differences can appear in the size of the cut-out. One possibility is to appoint a fixed size, i.e. the rectangle keeps its size all the time. Another method is to let the user choose the size by dragging a rectangular area that fits the user’s needs. A side-effect of the second version is the necessary adaption of the zoom area to the screen space. If width and height of the rectangle are freely selectable, they have to be scaled where appropriate to fit into the available space.

Although more flexibility is provided, this might cause confusion for the user be-cause the selected area and the resulting image do not accord exactly. Figure 4.2 provides an overview of three different variations of zoom and replace.

• Pan and Zoom: Provides the same features as zoom and replace. The user can select a rectangular area to be magnified which replaces the current view. As an extension, the user can relocate (”pan”) the magnified area. This feature allows a fast scan of the complete area, restricted only by the zoom factor. If the zoom factor is too large, a scan will take much longer and the danger of loosing the context is much higher.

• Overview and Detail: This technique can be seen as a logical extension of ”sim-ple” pan and zoom. To avoid the risk of not knowing where the current cut-out (detail) is located, an additional view is introduced that always displays the global view (overview). In general, a small part of the screen is reserved for the global view. Nevertheless, a separate window is another often-used possibility. Figure 4.3 illustrates the use of two separated windows, displaying the SVG browser Squiggle.

Figure 4.2: Variations of zoom and replace: a) zoom only, b) zoom and the possibility of scrolling, c) zoom with additional levels of magnification (adapted from [PCS95])

Figure 4.3: Overview and detail implemented in the SVG Browser Squiggle

• Tiled Multilevel Views: In this zoom variant three different views are used to imple-ment diverse magnification steps. The global and the detailed view (see ”overview and detail”) are extended by a third one, the ”intermediate” view. This allows a multidimensional zoom using different zoom factors for different views. A good example is an application showing a map in distinct detail levels. The global view displays e.g. the complete map of a national park in the US (see Figure 4.4). De-pending on the size of the park, you may be interested in a specific part that would allow a round trip within a specific, self-chosen time range. Therefore, the interme-diate view shows a map of the eastern part of the park including the point where the trip would normally start - the visitor center. A large variety of intersection sign-posts in the south makes this particular area especially interesting und thus an even more detailed view shows this location in depth. Information that was not visible before is now readable, e.g. the Jordan Pond House. Coordination between global and intermediate view, as well as between intermediate and detailed view, can be implemented as described above in ”overview and detail” with one small restric-tion: if the selected area in the overview (rectangle A) is moved, the selected area in the intermediate view (rectangle B) should also be moved to avoid a complete disappearance of rectangle B if rectangle A is moved to a position where B is not visible any more.

• Free Zoom and Multiple Overlap: An overview of the entire image is displayed in a main window. This provides the basis for the zoom action. The zoom is called free because users are enabled to define a) an arbitrary area in the actual view and b) borders for a new window. Accordingly, the marked area is presented in the newly created window, which overlaps the source window. To implement various zoom factors, this approach can be repeated using any available window. No coordination between the windows is determined, so all windows act independently. Although this leads to an advantage in specific situations, the problem of overlapping and thus obscuring windows still exists.

• Bifocal View: The bifocal view uses a magnification lens metaphor to emphasize the interest in a small area without losing the context surrounding this area. The idea is to present the items of current interest in readable detail whereas the surrounding items are visible in outline. A typical example is the London Underground Map (Figure 4.5).

• Fisheye View: The fisheye view extends the bifocal display by adding a distortion factor to the surrounding area and using a smooth transition between the two ex-treme zoom factors that are described in the bifocal view. Figure 4.6 clarifies the effect. A more detailed view of this topic is described in Section 4.3.

• Translucent zooming and panning: This technique extends the general zooming and panning and adds transparent layers that are displayed simultaneously. Focus and context are shown in combination, but coordination of detail cut-outs has to be done

Figure 4.4: Overview and detail realized within a tiled multilevel view

by users themselves, not by the system, in contrast to e.g. a system using a fisheye technique. The Macroscope System [Lie97] uses this kind of zoom (see Figure 4.7).

As we have seen, the large variety of zoom techniques and their possible implemen-tations can provide more than a ”simple magnification”. Different windows, parts of windows, zoom factors and distortion techniques can be used to support the process of zooming. The complete approach is independent of the tasks to be fulfilled. Systems like Jazz [BMG00] and Piccolo [BGM04] (see Chapter 2) provide the opportunity to include a ”Zoomable User Interface” (ZUI) to other applications. Apart from the tech-niques available, the zooming behavior plays a role as well. A short introduction is now presented.

Figure 4.5: London Underground Map using a Bifocal Display

Figure 4.6: Map of Washington, D.C., using a Fisheye View

Figure 4.7: Visualization of a file system, using translucent layers in the Macroscope system