Rendering Navigation and Information Space with HoneyComb TM
Bill McDaniel, edp DERI NUI Galway, Ireland
[email protected]
Sebastian Ryszard Kruk DERI NUI Galway, Ireland
[email protected] ABSTRACT
Motivations
The growing amount of available information poses challenges not only in the process of information retrieval. The usability of the rendered search process and results can be increased by appropriate visualization techniques or new interaction paradigms, or both. In this article we present the HoneyCombTM paradigm, an information visualization style that aims to render and manage large quantities of information items. We describe the design objectives and the prototype of HoneyCombTM . Finally, we present a short evaluation of the HoneyCombTM paradigm in the context of search and browsing.
One of challenges for the new eLearning is providing an ability to align and present learning material from various sources, both formal and informal. Users should be able to intuitively discover, choose, and share accessible courseware material. Browsing courseware augmented with informal learning
The standard courseware consists of a chain of learning objects, delivered in the predefined order, with content tailored for everyone. More and more solutions, however, take into account other sources of learning material, such as wikis, blogs, and fora. These sources, cannot be directly integrated into the courseware, since their pedagogical quality is often questionable; they are, however, a source of interesting, and sometimes necessary, auxiliary learning material. Some of the learning systems allow users to select alternative paths between a number of predefined coursewares.
Author Keywords
visual paradigm, information rendering, browsing ACM Classification Keywords
H.5.2, H.5.3, H.5.4, H.1.2
These two requirements, i.e., the ability to align learning objects from different sources, and allowing users to browse and learn using alternative paths, define our first motivation for building a new visual paradigm. The paradigm should be capable of representing learning objects, tracking user progress, showing main and alternative paths of learning. The main shortcomings of existing solutions were that these solutions could be used only for visualizing a path, or paths, of learning objects; other solutions that could visualize the graphs were too hard to use by average users, as they have been built to deal with complex graphs.
General Terms
Design, Human Factors INTRODUCTION
As the Internet is evolving towards the Web of interconnected media, people, and services, so is eLearning shifting focus towards taking into account informal learning. As we have presented in [5] social semantic information sources, the social media bound with semantics, can be a valuable source of information for future eLearning solutions. The rapid development of new aspects the Internet, including new eLearning solutions, poses new challenges to the research on the human-computer interaction. In order to provide efficient interaction with this challenging source new visualization paradigms are being invented. Graph models support the aforementioned networks of people and information; they are, however, harder to understand by average Internet users. Most of the solutions for rendering information and user interaction concentrate on presenting a tree that is a part of the underlying graph model. Users very often do not understand the concepts and models underlying these visual paradigms. Some of them, e.g., a hyperbolic view [6], require well developed understanding of interactions in 3D environment; other, such as pie-menu view [1], are too simple to encompass large sets of information. Quite often the centralized point of view, offered by the visualization, requires unintuitive interaction when it comes to browsing other parts of the information.
HoneyCombTM interfaces should allow developers to represent various learning objects, their relations; it should allow them to be interconnected or drawn closer, or both. Multilevel History of Faceted Navigation
The social semantic information sources are a growing space of information. In order to navigate through it and discover interesting concepts, solutions like faceted navigation [8] on unstructured metadata [7, 3] are gaining more interest. While building MultiBeeBrowse [4], our collaborative browsing solution, we had to resolve certain usability issues, related to more advanced features of the system. There are two features of MultiBeeBrowse (MBB) that were motivation to work on the HoneyCombTM paradigm: (1) MBB allows users to keep a multilevel history of actions, i.e., query refinements. (2) Users can perform one of four combination operations (intersection, sum, difference, and binding) on two 1
HEXBROWSER - THE PROTOTYPE OF HoneyCombTM
sets of previous results of the faceted navigations.
In this section we will present the prototype implementation of HoneyCombTM as an AJAX component called HexBrowser. We will start with design objectives and technology used. We will analyze the surface function, which is one of important assets of this prototype. Finally, we will conclude with description of a system where HexBrowser, and hence the HoneyCombTM , has been deployed.
We had to deliver an additional dimension to the history of interactions in order to answer the first requirement. The latter requirement could have been answered with existing techniques, such as selecting previous sets of results from a list; we were hoping, however, that we could enhance usability of these operations by allowing users to "drag" two results closer to each other in order to compute one of the combination functions.
Design Objectives
The prototype implementation of the HoneyCombTM paradigm had to answer a number of design objectives. We will briefly describe each of the objectives and suggest a potential solution.
Contribution
In this article we present the HoneyCombTM , an information visualization and navigation paradigm. HoneyCombTM Represents information items, represented as hexagonal lozenges, on a hyperbolic surface. It allows users to manipulate existing hexagons, open new ones on edges and corners. User can quickly zoom in and out, move to a given lozenge, and rotate the view. We describe how this visualization paradigm can be applied to eLearning solutions. We present the prototype implementation, HexBrowser, which implements most of the presented features. HexBrowser has been successfully deployed in the MultBeeBrowse, a collaborative browsing component. We show how the HoneyComb paradigm allows to implement specific features of the MultiBeeBrowse.
• Limit information overload – A growing number of presented information items can lead to information overload. HoneyCombTM does not solve that problem by default. Applying other visualization techniques, however, can help. One of possible solutions is to render hexagon lozenges on a 3D surface, such as a sphere or a hyperbola (see Fig. 1). Each of these surfaces introduces new challenges. The sphere is not infinite, which will introduce limitations on the number of information items presented by HoneyCombTM . Inexperienced users, on the other hand, might encounter problems when using hyperbolic visualization.
HoneyCombTM – VISUAL PARADIGM
The HoneyCombTM presentation paradigm utilizes the organizing features of a tiled space of hexagons to represent data presentation spaces within the usual graphical user interface space of modern operating systems. The paradigm lends itself to multi-modal encodations of meaning. Such navigational meanings can be encoded in edge interactions and colors, cell colors, spatial organization, corner interactions, and other interaction modes.
(a) Many Lozenges
Hexagons were chosen primarily for their ability to uniformly tile the plane. While it is possible to create a U-matrix display (Uniform Distance Matrix) using HoneyCombTM , it is not based on previous work done on such data visualization methods. Other shapes can be used to implement the same honeycomb style presentation paradigm, but hexagons offer the greatest number of possible encodation options [2]
(b) On the Edges of Space
Figure 1. Infinite Space and Reduction of Information Overload
The HoneyCombTM paradigm provides interface designers with a simple method for defining and drawing either single hexagonal display areas or tiled planes of hexagonal cells. The cells can then be overloaded with text browsers, video or audio players, image browsers or any other type of interface widget. Each cell can intercept user events such as mouse clicks and can also respond to drag events.
• Infinite and intuitive 3D surface – The 3D surface used to render the information items of HoneyCombTM should answer two requirements: be infinite and allow for intuitive navigation. The first requirement can be realized by the family of hyperbolic functions. They are not, however, as intuitive as spherical or flat surfaces. Hence we need to design a hyperbolic function that would render a significant part of the visualization flat-like; it should also allow a sphere-like navigation experience. This would result in an infinite surface, with part of the visualization with 3Dlike distortions, and with familiar, sphere-like navigation (see Fig. 4).
The interface components are extensively configurable to provide the developer with the ability to define the interaction model and metaphor within the confines of the hexagonal paradigm. This provides developers the ability to assign meaning to the edge interactions, the corner interactions, and the other elements of the HoneyCombTM visualization paradigm including the ability to move cells around on a screen, connecting them into new patterns.
• Assign actions to lozenges, edges, and corners – The HoneyCombTM prototype should allow developers to assign any action to mouse clicking on the content of a lozenge, an edge, or a corner. The number of direct connections between information items represented by lozenges, is limited to 6; we expect that allowing lozenges to be moved from place to place can become a remedy to this limitation. The default action should be a configurable content 2
(a) Pop-up Dialog
Figure 4. 3D Model of the Surface
(b) Visual Reponse
Figure 2. Responding to User Actions in HoneyCombTM
3D Shape of the Surface
The 3D surface used in the HoneyCombTM prototype to limit the information overload should: be infinite, provide an intuitive interaction style, allow applications to display a given number of lozenges without distortions.
window where more information related to a given part of the HoneyCombTM information system could be rendered (see Fig. 2(a)). Our future prototypes of HoneyCombTM will also allow to identify lozenges with text and icon labels rendered directly on the lozenges.
After a number of try-and-fail attempts we came up with following definition of a hyperbolic surface:
• Adapt presented visualization to user requirements – In the HoneyCombTM paradigm, the reading order does not always stay left-to-right or top-down. Hexagons introduce another, i.e., diagonal, axis; hence some information flow can go along this axis. We can also assume that when a user starts to move lozenges around, to mix-andmatch his/her needs, the flow of information might not even continue along straight lines. Therefore it might be sometimes necessary to rotate (see Sec. 2(b)) the view to adjust the flow of information, i.e., layout of lozenges, to an orientation more natural to the user. The number of information items represented with hexagon lozenges can sometimes be quite large. Hence by reducing the information overload a user might have to preform too many operations to scroll to any group of lozenges. On the other hand, sometimes it might be necessary to limit the scope to just one lozenge. Therefore, the HoneyCombTM prototype should allow zooming (see Fig. 3).
2
Surf aceHC (r, φ, z) = {z = −tan(π 2·Rr2 ), r ∈ [0, RM AX ], M AX φ ∈ [0, 2π]} Where RM AX is the maximum radius of the 2D projection perpendicular to the Surf aceHC in point (0, 0, 0). The 2D projection of Surf aceHC (see Fig. 4) resembles a projection of a sphere (see Fig. 1(a)). In our opinion, this should allow inexperienced users to ease the use of HoneyCombTM . In the future we will evaluate the quality of this definition for Surf aceHC . The default size of the hexagon lozenge with radius Rlozenge = RM AX allows for the center lozenge and surrounding ones to 5 be displayed without any distortions, while those in the second "circle" to be displayed slightly skewed. This can be, however, changed through the zoom operation.
• Visual response to user actions – One of the important features of a user interface is the visual response to user actions. Visual response becomes an issue with the growth of processing power of current personal computers. A user might not notice or understand the performed action. Therefore in operations like move or scroll HoneyCombTM prototype should leave the trace of actions (see Fig. 2(b)).
Canvas – system independent web technology
The HoneyCombTM prototype has been implemented in JavaScript using AJAX technology. There are two competing solutions to render script-controlled graphics within a web browser: SVG1 and Canvas2 . Even though the first one is designed to handle vector graphics, we chose Canvas. The main reason was extensibility and performance offered by this rendering solution. Canvas are supported by Safari and Mozilla-based web browsers. Our HoneyCombTM prototype can be run on all three major OS platforms: Windows, Linux, and Mac OS X. However, to support still the most popular web browser, i.e., Microsoft Internet Explorer, we plan to implement next HoneyCombTM prototype using Adobe Flash technology.
• Non-functional objectives – The most important nonfunctional objectives for the HoneyCombTM prototype are: extensibility and system independence.
HexBrowser in use
HexBrowser, the prototype of the HoneyCombTM paradigm, has been successfully deployed in the MultiBeeBrowse component [4]. MultiBeeBrowse is a faceted navigation solu(a) Zoom out
(b) Normal view
(c) Zoom in
1
http://www.w3.org/Graphics/SVG/ http://www.whatwg.org/specs/web-apps/ current-work/#the-canvas 2
Figure 3. Zooming in HoneyCombTM
3
scored close to base values for all the metrics: confusion – 2.6 (σ = 1.17, scale: 0–10, base5 = 2 ), number of operations – 2.4 (σ = 0.52, base = 2), time to complete the task – 53s (σ = 26.7s, base = 30s). In the post evaluation questionnaire we asked users about their opinion on the HoneyCombTM interface. The scores were given from range 1 to 10. The results were: interesting – 7.92 (σ = 1.75) , useful – 6.33 (σ = 2.23), clear – 6.73 (σ = 1.67); compared to browsing without HoneyCombTM : interesting – 6.31 (σ = 2.18), useful – 5.77 (σ = 2.55), clear – 5.38 (σ = 2.18). CONCLUSIONS
The HoneyCombTM interface paradigm provides significantly more information and navigability over search result sets as indicated by its implementation in the MultiBeeBrowse prototype. It provides a compact and engaging interface which allows the developer to encode multiple dimensions of semantics while remaining easy to use and understand. Figure 5. Results of the Evaluation
Performance-wise, MBB implemented over the HoneyCombTM paradigm resulted in low confusion and more involved user interaction, encouraging exploratory efforts by users.
tion that allows users to browse collaboratively. The HoneyCombTM paradigm is used to render an overview of browse actions performed by the user. It also allows users to perform combination queries, i.e., calculate sum, intersection, difference, and binding, between the sets. HoneyCombTM is used in MBB to render the graph of browsing actions (according to Context ontology3 ; we expect that this paradigm can come in handy in other solutions as well.
Acknowledgments This material is based upon works supported by Enterprise Ireland under Grant No. ILP/05/203 and by Science Foundation Ireland Grant No. SFI/02/CE1/I131. Authors thank Stefan Decker, Daniel Schwabe, and Peter Brusilovsky for all their help, and all members of the DERI community for fruitful discussions on this project.
EVALUATION
REFERENCES
In [4] we presented MultiBeeBrowse (MBB) collaborative browsing component. HoneyCombTM paradigm was implemented as a part of component. In this section we briefly spot-light on the part of evaluation of MBB related to HoneyCombTM . The evaluation is thoroughly described in [4]. 20 participants were asked to compare three faceted navigation systems: BrowseRDF [7], Longwell4 , and MultiBeeBrowse. The evaluation consisted of 2 parts: search and browse tasks, and a post-evaluation questionnaire.
1. J. Callahan, D. Hopkins, M. Weiser, and B. Shneiderman. An empirical comparison of pie vs. linear menus. In Proc. of CHI ’88, 1988. 2. B. Grünbaum and G. C. Shephard. Tilings and patterns. W. H. Freeman & Co., New York, NY, USA, 1986. 3. M. Hildebrand, J. van Ossenbruggen, and L. Hardman. /facet: A browser for heterogeneous semantic web repositories. In Proc. of ISWC’06, 2006.
In the search and browse part participants were asked to answer 4 questions using all three aforementioned faceted navigation solutions. The questions were: (1) Find all friends of Sebastian (2) Find all co-authors of Decker (3) Who were composers contemporary to Mozart? (4) Find all articles about semantic web but not about web services. The fourth question was designed to be answered using the HoneyCombTM interface. We compared level of confusion (1-10), number of operations and time required to complete the query (see Fig. 5). Users were asked about their confusion (to determine if HoneyCombTM supports users or not), while we measured the time and number of operations. We compare the results with the base values from the pre-evaluation done with the authors. The results show that HoneyCombTM 3 http://wiki.s3b.corrib.org/MBB/SOA#MMB_ Context 4 http://simile.mit.edu/wiki/Longwell
4. S. R. Kruk, A. Gzella, F. Czaja, W. Bultrowicz, and E. Kruk. Multibeebrowse – accessible browsing on unstructured metadata. In Proc. of ODBASE’2007, 2007. 5. S. R. Kruk, A. Gzella, D. Jarosław, T. Woroniecki, and B. McDaniel. E-learning on the social semantic information sources. In Proc. of EC-TEL, 2007. 6. T. Munzner. H3: laying out large directed graphs in 3d hyperbolic space. In Proc. of INFOVIS ’97, 1997. 7. E. Oren, R. Delbru, and S. Decker. Extending faceted navigation for RDF data. In Proc. of ISWC, 2006. 8. P. Yee, K. Swearingen, K. Li, and M. Hearst. Faceted metadata for image search and browsing. In Proceedings of ACM CHI 2003, 2003. 5 base – average results achieved by the authors of the MBB paper [4]
4
