I contemplated whether to post this message in the following forum:
http://moodle.org/mod/forum/discuss.php?d=38736; but decided not to given the history of the thread and the focus on the "Portfolio Module" as a specific implementation. Somebody may choose to move the thread as required.
I'm writing to describe the Open University's (OU) planned work for development of an electronic portfolio system/application/tool for the OU's Virtual Learning Environment and to garner feedback, comments and interest from the community. The Portfolio tool the OU is proposing to develop will become a Moodle Tool and make use of many Moodle components (including current and future plan Moodle components; e.g. Forums, Wikis, Blogs, Repository, Roles+Permissions, etc.).
As a side point, I have started touch-point discussions with Matt Oquist (http://moodle.org/user/view.php?id=82371&course=5) to see if our work matches his work on the "Portfolio Module" and whether there is any scope for us to merge our two activities into one Moodle development effort. This has only started so its a developing discussion.
OU Portfolio System Proposal
The OU has spent 6 months doing stakeholder analysis to determine the OU's definition and requirements for an "Electronic Portfolio". We have done feasibility studies which included evaluating open source and commercial Portfolio Systems. We are now piloting a commercial Portfolio System within various small groups and courses within the OU.
This background study has given us a strong understanding of the current and developing trends in the "Electronic Portfolio" space and also given us the strength of will to say exactly what we think an "Electronic Portfolio" is and what the OU needs. We hope that this perepsctive generally match the world-wide trends and this posting will hopefully help us test this perspective.
2.0 Project Objectives
The OU Portfolio project objectives are:
a) To create an "Electronic Portfolio" tool that will be used by all users within the Open University community and ideally to support their life-long, life-wide learning and personal development; the latter implies we may want the tool to be made available to users beyond their study life with the OU;
b) The "Electronic Portfolio" tool will become a standard tool within the Moodle tool-set;
c) The "Electronic Portfolio" tool will leverage Moodle components and tools where relevant and as appropriate; this means we will not duplicate functionality in the Portfolio tool where they are sensibly found in Moodle and are applicable and usable;
d) The "Electronic Portfolio" tool should acknowledge and address the issue of supporting Portfolio systems provided by multiple learning institutes; this may be at the data/content level (i.e. the transfer of the "Portfolio" as a content item from one insitution to another) or it may be at the system interoperability level; where appropriate the OU will follow trends in the international standards world such as IMS (http://www.imsglobal.org/ep/index.html);
e) The "Electronic Portfolio" tool will support users whilst they are studying in a course, working in a social/group context, working on their own under the banner of personal and career development, or provide support to achieve accreditation from professional awarding bodies and profession groups;
3.0 Portfolio Definition
Formally, from a UK perspective, an ePortfolio system can be defined as a system to support reflective and self directed learning by enabling the collection (or archive) of reflective writing and associated evidence, which documents learning [and life experiences] and which a learner may draw upon to identify and present his/her learning and achievements. It encompasses the concept of personal development records (PDRs), including records that may contribute to the UK Higher Education Progress File (UK Dearing report, 1997), and extends beyond that, to incorporate artefacts which may evidence claims
made in Personal Development Records.
In practice, one cannot easily define a portfolio. One can define portfolio by its function; i.e. what does it allow you to do. But more usefully, portfolio should be defined by what you use it for and in what context it is usaeful and add value to your work (life, career or study).
The purpose and usage context of an ePortfolio within the Open University includes:
A) supporting students studying course- and programme-related requirements for ePortfolio;
B) supporting the development of portfolios of evidence for accreditation with professional and academic bodies;
C) supporting OU staff in their learning and career development (CDP) requirements.
In essence the Open Universitys ePortfolio system needs to:
A) Enable students to save study and learning related items (e.g. a snap shot of a blog, a paper, or notes from a training day). Importantly it needs to enable students to save OU study activities at a click of a button within the VLE.
B) Interrogate, manipulate and search the store (or repository).
C) Enable the students to create, save and manipulate multiple portfolios created for a range of purposes (e.g. assignments, CVs).
D) Share specific items or portfolios with others (often for feedback and comment).
There is no right or wrong answer/definition. There are common portfolio functional elements/abilities but how they are used define your definition of a portfolio.
4.0 Project Progress
The OU development team are now in what we call "System Detailed Design" phase where we translate our stakeholder consultatin of features and functionality into documented system requirements. This work has developed:
a) Use Case documentation;
b) Functional Requirements documentation;
c) A wireframe prototype to demonstrate the interaction of features and functions;
d) Working staticvisuals of user interface designs and analysis of terminology, concepts and metaphors;
These outcomes and development have been through the OU stakeholders to confirm their accuracy and we have engaged in usability sessions with real potential users to test that our thinking and recommendations are correct.
We are at the stage where these outcomes are complete in the 1st draft and requiring a 2nd draft review. It is for this reason that this posting is being made as we feel it is a good time to get feedback from the Moodle community.
5.0 The OU Portfolio Solution Details
The diagram below depicts the architectural view of what the Open Universiy Portfolio system will be:
There are many components in the diagram which demonstrates the many interdependencies inherent in an "Electronic Portfolio" system.
We have spent a great deal of time arguing and clarifying what people mean when they say they want an "Electronic Portfolio" and this debate has define for us clearly what we see as in-scope and out-of-scope of a portfolio system.
Our Portfolio system is scoped as box number 4 in the diagram.
Box number 1, 2 and 3 are specialised "Portfolio" applications (usages of a portfolio) that is built on top of a Portfolio System.
The Portfolio system needs box number 5, 11, and 12 to exists for it to work; i.e. these components are the basis from which you build a portfolio system.
Box number 7, 8, 9 and 10 are example tools in Moodle that may generate content that is to be saved in a Portfolio System. There will be many others but these boxes show the relationship of Moodle and Moodle tools in relation to a Portfolio System.
So if these are the component pieces, what follows is an explanatio of what they do......
Box Number 5: Personal Repository
When most people talk about a Portfolio System they are generally talking about a Personal Repository or Personal Content Management System or their personal local desktop computer hard drive.
This is because to create a portfolio; there must be a means to collect content, information; to organise the content into a meaningful folder/virtual organisation; and then to comment on the content item and manage its many edits and version history.
All this effort is about collating "evidence"/"content" that may be useful now or later in creating a body of work (content) called a Portfolio.
We consider the "Personal Repository" as a useful tool in its own right and should exists indepant of a Portfolio System. That is a person can have and make of a "Personal Repository" without a Portfolio System; but a Portfolio System cannot exist without a "Personal Repository" tool.
Note: the "Personal Repository" will also be the means to publish and share content with other users. On this front we see a "Portfolio" content item as just another content item to be managed by the "Personal Repository".
Box Number 4: Portfolio
In our strictest working defintiion, this component is what we call an "Electronic Portfolio" system.
Its job is to:
A) Provide a tool for a user to reflect on any collated "evidence"/content found within their "Personal Repository"; think if this as a blogging tool but the blog is always attached to some piece of "evidence"/content;
B) Provide a Portfolio Manager function to organise and collate and merge all the "evidence"/content found within their "Personal Repository" into a content item called a Portfolio; a Portfolio may be structured and supported by templates which define what content is held within it and how the content is to be laid out and visually presented;
C) Provide a Portfolio Wizard that provides an easy to use computer-mediated wizard interface to guid a user to create portfolio content items; this is akin to a program installation wizard and is provided as a structured way to help somebody create a portfolio as opposed to the create the portfolio any way you like offered by the Portfolio Manager. What the wizard does, how many wizard exists depends on the usage, the developing insitution, etc.
D) Provide a Forms Management function which allows the development of structured electronic forms and the usage of these forms to collate structured information for inclusion in a portfolio. These forms may include, name+address, your objectives, your work experience, etc. The structured nature of these information (i.e. XML usae?) means they can be computaionally munged fpr the user into a nice visual portfolio without much technical input from the user;
E) Finally a wholse set of fucntionality around admistering and creating reports to support the Portfolio system in general;
Box number 7, 8, 9, 10 and 13
We have taken the clear view that many other tools exists to create content. This includes your desktop office application (Microsoft Office and OpenOffice, etc.) and may include VLE Moodle tools such as Forums, Blogs Wikis, etc.
The portfolio system should not duplicate these functions; instead allow content created using these tool to be stored in the the "Personal Repository" for inclusion in the creation of a portfolio. The content stored will be "static snnapshots" of dynamically changing content from blogs, wikis, etc. Hey are snapshots personal to the user of the portoflio (i.e. their own copy of the content snippet).
Once the "static snnapshot" content is in the "Personal Repository", they can choose to organise any way the choose and use the Portfolio refelctive writing tool to annotate it and to use the Portfolio Manager to compile the content into a "Portfolio".
Box number 1, 2 and 3
If "Box Number 4: Portfolio" is the generic portfolio system, then Box number 1, 2 and 3 are specific applications (usage) of the portfolio system. By application I mean, they will contain reading materials, guidance on usage and support material for usage on how you make use of a portfolio system and its features and functions to do specific tasks such as Persaonl Develoment, Career Development, etc.
For example, in the Open University, we see OU courses that use an electronic portfolio system as an example of an "application" of a portfolio system.
Box number 11 and 12
These demonstrate that the Portfolio system will depend on Moodle for roles+permissions and user+group management.
Box number 6
This box demonstrates that the "Personal Repository" is a subset of a more generic repository system to be provided by Moodle.
Note: See this discussion on the proposed generic repository system (http://moodle.org/mod/forum/discuss.php?d=43689)
We see the Portfolio System being built on the proposed generic repository system described in the aforementioned thread discussion.
6.0 Implementation Roadmap
The Open University is near the stage of beginning to build the components labelled as box number 1, 4, 5 and 6. The plan is to potentially begin code writing in mid-May 2006 and aim for first deliverable in February 2007.
This posting has a lot of detail, and I'm in danger of providing too much.
Feel free to review this proposal and feed back your comments and ask directed questions on any issues.
This proposal does not consider security of web applications. There are several known problems related to untrusted content and roles in general. We must solve these problems first.
Looking at the picture - I do not like it, because it does not look like our Moodle at all The internal design is very different.
I will think about it oday and write some more detailed explanation of my objections.
Thanh hasn't described the internal design in much detail, only a very high-level architecture overview... but I don't think there's anything fundamental that would prevent implementing this system in Moodle. Similarly, there aren't fundamental security implications to the proposal at this high level.
To give some context that may help see how it could work on a more practical level - the main connect points between this and other parts of Moodle are the personal repository bit (which is fairly non-controversial I should think) and the modules (e.g. forum, wiki). Essentially, the extension required is to make things 'portfolio-able'. Here's an example of how that could be implemented:
- Module implements module_can_snapshot() function, which returns a code string [e.g. encoding of module instance id and item id] if the module is capable of providing a snapshot of its current page.
- If this returns TRUE and user has a portfolio, then a 'Save to portfolio' button is displayed in e.g. page footer.
- Module implements module_snapshot(codestring) function, which is called when they click 'Save to portfolio'. This returns a zip file which contains content in xml - a standard or module-defined format - plus metadata [standard] about where the item came from, plus of course any other necessary files such as images. There could be a default implementation of this function that simply saves the html from the page...
- In the portfolio tool, obviously the user can see their saved stuff... should they wish to view a particular item that came from a module, that was in a module-specific format rather than a standard one the portfolio supports (e.g. plain xhtml), then the portfolio could call e.g. module_display_snapshot with the file. Obviously modules only need to implement this if they provide information in a nonstandard format.
(The University is closed for the Easter weekend i.e. until Tuesday. I will try not to get involved too much in this thread since it's not my business, but just to let others know, most likely Thanh also will not reply to any comments until then.)
Furthermore, (just like the repository ) this is very similar to what I ended up doing -- which is why we're talking about helping each other out. (Though your repository proposal has standards in the design where my design was I-made-it-up-last-week.)
As the OU folks already know, what I've implemented and called the "portfolio plugin" falls under box 4. I found the same needs they've identified along the way, so I wrote some access controls (box 11) and a repository system (boxes 5 & 6).
Box 13 has been in my plan since the beginning, but I've been waiting for the ongoing Roles and Permissions Architecture discussion to progress before I work on box 13. (I've been busy the past few days with my own education, so I haven't done further work on that yet.)
Boxes 1, 2, and 3 are interesting. I was working with the idea of "multiple portfolios" at one point, and my sponsor talked me out of it. What my implementation has ATM is just a collection of portfolio artifacts that are "in" or "not in" a "portfolio", which consists ONLY of an ownership specification that allows for group publication control. (i.e., the user owns portfolio artifacts that are "not in" her portfolio, and once an artifact is placed in the portfolio the "portfolio" owns that artifact. The user owns the "portfolio" and can publish it as a single unit.) The UI for all of this is much weaker than I want it to be, but I haven't had time to improve it yet.
I like the Reflective Writing Tool in box 4, and of course we had the same sort of idea here. Our thought was to have one text input box (HTML form option someday...) for student "reflections" and then a forum discussion attached to each artifact for interactive discussion between a portfolio advisor/teacher and a student. I haven't yet looked into how difficult it will actually be to re-use any of the existing Moodle discussion/journal/blog/whatever code to attach something like a conversation to an artifact.
Forms management is cool and has only ever been in the back of my mind, unless I misunderstand what you mean by the term. Definitely good to do, and I haven't yet thought about how.
Gotta run for now. I'll reverse-engineer and come up with some design documents for my implementation soon; I'm hoping within the next week or so.
>>I haven't yet looked into how difficult it will actually be to re-use any of the existing Moodle discussion/journal/blog/whatever code to attach something like a conversation to an artifact.
Good idea, I have simpleblog_0.3.zip module in my Moodle. It shouldn't be all that difficult... one would hope anyway. It has various settings- learners can have personal blogs (only teacher can view) or learner community blogs and is attached to a forum discussion. No setting for artifact yet (or I completely missed it)...
The plan is to add "Blog this" buttons everywhere around Moodle which will start new entries with a backward reference to the thing you clicked the link on.
We feel that our ideas are similar to Matt's existing work, just extending it. In some areas there's quite a lot of extension and in others, not a lot.
Our ideas for forms management can be thought of as similar to the database module. I can assure you that wherever possible we'll be drawing on what Moodle in general and Matt's module already have, and we certainly have no plans to make sweeping changes to Moodle core.
Sam's description of how an existing Moodle module could be "portfolio-enabled" is pretty much exactly what we had in mind, unless any-one has a better idea?
I don't want to go into too much detail, as I'm sure Thanh will do that. However, he's on leave all this week, so I wanted to post a quick response so that you know we're not ignoring you .
We're planning to work on the excellent base Matt has provided this summer, extending it with a few things the Cal State system needs for an ePortfolio system (there are new program assessment requirements which are becoming essential for the US accreditation process).
So we are hoping that work we do on this will be extendable into future versions, of course.
This is the link to the California State University system's ePortfolio site:
For partners, and other folks who want to see Moodle really take off in the US, this statement is a key indicator that ePortfolios are going to be a next <big thing> in US education:
Basically, we're thinking of a two-tier verification. One tier would be peer to peer where other students verify each other's work and the higher tier is where some-one with a level of authority can verify a student. This verification could then be submitted as part of a portfolio to an accreditation agency.
What we haven't worked out yet is how to give the verifier access to the Portfolio module if they're not an OU staff member, but that's more of a back-end admin issue.
I've been focusing on my own schooling for the past couple of weeks, so I haven't been very active on the three fronts where we're talking: repository, roles/capabilities, and electronic portfolios. I have a paper due next Tuesday, and after that my schedule should clear up a bit to allow moodling.
And you're right, based on what you've said so far our approaches to Moodle-based portfolios are very, very similar. I was just talking with my client the other day, and I said that your proposal looks like 150% of what we've implemented and 110-115% of what we're seriously planning to implement.
Anyhow, I'll be back later with more substantial discussion.
Of course one question then is, how to extract the data from whatever object is currently being viewed (Forum message or thread, blog entry, quiz transcript, wiki pagem etc) in a consistent way, in order to stuff it into this xml file with the metadata.
I am not a programmer, but I am assuming that there is a set of functions somewhere in a library for each module, that knows how to retrieve the contents from the in order to display them. It can't go to the database directly, as the structure may change with future upgrades. Does anyone have a list of these library functions for the more common Modules?
Sorry if you've seen something like this question elsewhere recently - I thought I had posted it in here last week, but have not been able to track it down since.
A pragmatic approach to getting an e-portfolio working for users is important but specifying now to be able to meet future implemented standards should be attempted i would have thought?
Will this OU implementation take the future needs of a schools>FE>HE>.... ePortfolio into consideration?
You're probably also aware of the Dearing Report which suggests exactly what you're saying - that a schoolchild can carry their ePortfolio through into F&HE.
Standards in this area would make that a lot easier! We've also been tracking the IMS ePortfolio and content packaging specifications as ways of moving portfolios around, and we'll be keen to support any emerging leader.
I've just returned from Easter break and finally got round to reading the above commentary and also made further contact with Matt Oquist.
As an update:
1) the Open University is still comitted to delivering a working portfolio solution in February 2007 with two further interim releases in May and September 2007 follow by the final full release version in February 2008. Within these four release dates we will add further functionality.
2) Code building and actual development is scheduled to begin next week (May 2006).
3) We've scheduled in 4 months of actual coding followed by 4 months or trainining, deployment and administration needs to get the system live and up running for out students in February 2007. Within the 4 months of "deployment" planning, actual coding will still continue but not as our primary activity.
4) We will follow a Rapid Development Methodology of delivering workable components each month and doing incremental build. So hopefully, for those interested they can follow our development and play with our various build releases on a regular basis.
With ref: to collaborating with Matt Oquist's work, I've reviewed Matt's work and although conceptually we are very much in agreement, I feel we cannot build on Matt's work without refactoring much of his code or adding a lot of very needed missing functionality. On this basis we will borrow ideas from Matt's work where relevant but effectively write much of the code from starting point and building in sensible connections to ongoing projects elsewhere (such as the repository proposal and roles and permissions proposal). I sounded this view with Matt and I'm discussing with Matt as to how best we can ensure his ideas are not lost but at the same time get to a stage where the Open University will have a portoflio system that does what we need but also would meet Matt's needs and those that have used Matt's implementation. I've also asked Matt to contribute his time and effort to our work. Will update you as the discussion pans out.
In response to Micheal Penney's posting, I note you are planning to use Matt's work this summer. Apart from doing this, are you (Micheal) interested in discussing your requirements with us and also getting into the nitty gritty of what the Open University is proposing. It would be nice to see what we are developing meets yours and Cal State's future needs.
Having said that, I reiterate my call for interest to you all. Are there people out there interested in contributing their time and effort to help us develop the Portfolio system. I foresee we can compartmentalise various devlopment work and allow people to work remotely to contribute to our effort.
I will post another update next week and hopefully provide links to our design documentations and user interface visuals so people can see the extent of the work that is going to be undertaken.
Feel free to ask me questions.
This is a really cool idea. I'm not in the education community on a formal basis, so I hadn't heard of the eportfolio concept before. It seems like it could work very well for students and professionals alike. It would be an excellent tool for corporate/technical training as well. Companies could generate reports to show what wonderful, qualified employees they have, and the employees would have this great eportfolio to use in furthering their own careers and interests!
I can't offer any technical help right now, as I am a real newbie at moodle and all the structures that support it, but I think it's a great idea!
Thanks for the positive words of encouragement.
Yes, internally, we are investigating whether we can deploy the ePortfolio tools to our staff. That is to say, staff should use the same tools that student uses. And for staff, the focus is on staff professional development, etc. There's many internal political hurdle for us to go through, so whether we will do it or not is another time and issue... but the potential for coporate/staff training is there as you say.
We're building the system in serious earnest now, and I would hope to releasing something that people can play with in a couple of months time prior to our formal release date in February 2007.
Can you advise as to when the OU portfolio module will be available for release?
We're also wondering how authentication in terms of assessment evidence can be met. The commerical e-portfolios have separate "tick boxes" for:
- assessor - checks learners work
- internal verifier - checks assessor correct
- external verifier - from awarding body - checks all work
Would this be possible, as it would be a key need for us I think.
I'm a project manager for the E-portfolios and am very interested in the success of your project.
What would you suggest we as a school district looking to pilot Moodle and Eportfolios for students now?
We have full access to moodle and are in negotiations with the Office of Learning Technologies.
Please provide a suggested timeline on the benefits to using Moodle and E-portfolios for the layman. We are looking to sell this project to teachers and students in the next academic year.
Interesting ideas generated as a byproduct of your input. Looking forward to further the discussion on eportfolios and moodle.