The MedioVis Prototype

As described above, the MedioVis prototype was created with the intention of satisfying two different user groups - ”normal” library users and administrative staff. To meet the first users group’s need, the GridTable is implemented (Figure 6.7). The layout resembles the LevelTable introduced in the VisMeB framework, but fewer features and visualiza-tions are available. It is restricted to an interface that does not overstrain the users. All in all, ten different levels in the two SuperTable variants would certainly produce an over-head that would deter the users from further work with the system. We still have to keep in mind that the idea of the global project was to provide a system created for experts, not for occasional users. Thus, our objectives had to be adapted to the situation and the user’s abilities. Figure 6.7 displays the GridTable in its original version.

Figure 6.7: GridTable implemented in the MedioVis project to present information to a library user

The strong similarity to the LevelTable can not be ignored. Differences can be found in e.g. the way of changing the level of detail. A specific number seemed to be less meaningful than simple ”+” and ”-” buttons, supported by a graphical presentation as a kind of stairway. At a later stage, the names changed from ”LevelTable” to ”Table View”

and from ”ScatterPlot” to ”Graphical View”, to describe the corresponding visualization in words the user is familiar with. In the original LevelTable the different levels provide different information about the data sets. Nevertheless, additional visualizations like the SegmentView or BarCharts were omitted to minimize the number of new techniques to be learned.

In contrast to the GridTable, the MediaGrid can be seen as a more research oriented development. New ideas and concepts are given a chance and are developed concurrently with the GridTable implementation. The possibility of zooming into single cells instead of moving the whole data set from one detail level to another is the main advance in this

SuperTable version. Additionally, further information resources (like the IMBD ¹) are used to include other material like movie posters or images of actors. The new concept even allows the playing of a trailer in a cell. Visualizations like the SegmentView, Bars, or even the LocationMap can be integrated again; no specific level has to be determined to display them. The necessary space is defined by the size of the visualization or the length of the presented text, not the level that provides a fixed height or width for rows and columns. Figure 6.8 shows an example displaying a poster in one column, a trailer in a second, and the LocationMap in a third one.

Figure 6.8: The MediaGrid of the MedioVis project. A zoom to single cells is possible, resulting in e.g. the display of a movie poster (left column), a trailer (center), or the location map (right column)

To find out if users are comfortable with the MedioVis system further evaluations have to be undertaken. The DROID project has therefore been established. More details about its current status can be found in the Outlook, Chapter 8.

6.3 Summary

This chapter gives a short introduction to the field of user-centered design. As part of interaction design, several lifecycle models are introduced that describe the complete development process. A very important aspect is the iterative approach that leads to a well-designed product. It is impossible to define requirements that remain completely unchanged during the whole lifecycle. Feedback has to be obtained by different tech-niques, as described above. Examples of interaction and design paradigms as well as data-gathering techniques are cited. Furthermore, the diverse development stages that the VisMeB project went through are considered, starting with a paper-based mockup, to a working system implemented in Java, i.e. the final implementation within the MedioVis

1International Movie DataBase, http://www.imdb.com

project. The importance and advantages of a user-centered design process are explained, emphasized by several examples. This knowledge forms a basis for understanding Chap-ter 7, where a simple list and the LevelTable are compared.

The complete implementation of the VisMeB framework followed the user-centered de-sign process (see Chapter 6). This included tests using paper mockups, HTML mockups and a working system implemented in Java. But all tests focussed on the question, of whether users could handle the system, whether they liked the idea or not, what was good and what was bad, and so on. So far, the question if the visualizations used lead to an im-provement in efficiency, was not considered. Therefore, there was a need for a user study to verify and quantify the benefits of the SuperTable and measure the subjective user pref-erences. As a result, in summer 2003 an evaluation was performed as part of a Bachelor thesis [Ger03]. The test’s objective was to compare the SuperTable with a typical list-based visualization such as that e.g. Google. We decided to test these visualizations, because at the present time only a few users are familiar with visualizations similar to the SuperTable. A list or simple table presentation for results of a database query is the usual way to present the information retrieved from a database. The LevelTable was chosen in accordance to a heuristic evaluation made initially by the developers of the system. Infor-mation concerning the statistical background can be found in [AA03], or [KBW00]. A detailed report of the evaluation will now be given.

7.1 Introduction

To guarantee the validity of usability tests, an appropriate analysis is indispensable. De-pending on the kind of evaluation, statistical methods, applied in a correct manner, can fulfill this condition. In the present case, a performance test to compare two visualizations - list and LevelTable - complies with the conditions. As we have seen in the preceeding chapter, the first step in starting an evaluation is to define the goals that are to be attained.

Depending on these goals, the questions can be formulated to ensure proper results. This can be done by formulating hypotheses. One possible hypothesis is the null hypothe-sis. It assumes that there is no effect between the dependent and independent variable.

Nowadays the use of multiple dependent and independent variables is usual, although the analysis becomes more complex. In our case, the dependent variable is given by time (performance) whereas the different visualizations used (list or LevelTable) can be

de-177

scribed as the independent variable. Therefore, the null hypothesis H0 and the research hypothesisH₁ for the present case can be written as

• H₀: ”Concerning effectiveness, the LevelTable does not have any advantages over a list-based visualization.”

• H1: ”One result presentation is more efficient than the other.”

If the test participants solve the task faster with one visualization than the other, the null-hypothesisH0 can be rejected.

Typical analysis methods for usability tests like the present one are ANOVA (ANalysis Of VAriance) and Student’s T-Test. The dependent variable is given by the performance, i.e. the time users need to fulfill a task. The independent variable is available in two vari-ants, visualization A (list) and visualization B (LevelTable). For that reason, a Student’s T-Test or an ANOVA should be used to get a correct interpretation. This is conditioned by the respective situations, which influence the choice of the corresponding method. In this case, both methods are used.

To compute the statistical analysis, the widespread and reliable SPSS system was chosen. Among other possibilities it provides output in the form of tables that display the values that are most important in coming to a decision concerning a rejection or retention of the null-hypothesis, as can be seen in e.g. Table 7.1.

Besides the correct evaluation method, there is yet another decision to make. What kind of test design is chosen? Possible test designs are the between-subjects design and the within-subjects design. Both versions are widespread and commonly applied. For the present case a between-subjects design was chosen. The visualizations to be compared were limited to the SuperTable, or rather the LevelTable as one possible version, and an additionally created list visualization, based on the typical layout of a search result presentation such as that known from e.g. Google. All other visualizations were excluded.

One reason was the additional training time that would have been necessary to work in an efficient manner with additional visualizations like the CircleSegmentView, or the ScatterPlot in its two- and three-dimensional versions. The functionality provided by the system could overwhelm the user and thus confront him with problems that would lead to less meaningful results. The purpose of the VisMeB framework was to support professional users at their work, so a longer initial training is reasonable and acceptable.

But this extra time could not be spent on the usability test, which is very restricted to a specific time frame of at most two hours - including introduction, pretest, main test, and posttest.