Notes from 11-09-10 Portfolio Visioning Meeting
Portfolio Visioning Notes from 11-09-10
- Janice Smith Three Canoes
- Robin Hill, University of Wyoming
- Lynn Ward, Indiana University
- Debbie Runshe, IU/IUPUI
- Jacques Raynauld, HEC Montréal
- Teggin Summers, Virginia Tech
- Bob Squillace, New York University
- Shoji Kajita, Nagoya University
- Ryuichi Matsuba, Kumamoto University
- Hugo Jacobs, LOI
- Nancy O'Laughlin, University of Delaware
- Hiroshi Nakano, Kumamoto University
Agenda
- Introduction of new participants
- Report on Portfolio Personas
- Report on Portfolio Reports
- Creating a list of possible names for Portfolio MiniSpecs
Notes for November 9, 2010
Three new participants, Ryuichi Matsuba and Hiroshi Nakano from Kumamoto University and Shoji Kajita from Nagoya University, who are interested in institution-wide portfolio systems and consortium-wide portfolio systems.
Portfolio Personas
- http://confluence.sakaiproject.org/display/OSP/Portfolio+Personas
- https://spreadsheets.google.com/ccc?key=tOgflcWjbDQxGDAxnI60e8w
Lynn: Three groups of scenarios are emerging: 1) assessment (people at program level, assessment cooridnator, dean, assessment committee), 2) class level (instructor is guiding force), and 3) user level (student or portfolio owner is the one in control, learning and tracking their own development). Not hard and fast categories. Hope that by grouping them this way, we can identify one scenario to represent the others as the primary scenario for identifying needs and personas. Then will look to existing persona set to see how to tweak the personas to fit the scenario. Now have a nice set of needs, moving toward the identification of personas, have the scenarios, all of which are needed for identification of minispecs, which is the principal method for identifying requirements for Sakai 3 (OAE).
Lynn and Shoji: OAE is the current development name for Sakai 3.0. The Sakai Board has authorized it for now.
Teggin: How can new people get involved?
Lynn: Next target is to identify the primary scenarios for each of the three groups of scenarios and then look at existing personal set to see if they can be tweaked to accommodate the scenarios. Also deciding on additional personas, for example, an external person, an advisor, common roles that emerge in the scenarios.
Janice: How about international input into the persona identification process?
Lynn: Cheryl is part of the group and may be providing input after she returns from conferences.
Teggin: Can provide information for advisor persona. Can talk to advisors at Virginia Tech.
Lynn: Personas are supposed to be archetypes. We will want to get input from many sources about advisor roles at a variety of institutions. It would be great if new people could read through the existing scenarios to see if they are representative. If they are not, we invite new scenarios.
Robin: The persona technique is based on goal-directed design, which is well documented. We have departed somewhat from the original process.
Lynn: Archetypes are syntheses of real people, looking for key characteristics that are typical, a handful of characteristics that influence the way a particular role might interact with others. Try to create personas that represent the range of characteristics and attitudes. Synthesis of multiple interviews and multiple people into one that pulls together the essential traits.
Robin: You can look at the original personas information from the Fluid project to see where this process came from. http://wiki.fluidproject.org/display/fluid/Personas
Hugo: Are you looking for personas all in the same department?
Lynn: Existing personas for Sakai for faculty and students are all in separate departments. Can we change their departments but not some of their essential characteristics? If changing their departments would make them inconsistent or incompatible, we could not do it. But hope to put personas into families that would allow a full life cycle within a specific department. Try to use make use of the ones we have. Designers are trying to keep the numbers down.
Hugo: You want to reflect a different set of people within the same role to provide guidance around portfolio building?
Lynn: Need for someone to be an assessment coordinator or administrator, have someone in role of formative feedback or summative evaluation. There are cases where faculty from other departments are brought in to do evaluation on general education portfolios, so we might be able to use some of the existing people.
Hugo: You can have two people each essentially doing the same thing on the other end of the communication. If one is anonymous and the other is really the persona, perhaps you can prevent duplicate scenarios. Using anonymous individuals around one person who is really carrying the weight of the scenario. Like a movie, where you have the main actors and the participants.
Lynn: MiniSpecs have thus far been written from the point of view of one persona. There may be different needs associated with the same activities performed by different people. May not need a full spectrum of all the players. We may not need, for example, two evaluator personas, for a scenario with multiple evaluators. Can tell the story from the point of view of one evaluator.
Hugo: Also important to prevent duplicate scenarios.
Lynn: Will try to identify personas for primary scenarios. MiniSpecs do not represent all needs.
Next meeting for Portfolio Personas has been rescheduled for Friday, December 3, 12 noon EST. See Portfolio Personas.
Portfolio Reports
Jacques: Learned from 2.x that the data being stored in XML makes it hard to get the data out to display in reports, so the discussion turned to technical requirements about databases. It is related to MiniSpecs, to what activities we want to do in reporting. But a discussion about backends in data processing would be interesting. Trying to convey to the people who will be writing the code what kind of needs we have that might have an impact on their work.
Janice and Lynn: Discussing with Clay (product manager for all of Sakai), Alan (project manager), Edd (lead designer). Together in working with Sakai 3 Steering Group and User Reference Group (URG) - one rep each from Berkeley, Charles Sturt, NYU, IU, Cambridge, Georgia Tech - the group that currently are devoting significant resources to the project. They get together once a week to talk about the project. Their fireside chats are being recorded. What is the Sakai 3 road map? Things are progressively changing. Priorities are shifting based on needs of early stakeholders (people with skin in the game). Originally pressured to get all of our work done by December. Now uncertain of how much time we have.
Robin: Sketchy requirements definitions is a current self-assignment to the group, to be done over the next month. See Portfolio Reports page for next meeting (early December). Root page for Fireside talks?
Sakai 3 Source Documents (audio and notes)
http://confluence.sakaiproject.org/display/3AK/Source+Materials
Next meeting of Portfolio Reports TBA. See Portfolio Reports.
Portfolio MiniSpecs
Janice: How many MiniSpecs are we aiming at?
Lynn: They are fairly broad. I want to collect and present collections of my work.
Bob: The level translates into portfolio = I want to aggregate and organize content into a freely determined template. I want to comment on portfolio items in a space that is private.
Lynn: Wanting to cluster the needs in ways that help us surface the right titles. Clay is guiding the minispec process. Plain English title that helps you understand the board. Generalized title and more fine-grained activities below it.
Bob: Some of the needs on the list may be too general and need to be made more fine-grained.
Lynn: Need to be sure we focus on needs rather than technical specifications. How things are done is not relevant except in terms of specific needs.
Jacques: Learning outcomes were part of the minispec on tasks. Hard to keep track of all these needs.
Lynn: Number of minispecs will get shorter, but needs may get longer.
Hugo: possible format: As a <<role>> I want to do <<task>> to <<goal>>
Nancy: Need to group them in order to create minispecs.
Lynn: Use cases may be clustered in order to feed into the minispecs. You may need to hold several minispecs in mind all at once. Learning outcomes minispec may need to be used in a variety of ways.
Bob: I want to create and manage a group - there may be 75 different use cases for this minispec. The portfolio minispecs may be similar.
Janice: Can we move forward with naming the minispecs while the personas group is doing its process?
Lynn: The personas group may be the place where the minispecs get started. Hard to manipulate a list in confluence. Need to use spreadsheets.
Lynn: Possible way to go is to start out with the titles of MiniSpec using the portfolio action verbs.
Nancy: Look at Needs by Category on the spreadsheet to move forward.
Volunteers needed! Portfolio awaits design.