I was just reading this criticism of Moodle, and the thing that strikes me about Bryan Ollendyke's criticisms are the reactions of a software geek. They are also very familiar. I had a similarly horrified reaction the first time I saw the Moodle code (and got into trouble with my boss at the time for speaking my mind at an inopportune moment ;-)) and three and a half years later the same criticisms still apply.
But what I have come to learn over the last three and a half years is that it does not really matter. That is somewhat humbling. I am a professional software developer. I have worked hard to learn to write good code; to build and appreciate elegant and powerful software architectures; to design usable interfaces with modern UI idioms; and so on. However, as I say, that seems not to be very important. Teachers all over the world use Moodle to create great (and ordinary) learning experiences; teachers who move from other learning management systems tend to like Moodle better than whatever they were using before; and all sorts of people from all over the place seem to be able to write plugins. All that, despite Moodle not being a text-book example of software design.
So, are Bryan and I and others with similar opinions just software engineering snobs? Well, probably yes, up to a point, but it is our job to care about these things. Other things being equal, we should do things the right way. The point is that some of the other things are much more important than the cool (or not) technical things going on behind the scenes. The most important thing is education. Moodle's genesis was in Martin Dougiamas's postgraduate studies of online education; but more important is that the Moodle project, led by Martin, has always focussed on engaging teachers, as well as developers, in the Moodle community. To use the HCI jargon, Moodle has always practiced user-centred design.
Now, if you are an expert in HCI design, and you have seen parts of Moodle like the quiz settings form (screen-shot right), then that last sentence might make you laugh. That form is a typical long Moodle form with a million fields you can fill in. In the technical details it does not follow recent user interface best practice. However, suppose you really want to simplify it. The best approach would be to find some options that nobody really needs, and remove them. Well, believe me, I have tried on several occasions. I have convinced myself that some feature is pointless and posted in the quiz forum. Of course, I quickly get a lot typical 'How dare you! I love it that feature. I'll throw my toys out of the pram if you remove it.' responses. Then, invariably, someone will make a well reasoned post that explains a compelling educational situation where that feature really makes a difference, and I will realise why that feature was added in the first place, and why it would be a mistake to remove it.
That is the thing. All those features that bloat the interface are there because someone wanted them badly enough to implement them. Even if they were not a professional developer, and even if their code is not first rate. On the whole, it is probably better for Moodle to have those features than not, even if that means that the interface is not great. We are not here primarily to build beautiful interfaces. We are here to let teachers build beautiful learning experiences. Of course, that is not an excuse to just ignore defects in the interface. We should, and do, go back and apply HCI know-how to improve the interfaces of existing features; and these days we do try to think about UI design for new features before we implement them. We are learning.
To reiterate my main points in summary: While we developers should strive to do the best job we can, technically, we should not be snobbish about it. We must remember that the most important people for Moodle are the teachers and learners, and it is our job to serve them. We should not reject contributions from people who know lots about education, even if they do not write code as well as we do.
I agree with your comments, but I think that our job is also to write the code in a way that reduces development time, effort and overheads. It's all about balance, in fact. If we are careless about code design because we focus too heavily on UI, we end up painting ourselves into a corner, and when a feature is requested, we have to say: "Sorry, that would require a complete rewrite. Too costly!".
ReplyDeleteBasically the same argument I'd lay out as well. End users -- teachers, instructors, students; shouldn't care if it's eligant or not; but the IT staff / developers definitely should.
ReplyDeleteMy followup to your follow up :) -- http://btopro.wordpress.com/2009/06/18/moodlemoot/#comment-33
My initial reaction was that this man is crrazy. Usability, which is in close relation to User-Centered Design, is all about really knowing the users' needs - that is, serving both the business goals (education) and the personal goals of users (appearing smart and getting the job done). But yes, if you consider usability as adding a fix and there and using modern UI idioms, sure, it does seem superficial snobbery.
ReplyDeleteBut then, how do strong designs like Firefox or Gnome appear? The answer it seems, is that open source does not exclude great design. There simply has to be a strong vision about which user goals of which users we are to serve. On one hand, Moodle started from broad user goals - on the other, those needs are not explicitly stated anywhere in enough detail to drive design. In Cooper's terms, we are riding a tiger: users dictate what we do, since we lack a strong enough vision ourselves.
But strangely, Moodle is somewhat successful. In Cooper's terms: the wonder is not that the bear dances well, but that it dances at all.
Both the arts of requirements engineering and of user centered design promote the idea that we do not do great design by asking users what they need, but by really understanding their actual goals and being capable of translating those needs into designs. Users only know what they need when they see it done.
The rest of this post comment is in a related forum discussion:
http://moodle.org/mod/forum/discuss.php?d=126856#p555925
Going on thinking about it - the funny thing about open source is that the geeks, too, do really matter. They make it possible to have something like Moodle.
ReplyDeleteSo I have to agree with Nicolas: it would be critical to reach a state of balance where the engineering and the interaction design of a given open source package mature at roughly the same rate. Where are we on that scale? Of what kind are the most critical needs of users towards moodle, at the moment?
Yes, OK developers do matter too.
ReplyDeleteActually, in the work I am doing right now, re-developing Moodle's themes architecture, all my 'users' are developers. I am constantly thinking about what people creating Moodle themes, or people creating new plugins, will have to do. And I am trying to discuss my changes with these people, to see if they can understand how to use my new library code.
None of my changes this week affect Moodle usability, because the aim is to rework the themes architecture, without changing the HTML that is output by default.
Come now, Tim... you didn't get into THAT much trouble... But I did enjoy the daily "numbers of lines of redundant code removed" report that followed.
ReplyDeleteHey Tim,
ReplyDelete"I had a similarly horrified reaction..." rings a bell with me, lol!
I noticed Drupal being mentioned & compared to Moodle - please don't follow Drupals practices. I've tried at minimum developing a theme for Mambo, Drupal, Typo 3, Moodle and Wordpress. By far the easiest from *both* a developer && user is Wordpress, imo. But anyways...
Let me share some thoughts with you. Do you think that sometimes we developers are too smart for our own good? (Maybe that's a nice way of saying not quite as smart as we think?) I don't know about you, but I find it's hard to push through to get that elegant, simple solution - it's much easier to stop at some point before that where the code is complex, hard to maintain, etc. (that last 20% of work takes "80%" of the effort...).
Another concept - I once heard or was told something like "a strength is usually also a weakness" (and visa-versa) -- now today I was pondering the thought a little that what makes moodle great (and it is great!) is NOT it's awesome code... rather the organization, the community (and other communities do not necessarily have the equivalent strength that moodle does, imo - e.g. I know of both dev's && users that both know & understand some of the issues with moodle, but will not depart...). I wonder if there is not some way to get the majority of people who do code work on moodle to begin *thinking* the right way... for example WordPress' slogan is "code is poetry" --- is it truely coincidence that their code is so easy to work with? (if you haven't delved in - try it, it's like a breath of fresh air after working hard at a moodle coding project). Ok back on track, so how is the "strength" of moodle it's weakness? Well, because people are going to use it anyways because of all the things going for it - lot's of features, it's largely free (lack of oss/free competition) - there is not a lot of incentive to "do it right" from a dev/architecture/UI etc standpoint! As long as people keep using it and are happy *enough* with it...
Now, over time, this could theoretically land moodle in a bad spot, no? (Please understand what I'm saying in the right light - just speculating...). Things can happen real fast in the internet realm. For example, I noticed one of the comments on the other blog mentioned spending $50000 trying to make a commercial CMS do what they wanted, and failed - lot's of those stories I'm sure (people spend tonnes on custom code that sucks - I've been called to fix such stuff!) BUT, imagine they had picked the right developer, who picked the right foundation to build on, and actually succeeded in building something with significant promise (yes, for $50000 I really do think it is actually possible...) - in a very short time there could be an alternative to Moodle! Such a think could take a HUGE dent out of the competitive advantage moodle enjoys, no?
Thanks for all your hard work on moodle by the way!
Well, the (fairly meaningless) ohloh estimate is that Moodle currently represents $10 000 000 of development (https://www.ohloh.net/p/moodle) and that is just core. Multiply that by about three to include all the third-party plugins. So I think you are underestimating what it would take to make a ground-up rewrite of Moodle's key features.
ReplyDeleteAlso, it is perfectly possible to rewrite the inner-workings of something in a way that makes the inner workings more elegant, keeps all the existing functionality, but by virtue of the greater elegance adds lots of new functionality. My hope is that my recent work on blocks and themes for Moodle 2.0 is a good example of that, and that is just one of several internal API clean-ups in 2.0. The the more difficult part was all the experimentation and learning that lead to the old inelegant version. Having working, but messy, code is a very precise feature specification to work from when writing the new code.
One of the points I was trying to make in this blog post is that it is the community that is Moodle's great strength. The fact that we have lots of debate about what features get added. And that a lot of people are contributing new features, even though the inner workings may benefit from a rewrite later.
Another important distinction is between simple but shallow code - for example, get this data from the DB, and display it as HTML like so - any developer can understand and modify code like that - and terribly deep code like the moodle roles system - which is really elegant if you are one of the ~5 people in the world who understand it. Moodle is historically tended towards shallow code, which may well have been a strength that helped attach developers to the project, even if professional developers end up feeling that they are having to write boring repetitive code. Moodle code is definitely getting deeper (and my new blocks code is also an example of that.) We will have to wait and see whether that causes problems in future.
Hey Tim,
ReplyDeleteThanks for the response!
Re ohloh estimate... lol, you're probably right - it's easy to underestmate and moodle is crazy huge in both features & install/user base!
Your second paragraph has me pumped - that sounds awesome! I'll have to dig in some time...
Yeah - the community around Moodle is impressive alright - dedicated, positive & helpful in my experience of late.
Another thought is that since the code for Moodle is developed for and with the education community, that probably impacts a lot of stuff about it -- I'm not sure exactly how, but in speculation I would say it's more (oh-oh) ... formal with oodles of details to work out for each feature; basically I think it's lending to complexity rather than simplicity. A huge barrier to simplicity is the existing feature set (like you've mentioned elsewhere I believe - something along the lines of "remove a feature/setting and lots of people come knocking..." [my wording]). Can we have both simplicity & our required features?
I spent a number of years in continuous improvement where we learn a lot of different process improvement philosophies and methodologies & apply them. One of the basic things I discovered was that complexity lends itself to inconsistency & "problems" (problems being anything from bugs/defects to in-efficiencies) - not to mention increasing the learning curve, maintenance requirements, etc. In general, if we can simplify the innermost core aspects of Moodle, I think the code refinements would naturally start influencing all the stuff around it (3rd party code - plugins, themes, integrations, etc.). Not all complexity is bad, but if there is a simpler way to accomplish the same thing, it's better (but the simple solution may take more time & effort up-front to achieve, because it may not be obvious at first).
I guess Moodle is at a good point - having worked out a huge amount of detail, somewhat through trial & error, it is more clear what the good/bad/ugly are. Good timing for 2.0. It'd be nice to get the refinements done asap so that we could work towards web 2/3/X.0 (lol...). Cheers.
out of curiousity, I checked moodle.
ReplyDeleteprobably I'll agree to all you've said, although I'm still looking at it. wonder how HTML5 will shake all those 2.0 sites.
anonymous reader