Much has been written about ePortfolios, which combine curated archives of digitized student work, “rubrics” indicating the learning objectives the work responded to, and student-teacher commentary about how well the work met those objectives. A list of background resources is appended below this post.
While it is relatively easy for “technology pioneer” teachers to adopt some pieces of the ePortfolio model with their own students, school-wide adoption requires significant investments in visioning among administration, faculty and staff; hosting expenses (Sakai hosting starts at $300/month); LAN infrastructure (classfuls of students need to upload all their work at the same time); teacher professional development; and instructional time (processing online communication) in addition to training students to use the system.
However, all that investment can pay off. A school that implements ePortfolios will mirror the collaborative patterns in academia and industry, where research and development are collaborative, peer-reviewed, and cumulative. Such schools not only make the necessary evolution from individual training to community learning, but effectively prepare students for the world of knowledge work.
In short, ePortfolios are a high-cost, high-risk, and high-return pattern to adopt. Although the State of New Hampshire (ambitiously) required all public schools to adopt ePortfolios by a common deadline, not all schools were (or are) ready for that level of technology integration into instruction and assessment.
This post considers “Google Apps for Education” as an “intranet ecosystem” from which the patterns of ePortfolio adoption can emerge like Life from the ancient primeval molecular soup of yore.
Google Apps: an Intranet Ecosystem
Blended learning in a school environment implies online communication, creation, and collaboration in an intranet ecosystem (where outside eyes cannot pry). That ecosystem needs to handle applications, file storage (individual and shared folders), synchronous and asynchronous communications, and authentication to manage permissions for all of these.
Some schools adopt ready-made environments that handle many of these functions (e.g. Whipple Hill, First Class, Google Apps), while others have sufficient IT expertise and user flexibility to develop, integrate, and upgrade components as needed. Choices include local versus cloud-based file and application servers, and how working offline will be supported.
Schools that adopt Google Apps “cloud” are granted collaborative potentials that may never be fully actualized, as well as limitations that may never be fully uncovered, depending on the patterns of activity attempted, and the scale of pattern adoption. As tasks move from simple…
- student creates document
- student emails teacher with attached document
- teacher emails back comments
- student drafts document
- student shares document with teacher
- teacher gets email notification
- teacher adds comment stream and contextual feedback to document
- student gets email notification
- student creates new revision and responds to some comments
- teacher gets notification, etc.
…more potentials are explored, but with these, more time must be spent learning and mastering Google Apps management. Two thresholds are eventually reached:
- Time spent learning / teaching complex Google Apps patterns becomes prohibitive for all but the “early adopter” teachers and students.
- Time required for conducting the collaborative interactions Google Apps are designed to support is found to be prohibitive.
When these thresholds are reached, there is either a “cutting back” to simpler patterns by all but the “early adopters”, or a new software product, an “overlay system” integrated with Google Apps (such as Digication, Haiku LMS or Hapara) must be purchased to accommodate whatever collaborative or instructional patterns are emerging school-wide needs.
Essential patterns that Google Apps support (until they are outgrown) include project management, learning management, distributed collaboration in real-time, and digital collection management.
“EPortfolios” describes a meta-pattern involving collaborative learning, authentic assessment and digital collection management. As such, the path towards ePortfolio implementation involves pushing the capacities of Google Apps (and of faculty learning and teaching the various steps needed to make Google Apps do complex things) to their limits.
I advocate understanding all this at the outset, and accepting it….even choosing and appreciating it. Google Apps for Education is free, and supports all the “pieces” that make up ePortfolios, so serve as an excellent incremental training ground. I believe that the skills learned to make Google do these complex things will remain useful, even after an “overlay system” is purchased to make ePortfolios easier for everyone. Also, once faculty appreciate the need for the additional system after trying to make “Google native” behave like a full ePortfolio solution, the new application will be more likely welcomed, rather than bemoaned as “yet another log-in.”
An overlay system for ePortfolios needs to be a school-wide (or district-wide), long-term commitment, so that digital artifacts follow students and through and past graduation. Preparing for this commitment, a Google Apps school can pilot two or three systems, at the point when faculty and student have sufficient experience with existing limitations to appreciate what the pilot system makes possible.
ePorfolio Patterns with Google Apps
In the example at right, I will follow the evolution of an ePortfolio pattern that supports staged submission and evaluation of student work. Imagine, for the sake of argument, a teacher assigning a piece of writing to students, an essay about, oh, Occupy Wall Street.
In the image at left, students produce some digital artifact (a word processing document using any software, from Microsoft Word to Open Office), attach it to an email message and send it to the teacher, who replies to the email with comments.
With Google Apps, this process can be streamlined by instructing students to include a “hashtag” — in this case, “#OWS” — in their email subjects when they submit the assignment, mirroring good Tweeting practice.
The teacher then creates a Gmail “label” (a.k.a. folder) called OWS and a filter to move all messages with “#OWS” into that folder.
This way, the significant but postponable work of managing the student emails and documents can be set aside from the daily flow of communication in the teacher’s Inbox.
However, the “file attachment” model above is a vestigial pattern once a school adopts Google Apps. Rather than requiring students and teachers to manage various versions, Google Apps supports sharing access to (and even editing of) digital artifacts (like documents, slideshows, and many other file types).
The “Google Apps” way for a student to submit work is to “share” the artifact with the instructor, and in the act of sharing, generate an email message which notifies the teacher that the artifact is ready for evaluation, and includes a link to that artifact (see diagram at left).
This is a clear improvement over emailing and downloading files, but still requires the teacher and student to establish email correspondence, which can quickly fill up in-boxes. One way to “distribute the workload” is to establish a “peer review” phase prior to submitting work for teacher review, providing students with a “rubric” against which to evaluate peer work.
In the model at right, an all-class “Google Group” is established, and students share the document with that group. The document title is included in the subject line of the share notification, so as long as students choose unique titles for their documents, identifiable discussion threads will appear on the Google Groups page.
Problem: every student will get an email each time a message is posted to the group. Solution: make the default group setting “no email”: messages are found only on the group page, where students easily find their own assignment thread (or the assignment they were tasked to peer-review) and also see other exchanges for models.
What about the rubric against which the work should be evaluated? In a fully collaborative classroom, editable rubrics can serve as self-evaluations by student authors, then be used as first-round feedback by peer reviewers, then last by the teacher in justifying a grade (or paving the way for final edits), each phase responding to successive revisions prompted by the last.
To associate rubrics with work, the teacher shares a read-only copy of the rubric template for this assignment with the class group Each student then makes a personal copy.
Following the State of New Hampshire’s model, a digital portfolio requires a triad of three artifacts: the student work, the rubric against which it was developed, and a cover sheet with student comments and teacher response. One disadvantage of this “Groups method” is that the document is easily separated from its commentary, which is thus lost to the ePortfolio record. It is appropriate for commenting prior to archiving, but not during archiving.
Google supports the commenting associated with the second, “archiving” phase of ePortfolio submission through the “Comment Stream.” Comments can be “free floating” (the student’s “cover comment” and the teacher’s reply) or attached to a word or phrase in the document (as issues requiring resolution).
If the work is deemed acceptable for portfolio storage, a teacher might respond to the student’s “cover comment”, and that would conclude the archiving process. Otherwise, a teacher might use Google’s contextual commenting feature to indicate final changes needed (see below) and students can click “resolve” as the comments are addressed, which removes them from the margin and the “stream”.
Note: the “Notifications Settings” under the “Comments” menu on documents is set to send the document author a separate email for each comment by default. The reviewer placing the comments would not automatically receive comments. Because many comments can be overwhelming, it is advisable to warn students ahead of time, before they open themselves up to group feedback, or even teacher feedback, without being prepared for all those emails.
Different Google Apps document types support different types of commenting, which must each be mastered along with complexities (using Picasa to comment on images requires significant set-up) and weaknesses (using “speaker notes” in presentations for comments provides no way to track who is commenting).
Depending on your familiarity with Google Apps, student peer review models, and the ePortfolio ideal adopted by New Hampshire, you may imagine the collaborative procedures I have outlined to be either prohibitively complex or reasonably woven into the fabric of classroom interactions by your most tech-savvy teachers.
However, the biggest drawback of Google Apps for ePortfolios is not the awkwardness of associating comments and rubrics with documents, but the difficulty of archiving and retrieving documents, comments, and rubrics together in a standardized way, the way Sakai, Mahara and other ePortfolio management systems do. I am not aware of any schools who are using “Google Apps Native” to implement this New Hampshire model, and doubt it can be feasibly accomplished.
Before investing in school wide professional development for such complex interchanges, it is worth asking whether the time is right to make a long-term commitment to a “Google-friendly” overlay system, and thus avoid overloading faculty in ways that permanently tarnish the adoption of what might otherwise be a transformative approach to instruction, collaboration, and assessment in a 21st Century school.
My hope is that this combination of a broad overview and specific example illustrate how the component patterns for collaborative online learning and ePortfolios can be initiated within a Google Apps environment, and how faculty readiness for new software can be gradually nurtured until the point when Google Apps are outgrown and it becomes a clear necessity.
Bram Moreinis, Educational Collaborators
More About Digital Portfolios
- My ePortfolios Page: Background, video and resources: https://sites.google.com/a/danvillek12vt.us/tech-integration/eportfolios
- Digital Portfolios Made Easy: http://www.dpme.org – a great please to start!
- Google Apps ePortfolio Mashup: http://electronicportfolios.com/google/ A great introduction to Dr. Helen Barret’s work.
- ePortfolios with Google Apps: https://sites.google.com/site/eportfolioapps – Dr. Barret’s super-resource)
- Student Work Rubrics: http://www.uwstout.edu/soe/profdev/rubrics.cfm – for assessing student digital work products.
- ISTE NETS ePortfolio Matrix Examples - http://electronicportfolios.com/nets.html – indexing an individual’s work to the 6 NETS standards.Pedagogy + Assessment + Storage