OERca2 doc
From openmichigan
Contents |
[edit] Introduction
Development and subsequent usage of OERca (open educational resources clearing application) have provided vital information in understanding the architecture, usability challenges and feature requirements required to support the dScribe process being employed to open up educational resources at Michigan. Some of these observations have allowed us to enhance the initial feature set that was present at launch while others have revealed the limitations in the current design that make it challenging to provide needed functionality. The current version of OERca is the result of 3 "phases" of cumulative development and it is stable enough to be used by dScribes in a production environment. However, it is now showing its age and phase 3 of development has revealed that adding new functionality is becoming increasingly challenging.
This document intends to articulate the importance of and method for developing a second version of the original content and decision management software. OERca version 2 (O2) would serve to greatly reduce the amount of redundant tasks users face in managing and clearing educational content allowing the process to scale to the level envisioned by the team and reducing the need. This document also tackles the problem that the initial software base was built as a student project and patched over the course of a year. The proposed restructuring of the database will provide a solid foundation from which we will be able to build more modular code which will allow for more flexibility and greater interoperability with other linking systems.
[edit] Issues with Version 1
The original development of OERca, or "the Tool" (as it was initially called), began in late 2007 within the realm of a student-led project around finding a sustainable way to publish OCW. A single developer worked hand-in-hand with a few people acting as content publishers. The publishers were trying to process course materials while inventing a publishing model that could be distributed among many individuals. Much of this workflow was captured in the software, with some abstraction of the steps involved in order to make the software more flexible in case needs changed in the future. This has allowed us to build on the existing system, but it has also limited our ability to streamline tasks and automate processes within the overarching publishing process. The tight development schedule for coming up with a resource to support the workflow has placed several constraints on the current software architecture, particularly the modularity and extensibility of the tool.
OERca requires a number of adjustments of which are listed here:
- built-in licensing forms for faculty, students
- automated content object extraction from .doc, .pdf, and .ppt files
- automated slide/page conversion to images for .doc, .pdf, and .ppt files
- user-defined organization of content
- automated and bulk metadata and action assignment to content
- multiple roles for individual users
- sub-division of tasks (to-do lists, assignments)
- complete bridge to CTools/Sakai
- streamlining of the editing process (metadata tags, licensing)
- video processing (perhaps through BlueStream)
- dScribe-dScribe user interaction
- reduce the need to manipulate content within external applications
- interface to deal with multiple authoring platforms (Connexions, Google Docs, others)
- complete "dashboard" of user status (connect to task lists)
- instructor review for cleared materials
- (see other OERca2 Functionality)
To implement these changes, a new database foundation will need to be put into place. Also, a completely new interface will be required to add the organization functionality (see below: drag-and-drop bins).
[edit] Audience for Version 2
We spent a considerable amount of time trying to understand the various user groups who might find a tool like OERca useful within their set of activities. Our user scenarios touched on faculty, students, staff and dScribes within the U-M system, as well as faculty and students from countries with limited ICT resources. We did not cover every type of audience, so we invite suggestions to do further exploration. One of the main takeaways from this exercise was that we need a better understanding of users in developing countries. We seemed to be making a lot of assumptions backed by brief research articles or experience. This made a strong case for holding off on developing a version of OERca for that population segment until we've gained more knowledge about those potential users.
Through the user scenarios we have learned that OERca, in its current state, addresses a number of potential problems with remote collaboration (central file system, "unlimited" file size, version control). However, we also learned that a more adequate collaboration tool requires a functioning bridge to an institution's CMS/LMS, metadata requirements for search upon material upload, greater assistance in content processing (open licensing help, etc.), document/site annotation that includes adding media as commentary (CloudSocial?), and the potential for crowdsourcing the search of replacement content. The scenarios also pointed out that OERca could do a better job of facilitating collaboration between the dScribe and faculty (adding citation information for COs, completing the final faculty review, online licensing of materials). Lastly, we learned that OERca is not and probably will not become an authoring tool. The structure and design of the current system does not lend itself to this type of work. With this in mind, any future versions of OERca need to be capable of bringing in authored content from any system (or at least the popular systems).
See OERca v1 User Scenarios for more details about the types of audiences we envisioned and their interactions.
In addition to user scenarios, we have been conducting outside demonstrations and testing of OERca. We have been encouraged by the positive response from other individuals and institutions to the tools we are employing, particularly OERca. The demonstration that was conducted during the OpenEd conference in September 2008 at Logan, Utah generated several trial account requests from conference participants. We also heard several people remark that an application like OERca was essential to the publication process of OERs, but nobody had taken the time or effort to built it. It appears that O2, if the design were flexible enough, may be adopted at other institutions.
[edit] User Interface and Functionality
For more details on this section, see Jacob's user report (PDF) on OERca usability and his theories for the use of personalized content management and organization.
[edit] Personal Workspace Model
OERca version 2 should present the user a with home page or personal workspace from which all other functions and features are quickly accessible. This page should keep users within three to four clicks of anything else in OERca. Such a page would present a visualization of the entire dScribe process relevant to each particular user, as well as presenting all permitted OERca functionality occurring within this personal workspace. A link to this page should appear in a locked position on the screen. A personal task list should be part of this personal workspace. Gmail has recently released an impressive task list interface which should be looked at as a model. The feasibility of automatic task list updating should be discussed.
[edit] Workspace According to Role
The specific information and layout of the home page will vary according to the user's role. dScribes, dscribe2's, instructors, publishers, and administrators have different processes and different needs within OERca. For instance, the home page for a dScribe should illustrate the process of collecting content, evaluating the content, recommending and executing actions, and progress in each of these domains should be represented. A dScribe2's home page would feature pending questions from dScribes or faculty, content objects which need approval before a final action can be taken, analysis of the progress of dScribes or specific courses, and requests for the legal team. Instructors' home pages would include a collection of items which need final instructor approval. Additionally, users need to be able to maintain more than one role, and possibly keep separate workspaces for each of their roles.
[edit] Bins
One of the key functions of the personal workspace model is to aggregate users' bins. O2 will shift the process of clearing items from assigning content objects a status or action to moving content objects from location to location according to actions that are required of given objects. This model was developed to take advantage of location based information management, which Barreau and Nardi (1995) demonstrated to be superior to list based organization. This concept is represented metaphorically in OERca as "binning." Users organize their work across the entire process by using bins to organize their work. Bins become "to do lists" and help users manage their time and efforts giving clear indication of progress. They make it easier for users to find content, as testing and literature have shown that the location based model is beneficial to personal content management. One of the most important steps in developing this model is determining the specific categories which will be represented by bins, as well as determining the appropriate level of customization that users should be permitted. Testing and surveying dScribes has generated some data, but more is needed before final determinations are made.
[edit] Auditing/Reporting
Tracking the actions performed on a Content Object and identifying the people involved in performing those actions helps make the clearance and annotation process more transparent. It also provides more accurate information on the time involved in processing content and helps estimate the costs involved in opening educational resources. Reports will provide aggregated information at several different levels of granularity and provide and overall view of the processes involved when working with content.
[edit] Other Features
[edit] Notification System
Efficient communication between OERca users is critical to its usability. An important feature of O2 will be a status tracking and notification system that operates entirely inside of OERca. This system should make it easy for users of various roles to clearly identify and reference specific content objects, courses, materials and users within OERca so as to minimize the navigation required for users to extract context from messages. One of the goals of this notification system is also to indicate changes to content within the system. [NOTE: This messaging or notification system would behave differently than email or IM because it would collect and send information about actions to content as well as user-generated comments about content. A tool like CloudSocial might help in this area, though an internal system for documenting actions and notifying users is important. However, CloudSocial is currently based on a page-centric approach which may not lend itself well to a drag and drop application modeled on a desktop thick-client style interaction model.]
[edit] Action Recommendation Assistance
Of particular value to dScribes will be a module which aids in navigating through the Recommended Action Decision Tree. This module could not only help dScribes in their decision making, but it could record their decision making process. This metadata could be valuable in determining legal questions, as well as for future designs or improvements to OERca. This will most likely look like the image examples (casebook) that we have discussed in legal meetings. The examples could be expanded to show actual decision commentary to help users understand rationale behind those decisions.
[edit] Import/Export of Content
Import and export of materials and content objects should be carefully considered and documented so O2 can work with a wide variety of authoring and publishing platforms. Ensuring proper interoperability with authoring platforms for incoming content and publishing and presenting platforms for outgoing cleared content is essential to scaling the entire OER publishing process and encouraging external adoption.
[edit] Technical Notes
[edit] Bins
The proposed binning model can be realized well with the drag and drop functionality that is available in many of the widely used open source javascript libraries like jQuery , Yahoo UI, Dojo. In addition to simplifying content clearance, drag and drop can also make it significantly easier to add metadata to content and reduce the amount of repetition that current dScribe1s have to suffer. This idea was provoked by (i.e. shamelessly stolen from) Yahoo Pipes http://pipes.yahoo.com/pipes/ which provides a very elegant, intuitive and powerful way to build content processing pipelines. The LAMS2 project http://wiki.lamsfoundation.org/display/lamsdocs/Home also has a drag and drop based UI for authoring learning activities.
Bins should be both drop "destinations" and themselves draggable. The workflow can be represented by bins arranged in specific order. Institutions can represent their specific workflows as compulsory steps in the bin layout. They can contribute back their workflow layouts to allow new adopters to simply modify existing layouts instead of creating their own from scratch. Additionally students should have the ability to create their own bins and filters to facilitate the process and provide some flexibility to automate tasks that are specific to their work within the OERca application. This maintains OERca's flexible abstraction of workflow while allowing for streamlining of sub-processes.
As an example of this adjustable workflow model a dScribe could create a filter/bin that can then be used to assign a specified set of metadata to any object dropped on it and selections of multiple objects, or objects within other bins could be sent through the filter to add any specified metadata.
[edit] Database
There is currently no formal data model that represents the database schema. The database schema has evolved on an as-needed process as was required to support OERca functionality. As a result, even the developers don't have a fully resolved picture of the data model and how the database represents it. Model classes and methods replicate functionality and further complicate data manipulation operations.
The next version of OERca should aspire towards a clearly defined data model that is accurately represented in the database schema. This will be particularly helpful with the Authentication and Authorization functionality which is neither as secure nor as robust as we would like. The gaps in capability are likely do the limitations imposed by web framework authentication plugin currently being used and the next version should either build in or use components that fully enforce acls providing robust authorization checks and controls.
A data model that allows creation of custom filters and bins needs to be fairly abstract. We have to be mindful of the fact that entities that are currently statically defined within the DB schema will likely need to be defined as data since some bins will be dynamically created and destroyed while others will only be manipulated on a per-institution basis. End-users will likely not be granted access to delete bins that represent the content clearance and annotation workflow.
[edit] Development Resources
This section lays out the various tasks and sub-tasks required to begin development of O2. For each of these tasks we will attempt to define what resources are necessary for completion.
