Child pages
  • Minor UI Changes to Portfolio Tool
Skip to end of metadata
Go to start of metadata
This page contains macros or features from a plugin which requires a valid license.

You will need to contact your administrator.


Minor UI Changes to Portfolio Tool

Jira Number:

SAK-17323, SAK-173234, SAK-17325, SAK-17326

Related Jira Numbers:

(JIRA numbers as links)




Lynn Ward


October 26, 2009

Demo Status and Date(s):

Status: Suggested
Date: November 2, 2009

Part 1: Functional Description

Minor User Interface Changes for the Portfolio Tool (1)

Summary (1)

Indiana University will be deploying a customized version of the University of Michigan Page Composer environment for the spring 2010 semester. To prepare for supporting this environment, members of our portfolio planning and support team have been experimenting with the 2.6 Portfolios tool (this tool is not currently used at IU).  While the user 2.6 interface is much more attractive than previous versions, the IU team found the tool confusing.  In particular, they felt the steps required to create the portfolio were not clear without detailed documentation.  This document proposes some simple changes to the Portfolio UI, which we believe will make the tool more intuitive, although they do not completely address the portfolio workflow question.

Rationale (1)

The goal of the proposed changes is to make certain features of the tool more intuitive.  The rational for each suggestion is provided in the Diagrams and Mockups section.

Origin (1)

Describe how the need or desire for this enhancement arose, including background information about the problem it is meant to solve. Be specific about institution(s) and people who have played a role in planning the enhancement.

User Stories (1)

The User Stories should paint a picture of what it is like for a user to make use of the enhancement. The actors should be based on real users with definable tasks and goals. Include as many stories as necessary to demonstrate how the enhancement would be used by different types of users.

Actors and Stakeholders

  • Portfolio site members (primarily student participants) who are either asked to create a portfolio or decide to create one on their own initiative
  • Any Sakai user with the Portfolios tool exposed in My Workspace


  • A student wants to share her portfolio, but she has not yet filled out the outline options form.  She notices that Share with Others link is inactive, reads the red text beneath the link, and realizes she needs to complete an additional step before she can preview her work. 
  • A student wants to preview her portfolio, but she has not yet filled out the outline options form.  She notices that Preview link is inactive, reads the red text beneath the link, and realizes she needs to complete an additional step before she can share her portfolio. 
  • A student creates a new portfolio.  He is immediately prompted to enter a meaningful name.  After he selects the portfolio type, he is taken to the Portfolio Summary screen.  The title of the Summary page is the name he selected.  The portfolio is also indentified by this name in the Portfolio list screen.
  • A student is creates a templated portfolio, but has no saved form instances to select.  Instead he creates each form in the Add/Edit Content screen.  When he saves each form instance, it is already selected to be included in the portfolio.

Functional Details (may be added after community demo) (1)

Describe any functionality not fully captured in the User Stories.

Interaction and Implications (1)

Identify and describe potential interactions with existing and planned OSP/Sakai tools and enhancements from a functional perspective.

Diagrams and Mockups (3)

Portfolio Name

Prompt User for Name at Time of Creation:
Currently, when a user creates a new portfolio, the portfolio is assigned a name automatically.  The assigned name is either the name of the template on which the portfolio is based or, if the user chooses the "Design Your Own" option, the name is "Free Form Presentation".  In either case, the username is appended to the end of the portfolio name (e.g., Resume Template - leward).    If the user creates more than one free form or template-based portfolio in the same site, the default naming scheme will result in duplicate names, making it difficult for the owner to distinguish one from the other.  To prevent this from occurring as well as to help the user to recognize the purpose for which the portfolio was created, we suggest prompting the user for the portfolio name at the time of creation.




Discussed on November 2, 2009 call.  No objections, but Michigan would prefer to make the field optional.  If left blank, the default name would be assigned.

Add Portfolio Name to Portfolio Details on Summary Screen:

Our test users also felt that it wasn't obvious how to change the name of an existing portfolio. The name appears in large type at the top of the summary screen, but there is no label to indicate that this is the name. Compounding the problem is the fact that the portfolio type found in the Portfolio Details section of the summary screen is nearly identical to the default name.  While requiring the user to enter a name as proposed above will help address the latter issue, there remains the fact that nothing on the screen tells the user that the text at the top of the screen is the portfolio's name.  With the exception of the name, all other descriptive data about the portfolio are displayed in the Portfolio Details area of the screen descriptive labels with.  We suggest adding the Portfolio Name to this area of the screen and adding an edit link next to the name.  We feel that this would add greater consistency to the interface in that both the name and the description would be editable in more or less the same place and by the same method, rather than locating the edit widget for the name at the top of the screen and the edit widget for the description in a different area of the screen. 



Discussed on November 2, 2009 call.  Strong support for this change.  Michigan will try to implement for 2.7.

Required Settings (Outline Options form)

When the user creates a portfolio based on a template with an outline options form, the form must be completed before the portfolio can be made active and shared.  In the current implementation, it's easy for the user to skip the required settings before attempting to preview or share the portfolio. 


A number of changes could be made to give the required settings greater prominence and/or to prevent the user from attempting actions that should not be taken until the outline options form has been completed. The following changes are suggested for consideration.  These changes could be implemented individually or in combination

  1. Disable"Share with Others' links on Portfolio Summary Page (1a) and remove "Share" option in Actions menu on Portfolios List page until required settings have been completed (1b):

    Proposed (1a)

    Proposed (1b)

  2. Disable Preview the Portfolio until required settings have been completed:

    Proposed (2)

  3.  Move the Required Settings link above the Add/Edit content link to give it greater prominence:

    Proposed (3)

  4. Open the outline options form as soon as the user creates the portfolio.

    Proposed (4a)

    Proposed (4b)

    (Proposed (4c)

Discussed on November 2, 2009 call.  Strong support for options 1, 2 and 3.  Michigan will try to implement for 2.7.  Option 4, which will require significantly greater effort was tabled until we assess the affects of implementing 1-3.

Autoselect New Forms

Currently, when a user creates a new form within the Portfolios tool, the saved form is unselected.  In most cases, when users create new forms while adding or editing content in a Portfolio, the intention is to use the form in the current Portfolio.  Requiring the user to select the form is an unexpected behavior that creates extra work.  Instead, we suggest automatically selected newly created forms and, for selections that allow multiple selections, moving the "Create New" link to the "Selected Items" column.



Discussed on November 2, 2009 call.  Good support for this change.  Michigan will try to implement for 2.7, but may not be able to get to it before feature freeze.

Community Acceptance (4)

These changes were proposed during the Oct 26 community call and then voted upon on the November 2 call with IU, Michigan, Virginia Tech, Delaware, and Wyoming represented.  Reaction to each provided in appropriate section above.

Part 2 of the Proposal for Enhancement Template: The Specification
The specification should be filled out once the feature is clearly defined.

Specification Template (5)


Describe each specific behavior of the feature in the present tense as if the feature were implemented perfectly. Use precise, objective language to describe ideal behaviors against which actual behaviors can be evaluated.

In the case of conditions and behaviors that must be evaluated independently, they should be presented in a two-column table as below.



(Short description of mutually exclusive condition #1)

(Objective, verifiable behavior in response to condition #1)

(Short description of mutually exclusive condition #2)

(Objective, verifiable behavior in response to condition #2)

When there are workflow behaviors (steps) that must be evaluated in sequence, they should be identified with prerequisite conditions, behavior, and post-behavior conditions as below.

Workflow Steps

(Unique, short, representative name of the step)

Prerequisite Conditions or Step:

(Conditions or Step name)


(Objective, verifiable behavior)

Post-step Conditions or Next Step:

(Conditions or Step name)


List any entities or actors that are used or affected by this feature. Each should link to an entry in the OSP Terminology page.

Quality Metrics

Describe any non-functional requirements of the feature, such as usability, performance, or design. Provide objective and, where possible, quantitative measures against which actual implementations can be evaluated.


Provide any assumptions about implementation path, availability of other required features, schedule concerns or otherwise.

Outstanding Issues

The Outstanding Issues section is a placeholder for the evolution of this specific feature. It should mention any explicit design or implementation decisions that are pending. There must be no outstanding decisions as of the confirmation of the feature as a requirement.

  • No labels