It's time to get back to the Scholar's Box. My talk at RLG on Monday was invigorating, not so much for what I took to be affirmation of the Scholar's Box concept (which is nice) but more for the call to focus our work on the Scholar's Box more tightly. In our development, we have brought up way more questions than we can possibly answer at this point. The task now is to narrow down the list to a few focal points.
About half a year ago, I started the Scholar's Box Essay Series. I hedged on my commitment to the series, stating the essays would be occasional, but I'm embarrassed about how occasional it has turned out to be! I now want to jump back in. How I think about Scholar's Box has changed in important ways, but the point of entry (or re-entry) in the essays remains the same: describing the current state of the Scholar's Box. Before providing a detailed description of the current functionality of Scholar's Box, let me reflect on the events that have changed my thinking. This is a good time to reflect on what we have learned, re-examine our underlying assumptions, and determine next steps.
My current thinking is reflected in my proposed (and now accepted) talk at the Digital Library Federation Fall 2004 meeting, which I quoted Monday on my wiki. I propose to talk about the wide range of emerging gather/create/share tools, among which I count the Scholar's Box as one but only one tool of many.
Does de-emphasizing the Scholar's Box in my talk mean that I am moving away from working on the Scholar's Box? Definitely not -- at least not from the concept of the Scholar's Box, "Scholar's Box in the large", and the deployment of Scholar's Box-like services everywhere. But if I mean by the Python-based desktop client that we have been building ("Scholar's Box in the small"), then the answer becomes I don't know exactly. If I had to give my best current guess , I'd say that the phase of focused expansion of technological possibilities has ended, and that we have shifted firmly at driving our software development efforts to support greater user-friendly gather/create/share functionality that may or many not exploit the technical possibilities we have elucidated.
Let me give an example. Tom and I have been working hard to connect a web-browser to Scholar's Box so that a user can gather resources from the Web into the Scholar's Box. To want to build such functionality is not a surprise. A whole slew of web-grabbing tools have emerged (including OnFolio, Net Snippets) to enable users to grab URLs and chunks of web pages and organize them into annotated collections. One might argue that Microsoft's new One Note plays roughly in the same web-gathering space. An examination of the different strategies that we went about to effect integration of web browsing and the Scholar's Box would make an interesting discussion for another day. Let me just say that we have now decided to build FireFox extension(s) that will provide an interface for users to gather materials and to route these materials to different destinations (a basket within FireFox, the Scholar's Box running as a different application, a weblog, and a wiki are all possibilities we are considering.)
Although focusing on the FireFox and its extension mechanism is a promising strategy, it has also taken us away from direct development of the Scholar's Box. Moreover, it has prompted me to think harder about the role to be played by Scholar's Box when one can shift not only the gathering functionality but possibly the collection organizing functionality to the browser. Do we still want to work any more on developing the interface in the Scholar's Box? Probably. But what is the division of labor among the various tools? Ideally, we want to have gather and create and share functionality scattered throughout our tools in the right proportions, with our tools and our data seamlessly working together.
Pulling off near-frictionless interaction of data and tools is on many people's minds. I found, for example, Jon Udell's
analysis of "next-generation infoware" spot on:
-
From the user's perspective, del.icio.us and Flickr support near-optimal entry and exit strategies. You can deeply and automatically mesh your own information with them. And you can undo that meshing. Participation in the services is thus an "at will" arrangement. If you maintain well-structured information, you can as easily mesh it with another comparably-equipped service. So the switching cost, as economists say, is low.
(A sidenote: Udell's essay inspired a really thoughtful piece
TeledyN: Living with Webservices that I am still in the process of absorbing.)
Figuring how the Scholar's Box should interact with digital libraries, other tools, and the wide variety of data a scholar might bring into the mix is one of my major tasks in the months to come, the subject of what I hope will be a renewed essay series.
