Summary

The Interface Cell has been active in the initial design and refinement of potential user interfaces for Monk, as well as in the preliminary implementation of some of these designs. Some of the challenges confronted in the design work have included 1) designing complex workflows for an audience less familiar with relevant practices; 2) finding visual ways to convey information to literary users 3) choosing appropriate terminology. We have also recently begun developing a visual identity for the workbench. Some of the challenges confronted in the implementation work have included 1) settling on the most appropriate technologies to use given our particular mix of expertise and availability; 2) developing a flexible, modular workbench framework that allows our current tools to exist and future tools to fit in.

Design Work

We set out with the goal of designing a functional system that can run in a browser and has enough innovative components to interest new kinds of users, those not already working with MONK-style software. We recognized that this system would need to provide a variety of different functions, which could be mixed and matched into task flows. Drawing for inspiration on the use cases, other project discussions, and toolsets being developed by similar projects, we created a list of proposed tools. We divided these tools into three types: basic, enhanced, and experimental. Basic tools should contain the minimal functionality for MONK to be useful. Enhanced tools should allow for more complex processes. Experimental tools should push the envelope. Here is our current list of tools, using the language we currently propose for the user:

• Select documents using a list
• Select documents using columns
• Select documents using facets
• Select documents using magnets
• Select random documents
• Select documents using a hyper-graph
• View results
• Read text
• Search
• Search by example
• Search by taxonomy
• Explore feature list
• Explore feature overview
• Explore relationships
• Construct a timeline
• Visualize sonic colouring
• Explore geography
• Manage project
• Manage workset
• Re-visit workbench history
• View statistics
• View graphs

By combining these tools into toolsets, we hoped to allow a set of clear paths into using the MONK system, rather than overwhelming users with choices. Since MONK is a complex collection of functions, it is overwhelming nonetheless.

Choice of Implementation Technologies

By far the most time-consuming step has been determining an appropriate set of technologies for the user interface; essentially that has taken from March to September 2007 to really settle down. The choice hasn't been taken lightly, as we want to avoid developing a bunch of tools and then needing to re-implement them in a different framework a year later.

Some of the recurring priorities for the technologies are as follows:

• attractive and slick
• cross-platform
• works fast
• capable of animation
• capable of scaling for showing many items
• incremental loading of content
• no download required
• able to host or interact with other technologies (Java, Flash, etc.)
• decent control over typography
• XML or JSON support for data interchange
• ability to simulate state
• ability to log (for testing, user undo, and possibly collaboration)

We surveyed and experimented with a wide range of potential solutions, including OpenLaszlo, Flash, Adobe Apollo, Adobe Flex, Echo2, GWT, ZUL, YUI, EXTJS, JQuery, MooTools, jMaki, RAP, etc...

Among the most significant distinctions were the following:

• client-side vs. server-side management
• embedded objects (Flash, applet, etc.) vs. native browser support (DHTML & AJAX)
• level of programming language (given our current personnel)

Toward the end of the summer, as the idea of a Monk Workbench was taking form, we had narrowed things down to two main options:

• RAP, an Eclipse-based server-side framework for building rich web applications
• a custom, client-side Javascript framework, based on EXJTS

Although RAP has much to recommend it, we decide that the technology was 1) a bit premature; 2) too difficult to customize currently; 3) too demanding to develop (essentially in Java). Shortly after the Kramer Pond Hackfest, we decided to pursue the custom, client-side Javascript framework.

Monk Workbench

Given the diversity of functions that we want to provide to users, we had two choices: 1) build a series of autonomous "boutique" applications with little or no interoperability; 2) build a framework able to support several very different types of procedures. This realization, and the desire to have some visual and functional cohesion across different applications, led us to imagine a Monk Workbench - a single environment that could host different types of applications, while reusing common modules as much as possible.

One of the important aspects of the Monk Workbench architecture is that it splits the functionality of the individual components and the outer shell (or "window manager"). As such, the same tools can be packaged and presented in different ways, as can be seen from the current Monk Workbench welcome page (from the SVN directory - this is not stable).

Development is currently focused on a new Workbench manager, one that more closely resembles the Alberta interface sketches. Among the defining features are a desire to see toolsets - with some similarities to analytic recipes - in pre-defined and editable bundles, as well as a desire to see more animated flow between the pages (rather than one page replacing the previous one).

Immediate and Future Challenges

We have several mostly developed tools (NoraOL, FeatureLens, Monk Workbench), though they are incompatible in small but significant ways, especially with respect to proxy calls. One of the highest priorities is a thorough re-examination of needed proxy calls. We need to plan carefully so that when individual components need a specific call it can be implemented quickly and in a fairly stable manner. We keep saying that we're thinking about the Proxy calls, but things have remained relatively ill-defined; we need a new strategy for revamping the Proxy.

We need to make it easier for others to develop new components, which really means we need to complete and update existing Workbench documentation. The workbench is designed to allow for modular, distributed development, and we now have to make that a reality if we hope to go beyond the applications we already had.

We have made some bold choices for the user interface design, such as the toolsets workflow metaphor. We need to have several iterations of usability testing with actual users to ensure that our choices have been sound and to help refine the current designs.