It's not exactly a major feature, but is certainly significant, and as Martin comments, "We need some help from the community here ..." - MDL-35985.

It's not exactly a major feature, but is certainly significant, and as Martin comments, "We need some help from the community here ..." - MDL-35985.
Wow - that's horrible. A really big usability downgrade. I very frequently need to edit settings for things and this would make it so much harder.
My suggestions to improve usability would be to keep the icons basically as they are but:
1. Remove icons for tasks which are infrequent and only really needed as part of detailed configuration of the activity, so it would be okay to just go to the edit screen (group mode, assign roles).
2. Make it fade out all the icons, not hide them completely so you can still see to go to them but use say 20% opacity, except when you are hovering over the line.
The kind of 'settings' menu shown in the example screenshot here is OK for infrequently used, complex tasks but shouldn't be part of the normal interface for manipulating the item. I'm sure different people have different usage patterns, but for me 'Update' is the top priority item, followed by 'Delete', then uh maybe 'Hide', 'Rename', 'Duplicate'...
By the way, when the AJAX interface is in use, it would be sensible if the 'move left/right' feature was handled by drag/drop instead; in other words, when you drag something into a line, instead of just being one drop target there could be, say, four different left/right slots.
--sam
> Make it fade out all the icons, not hide them completely so you can still see to go to them but use say 20% opacity, except when you are hovering over the line.
Actually, I think it would be perfectly ok to hide them completely. I've seen it done in a theme (I don't remember which one). The icons were hidden and they became visible (the whole row of them) only when the cursor hovered over the line. That was wonderful.
The problem with the suggestin in Helen's post is that - if implemented, more clicks would be needed to do a task. Right now you're only one click away from e.g. editing a resource. If you have to click the gears icon and then one of the icons which appear, that's two clicks. One click more is a lot when we're talking about such frequent tasks.
+1 here and also consider positioning the settings icon to the left (in ltr) of the activity link for cleaner aligned look which may contribute to usability when editing the page.
Note that the menu does currently magically appears on hover for desktops (no extra click), but we can't rely on hover ONLY because of touch screens, and touch screens are fast becoming the way most people will use Moodle. The old-style icons are also really hard to hit on a touch screen (and for many people on a desktop too!).
That's the main reason we are pursuing the big settings icon -> named menu approach.
Helen
is this suggestion accessible?
Yes, the menu is accessible. Menu pop's-up on mouse hover/click, or right-key press and up/down arrow keys.
Number of clicks will not be increased as menu pop's up on mouse hover.
Contextual actions are, for our staff and tutors, one of the most commonly used part of moodle. Anything to make the cms side of moodle they use every day easier is very much a major feature for them.
Reducing the display of complexity, until it is needed, makes all operations easier
Moodle often currently suffers from http://en.wikipedia.org/wiki/Hick's_law . The sheer volume of options displyed to users makes it overly confusing to use. Progressive disclosure is a well documented pattern for solving this and in this instance the contextual actions pattern is a best fit solution.
From our own experience using the context actions design pattern in moodle ( http://blogs.sussex.ac.uk/elearningteam/2012/04/20/editing-activities-labels-resource/) we found that the benefits of adding a contextual actions menu and that extra click far outweighed the cognitive load and related decision time users face when all the options are shown at all times.
We found that this use of progressive disclosure and the contexual actions pattern greatly contributed to reducing the overall visual busyness of moodle and thus, as Hick's law might indicate, enhances usability for moodle on a far wider level than simply this use case.
Triggering contextual actions on hover was something our users found seriously iritating.
Menus were frquently triggered by accident, causing anoyance and confusion -no matter what time delays were in place. This corresponds to some general usability issues around onhover where accidental mouseovers are more common than any actual intent by users to trigger an action by hover.
Hovering is fine for showing extra information (tooltip etc) but our user found the noise of their many accidental hovers a greater distraction than convinience.
Our users also agreed with Sam in that only the most frequently performed tasks should be part of a contextual actions menu on this page.
Those actions which require the user to have supplemental information and are better performed in a context where this information is all available e.g. a settings/editing page for groups/roles etc. Again, prograsive disclosure is a best fit for these actions.
Ordering by most frequently used actions also helped users.
The more relevant, expected and simpler the contextual actions can be, the better.
Not sure what experience others have of this, but take a look around the web at where else contextual actions are used (dropbox, g+, fbook etc) and have a look at how why it works for that system.
Microsoft have some nice guidelines for developing what they named context menus here -
http://msdn.microsoft.com/en-us/library/windows/apps/hh465308.aspx
hope this helps!
cheers
Stuart
p.s. the http://www.w3schools.com/tags/tag_summary.asp achieves the interaction you want. css does the rest.
If you need a polfill for this https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills has lots to pick from and using http://modernizr.com/ lets you run them based if browser supports.
Hi all,
We ran into this problem when we (UCLA) were in our pilot phase of Moodle 2 a while back and we'd like to share our solution.
Our users did not like the icons at all. Understandably so since they are all squished against the name of the activity/resource making them look more like clutter than useful tools. Our approach to fix this problem was also to reduce the complexity, but not by hiding it away as a previous post does with a singular 'edit' button.
Since we're not hiding the complexity, our other option is to order it and make it manageable. One of their main complaints was that users had, was that they always to evaluate what each icon did for every activity. So we tried to remove the guess work for users by making alignments consistent and grouping icons into logical partitions. This allows users to always know where an icon is and what it does by infering from the group. We also moved the delete icon far away from the other icons. It's far too easy to click it when you mean to duplicate or hide an item.
I've attached a small presentation where we outline the problems and some solutions that we eventually implemented. We achieved these changes purely though CSS modifications. We did not implement all the changes since we did not want to touch Moodle core. Our changes, however, have simplified the problem for our users.
I'm including our CSS in the form of a github branch. This is a copy/paste from our format to the topics format. There might be some flaws lurking, but I'd be happy to fix these if the community finds it useful: https://github.com/alroman/moodle/commit/b61713e028ae547537d9bb24064e4d4a4951997c
-Alfonso
Here is a screenshot of our implementation.
-Alfonso
I love it! Could you please also post a screenshot with all of these at the same time (as a worst-case scenario)?
Thanks a lot for this. It seems very good for me (and answer my question for long elements)
Just two points : why have'nt you put greyed left arrow (as explained in Alfonso's long post), to have all icons always well aligned ? Nor put moving icons on the left ?
Séverin
We didn't go completely with Alfonso's original proposal because that requires some core Moodle hacks. We decided to see what we can accomplish with CSS changes alone and that is what you see above.
If Moodle core would adopt this change and can refactor the way the editing icons are arranged we can achieve the original goals of Alfonso's proposal.
Rex - We managed to get the icon set alfonso's design includes from twitter bootstrap working in moodle using renders in a theme, without changing the core. I think i know a hack with renderers to get them to output as your original design intends. Have a look at https://github.com/stuartlamour/moodle_bootstrap/blob/master/renderers.php
Hugely agreed though - it would be great to get core to change the terrible way icons have to be implimented at the moment if you want to comment on https://moodle.org/mod/forum/discuss.php?d=204278
Thanks for sharing... very well explained... well thought of... make sense... neatly laid out... pleasing to the eye...
Looks great Alfonso.
Logical grouping make sense and looks great as well.
IMO move looks better on left of the activity as done on UCLA site.
+1
I really like the design work and information architecture in this. Also nice use of the twitter bootstrap icons.
Just a note on the layout though - If you give someone a tool which suggest they should structure their content as lists of links and documents, they will often create a lists of links and documents.
The layout you posted above harks back to something our students used to hate about moodle -
The image above is from a real one of our moodle course in 2009 - its probably familiar to lots of moodle users. Its just a list of stuff without much context. You might as well give tutors google drive or dropbox which do this in a more convenient way than moodle.
From watching our tutors in their offices using moodle we noticed how a standard moodle leads tutors to build this kind of repository.
Rather than using our budget to train tutors in web design, we set about making interface changes to break this pattern.
The interface and workflow in our moodle now seems to encourage tutors to create something more akin to normal web sites.
This is the same course section today -
Inline creation of text, images, videos etc make it simple for tutors to put them directly on the page, rather than as disparate links, and it certainly doesn't look like a file repository. Our changes to the interface alter the tutors workflow which in turn has a direct impact on how they build their sites.
There was a great talk at a moodle moot called From Messy Repository to Quality Interaction and Engagement - which i'm sure is something we all want to aim for with our moodles.
I'd be very cautious of the route you are going down - the table style layout, striping of the list and emphasis of the block layout all contribute to your tutors thinking of and creating that file repository look moodle so often suffers from.
The tool you give people to create with hugely influences what they create.
If you are anything like us - with over 1,500 rather un-web savy staff making courses - you'll want an interface which disuades tutors from the file dump approach, and encourages them to make rich, engaging learning environments.
Hope you take this advice in the spirit it is intended, and not as a critisism.
Cheers
Stuart
p.s. nice responsive design!
This is very cool and inspiring.
I'm going to try to implement some of this, aiming for something between what you finally did with CSS and the top of part 3. I double checked and there's no easy way to do this with renderers as it's not implemented yet.
Stuart mentions he knows a hacky way to do it with renderers, but the only things I can think of are pretty hideous (i.e. watching out for a specific icon being requested and injecting a whole string of HTML into where that single icon should go), but maybe he's got something a bit more sophisticated in mind.
In the meantime I'll see how far I can get with CSS, one improvement to take it closer to your original design is to insert a inactive faded left arrow when the activity is as far left as it can go, with the following:
.editing_moveright:before {
content: url("location of your left-pointing arrow");
vertical-align: middle;
opacity: 0.5;
padding-right: 2px;
}
.editing_moveleft + .editing_moveright:before {
content: none;
}
It's not the most elegant thing in the world but it works. Note that IE generally sucks at opacity, so a production implementation of this would probably create a second, faded version of the icon and point to that, but using opacity illustrates the idea, the other two style for padding and vertical align are just a repetition of what has been applied to the other icons so that it fits in visually. That might need to be customised for each theme.
Have you investigated using position: relative and left: -280px (or whatever is appropriate) to shift all the movement icons to the left of the activity name? I think it might be tricky, but could probably work.
I just implemented something like that - the problem with using :before on an <a> element is that the content of the before gets included in the a, so you'll have a dimmed left arrow that actually has a link to move it to the right. That's why I just went with margins.