LearnPress

Open-source content management system for education combining a publishing platform with a learning objects repository.

I designed and built LearnPress for LEARN NC at UNC-Chapel Hill between 2005 and 2011. It powered, among other things, the North Carolina Digital History project. The original application was built piecemeal over several years to serve internal needs, and it quickly outgrew its initial design in both scope and use. In 2010, working with one full-time developer, I began a full rebuild and upgrade to rationalize the code, improve performance, expand functionality, and ease back-end use. When I left LEARN NC in 2011, version 2.0 was in the final stage of development, but I never had a budget to complete it. This document gives an overview of LearnPress 2.0 as I left it in 2011.


LearnPress combines a state-of-the-art professional web publishing system with a digital library (or learning object repository). It is designed primarily but not exclusively for education.
Version 1.x has powered the LEARN NC website (www.learnnc.org) since 2006. Version 2.0 is in development. This document describes LearnPress 2.0.

Core digital objects

Digital content in LearnPress consists primarily of four types of digital learning objects, which share common metadata:

Pages

A page is essentially a single web page: HTML and related content that can be fit into a wrapper. Like the content of a blog post, it does not contain HTML header/footer, site navitation, etc. In addition to HTML markup, editor tools permit the following:

  • Content may be provided for title, subtitle, body, sidebar, and footer.
  • Catalogued media may be embedded into pages.
  • Footnotes may be created and automatically numbered, referencing catalogued bibliographic entries.
  • Annotations may be made to page content, which are accessible via mouseover.
  • Terms may be defined to create an inline glossary, or may be referenced from an existing dictionary.

Media

Media include images, audio, video (including Flash elements), and documents. Media objects are catalogued individually and may be inserted into pages.

  • Images may be uploaded and automatically resized for display via editor tools.
  • Audio and video display are designed to be HTML5-compliant for compatibility with all modern user agents and devices.

Editions

Pages may be strung together into editions, which may be organized into chapters and may have front and back matter like a book. Editions may range in scope from a slideshow to a digital textbook.

External resources

External web pages may be catalogued as learning objects and assigned standard metadata (see below).

Metadata

All objects share certain core metadata, including keyword tagging, creator/provider information, copyright and licensing, publication status, and optional standards alignment.

Helper objects

To support the main types of learning objects, the following types of “helper” objects are provided:

  • Person records: Including contact information, bio, and photograph, to be assigned as creators of objects.
  • Organization records: to be assigned as providers of objects.
  • Terms: With definitions, may be added to page glossaries.
  • Works cited: Bibliographic entries that may be used to create a bibliography for an edition or as citations in page footnotes.

Projects and groups

Each object is assigned to a project and (optionally) a group (or sub-project).

  • Users may be assigned various levels of access to specific projects and groups, including reviewer, author, and editor.
  • Projects may have unique templates (see below).

User access and display

Templates

Unique templates may be designed for pages, editions, and projects. Templates define appearance, layout, general navigation, and available functionality.

Searching

A faceted search permits users to browse or search learning objects by standard metadata.

Playlists

Learning objects (pages, editions, media, external resources) may be organized into playlists with context-specific framing and annotation. (Examples of playlists might be unit plans or weekly student content.)

User management

A self-registration and user management system will be bundled with LearnPress. Users have default levels of access to content assigned by site managers and may be assigned additional access to particular projects or groups.

User functionality

Draft functionality for (non-admin) user functionality exists, including commenting and the ability to make playlists.

Administrative tools

Administrative and editorial tools use jQuery and AJAX to provide continuous database access, autosaving, and integrated editing of object records. This is considerably cooler in practice than it sounds here.

All object records can be searched, sorted, and accessed by project, full-text search, and various other available metadata.

Administrative users may create and save “views” — essentially bookmarks to frequent searches of content. (For example, “pages in development” in a given project.)

System requirements

LearnPress is built in PHP/MySQL and uses jQuery for editing and adminstrative tools. It requires PHP 5.3 and MySQL 5.5; jQuery is bundled with the application. For media uploads, LearnPress requires write access to a directory and all subdirectories. If clean URLs are desired, an .htaccess file is used, which requires that the app be running on an Apache server.

Development needs

  • Administrative area. A great deal of work remains to be done in the administrative area, followed by cross-platform testing and refinements based on alpha testing with potential editorial staff.
  • User management. The existing application uses LEARN NC’s registration and user management system. Another open-source application has been tested but will need to be fully integrated. If that in turn needs to talk to an existing registration system, further work will be required.
  • Templating. Existing templates are LEARN NC-specific, and new templates must be developed.
  • Documentation. Documentation will be required for editorial/administrative staff, template designers, and developers/system administrators.
  • User functionality. If public user functionality is desired, the draft functionality will require considerable work.
  • General cleanup. Considerable cleanup will be required before the application can be handed off to other developers or technical staff.