Got plenty of feedback on the prototype guideline I posted two weeks ago, and things are advancing on that front. I am about to create a template guideline that explains the format of a guideline so it will be easier to comment on without getting tangled up in the actual content.
Much of this week will still be going through the different parts of Moodle, reading books, and prioritizing different interaction styles. Also, I need to be moving towards figuring out a format for guidelines that can then be finally commented by the community. I am also reading Using Moodle and gathering usage scenarios from there.
As I was reading through the Roles system part, I got a bit of an inspiration. Not really grasping the UI issue with roles has been bugging me for months, so it was enjoyable to finally see on some level what the problems are about. Essentially it seems communicating the system effectively requires a richer tool in terms of interaction, using which users can graphically put in place the permissions they want.
An initial reaction was that my suggestion is too radical for now. In a sense, I am glad that the implementation challenges are aknowledged. On the other hand, from the point of view of the role I assume in Moodle, I want to look at the overall issues there are in the interaction model: What is it that we are supposed to communicate between the system and the user, and how did we do: does the user understand the communication, how much time does learning to understand the communication take?
For me, one great challenge of the OSS developer community is that thoughts about design are deeply intertwined with thoughts about implementation. Of course we need to be realistic, but we need to do that also in terms of how well actual users will understand what we create. The ultimate hard reality we face is not the technology constraints, since technology is just a means – reality hits us in the face when we see users struggle with the product of our own ingeniosity.
In open source, there is the risk of hurrying to code away after a need has been recognized – design is done, but it has to do only with software architecture and requirements. The intermediate thinking about what the experience of using the software should look like seems to often stay shallow. I would love to see, in the long run, that design move to early in the development process, like any HCI professional in the industry will require: this is the only way to create really satisfying user experiences.
With roles, the conceptual system is solid, meaning that the different use cases have been recognized and likely much that users need can be done using the system. But as the complexity of the system is significant, the difficulty of using the UI approaches using a programming language: users have to translate what they need into the language of the computer system they are using.
Software developers are happy with complex systems, which they need to learn to be capable of using their power. With the roles system, it seems to have been assumed that since that conceptual system is what is required to express fulfilling the requirements systematically, we just need to design an UI on top of that system. Users then need to grasp that conceptual system to get the power they want. The concrete use cases and the language involved are abstracted away in the process (unlike in Moodle pre-1.7, though the old presets are still available), and so a new language for the users to learn is created. The interaction design is derived from that language, glued on top of it, resulting in a user interface that is essentially alien to users, requiring quite a bit of commitment.
The question that forms in my head is very similar to the one that initiated Quiz UI redesign: how to let users get from their needs, expressed in their own concepts, to meeting those needs with Moodle, as painlessly as possible, minimising extra burden from the system’s intricacies?
My proposition for a solution, so far is in the Moodle Docs. In addition, really bringing the most probable use cases back to the UI as something like presets would be ideal. Of course there is no concrete UI design yet, but seeing the complexity of the logic of the software and the variety of needs it tries to serve is a good start.
