UserPreferences

ScholarsBox/StatusSummary200402

  1. What I hope to do here
  2. The big picture
  3. Scholar's Box in the small
    1. Longer term changes in the interface
  4. Scholar's Box in the large
  5. Writing, writing, and more writing
  6. Working with the CDL
  7. Mellon crosswalk work
  8. Other areas (outline)
  9. Chandler
  10. Browser extension
  11. Web interface to ScholarsBox

What I hope to do here

I want to write a high level summary of the status of the Scholar's Box as of February 2004.

We are pushing ahead on our technology work, getting user input, writing grant proposals, continuing partnerships, fulfilling obligations all at the same time. Sorting all this stuff out in a nice coherent package is what I hope to do here -- without going into too much detail.

The big picture

At a recent meeting focused on the CaliforniaDigitalLibrary/MetasearchInfrastructure, I presented a list of goals and deliverables that I find helpful in framing the work I'm involved with.

Goals

  1. To provide software that will allow various key audiences (K-12 teachers, college and university faculty, librarians, etc.) to access and work with materials of interest to them

  2. To develop a sustainable business plan.

  3. To provide a model that other people can contextualize and use in their unique situations.

Deliverables:

  1. Scholar's Box "in the small" (the software)

  2. Scholar's Box "in the large" the idea, plus technical frameworks implemented elsewhere

  3. The documents that describe it, plan it, and contextualize it

  4. How all that aligns with things happening at CDL

How are proceeding on the goals and deliverables? We touch upon a lot of topics because I think that we have to -- writing about the perceived relevance of different topics is helpful for clarifying how important things really are.

I want to establish clearer relationship to ScholarsBox/EssaySeries/TopicsList.

Scholar's Box in the small

By Scholar's Box "in the small", I mean the actual software and not the architecture/ideas/grand vision represented by the ScholarsBox.

The software is moving along; TomSchirmer is putting the bulk of his focus on it. I'm in the middle of describing the current state of the ScholarsBox. ChrisAshley is pushing forward on the user interface of the prototype.

We know that we will need to build the ScholarsBox incrementally. Hence, we have gone after building prototypes that are purposely focused to specifically functionality instead of trying to embody all the functionality that could ultimately be reasonably included. For instance, the first round is the ScholarsBox/ImagePrototype, in which we are developing a PythonLanguage based desktop client to allow users to gather and organize digital images from their own collections and digital repositories and create interesting new things from these images, including ThemedCollections and LearningAlbums. Truth be told, the functionality has expanded beyond images specifically. We know that there are different ways to generalize our approach, along any of our ScholarsBox/AxesOfGeneralizability, for instance.

I started to articulate "architectural issues" of the current prototype: ScholarsBox/ImagePrototype/ArchitecturalIssues. While building the ScholarsBox/ImagePrototype, we have made pragmatic decisions about how to knit functionality together. We've tried to make good design decisions that have some hope of being generalizable -- but haven't spent a lot of time pounding our head to make sure that this is so. The list of architectural issues are those questions that we know we need to address to get to the next level although we can get pretty far without addressing them immediately. (Another good list is to be found at ChrisAshley's [WWW]blog. (For instance, we haven't taken on the issue of metadata reconciliation: how metadata from different sources can be mapped to one another. This can come up if we start trying to translate metadata from one format to another.)

There's been a lot of expanding pure functionality -- and there needs to be a balance with a focus on knitting that functionality coherently. For example, we are working on ScholarsBox/NsdlIntegration because it helpful to see how hard or easy it will be to do that integration to enable us to gauge the suitability of writing a proposal. The hard part is exactly how we envision these materials being used in concrete detail. Much of our mental model has been around the gathering of objects where we haven't had to provide much functionality aimed that internals of the objects.

Where we need to go -- push on turning the ScholarsBox/ImagePrototype into something usable, even if it is for a limited domain. One approach: for me or someone else to sit down and use SB as it stands and write in excruciating detail what hinders our use of it. One that occurs to me immediately is that a lot of my research is based on searching the Web. Though we have a google search and we can grab URLs, we can't grab HTML per se. Do we want to do that? Then is it possible to build some simple annotation system for that? (I use AdobeAcrobat in exactly this way.)

Although the ScholarsBox is not designed for me per se, I do find it helpful to think about what the ScholarsBox would look like if I were the primary (and perhaps sole) user. Why is it helpful to me? I know the user and what the user wants; thinking about a concrete user grounds the software and drives integration of the functionality into usability; I'm a cutting edge user -- and so designing for that user can surface techniques/usages that people who aren't so tech-savvy will want. The downsides are essentially the mirror-image of the putative advantages and are well articulated by people like AlanCooper ScholarsBox/DesignedForRaymondYee

Longer term changes in the interface

In many regards, I would like the interface to be more browser-like. There is an openness, expansiveness I-can-go-anywhere/I-can-go-to-related-links freedom that our current interface doesn't have. In other words, we don't have browse functionality but just search at this point. How to correct. Some brainstorm: build on top of Mozilla; use MultivalentBrowser; look at a browser in the WxPython widget set.

Scholar's Box in the large

Writing, writing, and more writing

Working with the CDL

Mellon crosswalk work

Other areas (outline)

Chandler

The ChandlerProject is extremely promising as a foundation for the ScholarsBox. It's at [WWW]version 0.3 right now (just released). Exciting and timely stuff:

I have written previous notes about the ChandlerProject -- but it was geared to version 0.2, which I believe is substantially different from 0.3 in many ways.

Write about the pros and cons of using the ChandlerProject. (Explain a bit about what Chandler is.)

Next steps if we go the ChandlerProject exploration route:

Browser extension

Why care about "rich clients" at all? Isn't plain HTML good enough? To let users do the type of authoring with SB that we envision. Also, we would like integration with desktop files/apps while working in SB.

The browser is in many ways a natural home for the ScholarsBox. At this point, the ScholarsBox doesn't support the type of browsing that is what web browsers are about. A possible strategy: build an IE SB toolbar to give some basic functionality and then point people to the full desktop client for those who want more functionality.

Might be helpful to say what NetSnippets is and how ScholarsBox is different.

Probably: a big con of such models is that the browser extensions don't allow full integration with the desktop because of security models. I might be wrong about this point though. At any rate, security models are very important aspects of looking at browser extensions. Note the implicit assumptions: when people download apps to install, the apps basically have free reign over the machine. And that works generally because people have to think about whether they trust the source of the apps. When the application comes via the browser, the assumption is that users shouldn't have to worry about trust issues every time they go to a page. Hence the differences in security issues.

Use the [WWW]imagedrag bookmarklet to make the point that the browser can be fundamentally different. (writeable web)

Might talk about MVC to talk about where would like to go with our architecture.

Distinguish between:

Make connections between surface and deep web. Use CDL as an example.

We could try building ScholarsBox as an extension to a browser such as MicrosoftInternetExplorer or MozillaProject. (See, for example, how NetSnippets builds on IE and the ConnexionsProject builds on the MozillaProject.) If we built ScholarsBox on top of a browser, we would be taking advantages of the underlying infrastucture of a browser. Ideally, one could build such an extension so as to work in all "standards-compliant" browsers. The way that I know that might be along those lines is to use DHTML. But in [WWW]my (admittedly limited) experience, cross-platform DHTML is hard to pull off and is limited in how deeply one can get into the guts of a browser because of (different) security models and because the conceptual models of browsers might not lend themselves to the types of extensional functionality that we want to build. (Indeed, it is the promise of such additional flexibility that gets me exceited about the MultivalentBrowser. The problem with the MultivalentBrowser approach, however, is that it is not widely used and that it is not sufficiently refined for daily use.)

To really get at the pros and cons of going with a browser-extension approach, one really does have to distinguish among the different browsers. Let me try to do such an analysis here.

Browser Pro Con
MicrosoftInternetExplorer Widely used closed, proprietary
MozillaProject open source/ interesting and possibly powerful extensibility not widely deployed (yet)
MultivalentBrowser

Conclusions

Web interface to ScholarsBox

Right now, we are building the ScholarsBox as a desktop client written in WxPython. But what about building a web-based interface? Why do it? If we want to do it, how might we proceed?

Lots of the pros and cons are generic ones for all web-based vs desktop-based apps. Some pros and cons are specific to the ScholarsBox app.

I should be clear here by what I mean by web interface: something that can run on a wide range of web browsers without the need for plugins....

(Actually, as I write this section, I'm beginning to see that there is a real continuity of solutions between "browser extensions" and a "web interface". They share in common the use of a "web browser". Sometimes the browser is already installed. For example, MicrosoftInternetExplorer. Other times, one would have to download it -- MozillaProject.)

Although writing ScholarsBox in MacromediaFlash can be thought of as a type of Browser extension, it really deserves its own categroy.

Make sure to talk about pros and cons.

Pros:

Cons:

UI work: starting with the prototypes we've already built (for presentations)

backend migration: PythonLanguage based vs other frameworks, such as JavaLanguage-ones.