Launching the UX framework site

For a little while now, the latest design phase for Sakai 3 has had issues with how it communicates with the Sakai community.

On the one hand, while our contracted designers need to access the accumulated practical wisdom and user insight lodged in our collective heads, there’s nevertheless a limit to how many voices and perspectives they can take in and try to sort through, especially if we want them to deliver a result in a reasonable timeframe.  I’ve mentioned the Drupal UX project experience before, and a comment one of the designers made there (can’t find the link right now) was that they spent about 60% of their time in on-list discussions and about 30% of their time actually designing. I know this sort of thing was a frustration for Nathan last year as well, and think we’ve needed to find a better balance. So we’ve been selective about points of engagement and channels of feedback, drawn as much as possible from community resources and leading figures in our UX efforts, but we’ve at times erred in taking this too far.  At some irreducible level there is a tension at work here between openness and getting results, and yet a simple tradeoff is not acceptable: we need both.

It’s all very well to want to discuss everything on list, and it’s a healthy default, but I think we sometimes also err in stopping at that point, imagining it to be the solution of a communication problem.  Lord knows I hear from many who say that the email threads are hard to follow, to the point that sometimes even the open conversations on list can seem like an exercise only for insiders. Or take the Confluence wiki as People’s Exhibit B of communication that can stop being helpful when it just unloads (and I’ve been complicit in this). Particularly when we’re talking about communication that often involves a lot of visual elements that have complex relationships to one another, we need a way for the discussion to zoom in on a particular focus without losing the ability to draw back out to the bigger picture. The feedback needs to be pertinent while the design needs to be coherent.

Enter now an attempt to find a balanced answer to several of these competing issues: the Sakai UX Framework. Sam and I first started working on this back in December, in fits and starts. It’s loosely inspired by Drupal’s UX Framework, but Drupal’s version (from our perspective) jumped a little too quickly into mechanical components of the interface, and wasn’t framed and grounded well enough in the user insights, which should be carried along as a constance reference and touchstone. Our framework is trying to open up and reveal the design work, provide a place to comment on it (including challenging it) at focused points, but to keep in mind the context at the same time. The hope is that we’ll be able to evolve things in feedback cycles without losing reference to the whole.

It’s still in its nascent stages, but I think it’s far enough along that it can now be a help in communication both directions, providing a picture of where things are headed while also revealing how they need to adapt or shift.

Sakai UX Framework

Contributing forward

“Contributing back” was once for me the phrase that packaged up practical engagement with open source projects. It signalled a readiness to participate, it implied a material contribution, and carried with it the healthy sense that one’s efforts were part of a broader whole.

In the last few years I’ve come to a more nuanced view. I’ve seen “contribute back” often mean that a body of code will simply be handed off or posted in a repository once completed to private satisfaction. No matter the generosity with which it’s offered (which I couldn’t doubt – I know it’s a non-trivial amount of effort to even get to the point where things could be handed off), the practical constraints on rethinking or continuing to develop the work effectively amount to a take-it-or-leave-it state. “Contributing back” can lead to a result something like that of software companies that try to suddenly open source products that have long been proprietary.

I wasn’t a great fan of the excesses of the “Pay it Forward” movement a decade or so back, but flipping the preposition offers a clarity worth braving the association. Open source contributions count for more if they’re thinking ahead about how they fit in, or even better, if they’re leading (and communicating) with the general problem of which their particular itch is one variant. The potential benefit is not simply that it’s a more selfless community spirit, but also that the solution will likely be sounder, longer-lived, and one is far less likely to be stuck with a brittle maintenance burden. Contribute forward.

At Play with 3akai

Enough with the angst and muddied conceptualizations. Some playgrounds I find encouraging. Little snippets and scraps from some demos and experiments that may not last long, and so links may break and I’ll have to take them down, but still. A few snapshots of activity:

Oszkar spent a day working up an illustration of an idea.

Sam found a tool that lets him create click-throughs as easily as wireframes.

Christian creates some click-throughs in a 3akai context. (Log in as admin/admin)

And of course, Lance’s demo of hybrid mode.

Despairing of Language

I’m trying to work my way toward a structured communication of the design work, and the words are killing me. I think it comes down to the fact that the words need some particularity in order to connote anything worth saying, but our ambitions for Sakai and education in general involves an eroding of boundaries and a fluidity of purpose.

Killing me.

Take an exercise of developing action words for our various user populations. You start to rattle off —

• Creating
• Reviewing
• Communicating
• Questioning
• Critiquing
• Reflecting
• Collecting

… and so forth. Who is doing these things and when? Well, everyone and all the time. So what’s the point in even laying these out?

A designer needs to be able to frame out who is doing what, when and why, and we come up with aspirational statements like (as one commenter put it) “Learners are teachers; both are researchers.” Everyone is somebody and no one’s anybody. Perfectly right. Perfectly killing me. Somebody throw me a lifeline of myopia.

UX Principles

In the midst of trying to shape a conceptual structure for communicating the Sakai 3 Design work, I’m riffing on an idea from the Drupal UX Project. At the top of all their pages they put:

Our UX Principles: 1. Make the most frequent tasks easy and less frequent tasks achievable. 2. Design for the 80% 3. Privilege the Content Creator 4. Make the default settings smart

I’m playing around with what they might be for Sakai. Here’s what I have right now:

1. Make Good things easy, and the Best thing achievable.
2. Design for user journeys, not institutional boundaries.
3. Collaboration is core; administration is superficial.
4. Make the user look and feel smart.

Update: Feel like I want to add a #5:

Learners are Researchers.

Cautionary Drupal Tales

I was aware of Drupal’s recent user experience project, but in a recent exchange John Norman brought it to my attention again with a link to Leisa Reichelt’s post-mortem reflections.

It is all to [sic] easy to make excuses for why designing in an open source community can be tough. Certainly there are lots of communication challenges and we don’t necessarily have the right tools. Some people focus on the relationship between designers (minority) and developers (majority) in these communities – I think to do so is to focus on a symptom  of the problem and not the cause.

Sam later told me he had mixed feelings about coming across Leisa’s reflections, in that she seemed to leave with more frustration than accomplishment, and perhaps there is something irreducibly hard about doing design work in these communities. The usual rules about why open source is a good thing don’t seem to translate well to design activities.

The tension between openness and effectiveness is a particular one worrying me these days.  I’m well acquainted with the voices that see this as a false dilemma, but recent experience leaves me not so sure. I’m skeptical about analogizing coding and design.

The way that we are currently engaging with the community is very different to the way the community currently gathers to discuss and resolve issues – which is very much consensus driven. I cannot say often or loudly enough how much we crave communication with the Drupal community on this project, but in order for us to do our job well, we need to engage in a somewhat different way.

I think that’s right. All the same, I think I’m working – in awkward, halting ways – to find out how and where consensus-driven approaches can be effective in this design-led effort. It’s clear I’ve put some stock into the idea of using our functional experts to come to some consensus on fundamental capabilities. I think there is also a lot of promise in distributed user research and testing. But many eyes do not seem to make design problems shallow.

The Input of Pedagogists

I was on a call with the Teaching and Learning (T&L) Sakai community yesterday, and was happy to find the focussed energy around articulating basic user needs picking up steam. It’s true that the mechanism in view is this spreadsheet, but I think the larger point, as I’ve said before, is that our pedagogists can best influence the product by turning their accumulated practical wisdom into the sorts of insights that can guide design.

The caveat is that it can take a fair bit of effort to reign in our technological assumptions, since so many of us are also technologists. It takes work to walk back from our ideas for good software features, built upon a decade or more of experimentation with web tools, and then trace them back to the originating point of the user need. It’s hard to shake free of the temptation to simply lay out feature requests or requirements and ask that they be developed literally, as opposed to expressing the need and trusting to experienced design talent to see that need met in a way that fits well with everything else, and probably didn’t follow the picture you had in your head.

It’s hard, but it’s work that needs to be done. The next stage, I think we’re all agreed, is trying to take the raw material in that spreadsheet and bring to it some consistency of interpretation, even some organization.

I have great hopes for this exercise, so much in fact that I feel I need to restrain my naive enthusiasms. I see in it the potential for not only informing current design work, but also for laying out a framework for a community roadmap, as we come to a shared picture of what the fundamental building blocks are, how we can build upon and refine them, and ultimately how we expect Sakai can make a difference for those we’re trying to serve.

Like I said, naive enthusiasms.

Reuse

When we first started talking to Sam about Sakai 3 we used the word “template” a lot. It had worked its way into our conceptual lexicon rather early on, as the answer to how a free-form editing environment could still be helpfully scaffolded, and not force everyone to start each time with a blank canvas. At times it even started to take on a semi-magical aura: someone in the back of a room during a presentation would call out a question about how we were going to do X. “That’s what templates are for,” I’d glibly respond. Well, not glibly. The idea fit. But the truth is that we hadn’t yet really designed for this apparently pivotal thing, and it was putting a lot of faith in something not yet realized.

If I can be forgiven for putting words in Sam’s mouth, I think his attitude when confronted with this was (tactfully expressed), “OK, it’s great that you guys already have a mechanism in mind. You’ve obviously given it a lot of thought. But if you don’t mind, can we please trace that back to what the user problems are that we’re trying to solve? Because that’s what I really need to be designing around, and maybe templates will cover it and maybe they won’t.”

OK, fine.

Leading Design

We’ve been talking a lot in the Sakai community in the last year about “design-led” development, but I’ve also gone on record in saying that our community members can get ahead of the design and inform it. I’ve been especially pleased to see UCD research springing up in a few areas, and in recent weeks have been promoting the maturation of the “Learning Capabilities” spreadsheet that David Goodrum has championed. At the same time I’ve been hearing concerns that such efforts might come to naught, or that they would not be listened to.

With the sponsorship of Cambridge, HEC Montreal, CSU, Georgia Tech and Berkeley we’ve contracted with a designer, Sam Peck, to lead the next stage of Sakai 3 design work, picking up from where Nathan left off last April. Relatively little has been produced in his first month of activity because so much effort has gone into understanding our domain. He’s been reading through spaces on the wiki, the Fluid project, instances of Sakai new and old, our UCD research, conversations with the long-winded, and also the “Learning Capabilities” spreadsheet. As we all know, it’s no mean feat to work through all these accumulated sources, make sense of them and tie them together. Sam has effectively been knitting together his own documentation as he goes along.

I wanted to share a recent round of his notes, both to provide greater visibility into the process and offer some encouragement that the T&L and UCD work are being factored in.  Attached is a synthesis of these various sources, arranged around flows of assignment activities and the users centrally engaged with them.  It does not claim to be complete or finished, yet although I need to be careful about expectations I offer it here all the same as an illustration of the process.

AssignmentNotes.pdf (16 MB)

On page 2 you’ll find literal quotes of the learning capability user statements that seemed most instructive in this area, and on pages 4, 8-10 you’ll also find the user journeys salted with more of these statements at particular points, followed by sketches that show initial attempts to design around these needs.

Teachers Talking to Developers

I often hear the problem of ensuring the relevance of development work to actual practice framed as “getting users and developers to talk to each other.” Now if by “developers” you mean anyone who has a constructive role in fashioning the end product, well, of course. That’s trivially true. But I think most of the time when I hear this it actually means getting end-users and coders to talk to each other, which sounds like a good idea but is not, I think, often very helpful.

Take the old Sakai requirements process of a few years back, which I think is generally regarded as a failure. Feature requests were itemized, voted on, and the biggest winners trumpeted, then very little happened. But I hear the failure described with variations of “developers didn’t implement” or “resource was not allocated to deliver,” and so forth. As though we had all the information we needed, and just didn’t execute. I think that really misunderstands the problem, mainly by not recognizing the design gap.