Usability: Editing on/off modality - how should it work?

Usability: Editing on/off modality - how should it work?

by Tim Hunt -
Number of replies: 10
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I am wrestling with this as part of Development:Navigation_2.0_implementation_plan.

As you know, in Moodle you have a button to 'Turn (blocks) editing on/off'. Exactly where this depends on who you are and where you are (that is, on roles and capabilites).

The question is, how should we track that state for each user? Obvious options include:
  1. Just one state that applies everywhere.
  2. Track a separate state for each course.
  3. Something else.

At the moment, it seems we mostly do 1., but with some inconsistencies wink I would like to eliminate the inconsistencies.

The consistent part is
  • a flag $USER->editing that is stored in the session.
The inconsistent parts are
  • a separate flag $USER->adminediting for admins that controls whether you are editing the blocks on the admin screens.
  • and another flag $SESSION->blog_editing_enabled for editing blocks on your blog page.
Naturally, if you are in a place where you are allowed to turn editing on (for example, a teacher in their own course) and then you go to a place where you are not allowed to edit (for example going to look at another teacher's course as a guest) then the page just looks just like normal, and there is no sign of the modality. But if you go black to a place where you can edit, then Moodle will remember that you are in editing mode.

And the only indications we have of the modality are
  • The presence of the editing UI on the page
  • the caption on the editing on/off button.

So, anyway, I am looking for suggestions of how it should work. Please justify your answer, and bonus marks for answers that are easy to implement wink
Average of ratings: -
In reply to Tim Hunt

Re: Usability: Editing on/off modality - how should it work?

by Frank Ralf -
Hi Tim,

I suppose my suggestion falls under option 3. I was tampering the other day with "block_admin_tree" to achieve an effect similar to Drupal's Administration Menu (http://drupal.org/project/admin_menu, demo site http://www.unleashedmind.com/drupal/admin_menu/admin/content). This provides a convenient menu bar across all pages of a site independent from the page content or other menu blocks.

hth
Frank



Average of ratings: -
In reply to Frank Ralf

Re: Usability: Editing on/off modality - how should it work?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
I don't think that answers the question I asked.
Average of ratings: -
In reply to Tim Hunt

Re: Usability: Editing on/off modality - how should it work?

by Olli Savolainen -
To rephrase: when a user sets the editing mode on somewhere in Moodle, should this state be
  • persistent on all pages in Moodle
  • persistent in just that part of moodle (course category/course/module)
  • persistent on just that page
  • not persistent at all; i.e. when the user leaves the page where they turned edit mode on, the edit mode will be off when they return. This could be an option if turning edit mode on was without delay, i.e. implemented with AJAX, so turning it back on was not a bother.
There is no simple answer to this, before there are descriptions of the broader usage scenarios, within which the use cases of editing content (possibly using this functionality) fit.

Of course the alternative is having someone who really knows enough of the scenarios (situations where this is used) to answer the question. smile
Average of ratings: -
In reply to Olli Savolainen

Re: Usability: Editing on/off modality - how should it work?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Yes, so for now I am going to apply Occam's razor, and implement persisting to all pages in Moodle. That is easiest to implement and also easiest to explain to users.

However, I am not going to hard-code that assumption everywhere, it will be nicely encapsulated in once place, so that if we need to change it later based on experience, we can.
Average of ratings: -
In reply to Tim Hunt

Re: Usability: Editing on/off modality - how should it work?

by Olli Savolainen -
I do feel that actually just trying to imagine what situations that feature is needed could go a long way in trying to see the picture that is needed to evaluate this. I think you might know more about the user needs than you realize, and just trying to write down possible use cases might put that information in a form where dots start to connect. Also, this written information, no matter in what form it is, could then be commented on by others.
  • What kinds of situations could there be, where a need exists to edit something in a way which is enabled by this mode? I.e. on a course page, what are the actions that a user can only do if this mode is turned on? What are the situations, where those actions would be a part of a larger goal, for example "to make students more brave on a course to engage socially online, I need to make this forum activity more visible so that students will find it"
  • Then, try to match those needs with the problem you are trying to solve: Is the edit mode used just to make single changes and returned to time and again while making other changes? Or is it truly a mode in which a user goes to do several tasks (a planned activity) at once, and when s/he determines that the goal s/he had in mind is what s/he sees, s/he can turn the mode off again?
  • Finally, does this vary between the different uses of this kind of a edit mode control? That is, does the answer to the previous questions change depending on whether this is used in a specific module or on a course page?
It really is this simple.

Of course then if you want to go further: when you know what you imagine the users to use it for, you can just go ask the same kinds of questions from people, from anyone you know that might use the functionality, verifying if your assumptions are real.
Average of ratings: -
In reply to Olli Savolainen

Re: Usability: Editing on/off modality - how should it work?

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Yes, but all that is time-consuming, and this is just one tiny detail of large changes to the blocks and page system which I have to get finished before I leave australia. I discussed this one lunchtime with Martin, and posted here. No one has given me a reason to do anything other than the simplest thing, so that will have to do for now.
Average of ratings: -
In reply to Tim Hunt

Re: Usability: Editing on/off modality - how should it work?

by Thomas Hanley -

Hi Tim,

Simplicity and consistency are important qualities in making a system usable so having one state that applies everywhere consistently seems like a good approach.

As you say if people cannot articulate why a different mechanism would be preferable then implementing the system you outlined would be best.

~thomas

Average of ratings: -
In reply to Tim Hunt

Usability workflow in open source

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
Now I am in less of a bad mood, perhaps I should explain this a bit more wink

Basically, I have found that the following workflow works effectively in the Moodle community (and probably in other open source communities) and it is the workflow I was implicitly following:

1. Given a particular design decision (whether it be UI design, database design, or any other type of design)

2. Think about all the use cases, user stories, requirements, etc. that you know about, come up with the best solution you can (perhaps also known as the simplest thing that could possibly work). Perhaps discuss this with a friend.

3. Given the importance and repercussions of the of the decision, are you sufficiently sure you have got a good enough solution? If yes, stop.

4. If no, post your proposed solution in an appropriate forum, and ask "can anyone give me a use case, user story or requirement that shows that this solution is not good enough?"

5. Wait a while. If anyone does give you relevant new facts, go back to 2. Otherwise stop.


Anyway, I am not sure that this particular approach is available in a lot of settings in which usability experts traditionally work.

But, given that coming up with an exhaustive set of use cases, user stories, or requirements for any really large application is essentially impossible, or at least exhausting, this workflow is worth considering. As I say, I have found it quite effective.
Average of ratings: Useful (1)
In reply to Tim Hunt

Re: Usability workflow in open source

by Oleg Sychev -
Picture of Core developers Picture of Plugin developers

I couldn't see anything quite wrong with global editing mode (assuming that editing activities is a separate thing, i.e. you should not enter in global editing mode to add a question to a quiz, apart from fact that loading course editing screen is quite slow, especially with AJAX on. It may as well be OK.

I still can give one use case when global mode can be a bad thing. Consider Moodle groups - it have such global mode right now. We have a forum where students can write a reports if they think some question is wrong. Looking on such reports I naturally use "all groups" mode. Reading a report I open in a new window a relevant quiz, and set in it reporter's group so I can easealy find his attempt. Finishing dealing with this attempt, I write a response in a forum and ... find myself in a reporter's group mode. And re-setting group mode in a forum I affect quiz mode, in which I need an exact group and so on... It would all be much easier if each module instance would have a separate group modes.

Overall conclusion: in ideal word the better system would be such: there would be two modes

  1. global (last setted maybe) mode - for a pages, on which user doesn't directly set a mode in this session
  2. local (page) mode - if a user set some mode directly on this page in this session, it should hold until explicitly setted by user in another mode.

It is debatable, if editing mode worth the trouble of implemeting such ideal solution (thought false loading of course edinting page is a costly operation, especially with AJAX).

Average of ratings: -
In reply to Oleg Sychev

Re: Usability workflow in open source

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers
The problem you describe is unrelated to editing on/off.

Instead, it is an instance of the 'Moodle sometimes uses the session for things that should be form parameters' bug. In this case, the group that the forum post will be made to.
Average of ratings: -