Latest News

Googling Towards ePortfolios

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…

  1. student creates document
  2. student emails teacher with attached document
  3. teacher emails back comments

to complex…

  1. student drafts document
  2. student shares document with teacher
  3. teacher gets email notification
  4. teacher adds comment stream and contextual feedback to document
  5. student gets email notification
  6. student creates new revision and responds to some comments
  7. 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:

  1. Time spent learning / teaching complex Google Apps patterns becomes prohibitive for all but the “early adopter” teachers and students.
  2. 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

Facebooktwittergoogle_pluslinkedinby feather

About the Author

The Author has not yet added any info about himself


  1. Janet | expateducator.com Says :
    Posted on January 23, 2012 at 2:33 pm

    “…more time must be spent learning and mastering Google Apps management.” I respectfully disagree.

    One of the best ways to get tech-hesitant teachers to work on ePortfolios is to keep it simple. Google apps need not be prohibitively complex.

    My teaching partner and I have adopted a model where we teach our students and our students teach other classes of students (student with teachers who are more fearful of their Google app skills). It takes about an hour for one of my students to guide another student through the process of creating a good template.

    The “each one teach one” model has one rule for student “teachers”: they are not allowed to touch other students’ computers. Instead, “teacher” students must verbally communicate instructions. Alternately, they can set their computer up beside the learner’s computer and model the actions.

    We created video tutorials for students who forget, are absent, or need reminders.

    As a last resort, students can google a question and are most often led to a helpful answer.

    Teachers do not have to fully understand a tool to implement it. Teachers MUST communicate the purpose of each ePortfolio page. They must help students evaluate content and layout. Students can teach other students the tech aspects.

    See http://wp.me/p1Dq2f-hN for a model and videos to get students started.

    • Bram Moreinis Says :
      Posted on January 23, 2012 at 4:32 pm

      Hey, Janet.

      I agree entirely with you that keeping it simple is key. I also totally agree with empowering students (see http://hvscouts.com).

      I’m just not seeing how we keep it simple FOR TEACHERS with Google Apps as they are, once we start a robust ePortfolio process that includes iterative feedback between students and teachers.

      I guess we’d need to get specific about the management steps I’m talking about, to make sure we mean the same thing. ePortfolios mean so many different things to people! I think they mean different things to you than to me.

      Feel free to contact me directly if you’d like to explore this further.


  2. 73 EdTech Resources You May Have Missed–Treasure Chest January 29, 2012 | Tech the Plunge Says :
    Posted on January 29, 2012 at 2:03 pm

    […] Googling Towards ePortfolios- Educational Collaborators–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. […]

  3. Jozsef Says :
    Posted on June 15, 2012 at 8:32 am

    Portfolio entry triad:1. Artifact2. Commentary3. Criteria (rubric, etc)Each of these triads (which can be srpaeate files or integrated artifact+comment depending on software) become part of an overlay list organized according to need.For example, student wants a list of work by year or theme, teacher wants list of all students with work, department wants list of all teachers with representative samples, institution wants list of representative graduates.So, overlays (matrices in eportfolio-ese) can be independent of artifact repository as long as links are permanent and files do not disappear.Hence need to distinguish between working repository (formative evaluation no overlay) and portfolio (summative evaluation and target of multiple overlays).Technically I reckon you can mix n match systems to do pieces of this but overhead for users is prohibitive. Systems like Mahara or Sakai or commercial solutions seem necessary to me, at least for the working repository and commenting with required notification to teachers and students that response is required as workflows progress.There will always be tension between evaluative overlay requirements and functional usability of course ..until you have a solid instructional fire going you can put the flame out every time you open the stove door to prod the logs. So I would recommend establishing what roaring fire stage should look like with the most user friendly tools you can afford first.Your evaluators should agree to wait until that milestone is reached before building overlays and overhead. Otherwise everyone will be frustrated during the pilot phase and adoption will be too unpleasant a prospect to sustain the kind of teaching and learning by all stakeholders that eportfolio-philes dream of.Many two cents there ..I love the depth of this threadBram