Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Sakai 3 ePortfolio (UM)

High Level Portfolio Requirements

The following high level portfolio functions are described in more detail by the Portfolio-related vignettes page.

  • Customize
    • templates and styles must be easy for non-technical users (Students/Faculty) to create and use
  • Present & Collaborate
  • Guide
    • Fine grained permissions
  • Collect & Associate
    • Portfolio artifacts must be available to both free-form (expressive) and guided/structured portfolios
  • Workflow
    • Email notification (opt-in)
  • Reflect
  • Evaluate & Feedback
    • Inline comments/feedback, rubric-based feedback
    • Email notification (opt-in)
    • Multiple evaluator workflow
  • Export
  • Share
    • All artifacts (images, etc) included in a portfolio must be easily viewed by any shared user
    • Email notification
  • Report
    • Aggregate student responses (with student id) into comma or tab-delimited data that can be pulled into SPSS
  • Tag (lesser priority pending user stories; supported by underlying Sling framework)

Legacy Portfolio Wish List

This section describes features that UM has wanted but been unable to implemented due to limitations with the underlying OSP framework. All have been mentioned above.

Multiple Evaluator Workflow

  • Matrix cells (and other completed artifacts) must allow evaluation by multiple users
  • Matrix cells (and other structures) must allow multiple types of evaluation (different forms specific to roles or users)
  • Users must be able to request feedback or evaluation on arbitrary completed components to site members or anyone
  • Guiding users (instructor/evaluator) must able to lock and "hand off" components to users who will take further action before returning an item to a student. (Per-item workflow phases). 

Additional Permissions

  • Users granted the ability must be able to edit instructions inside a Form or for a Cell without the full "Manage Matrices" permissions.

Bugs

  • Artifacts linked or submitted through a portion (cell) of the portfolio must be available to the users that may view that portion (cell); also written up as "Embedded images in resources not passing through security advisor" in http://jira.sakaiproject.org/browse/SAK-7464

Email Notification

  • Users must have the ability to opt into email notification for certain events (cells becoming available, being submitted, etc.)
  • Notification opt-in must provide useful batch operations such as enabling notification for all Matrices, Matrices within a specific site, a group of cells, new requests for feedback, all new pending evaluations, etc. (i.e. scope of email notification must be configurable).

"Matrix" Batch Operation

  • Batch operations must be better supported (e.g. changing a group of cells to available)

Reporting

  • Aggregate student responses (with student id) into comma or tab-delimited data that can be pulled into SPSS

Dashboard with filtered and aggregated views

A dashboard would provide a singe place where users can go for cross-site access the OSP tools, keep track of upcoming requirements, see what feedback has been requested or received. Gonzalo's original mockups and specification are available at http://confluence.sakaiproject.org/confluence/display/OSP/UMichigan+-+OSP+Dashboard.

Filtered Views

  • Users must be able to filter a view to only those items that they may interact with
    • Students must be able to filter to just those cells that are available
    • Instructors must be able to filter to just completed cells that are pending evaluation
  • Users must be able to filter or sort by recency of request or status change on a list of items Beth: What is an" item"?
  • Users must be able to filter a view to those items where another user has requested interaction (feedback/evaluation)

Aggregated Views

When using OSP in any volume, the multiplicity of sites and tools becomes very cumbersome, fracturing the integrative experience. Providing a single location where users can then navigate in portfolio-specific ways, rather than site- and tool-specific ways promises to alleviate much of the confusion and frustration.

  • Cross-Site Aggregation
    This is similar to the "synoptic" views, where a specific tool is placed in My Workspace to show the user, for example, Announcments from all of his sites. With respect to OSP, the user may complete artifacts within any sites, even those that are not specifically involved with portfolio methodology. The user may also be in multiple sites that do employ components of portfolio methodology. The user must be able to interact with content from all of these sites from a single location.
  • Cross-Tool View Aggregation
    To couple with cross-site aggregation, the user must be able to view artifacts and portfolio components from multiple tools. With respect to OSP, this means that a user must be able to view Matrices and Wizards, for example, in a single list. This type of aggregation is not currently present elsewhere in Sakai because each tool has a specific task-oriented purpose. The closest similarity is the integration between Assignments and Gradebook, where placing and viewing grades for a specific assignment could be expected to happen in either tool. The OSP tools are currently problematic for users because they are so numerous and the "task" is always some level of portfolio interaction.
  • Scope Adjustment Mechanisms
    The user must be able to "drill-down" to and search for content or interactions that are presently relevant. Seeing every item of every type from every site is likely to overwhelm almost all users, but overviews and complete lists are essential to some needs. Providing the "knobs" to "tune in" to certain types of information, specific sites, or other filtering will be absolutely necessary. These features should be very responsive (AJAX).

Inline Feedback

  • Ability to associate inline feedback in a database with a completed form
  • A mechanism for the user to request feedback from a portfolio page
  • A mechanism for the mentor to enter feedback directly in the portfolio page
  • A mechanism for the student to select which instance of feedback to view
  • A mechanism to view the selected feedback
  • Email notification upon request for feedback
  • Email notification upon submission of feedback
  • Several CSS styles to mark up feedback, such as a highlighted yellow background for inline feedback and a blockquote-like style for extended feedback.

  • No labels