Sakai

Very quiet in the office this week... Almost all the developers, and a good chunk of everybody else, are away at the 7th Sakai Conference in the Netherlands.

From the conference homepage, I found a nice use of Sakai Confluence, to help conference attendees do travel planning and find out where to spend their free time (when they're not attending BOF sessions :-) )

 

I've been following the debate on the Sakai Pedagogy list, about personas and their shortcomings.

For the benefit of those unfamiliar with this term, 'personas' are generic user profiles, similar in many respects to the consumer profiles used by marketing organisations. They are employed as a tool for systems analysis, the aim being to design and build more usable systems, by understanding the needs and intentions of the people who will use them. The process of creating a set of personas normally involves an iterative process of research / evaluation, whereby individuals' unique 'needs and intentions' are grouped into normative sets.

The problem is, they don't work. Their chief benefit is also their greatest shortcoming: personas are inherently generic. They are not tools for personalisation.

The other issue is that personas encourage systems analysts / software designers to build systems around institutional roles, instead of activities. Why!? Organisations change. Organisational and institutional roles have a tendency to mutate, shift, and/or vanish, and people may change roles within an institution - once, or several times. Changing a customised system once it's built is expensive and time-consuming.

To update my post on the Blackboard patent, here is some more detail on the requested reexamination of the patent claim and the Sakai Foundation's response.

As Paul Erickson notes (thanks, Paul!), the news initially started bubbling up when the Software Freedom Law Center (SFLC) announced that it has formally asked the Patent Office to reexamine and ultimately cancel all 44 claims of Blackboard's patent on e-learning systems.

The request has demonstrated the very real sense of unity and common purpose among the educational open source software community. It was filed on behalf of the Sakai Foundation (sakaiproject.org), the Moodle Community (moodle.org), and the ATutor Community (atutor.ca).

In their press release, the Sakai Foundation refers to the "the surrounding fear, uncertainty and doubt (FUD) being spread by Blackboard", and states: "We, the Sakai Foundation, consider the Blackboard patent to be a prime example of a bad patent in the area of educational software.  It is a threat to open source developers, providers and users of educational software."

The Sakai Project is a major open-source development, which aims to produce a robust, scalable collaborative learning environment for higher education.

An article by Stephen Downes in the latest issue of Innovate! provides a good overview of the Sakai project website and helpfully steers newcomers towards the best content and resources.

This is one of those Really Useful articles that the open-source community needs to do more - a lot more - of. Downes is right: the Sakai site is confusing to navigate and, in many sections, is dominated by technical language. This can be highly off-putting to non-developer stakeholders who choose to visit.

And this is precisely where many open source projects fall down: in terms of communications and outreach towards those who are located "outside" the developer community. The problem is that an open-source project website is (normally) both the public and the private face of the community. The website has to serve a dual purpose, looking "outward" towards casual visitors and end users, and "inward" towards its own members. You can't solve this problem by shutting the developers' mud-wrestling, sorry, complex and interesting discussions, off into password-protected areas of the site; because that usually means that the information left  within the "visitor/user" sections of the site is far too thin to be useful.

I met with usability specialist Michelle Bejian Lotia yesterday, to talk about GradTools and how we might use it at the University of Cambridge. Michelle works for the Usability, Support and Evaluation Lab at University of Michigan, which seems to be a very  similar institution to CARET. In the context of our move to Sakai (known as CamTools at Cambridge), it looks as though GradTools may be the tool we are looking for to help us track graduate progress through the multiple processes involved in completing a research degree.

We have two specific issues that GradTools may help us to address. First, audit requirements. UK universities now have access to a specific pool of government money (known as "Roberts money", after the 2001 review of postgraduate research and training by Gareth Roberts) which they are required to use for graduate training and skills development. At Cambridge, the Roberts money is divided up between the Faculties, who decide amongst themselves how they are going to spend it. There is an obvious need to ensure parity of training provision across the institution, and to record, at least at the departmental level, the number of students subscribing to training opportunities. GradTools relies on external data (at Cambridge, this would be provided through our PeopleSoft system, run by the student information services division) so it does not produce "authoritative" top-level data that meets formal audit requirements. But with some development, it could be very useful as an informal / internal reporting mechanism.

This 30 minute recording with Alfred Essa, Executive Director of the .LRN Consortium, gathers his thoughts on open source, blogs, podcasts, java, .LRN and a range of other topics.

In this recording, we'll continue our coverage of the library sector, but from an international perspective.  Let's listen in as Vidya interviews Marc van den Berg, the Department Head of Electronic Services at the Universiteit van Amsterdam.  The running time for this recording is about 20 minutes. 

In this recording, Vidya Ananthanarayanan sits down with Rich Kogut to chat about his experiences with the first American research university built in the 21st century.  Learn about the challenges & opportunities presented by opening a new campus, the questions of centralization vs. decentralization, identity management, and the use of technology at UC Merced. 

The OSS Watch Building Open Source Communities conference seemed to go pretty well yesterday. We had a broad range of people, with a broad range of interests and everyone seem to find something useful.

I had a great day, catching up with old friends and new, including: Gustav Delius University of York; Jim Farmer, Sakai Educational Partnership Program; Sean Keogh, OXILP; Bill Olivier, Development Director (Systems and Technology) JISC; Andrew Savory and Helen Sharp, Open University.

So, OSPI 2005. I could talk about the weather: hot and humid. Or the numbers: 145 people, 8 countries, 2 days. Or the people: including Darren Cambridge (George Mason U), Chris Coppola and Janice Smith (r-smart), Jeff Haywood (U of Edinburgh) and Susan Kahn (IUPUI). So...what's next, what's new...?

With OSPI 2.0 unveiled, we learned that its future is now pretty much bound up with that of Sakai. This is not just a question of architecture and admin underpinnings, it's also to do with the way the project will be managed in future. Word is, the OSPI board may disappear altogether; the project may be managed via an Apache-style foundation. This could be a real turning point for the OSP development. For the moment, I'm reserving overall judgment as to the costs/benefits of this apparent convergence. I do have questions about the financing aspect, and I also wonder how OSPI plans to balance "collaborative" development with development that is driven by lead institutional partners.

Most interesting "user" development, from my perspective, is the portfolio matrix tool - looks great, and is flexible enough to support a range of activities. IUPUI has invested time/energy in developing a pedagogy of "matrix thinking", drawing on Stanford's Helen Chen's work on "folio thinking". This is something to watch.

Some immediate thoughts/reactions:

1. We need to think hard about what constitutes "success" for the open source development model. More obviously: does "success" mean simply that we held the conference, and the people came? Or that the OSP is financed sustainably, develops in a coherent way, and is being used by multiple institutions in 3 years' time?
2. We need to keep the diversity. OSPI 2005 attracted academic teaching staff, educational technologists, faculty liaison, software developers, and vendors. This diversity is a major strength of the OSPI community. I have to say it stands in marked contrast to the Sakai conference - held in the same venue, immediately prior to OSPI 2005 - which is much more developer-centric. To this end, I floated the idea of starting up an evaluation group as a way of keeping faculty involved and making sure the OSP fits their diverse needs. This may be coordinated through EPICC (European Portfolio Initiatives Coordination Committee) - watch this space for details.
3. We need less architectural change, and more tools. This one kind of follows on from the second point. If you're showing a faculty member a VLE/CMS, it's hard for them to see the benefits of an "empty box": they want tools and content. But unless we slow down the number of releases and the number of major changes to the "plumbing", in Brad Wheeler's phrase, we'll never get to the tool-making stage. (I believe this point applies regardless of whether we conceive of e-portfolios as a "tool", a "practice", or a "community").

So my holy trinity is: focus on sustainability, talk to the end users, and work on creating the tools they need... (So, that's all? Nothing more, then? ;)