Hi,
This is a blatant cross post to http://moodle.org/mod/forum/discuss.php?d=119502. I am looking there to involve developers in creating some UI guidelines for Moodle.
I am applying for Google Summer of Code for 2009 to improve the overall consistency of Moodle.
http://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency
Please comment. Thanks!
(In case you're wondering about my previous posting, Season of Usability is still also an option but they have been rather quiet.)
Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Olli Savolainen -
Number of replies: 11
In reply to Olli Savolainen
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Thomas Hanley -
Hi Olli,
Thanks for your work on this. I think consistent UI guidelines as you suggest are essential to support the developers implementing Moodle modules. I can understand that given the modular nature of Moodle that inevitably there are many interface inconsistencies. Also totally agree with the point Martin Dougiamas made that usability has to be seen as an equal priority to technical code development.
Not sure what you meant by involving developers in creating UI guidelines. I can understand that developers will need guidelines that support their work and which are technically realistic. I am not sure though that they are the right people to focus on in terms of creating the UI guidelines themselves. As I understand it developers main focus is technical implementation; the intrticacies of coding in PHP and working with MySQL etc. Usability seems like a different field to me and a time-consuming one also. So I guess I am questioning how developers would find the time to delve into usability. Also I feel that best-practice user interface guidlelines should be independent to some extent from how interfaces are implemented. User-centred design should be the focus and I think in some ways developers are too close to the implementation to fully see things from the point of view of the user.
As far as making all this work I notice in the Drupal link you sent that different people are assigned to different aspects of the work. Is it possible to do this for the UI work you are undertaking?
One of the strengths of Moodle is open feedback and collaboration but I feel that sometimes this leads to information scattered across different discussion threads, the tracker, developer areas etc. I am not sure what the standard practice is for working through these issues. I feel that it would help if a core group of people were assigned to working on this and then sub-groups maybe to focus on different aspects of the work.
~thomas
In reply to Thomas Hanley
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Tim Hunt -
The model of a development project where some people are 'Developers' and they write code, and other people are 'Usability' people and they design the interface, and other people are ... - well that is one way to think about it, but I think it is a bad model. Particularly of Moodle. It is also pretty old fashioned.
I prefer a model where we are all 'Moodle developers' - that is, we all share a common goal of making Moodle better, and we contribute in whatever ways we can to achieving that, and most of us have multiple skills. For example, I write code a lot, but I also write documentation and help people in the forums. I also design bits of user interface interface or write specification or designs for new features.
Of course while we are all multi-skilled we also all have our specialities. That is perfectly natural. You try try to work on things that play to your strengths, and ask advice from other people when you are dealing with something you know less about.
So that is why it makes sense to involve developers in the discussion of the usability guidelines. Some of them will have useful insights. At the same time, one of the main reasons to have the guidelines is to make it easier for developers who are not usability experts. And those people need to be able to understand the guidelines we write, which is another reason to involve developers in the discussion.
I prefer a model where we are all 'Moodle developers' - that is, we all share a common goal of making Moodle better, and we contribute in whatever ways we can to achieving that, and most of us have multiple skills. For example, I write code a lot, but I also write documentation and help people in the forums. I also design bits of user interface interface or write specification or designs for new features.
Of course while we are all multi-skilled we also all have our specialities. That is perfectly natural. You try try to work on things that play to your strengths, and ask advice from other people when you are dealing with something you know less about.
So that is why it makes sense to involve developers in the discussion of the usability guidelines. Some of them will have useful insights. At the same time, one of the main reasons to have the guidelines is to make it easier for developers who are not usability experts. And those people need to be able to understand the guidelines we write, which is another reason to involve developers in the discussion.
In reply to Tim Hunt
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Thomas Hanley -
Hi Tim,
Thanks for your thoughts. My reason for questioning who leads with regard to developing user interface guidelines is that in my experience the majority of commercial web and software application development projects (particularly those which are large scale and complex projects) do have separate roles for those that do the technical implementation and those whose primary expertise is in the field of user interface design and usability. Both of these fields are complex and involving and require different skillsets in my opinion. Of course there is communication between these two groups of people, particularly with regard to technical feasiblity, but user-centred design is about focussing on the user and the design of the system first and technical implementation second.
In your post you didn't say why you though this was a bad model, you simply made a statement that this was 'old-fashioned'. Sorry but I don't understand what you mean by this statement. Could you give reasons *why* this model is a bad model?
Your suggested alternative where we are all Moodle developers with all due respect sounds vague and unstructured. I agree that Moodle developers should be involved but my question was: who is leading the development of the usability guidelines? Personally I believe that with such a complex large scale application such as Moodle you need people with specialist user-centred design and usability experience and skills to do this successfully.
I do agree with you that the Moodle community should have a significant role and input in improving Moodle's usability. However, it doesn't seem clear to me who exactly is guiding and leading the process. Who is taking the useful feedback from users and then ensuring that information is feeding into general usability guidelines or into the specifications for the interactions involved in different Moodle modules?
~thomas
In reply to Thomas Hanley
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Olli Savolainen -
Hi Thomas,
The point about involving developers - to the degree their areas of interest allow - is that the success of open source development is very much dependent on our capability to engage the entire community. That is, a HIG is only useful if it is naturally incorporated into the development process, and finding out a way to have it work for the developers as reference material.
Also, I do think that in a project like Moodle we do need to make developers more and more aware of usability themselves, as suggested by Nielsen in Guerilla HCI. This will never replace the need for a dedicated usability team actually focused in knowing the users, which is, at the end of the day, what HCI (Human-Computer Interaction [research]) is all about. Still, we do need to keep in mind that Moodle is still just starting to care about usability if measured with the scale of The Evolution of Usability Engineering in Organizations, further down the same page (I would say we are somewhere between stages 4 and 5).
However, I agree to a degree that finding someone who will be responsible for keeping the documentation up-to-date as new interaction styles emerge is a challenge, since this person would need to have a strong usability background.
Thank you for your helpful comments, it has helped me to weight the relationship between traditional and open source usability work.
The point about involving developers - to the degree their areas of interest allow - is that the success of open source development is very much dependent on our capability to engage the entire community. That is, a HIG is only useful if it is naturally incorporated into the development process, and finding out a way to have it work for the developers as reference material.
Also, I do think that in a project like Moodle we do need to make developers more and more aware of usability themselves, as suggested by Nielsen in Guerilla HCI. This will never replace the need for a dedicated usability team actually focused in knowing the users, which is, at the end of the day, what HCI (Human-Computer Interaction [research]) is all about. Still, we do need to keep in mind that Moodle is still just starting to care about usability if measured with the scale of The Evolution of Usability Engineering in Organizations, further down the same page (I would say we are somewhere between stages 4 and 5).
However, I agree to a degree that finding someone who will be responsible for keeping the documentation up-to-date as new interaction styles emerge is a challenge, since this person would need to have a strong usability background.
Thank you for your helpful comments, it has helped me to weight the relationship between traditional and open source usability work.
In reply to Olli Savolainen
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Olli Savolainen -
The drupal 7 UX project has been talked about in these forums a lot lately, but to further explain my point above, see How we will make Drupal 7 simple to use, since they are trying to deal with exactly the same kinds of problems: the first video tries to get community rejection as soon as possible along the project in order to "have it dealt with" when the project is finished. They have more of an all-encompassing approach: they are really thinking about the whole user experience of Drupal bottom-up.
The effort I am trying to kick the community and developers to look at is not quite as ambitious, but I do see it as a useful background work to start seeing the whole of Moodle user experience, and how it relates to different user groups and their goals.
The effort I am trying to kick the community and developers to look at is not quite as ambitious, but I do see it as a useful background work to start seeing the whole of Moodle user experience, and how it relates to different user groups and their goals.
In reply to Olli Savolainen
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Thomas Hanley -
Olli,
Sorry for my delay in responding. I got side-tracked on different posts. Thanks for all your work on making Moodle more usable and in particular on developing User Interface guidelines. I really believe that developing Moodle's user experience and interface design aspects is vitally important in enabling teachers and other Moodlers to make best use of this fantastic software (I can't imagine how many tens of thousands of development hours have gone into the programming!). There just needs now to be a push on the user-centred design / usability side of things.
I do agree that developers should be involved in this process. The extent and scope of this involvement is what I was questioning. I definitely think it is good that developers become more aware of the interaction design process and that they are provided with guidelines. I guess the main point of focus for me is on the experience users have and any issues they encounter which makes it hard for them to use Moodle. This is particularly significant as so many Moodlers are teachers, not interactive designers, usability experts or PHP coders! Their main concern is how to achieve a given task. They don't need to worry about XHTML, CSS, PHP etc ; ) So the more feedback from teachers who are non-technical the better.
Thanks for the Guerilla HCI link, seems like an approach that is very relevant to Moodle. I totally agree of aiming for usability engineering to be systematically used rather than sporadically. Of course this is a big task as alot of work will have to be done retrospectively.
Looking in your development area here:
http://docs.moodle.org/en/Development:Usability/Improve_Moodle_User_Experience_Consistency
I think it is a good idea to develop some lightweight Human Interface Guidelines as an intermediate step. I guess then there will need to be some prioritisation of the items which you have listed in
UIs to examine
Interaction styles/elements to examine
Clearly there are so many areas to look at it seems like a big ask for one person to look at everything (ie you!). Once areas to address first have been prioritised would it be possible then to assign one or more people to a specific area (in the same way that Moodle Tracker works?). These usability issues are not of course bugs, they are perhaps better termed 'improvements'. These individuals or smaller teams could carry out some analysis feeding back to someone overseeing this (you!), maybe at the start of the process they could be tasked to carry out the analysis in a structured way so that there is some consistency in the analysis. Not sure what your plans are as far as working through the list of items is. The reason I raise this suggestion is that although these issues can be addressed (to some extent) in the forums, it sometimes feels a bit ad hoc, random, fragmented. Also in terms of work load it would obviously be best to spread the work across a number of people (with a person or group overseeing). Not sure exactly how this would work.
User experience lead person / group
Role: to define the priorities, to provide a framework for analysing current interface mechanisms, interaction types etc
Possible participants: User experience / HCI types, developers, Moodle administrators, experienced Moodle teachers
Course Management (or any other priority area) lead person / group
Role: to use the framework provided by user experience lead in order to systematically analyse a specific areas of Moodle
Possible participants: User experience / HCI types, developers, Moodle administrators experienced Moodle teachers
Moodle Community (Developers, teachers, administrators etc)
Possible participants: User experience / HCI types, developers, Moodle administrators, experienced Moodle teachers, all other Moodle teachers
These ideas about participants are just loose thoughts. For me the main point here is that I think it would help to have some way of structuring how we engage the Moodle community. Yes we need as many Moodlers from all levels of experience involved as possible, but beyond this I think the critical point is how we make use of their skills, experience and time. How we can best make use of this valuable input in a way which is structured and can lead to the creation of user experience and interface design guidelines which are based on a systematic, holistic view of Moodle. I would be happy to offer to get involved in one aspect (maybe it is just how my mind works, but sometimes I find it helps to focus on one task and get this clear). Of course as stated earlier there would need also to be someone or ideally a group of people guiding this from a level where they can see / understand / have experience of many different areas of Moodle.
Hope this helps
~thomas
In reply to Thomas Hanley
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Joseph Rézeau -
Thomas "... interface design guidelines which are based on a systematic, holistic view of Moodle. I would be happy to offer to get involved in one aspect (maybe it is just how my mind works, but sometimes I find it helps to focus on one task and get this clear)." (my italics)
Hi Thomas, This quotation from your thought-stimulating post shows precisely how difficult it is for any individual to have a "systematic, holistic view of Moodle". How can developers and designers concentrate their efforts on specific aspects of Moodle while retaining a holistic view?
Joseph
In reply to Joseph Rézeau
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Thomas Hanley -
Hi Joseph,
The reason I suggested that would be happy to get involved with an aspect or specific area on Olli's list is that I am a relatively new Moodler (6 months!). To be honest I have barely scratched the surface and have not used most of the items on Olli's list.
I take your point though that Moodle is so wide-ranging that it is hard to have such a high-level, holistic, systematic overview. I was speculating (hoping!) that there are other people out there who have used Moodle for several years and are familiar with many different modules and interfaces. Or it maybe that Moodle is like any other software programme in that people generally use only 10-15% of the functionality. Everyone has different requirements and emphases and people may work alot with a subset of the available modules.
On reflection maybe some visual process would help? With complex tasks or information structures a card-sort methodology is often recommended by HCI experts. So you use post-it notes or cards and you lay them all out in front of you to sort and categorise the information or sub-divide the task. Maybe this could be applied to Moodle's interface(s)? You could take screenshots of all the different interface widgets / buttons / navigation mechanisms / interface mechanisms and then list all of the tasks being achieved and the interface mechanisms being used. The aim obviously to arrive at a consistent use of mechanisms for identical tasks. As a visual thinker myself this is the sort of approach I might take to try and tackle such a problem.
To (sort of!) answer your question the aim of the UI guidelines Olli is developing is to provide the holistic / systematic blueprint which is then used as a guide by Moodle developers who are coding specific modules. A developer wishing to include a specific task or interaction would refer to the guidelines to see what mechanism / widget should be used. The ultimate aim of course being a consistent user experience.
~thomas
In reply to Thomas Hanley
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Olli Savolainen -
Thank you, Thomas!
Sorry indeed for not answering you earlier! You raise plenty of important points and I feel your perspective of thinking is something sorely needed in the community. I quickly read your posts now, but will get back to them ASAP.
Olli
Sorry indeed for not answering you earlier! You raise plenty of important points and I feel your perspective of thinking is something sorely needed in the community. I quickly read your posts now, but will get back to them ASAP.
Olli
In reply to Olli Savolainen
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Thomas Hanley -
Hi Olli,
Glad you feel that my input was useful. I can see that developing such interface and user experience guidelines will be a big job, so somehow the task needs to be broken into smaller chunks.
I haven't spent as much time as I would like on developing our Moodle site (as I have been working on the content or a real-world process which Moodle will reflect). Recently though I have begun development work and to be honest I have found it frustrating.
I am in the position of creating a Moodle site from scratch. For me the first thing I have done is structure the information (information architecture is the flash way of saying this!). The site is a mixture of information (about a process) and then Moodle courses to provide training on aspects of the process. So I have sketched out roughly what activities are needed.
This information structure then translates into the site navigation. For me this is of critical importance in terms of usability. There needs to be a clear global way of navigating through the space ie there needs to be a global menu system. The last thing I want to do is present users with a difficult to understand navigation system which will frustrate and alienate them. My users are 90% teachers and they are under alot of time pressure, they do not have time to 'learn' how Moodle works because it is different to every other web site that they have used. I realise that there is this arguement that Moodle is not just a website that it is a VLE or a web application and therefore different. However, to a user this is irrelevant. The most basic thing Jakob Nielsen ever said (repeatedly) is that websites should follow conventions ie behave just like other websites. Of course it must be technically alot more complex to develop consistent navigation for Moodle as opposed to a website with limited interactivity. Particularly as it is modular, open-source, many developers etc. However, it is still critical that this happens.
I realise that Tim Hunt is working on Moodle's navigation and I can't wait to see what he comes up with! Using Moodle 1.94 I have found it problematic to create a basic standard navigation system *which is present on every screen* and therefore unified, holistic; a standard, unchanging way of navigating that is clear for users. There are things like the 'Main Menu' which is present only on the front page, then it disappears, there are different types of navigation that compete with each other (jump menu), the 'my menu block' cannot be set to display courses in non-alphabetical order without hacking PHP. I can't easily change the width if the course names are long! Then there is the navigation within the courses themselves which is not well-designed either and hard to use (ie hiding and revealing topics seems to confuse users).
The recent themes debates have been interesting also (although addressing the theme issue doesn't address navigation really). For me the navigation issues are the most fundamental. Yes I would like to have more control over layout in the content area between the header and the footer but this for me is secondary.
Anyway, I am beginning to rant now so I had better stop ; )
~thomas
In reply to Thomas Hanley
Re: Usability: Consistency: UI guidelines (GSoC 2009; cross post)
by Olli Savolainen -
Hi again,
http://www.pilpi.net/software/moodle/2009/05/27/dimensions-of-the-consistency-guidelines-project/
That is the current high-level thinking I have about the project. If you follow along the link to the community discussion part, you will notice that I do not have it in store for this summer to do much delegating. At the moment, there is little thinking ready at the moment for me to tell others what to do, though indeed, I do hope to get others involved as soon as possible. I will probably need to narrow down the number of modules/elements I inspect to a pretty bare minimum.
The first step for me at this time, is to cater for the developer community, to give them a chance to say how they would like to approach the UI design part of their work - what would they want to possibly delegate, what kinds of cooperation they would hope with UX folks, and how would they be capable of contributing to the guidelines. The minimal contribution I am hoping, at the moment, to get at least from the responsible developers: once there are guidelines, I hope each devel would identify, from the guidelines, which elements/interaction styles are involved in the module he/she is involved with, and adding that information in the guidelines so that it would be easy to find examples of a specific guideline. To at least get acquainted with the guidelines.
I do hope a framework for evaluating the UIs themselves will start to form as we go on - and that I can keep the process of creating it transparent and interactive. This way, some creative individuals could pick up from where my hands can't reach. Of course, as I will during the summer suggest different approaches to cataloguing the current UIs, I hope you will be there to comment on them. Just to have an idea, how much time might you have for contributing inspections of different modules? Do you have an UX/IA background of some sort yourself? What parts of Moodle (modules or other aspects) are the most interesting to you?
http://www.pilpi.net/software/moodle/2009/05/27/dimensions-of-the-consistency-guidelines-project/
That is the current high-level thinking I have about the project. If you follow along the link to the community discussion part, you will notice that I do not have it in store for this summer to do much delegating. At the moment, there is little thinking ready at the moment for me to tell others what to do, though indeed, I do hope to get others involved as soon as possible. I will probably need to narrow down the number of modules/elements I inspect to a pretty bare minimum.
The first step for me at this time, is to cater for the developer community, to give them a chance to say how they would like to approach the UI design part of their work - what would they want to possibly delegate, what kinds of cooperation they would hope with UX folks, and how would they be capable of contributing to the guidelines. The minimal contribution I am hoping, at the moment, to get at least from the responsible developers: once there are guidelines, I hope each devel would identify, from the guidelines, which elements/interaction styles are involved in the module he/she is involved with, and adding that information in the guidelines so that it would be easy to find examples of a specific guideline. To at least get acquainted with the guidelines.
I do hope a framework for evaluating the UIs themselves will start to form as we go on - and that I can keep the process of creating it transparent and interactive. This way, some creative individuals could pick up from where my hands can't reach. Of course, as I will during the summer suggest different approaches to cataloguing the current UIs, I hope you will be there to comment on them. Just to have an idea, how much time might you have for contributing inspections of different modules? Do you have an UX/IA background of some sort yourself? What parts of Moodle (modules or other aspects) are the most interesting to you?