Sakai -- Who's Doing the Wagging?

As mentioned in my last blog post, when I attended the Vancouver conference I was excited by how efficient it was to locate like-minded individuals, and how easy it was to avoid "mailing list momentum". Unfortunately, with UWinnipeg's official go-live to faculty and students this week, I did *not* make the Breeze meeting that I had hoped to. Next time....

In a very recent email to the Sakai User Interaction discussion group, sakai-dg-ui, Kathleen Moore from Boston University states:

"The next question is, how do we relate to the (dominant) development-centered group? Is there any mechanism, channel, or understanding that would tend to make the people building the software pay serious attention to us?"

Peter Knoop replies:

"One of the reasons folks have suggested for aggregating this group with sakai-dev (and other development-related groups) into a broader
Developer Forum is that this should not really be a question of "Us vs. Them". If all the stake-holders interested in developing and improving Sakai have a place -- when appropriate -- to share information and discuss design modifications and additions, then hopefully we will have a channel for reaching a common understanding of the issues at hand and how to best address them to serve the community's needs."

Unfortunately, I do think that Kathleen, not Peter, has it right here.

While I agree that we don't want an "Us vs. Them" situation, the main problem, I would say, is how to get the attention of the developers.

Let me use a related example to illustrate a point: I have been contracted by UWinnipeg to install, configure, re-skin, customize, patch, maintain, monitor, troubleshoot, and even occasionally upgrade a Sakai installation.

Why occasionally? Well, when there is only one of you to do everything, Sakai is not great software. It's a pain to patch, troubleshoot, and upgrade. The learning curves are all absolutely required, and they're all steep.

Yes, those curves are "fun" for me, but they are not necessarily "fun" for everyone. And regardless of how fun they are for technologists, the main point here is that software is not written to justify technologists having fun, its written for users. In this case, students, faculty, research collaborators. Them.

(Thus, the "lazy user" side of my personality demands Easy Sakai.)

Now don't get me wrong! The Sakai ED understands this. As I learned first-hand in Vancouver, many others, including many developers, understand it as well.

The big question then, getting back to Kathleen's point, is how do we shift our community of developers to start solving some of these problems?

Here is my suggested four-point plan:

1. increase the communication bandwidth to minimize the chances of alternative views being lost. (Even though Peter probably doesn't mean to stifle the UI group, I suspect that that is what would happen if it were folded into sakai-dev.) Let's keep a separate mailing list, regardless of what it is called, and get it on gmane so it's easier to access and search! Also, where are the Sakai UI blogs? If you log in and add a link to your blog in the comments below this post, I'll add it in my LH menu "Sakai Blog" section; believe it or not, these small actions will really help to keep the bandwidth up!
2. criticize Sakai publically. I just did, when I said "...it's a pain to patch, troubleshoot, and upgrade". We all know it's true; the more of us that come out and say it, the more (we) Sakai developers will be compelled to prioritize improving whatever it is that Just Plain Sucks.
3. hire a developer for a specific task (possible examples: consistent pagination or icons across tools, whatever). If you think that a specific UI problem is serious, while you could spend the rest of your life trying to convince the developers, you may be able to convince your Program Chair much faster to put some money on the table. Once a developer answers to you, you're in a much better spot to get some work done! Remember, you don't need a full-time body; even a small number of hours can make a difference!
4. if your school already has developers, talk to their managers about setting standards, or setting requirements on their work. Most developers will do things "the right way" if they know what it is; but if they don't feel that they have the time, then it won't happen. And if you come to them waving your hands, you're dead in the water. So please take the time to learn about a topic ahead of time, and talk to your developers' managers about how these needs can be included in the daily work. Will training or books be required? Will new workflows that include an internal UI team help the situation? If you want this to work, I suggest short, iterative cycles, (plan for regular review/input points so that the developers aren't reversing weeks and weeks of work) and whatever you do, don't committee your developers to death!

Look for an upcoming post about understanding the motiviations of and working more effectively with developers.