In his recent post, Daniel Tunkelang issued a call for renewed interest in recall as a measure of performance of information retrieval systems, particularly for exploratory search tasks. It is interesting to note that there are several possible ways to measure recall and precision for interactive tasks, and which measure you should use depends on what aspect of the entire human-computer system you are interested in.
Daniel Tunkelang’s recent post on Twitter search got me thinking about what an HCIR geek would do, which produced the following random thoughts.
First, we should start with tasks. What kinds of information do people want to find in tweet streams? Do they want to find a document that’s been referenced? Do they want information about an event? Are they interested in finding a community of interest? What other useful tasks are there with respect to this stream?
In an earlier post, I described Waterworth and Chignell’s model of information exploration, and distinguished in from other theories ad models of information seeking in that it tried to address some aspects of interaction.The main problem with the model is related to the structural responsibility dimension. Structural responsibility models “who [system or user] is concerned with the structure [of the data]”, but since the user can only interact with the constructs exposed by the system through the interface, and the same structures can be expressed in many different ways, this dimension fails to capture a distinction that’s useful for design.
In his Hypertext ’97 keynote address, broadcast from the US to Southampton, UK, Ted Nelson lamented that (for the hypertext community) the Web was like waking up one day and discovering you had a teenage son, who was a juvenile delinquent. There was much concern among hypertext researchers that the web in general (and Tim Berners-Lee in particular) had gotten it all wrong because they had ignored the years of scholarship about how to build hypertext systems.
What does it mean to collaborate while searching?
There are many different ways to characterize collaborative information seeking, many dimensions on which collaborative search systems can be categorized.
For the past few years Jeremy Pickens and I have been thinking that our model of collaborative exploratory search needs some further explication. Or maybe we’re just trying to understand it better ourselves. We have found that to explain what our model is, we have to simultaneously explain what our model is not. This has led to numerous discussions not only about the various dimensions of collaboration, but also about the relative importance among those dimensions for distinguishing between systems.
Our paper on conference room automation got accepted to CHI 2009. We describe the DICE system and report on about a year’s worth of use during its deployment at FXPAL. The system uses a task-based user interface to manage meetings in technologically-enhanced conference rooms. Unlike AMX or Crestron systems, it integrates with the file system and supports multiple speakers. Each speaker can specify how the room should be configured independently, and the system manages the transitions between speakers.
SDForum’s Virtual World SIG (which I co-chair) and Women in Technology SIG celebrate Ada Lovelace Day by holding a joint SIG meeting featuring a panel of women who build, create, and work in virtual worlds. Panelists come from both industry and academia, and will discuss their work in virtual worlds.
The SIG is Monday, March 23, from 7 – 8:30 PM; networking (and pizza) starts around 6. It’s held at the Pillsbury-Winthrop offices in Palo Alto, off Page Mill Road. It’s free for SDForum members, $15 non-members.
Recently, I’ve been involved in a lot of discussions about exploratory search on this blog and in comments on The Noisy Channel. One way to look at exploratory search (and there are many others!) is to separate issues of interaction from issues of retrieval. The two are complementary: for example, recently Daniel Tunkelang posted about using sets rather than ranked lists as a way of representing search results. This has implications on one hand for how the retrieval engine identifies promising documents, and on the other for how results are to be communicated to the user, and how the user should interact with them.
Last June, Gary Marchionini hosted a workshop on Information Seeking Support Systems, which I was privileged to attend. The workshop brought together researchers from industry and academia for two days of stimulating discussion about systems, models of information seeking, and evaluation. One of the results of the workshop was a Special Issue of IEEE Computer that Gary and Ryen White edited.
We published a position paper at the workshop, and followed up with an article for the special issue, out today. We look broadly at collaboration in information seeking, including some motivating scenarios of use, a model of the design space, and a short discussion of roles.
This is the same issue that Daniel mentions in his post.
Update: IEEE says they are undergoing a “software changeover”, and expect the TOC to be up early next week.
Update 2: The online copy is now available from IEEE and on our web site.
The upcoming CHI 2009 conference will be the 20th consecutive CHI I have attended. My first CHI was in 1990, where I discovered the field of Human-Computer interaction, a term I had not come across in my undergraduate education as an electrical engineer.
One of the most memorable experiences at CHI was a tutorial on “Hypertext” taught by Bob Glushko. The concept was fascinating, and Bob was a good teacher. He did, however, say one thing that struck me as a challenge. He talked about nodes, links, and anchors, and said that to build hypertext systems, you needed a “graphics display and a mouse.” At the time, I was working at UCLA in the Office of Academic Computing (OAC) as a consultant and programmer. UCLA was an IBM shop, and we had a bunch of 24×80 green-on-black IBM 3178 (and equivalent) terminals. No mouse, no windows, no graphics. But we had something called ISPF, which allowed the program to read the cursor location on the screen, and VSAM with which I built a crude inverted index of our local online help.