A while back, I asked David Goodrum to write a guest post about some of the work that the Sakai Teaching & Learning Group has been doing to articulate the educational goals and requirements for Sakai 3. The document that they have been working on is called the Sakai Learning Capabilities document, and it entered a 1.0 release just prior to the start of the Denver Sakai conference. This is very important work that will certainly impact the future of Sakai and could have a wider impact in instructional technology.
The group articulate seven “lenses”, which you might think of as functional goals or even as design values for Sakai 3. They are called lenses because each one presents a different view or perspective of any given piece of functionality within Sakai 3 (or any piece of educational technology, really). Every tool and capability within the system should be examined from the perspective of each of the seven lenses at some point in the design phase to help the designers make sure that they are upholding the design values of the system wherever and whenever possible. Each lens contains several finer-grained “facets” which are, again, intended to help software designers ask the right questions as they are designing educational capabilities. These lenses include capabilities for addressing traditional LMS and ePortfolio as well as important educational scenarios that are not handled well by today’s systems.
Here’s what version 1.0 of the lenses looks like as a mind map:
Note that at least two of Dan Pink’s three drivers of motivation are articulated on the map. Autonomy is called out fairly directly as a lens. I would argue that “mastery” is represented in some of the facts of the “learning activities” lens. (Interestingly, the facet descriptors in the “assessment/evaluation” lens seem relatively devoid of connections to mastery at this point, although in fairness, there’s a lot more thought and analysis underneath this mind map that the descriptors may not be capturing.) I’m not sure that Dan Pink’s third motivator—purpose—can be wired into software, although I’ll be keeping my eye out for examples of it.
The key for the community will be to figure out how to translate these design values into concrete processes during the software design and development process. I have some ideas about how to go about this this. I hope/expect to write about them in a future post.
