The document type "spreadsheet" is indeed very successful: tens of millions professionals and managers create hundreds of millions of spreadsheets according to [15]. Spreadsheet documents are used to create, modify, and visualize numeric business and science data, therefore they are mathematical user interfaces. Their complexity and impact increased at the same time: this intensity yields wide-impact errors on the data level (up to 90% [15], see also [17]) and on the apprehension level (e.g. [16]). To address this problem, in the past we have extended spreadsheets semantically with the "SACHS (sx)" system [12,13].
In this paper, we ask what difference SACHS really makes: Do people perceive a difference when offered SACHS functionality in spreadsheets 1 ?
To better understand what users of spreadsheets perceive commonly as information units, what meaning users assign to these units and what meaning users assign to the additional SACHS information units, and finally, how users discriminate between them, we conducted a study using the Repertory Grid Interview (RGI) Technique [11,7,10]. RGI explores personal constructs, i.e., how persons perceive and understand the world around them. It has been used as a usability/user experience method to research users' personal constructs when interacting with software artifacts (see [9,19,8,4,21] for examples). RGI is a semi-empirical method that has the grand advantage of not depending on a high amount of study subjects and nevertheless delivering valuable insights into the perception of users.
As a pre-study we used a smaller RGI to elicit which "semantic objects", i.e., meaningful objects, are commonly perceived by users in spreadsheets. From these we identified those semantic objects, which were considered information objects. For our main study we added information units provided by SACHS. Besides getting a better grasp on human-spreadsheet interaction in general, we were specifically interested to find out which of these external information objects were perceived to deliver similar or different information compared to traditional spreadsheet information objects.
First we present the setup of our repertory grid interviews. Then we analyze the RGI and interpret the results. Finally, we conclude by drawing conclusions from our RGI study.
The aim of the study is a better understanding of information quality within a spreadsheet and whether existing applications already cover the information offerings of the SACHS extension. If such additional information were to be perceived by readers at all, we were especially interested in what ways these new qualities would be perceived.
A repertory grid is a grid consisting of "elements", i.e., the objects under consideration, and "constructs", i.e., pairs of antithetical properties that separate elements. The constructs serve as a bipolar dimension on which the elements are evaluated. As the property elicited first in a construct is the more salient one, RGI calls it the "implicit pole" and the other one emerging in the reflection of the dimension of comparison the "emergent pole".
Elements as well as constructs can be elicited by the test persons themselves or can be provided by the interviewer. Comparison of multiple repertory grids is simplified if the individual ratings are given on a fixed set of elements or constructs, but a free elicitation explores the perception space. For our main RGI we decided to fix the set of elements to be "common and additional information objects in spreadsheets", but to elicit individual constructs to better understand the information space.
In a first RGI we extracted spreadsheet elements that are considered common information objects for the main RGI. Then we selected six additional spreadsheet information objects from SACHS offerings, that are not contained in a common setup with spreadsheets. We used both element sets together to collect personal constructs used to evaluate these elements. Concretely, we asked the interviewees to tell us in what ways the selected elements considered as information objects were similar and different (according to traditional RGI).
We asked users to mark those elements from their self-created list of elements in the first RGI study, which they consider to be "information objects". We explained that we understand information objects to be objects carrying information identifiable to the reader.
Even though the resulting principal components given by a factor analysis and an accordingly weighed clustering were interesting per se, they wouldn't give us a gener-ally valid assessment, as the constructs were not directly comparable. But we found six information elements in this small RGI to be consistently listed: Title A phrase describing the content of the spreadsheet Headers A (short) phrase supporting the interpretation of values of a regionally close range of cells (e.g. a column header) Legends A list of content properties and resp. layouts (as in a map legend)
The content of a cell container Formulae A computational rule that yields a cell value (sx:)Color Coding
The use of color hinting at additional information Furthermore, two subjects also identified: Tables A possibly multidimensional homogenous structural layout of cells, that is perceived as an object of its own Note that "diagrams" are missing, which may be due to the fact, that they were not part of our standard spreadsheet example.
We selected these 7 information objects of common spreadsheets as part of the set of elements for the main RGI.
The SACHS system contains semantic spreadsheet-related information not usually available to spreadsheet users. It aims at providing user assistance for spreadsheet users based on a background ontology. As "cells" are the important semantic objects in spreadsheets, SACHS acts cell-oriented.
Fig. 1. A Simple Spreadsheet after [20] In a spreadsheet like the one in Fig. 1 a user clicks for example on a cell that contains "1,878" as information of Values. Common information objects tell the user about the context (e.g. by Title "Profit and Loss Statement", Headers "Profits" and "1986", or Legends "in Millions"). But what if the user doesn't understand how "Profits" are calculated? When using SACHS this cell might be linked to a concept in a background ontology that covers the domain knowledge of this particular spreadsheet. If the user likes to retrieve this linked concept from the ontology, then she can do so by opting for a "look-up" option provided by SACHS and by selecting the wanted cell. A pop-up close to the selected cell will appear with this additional information -e.g. "A profit is the difference between revenues and expenses." -together with the header information "Profits [1986]".
For this study, we extracted the following information objects that seemed to carry additional information benefits compared to the common information objects: An overview graph (in a different window) of concepts showing on which the corresponding (selected) cell is ontologically dependent sx:Relational Arrows
A node in sx:Dependency Graph representing a dependent subconcept, that additionally serves as a link to corresponding spreadsheet cells
For our study we interviewed 14 people, of which 10 were male and 4 female. The age mean was 29,3 years. Participants reported an average of 8.2 construct pairs (SD = 1.4) ranging between 5 and 11 pairs. 5 subjects were familiar with authoring spreadsheets, the other 9 only had occasional contact. The rating scale for the 115 elicited constructs was essentially binary: it consisted of -1,0,1 but the interviewees were only told about their option to use "0" as a rating when they otherwise would have discarded the construct in question as inapplicable.
We performed a Generalized Procrustes Analysis, as it can be used when data "have arisen from one type of scaling of the same stimuli as perceived by different individuals" [5, p. 33]. In particular, in our RGI we can compare the individual natural language constructs rated on our fixed set of information objects. We follow Grice's example procedure for a Generalized Procrustes Example [6]. In particular, after having produced a "consensus grid", i.e., a best fit grid for a number of grids that are equal in one dimension but not in the other, we conducted a Principal Components Analysis (PCA) on it yielding components {P C i=1,...,11 }. The first two components explain ca. 56% of the variance in the data, the first three even 71%. Hereafter, a Multiple Group Components Analysis was performed, which allows to map the specific construct/element distribution into the PCA results. 2 .
We now give an overview of element clusters we identified and the outcome of the reconstruction of elements/constructs via the Multiple Group Components Analysis of all elicited repertory grids followed by an interpretative discussion of the findings.
We focused each repertory grid by swapping the construct poles to optimize the amount of applicable poles for the set of common spreadsheet information objects. This way we could identify the characteristic construct poles for this and the remnant element set and their pole distribution.
For the analysis of multiple repertory grids we found the "Idiogrid"3 tools of analysis most helpful. Especially the availability of the Generalized Procrustes Analysis [5] resulting in a consensus grid, yielded a valuable input for other analyses. The constructs of the consensus grid are created based on the underlying statistical analysis, thus, they are an artificial gold standard for real elicited constructs.
In Fig. 3 we can see the outcome of the Multiple Group Components Analysis for P C 1 and P C 2 (with only the more salient constructs, in particular with 0.85% suppression of labels) run by Idiogrid. Emergent Poles are marked by a "(-)" prefix.
Let us first look at the elements themselves. As the set of elements were fixed in this Fig. 2. Element Cluster Dendrogram for the Concatenated Grid RGI, we could build the "concatenated grid" consisting of the given elements and their ratings on all elicited constructs. For this concatenated grid we ran a cluster analyis in OpenRepGrid 4 . Its dendrogram visualization (to be seen in Fig. 2) identifies three clusters. Note that these clusters can also be easily spotted in Fig. 3. They can be described as follows:
Local Cluster (L) The first cluster mainly contains the elements in quadrant II and III of Fig. 3. Concretely it consists of the elements Headers, Title, Legends, sx:Localized Info, Values, and Formulae. This cluster contains all local spreadsheet information objects -those elements whose content depend on their position. Therefore, we can categorize this cluster as the locally perceived information objects group or in short the "local cluster". Headers, Title, and Legends build a nested cluster as well as Values together with Formulae.
Both are linked in the main cluster via sx:Localized Info. Visual Cluster (V) The second group contains all elements in the first quadrant of Fig. 3, specifically the elements (sx:)Color Coding, sx:Functional Block, and Tables. As all of them communicate information visually, we call it the "visual cluster". Meta Cluster (M) In quadrant IV of Fig. 3 we find the remaining objects: sx:Relational Arrows, sx:Dependency Graph, and sx:Concept Nodes. The most salient pole nearest this cluster that does not refer to their property of being external to MS Excel reads "meta level", therefore we call this group the "meta cluster".
To approximate the meaning of the principal components, we looked at actual, similar constructs, especially at the more salient ones close to the axes in Fig. 3. Then we tried to find categories that can serve as common denominator constructs. As this content analysis was qualitative, the reliability was ensured by following the procedure given in [10, 155ff.].
Principal Component P C 1 The constructs coming closest to the first principal component (depicted by the horizontal axis in Fig. 3) are:
Implicit Pole Emergent Pole "Knowledge Tool" "Data Tool" meta level object level UX outside Excel UX in Excel implicit info explicit info relevant for analysis relevant for understanding represents relational info represents contextual info
Here, the black entries are more salient than the gray ones (cited for clarification). The main property which the poles of this component share is that they classify the elements according to how they are used by a spreadsheet user, i.e., according to their purpose. Probst et al. suggested in [18] a knowledge management model positing that glyphs, data, information, and knowledge can be seen as stages of a pipeline as in Fig. 4. This Fig. 4. Knowledge Management Model after [18] model differentiates what we have simply called "information" so far into four distinct traits. Glyphs are just a set of characters without any structure, combined with a syntax they become data, additionally enriched by context they become information, and finally, they turn into knowledge if a semantic net or a global context is present.
Even though Brown & Duguid don't speak of knowledge as such in their model, they also suggest to go beyond information in [1]. What this knowledge might be for knowledge workers is discussed in [2]. In the following we use the four distinct traits of "information" established by Probst et al.. We will use the term "information" in its generic (naive) form as before.
For the descriptions of the implicit poles this means that the information objects were used as "Knowledge Tools", i.e., that the communicated information aims at the knowledge level. In contrast, the descriptions of the emergent poles indicate that the according information objects are being used as "Data Tools": they handle information as pure data. We can say that in this categorial construct a macro perspective on information objects is captured.
Principal Component P C 2 The second component (vertical in Fig. 3) can be described best by the following constructs: "User" computation explanation data processing semantics Both, "computation" and "data processing" are concerned with the spreadsheet as intelligent application, but also with the author who uses the application to handle her input data. Thus, the implicit pole can be summarized under "Creator" as either application or author produces the spreadsheet by computation and by data processing. On the other hand, "explanation" and "semantics" apparently refer to the meaning of the document. To contrast it with the implicit pole we therefore named the emergent pole "User", which is justified since meaning of software artifacts can only be evaluated and experienced by its users. Please note that creators are applications as well as authors, whereas users can be authors as well as readers.
Let us now combine the findings about the elements and the constructs. Note that the term "versus" in the subtitles does not signify opposition, but is supposed to enhance users' distinct context experiences implied by our subjects' construct elicitations.
If we look at the element space with the coordinate system slightly shifted according to the construct vectors nearest to the axes, then all common spreadsheet information objects are on the left side and all SACHS ones are on the right side (except for the hybrid (sx:)Color Coding which is located very close to the separating axis). The construct "object level -meta level" is one of the constructs for which rating of the elements differ: common spreadsheet objects are considered to be at the object level, whereas SACHS objects are considered to be at the meta level. Similar constructs directly distinguish standard objects from the additional ones (e.g. "UX in Excel -UX outside Excel" or even "Excel -SACHS"), thus the term "meta" could indicate a mere "going beyond". Therefore we looked at more distinguishing constructs nearby by looking at Fig. 3 from within Idiogrid with suppression 0.70 and found e.g. the following:
Implicit Pole Emergent Pole "Common Spreadsheet" "SACHS"
(−→ "Data Tools", P C1) (−→ "Knowledge Tools", P C1)
Thus, we can conclude that our subjects perceived a qualitative difference between common spreadsheet-and SACHS information objects, where former are concerned with supporting the data interface qualities, i.e., on the object level, whereas latter aim at providing a global context as interpretation help for the data interface, that is on the meta level. Spreadsheet Player versus Spreadsheet Document At first glance it was troubling that the properties of the first and the second principal component both concerned "data" and "knowledge", as they were supposed to stress differences between elements. But a closer look (presented subsequently) reveals that the macro perspective "Knowledge Tool -Data Tool" rates the elements as information objects of the player whereas a view from the micro perspective "Represented Data -Implicit Knowledge" considers the elements as information objects of the document. A spreadsheet player is the application (e.g. MS Excel) which acts as a smart interface between the spreadsheet workbook and the human reader. This player e.g. renders the workbook on screen, interprets cells as value containers, runs computations for "cells", and so on. In a sense it is an interpreter/compiler for input data. This input is given by a spreadsheet document.
The document is an intermediate data layer as it presents a prepared view on the real data e.g. stemming from a database. Note that players "play" such a pre-compilation of data, whereas documents "document" (= "to furnish documentary evidence of, to provide with factual or substantial support for statements made or a hypothesis proposed" [14]) data. The information objects perceived as "Data Tools" are Title, Headers, Formulae, Legends, and Values. They either describe data coming from some input source or work on such. They serve the purpose of enriching these input data with context, thus elevating them into information. The spreadsheet player supports the transition from data to information e.g. by simply distinguishing between various cell formats (like "text" for Headers or "date" for Values) and by computational tools for Formulae. As "Data Tools" these information objects thus belong to the document player. With the same reasoning the elements perceived as "Knowledge Tools" are information objects viewed as spreadsheet player objects (turning data into knowledge). For example, if we look at the visual cluster V from the player perspective, they serve as "Knowledge Tools" as they help the user to elevate information into knowledge.
In Fig. 5 we visualized the element distribution according to the Principal Component Analysis as in Fig. 3. The only difference is that we enhanced the distance between the element clusters L, V, and M determined in Fig. 2 to allow for a horizontal grid to depict the distinctions discussed in the following. In light of the discussion above we interpret the first PCA component dimension as spreadsheet player dimension. In particular, we used the knowledge management model components glyph, data, information, and knowledge (Fig. 4) as scale for this axis. The exact location of these on the x-axis of Fig. 5 was determined by observing the specific transformation function of the spreadsheet player's information objects in terms of the model (see discussion above). Now, if we reconsider that a spreadsheet player is commonly considered as an interface for input data, we can clearly see that there are feature groups on the way from non-interpretable glyph to desirable knowledge e.g. as foundation for financial decisions based on the data.
Another aspect under which information objects are perceived is given by the second principal component construct "Represented Data -Implicit Knowledge". This categorial construct deals with the spreadsheet as a document, with which available knowledge is transformed into distributable data. According to this axis the elements in Fig. 3 are spread as information objects of the document, because the elements are rated with respect to their communication capacities. For instance, Tables are the most ex-pressive in terms of representing data, whereas the elements of the meta cluster M are the most expressive in representing implicit knowledge.
The perceived distinction between spreadsheet player and spreadsheet document is even more remarkable as clarification discussions with some of the interviewees revealed that this distinction was not an explicit one. Prompted to differentiate between the two, the subjects were surprised and not able to distinguish the concepts continuously.
Spreadsheet Author versus Spreadsheet Reader In Fig. 5 we took the element clusters from Fig. 2 into account and stressed their clustering according to the second principal component P C 2 , that refers to information objects of the document. Now we can interpret the distribution of information objects as document features as a communication timeline starting from retrieving available knowledge up to compiling it into a message. Note that the individual clusters thus show an ordering. Depending on what the document author wants to stress, she makes use of the offered information objects. From this we can cautiously assume that the distinction between a spreadsheet's author and a spreadsheet's reader is also perceived. To express the author's intention the degrees of liberty are highest for the elements of the visual cluster V, then follows the local cluster L and are lowest for the meta cluster M. A reader on the other hand can abstract from the author's design by using more and more information features along the data interface axis (Fig. 5). We suspect the underlying reason for the controversial location of Headers and Title in Fig. 3 with respect to this differentiation to be that the content of headers is implicitly already specified by the choice of data to be shown, whereas the title is more general and can thus be more freely chosen by the author.
As the document view is strongly correlated with a spreadsheet author's view, and the player view correlates with the reader's perspective, we can reformulate the dichotomy of "document versus player" as "author versus reader". This gives us an interesting second view on the phenomena involved.
Local Objects versus Global Objects in Spreadsheets As we have seen above our subjects perceived the spreadsheet application objects as different from the SACHS information objects. But it is noticeable that sx:Functional Block and especially sx:Localized Info are close to the separating line in Fig. 3. Only these elements together with (sx:)Color Coding (which can also be identified as an MS Excel information object) are also local to where the (user-)action is in the application, and by that perceived to belong to the application. Even though sx:Dependency Graph, sx:Relational Arrows, and sx:Concept Nodes are also triggered by local actions of the user, they are far more distant. This is a clear indication that this attribute makes a difference for a spreadsheet user. Together with the dichotomy of "author versus reader" above, we can interpret that the position of an information object relative to the spreadsheet is relevant to readers.
In this paper we presented a repertory grid study that investigates properties of information objects in spreadsheets in order to better understand the information qualities given by the SACHS extension for human-spreadsheet interaction. We found four different evaluation schemes for information objects in spreadsheets (see Fig. 6). The strongest quality dimension is the distinction between spreadsheet player and spreadsheet document. In particular, information is experienced differently, when associated with the spreadsheet player or with the spreadsheet document. A good example is the use of Formulae: as a player object the resulting values are considered factual data, as a document object these values are considered to contain implicit knowledge. We conjecture that the distinction between a document player and its document is strongly perceived by users in general, even though this study shows this only for spreadsheet applications. If so, then this has extensive consequences for future design options. For instance, we can distinguish between a presentation player like MS Pow-erPoint and a *.ppt file. Most services though support only document-independent features and miss out on the document-dependent opportunities. "Grouping of shapes" for example is a nice feature to ease copying or moving of a set of shapes. The fact that they "belong together" is only appreciated on the object level, whereas it very often targets a meta level as well: their semantics.
Another extracted dimension is the distinction between information objects in common spreadsheet applications and ones in the semantic spreadsheet extension SACHS. This is especially pleasing, as we conclude that such additional semantic services are new wrt. common spreadsheet features. In particular, the analysis of the RGI shows that features of the semantic extension do not duplicate already existing features of spreadsheet players. They are perceived by users as additional services targeting implicit general information provided by the player and specific information anchored in the document. They are conceived as features that transform information into knowledge. This doesn't prove the usability of SACHS itself, but it opens a new area of spreadsheet user requirements. Note that this can be generalized beyond spreadsheets as well. For instance, the sx:Dependency Graph can also be used for lectures in a presentation application like OO Impress or in a CAD application like Autodesk Inventor.
The distinction of local and non-local positioning of information objects is also of consequence for general application extensions. For instance, this is made use of in [3].
Last, the perceived differentiation of spreadsheet users into authors and readers allows a much better fine-tuning of services. Even though the existence of both groups has been recognized, the interface design for players has not yet seriously taken this distinction into account. A *.ppt document e.g. serves divergent needs of a lecturer versus a student, but basically only former are paid attention to.
All in all, this work has shown that semantic extensions of spreadsheets are perceived as offering distinct functionalities, that turn spreadsheets from data interfaces to knowledge interfaces.
Acknowledgement This work has been funded by the German Research Council under grant KO-2484-10-1.