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.
“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.
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.
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.
Take an exercise of developing action words for our various user populations. You start to rattle off —
… 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.
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:
- Make Good things easy, and the Best thing achievable.
- Design for user journeys, not institutional boundaries.
- Collaboration is core; administration is superficial.
- Make the user look and feel smart.
Update: Feel like I want to add a #5:
Learners are Researchers.
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.
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.