University of Michigan - Portfolio Authoring
Michigan has done extensive work to improve the experience of authoring portfolios. We have worked closely with students to understand their needs and frustrations and have developed a number of enhancements. These concentrate on a concept we have informally dubbed the "scaffolded portfolio", which provides suggestive guidance, but attempts to avoid any hard requirements.
A scaffolded portfolio is implemented with an OSP Portfolio Template and generic Forms, used one per page of the final presentation. The intensive work with learners has concentrated on showcasing work, in terms of leadership and research, so the pages fall in two categories: Basic Page and Example of Work. The augmented editing mode for Metaobj Forms is locally referred to as the "Page Composer".
Issues being addressed:
- Lack of context and styling
- Ease of losing work
- Sustainability across projects
- WYSIWYG editing in context
- Autosaving / navigation blocking
- "One Big Editor"
- Separate portfolio assembly from Matrix
- Standardized, structural HTML/XSL
- Pure CSS themes
- Generic Metaobj Forms
Lack of context and styling
When using the standard configurations for editing portfolio content, the result is quite unsatisfactory. The stock settings for the FCKeditor result in an editing area that is small and does not apply the final styling of the content. It also does not provide any of the surrounding target context. This causes many delays by forcing learners to preview the content repeatedly and attempt to compensate for styling or layout without predictable results.
Ease of losing work
When editing content that is personal and intended to have specific styling, it is very easy to spend a great deal of time in one editing session. Given that the content is meaningful and takes extended effort to create, it is very frustrating to lose this work. Any number of small mistakes or glitches – such as hitting backspace without a text field selected or a network connection dropping – can cause confounding loss of work.
When working with portfolio content, expressive ability is important to the learner. This means, primarily, that rigid structures assuming too much control over the final output or difficulty in completing a familiar task like aligning an image are very discouraging. These impediments actually hamper creativity and limit both the content and formatting of finished portfolios.
Sustainability across projects
The technique that has emerged as standard practice for working with Portfolio Templates involves extensive XSL work, specific to the kinds of Forms and Matrices used for a given project. Minor variations to those structures or the output are difficult and time-consuming, and present significant sustainability concerns when working with multiple projects.
WYSIWYG editing in context
The most pressing demand from users is to not be surprised by how their content is presented in relation to what they can view while editing. By placing the FCKeditor within the visual context of its destination and applying the target CSS rules to the editor, a nearly WYSIWYG experience is delivered. This removes the slow and frustrating steps of saving and previewing with each adjustment.
Autosaving / navigation blocking
To avoid the loss of work, two overlapping strategies can be applied. These are autosaving of the content and prompting for confirmation when navigating away from an editing page. The combination strategy covers most common data loss scenarios redundantly for high confidence.
"One Big Editor"
To address the expressiveness concerns, it is reasonable to consider each "page" of a Portfolio as a single, large, editable area, surrounded by some structure and navigation. This avoids the need to create and modify Forms to collect data, and then subsequently display the structured data. It also allows the learners control of more of each final page, which is almost universally requested.
Separating portfolio assembly from Matrix
A common strategy is to provide learners with guidance on a suggested portfolio structure. Within OSP, this can be implemented by developing Portfolio Templates that reference a Matrix structure and specialized Forms. Doing this provides some standardization, but at a high development cost due to complexity in the XSL, and a cost of user expressiveness. An alternative strategy lets learners select the individual artifacts for inclusion, which reduces complexity and allows remix capability for different target audiences.
To deploy the strategy outlined above, the Scaffolded Portfolio and Page Composer have been developed. Here are overview and more technical diagrams, respectively:
Standardized, structural HTML
Rather than using HTML specialized for a given layout, we have created a generic structure that has a limited number of semantic components. There are header and footer sections, primary and secondary navigation, and a container for an unbounded number of "pages", to be shown or hidden with script. This shift has proven to have extreme cost advantages by reducing the XSL maintenance to near zero.
Pure CSS themes
With structural HTML in place, everything for layout and styling can be applied with pure CSS. This simplifies skinning dramatically and allows design talent to be applied without requiring intricate XSL modifications.
Generic Metaobj Forms
Another major component of the cost of maintaining the XSL transforms for presentations is the reliance on specific Form elements. By simplifying the portfolio model into using generic "page" Forms, the XSL relies only on minimal structure, which can be used by convention. Combined with the generic HTML, this allows very cost-effective variations of a Portfolio Template with almost no modification to the complex underpinnings.
In order to deliver the experience of the WYSIWYG editing with on-the-fly theme selection, autosaving, auto-sizing editors, and the switching between embedded pages in the final presentations, script support is needed. The custom Form creation, Form viewing, and Portfolio presentation XSL files provide a place to reference script files without modifying the Sakai build. This flexibility has proven essential to evolve the experience in real-time. Hosting the files within Resources is an elegant solution that requires no extra infrastructure.