Over the years I've been interested in personal APIs, personal data stores, and personal clouds. If you've followed my work at all, you're aware that I care a lot about creating systems that are owned by the people who use them and give people control over how they work and how their data is used and shared. This is what sets personal apart from personalized. Personalized means that someone else's system recognizes me and uses that as context to change the data it shows me. Fine as far as it goes. Personal means that I own and control the system, the processing, and the data.
The best news is that personal systems are not at odds with enterprise and vendor provided services. As we'll see below, personal systems augment other systems and provide them with more accurate and more plentiful data.
In my present job, personal means thinking about how people relate to what we call learning management systems (LMS). Learning management systems are great, but they don't really do all that much for learners. And I think it's a mistake to try and build systems that work for students and schools alike. I think we're better off building different systems for each party and letting them talk to each other using APIs.
Learning Management Systems
Over the years, I've used a lot of different systems to provide online learning aids for my students. My first attempt was a class Web site I put together for CS330 at BYU in 1994. After blogging software came along I mostly used a blog as the Web site for the course and augmented it with things from Github, Blackboard, LearningSuite, and even Moodle. I'm lazy, so I can't say it was ever awesome, but it was functional so far as students finding the class schedule and the resources I put together for class.
In one way or another, they were all what today we call a "learning management system" or LMS. The perspective was me, the instructor, managing the class by controlling the communication, resources, quizes, etc. that the students used to learn. My focus was on my class.
Lately, I've been thinking about this whole thing from the perspective of the learner--the student. Students don't just have my class, they have a complete schedule. Their goal is to participate in the various learning activities that their instructors have planned and complete a set of courses. This starts when a student plans their class schedule and continues until the courses are over.
Beyond that, the student may have their own learning agenda outside of an organized school. That should seamlessly mix in with more formal content. And there's no need to envision this process with fixed start and end times. Students should be able to start and finish classes or even smaller modules on a flexible schedule.
The end result of all these learning activities are various artifacts that range from read papers, discussion comments, completed assignments, quizzes, projects, and so on to credentials and degrees. In a traditional LMS, all this work disappears unless the student saves it somehow. Only grades, degrees, and other credentials are retained by the institution.
There's a lot of talk about ePortfolios in higher education. Like the LMS, these are often thought of from the institution's perspective. Here's why.
Departments, colleges and universities go through a process called accreditation on a periodic basis where outside visitors audit the program or even the entire institution to ensure it's meeting certain desired metrics. One of the things that happens in an accreditation visit is a review of whether courses and programs can show evidence that students who complete the course of study have met the learning objectives the institution has outlined for the course or program.
Traditionally this entails collecting and saving samples of student work across the range of performance and a range of time. Years ago, this would result in the department conference room table covered with stacks containing paper copies of exams, assignments, etc. for accreditors to review. Now it's mostly online. And, not surprisingly, people are less forgiving of missing evidence...but that's another rant.
People who worry about accreditation love the idea of ePortfolios because they imagine that if the results of learning activities are captured in the student's portfolio like so much digital exhaust, then the evidence for accreditation could be gathered with the push of a button.
Another reason institutions love ePortfolios is for purposes of assessment. Student-created artifacts are graded to assess student progress and, eventually, competency in the course's stated objectives. Again, institutions gather all this student-created work and an ePortfolio seems like it would ease that burden by organizing it in a consistent way.
I believe what we call an ePortfolio is really three different systems:
- An institutional system for accreditation purposes
- An institutional system for grading purposes
- A personal system for the student's own record
We make a mistake when we conflate these three purposes. From a DDD perspective, they are three different domains with different contexts and languages.
A Personal Learning System
Lots has been written about the enterprise-side of this problem. I'd like to focus on what I call a personal learning system (PLS). The following diagram outlines some ideas for what a PLS might look like. The student is at the center, orchestrating the learning that takes place by:
- Completing learning activities
- Reviewing achievements
- Choosing what the share and with whom to share it
- Choosing what to learn
- Reviewing and acting on feedback
- Managing the learning plan and resources
The student owns and uses a PLS that contains both a learning dashboard and a portfolio. I like to think of the student transforming learning objectives and resources in the dashboard into completed activities and competencies in the portfolio as she completes various learning activities. I see the PLS dashboard and the portfolio as mirror images of each other, reflected across the now; things to do and things done.
The dashboard gets feedback from the portfolio that can be used to inform the student of the best next steps for the student to accomplish her objectives. This may involve changing the detailed learning plan, redoing work, skipping some things, etc.
Both the dashboard and the portfolio have an API that is part of the student's personal API. This API provides access to other outside systems. The dashboard is the repository and interface to the student's personally selected objectives, plan, and resources. All of these interact with external learning guides that might include:
- peers and social groups,
- digital textbooks,
- learning management systems, and
Anyone can affect the student's PLS dashboard if she has granted them permission to access to her personal API.
On the portfolio side, the student's personal API provides permissioned access to external organizations and systems that might include:
- institutional ePortfolio systems,
- learning management systems,
- social circles and groups,
- personal coaches, and
Again, these organizations and systems connect to the portfolio via the student's personal API and only with permission.
There may or may not be interaction between the learning guides and other external systems. It's likely, for example, that the student would give an external LMS that they're using permission to access both the dashboard and the portfolio. Similarly with employers.
There's no reason the PLS would talk to just one LMS. The learner may be using multiple systems for various purposes. The PLS would present all of these in a single view.
Being Personal Enables Life-Long Learning
By far, the most interesting aspect of the PLS is its focus on personal. Traditionally both LMS and ePortfolio systems have been enterprise systems, bought and installed by an institution for their purposes.
The PLS, on the other hand, is chosen and controlled by the learner. The institution, and others, link to and use the PLS, but the student is in control.
Focusing on personal is why the PLS is such a good tool for life-long learning. By giving students their own learning system and teaching them to use it, we make them responsible for their learning and teach them skills that will enable them to learn new things without institutional support. Moreover, we put the student at the center of their learning experience as an active participant rather than a passive consumer.
A personal learning system is not:
- an assessment engine—assessment would be provided by external systems.
- a content repository—learning resources might come from many sources.
- a group interaction system—chat, discussion, etc. happens elsewhere
- courseware—specialized texts, exercises, and simulations live outside the PLS
- a course—course content, syllabus, objectives, assignments, and assessments live in an LMS
In short, there's still plenty of room in a world of personal learning systems for learning management systems, grade books, schools, and instructors. The PLS augments these systems by extending the realm of the portfolio to include activities yet to be done rather than merely recording and what's done and storing those artifacts.
A Pilot Proposal
The BYU Domains project, our version of Domain of One's Own, is a good place to build a prototype PLS. BYU Domains is a CPanel system, so you could imagine a PLS that installs via CPanel and interfaces with institutional systems via an OAuth-mediated API.
If you're interested in these ideas or have comments and suggestions, I invite you to contact me.
The ideas in this post have been influenced by numerous discussions with Kelly Flanagan and Troy Martin in the Office of the CIO at Brigham Young University.