Moodle

I like the idea

But the risk is that all infos doesn't fit on the page

For Quiz module, with all the things you wrote, i'm not sure it will fit in one line...

Smaller tabs? More rows? Combine some? ("Management"?) Other solutions?

The 'Preview' tab probably could be removed - make it into a button from the Edit screen (that launches a popup or a separate, student-view-ish sequence of pages)?

Leaving aside quiz module I think it's a quite good idea and would like to see this. My only concern is that it makes modules a bit ugly/non-studentview-y, i.e. when you have edit permission you always see this row of tabs, no way to get rid of it. But it's only a bit more obtrusive than the current 'Update' button so maybe that makes no difference.

As usability (both senses) changes go, re the two roles screens that apply to activities, MDL-9466 and MDL-8312 are probably more important. But I would say that wouldn't I.

The main object is to help the user knows all the thing he can do from one point.
This can become more like the menu lists on a word processor but Moodle is inside a browser.
Unless...
we got a structure like Acrobat Reader

and Moodle complexify is growing.

The screen problem : which size set as a standard (more than 800*600!)
The language problem and the relation with the text length...

Setting some prototypes could help the discussion and can be a good summer work...

As I'm working on for french MoodleMoot 2008, writing a conference on how to develop an activity module, I was categorizing modules in two main ranges :

The first one I call sequential modules, where activity is proceeded by phase of actvity as linear process or maybe a more complex workflow. The second one I call it "sub application", which has rather a parallel access or tree-organisation just as a Web site.

Maybe the design of a sequential module may not have need of tabs, as only one screen of the module might be available at the same time for one user class. Of course more complex modules should merge both approaches, having a major sequential design but with accessories that might be accessed all the time.

In my older devs, Techproject was typically a sub-application, with very little workflow activity. Brainstorm (unpublished yet, but largely reviewed) was typically offering both, configuration selectable. This is the typical example of switch where tabs are required and help a lot usability when all phases of brainstorming may be accessed simultaneously, but where a teacher might choose to use it as a full sequential process. Tracker is such a sub-application, as was logical for that kind of function. Flashcard is getting rather a sequential module switching between two action screens for the student, and becoming a more parallel device for the teacher that has to access to status screens.

Usually, as a module is reviewed and enhanced, gaining in complexity, there are IMO very few situation where a pure sequential or pure parallel access may survive. We should quite always need both, even if the major behaviour of a module twicks to one or the other side.

Question : what would we do with a single tab bar, when functional design concludes we do not need more ?

Anyway, I vote in favour !!

Nice idea, as a newbie to Moodle one thing that stodd out for me early on was the need to scan the page looking for form buttons for various actions like "Update this thing", locating them near the end-user actions seems a good move.

Also, a tab-d layout would also fit nicely/easily with any of the AJAX libraries that support tab layout widgets.

Very good idea. I second Dean's comment - a lot of options are hidden behind multiple clicks and it acts as a moderate barrier to entry for new teachers, who need to be helped to discover things.

Martin - I think this might be a great area for Laia to work on even if it is a bit tedious. The idea would be to go through each of the core modules and identify what the tabs would be. I see to a large degree this has been done but it would be nice to have a table indicating areas where additional tabs are needed, to evaluate tab order, and general stuff like that. There is also the possibility of moving tabs using javascript mentioned in the Fluid project which I think plays into what Dean mentioned with support tab layout widgets. I think I might prefer javascript to AJAX as my impression has been that AJAX generally slows the page down especially for large courses. Again, some research on comparing these appoaches could be useful to the developers as we try to figure out how best to implement the tabs.A question for Laia that I would have is under what circumstances would tabs cause more confusion or not be recommended? Peace - Anthony

Anthony - I have studied what you suggested in http://docs.moodle.org/en/Student_projects/Usability_issues/Tabs analyzing the best structure of the tabs and its best implementation (which I found that AJAX is the best implementation) Moreover, I look the Tab Usability Guidelines described at Jakob Nielsen's Website (http://www.useit.com/alertbox/tabs.html) and I found that it would improve Moodle's usability if the currently selected tab is highlighted. I think this feature should be in all Moodle pages where tabs are used. I added this guidelines to the developer usability guidelines I am writing (http://docs.moodle.org/en/Student_projects/Usability_issues/T7).

I also think it is a good idea to
a) keep navigation across modules as consistent as possible (as long as it does not interfere with each module's specific use cases)
b) have configuration in a more obvious place than it is now (with a more obvious label than "update this [modulename]")
c) do something about the fact that quiz configuration now has a set of tabs of its own (there is no clear return route for users from those tabs to the main quiz set of tabs, or communication about the relationship between the two different sets of tabs).

This change seems to have a chance to solve the above. However, I do think that deciding to just "add tabs" as a means to improve usability is very superficial. There are big issues in the configuration screens, which will not be solved by this change. If a major change is introduced (the configuration is moved to another location), it would be best to take a good look at the configuration screens so that major changes need not be introduced in many subsequent versions. With the following, my intention is not to bash others' valuable work, but to demonstrate the fact that a superficial decision of whether configuration should be a tab or a button might not address the actual issues.

Expressed in another way, there seems to be no notion here of taking the actual usage scenarios into account, although this is an UI-level change. Moving functionality into tabs may help, adding consistency probably will, but unless you look at these changes in the context of the use cases and more broadly, the actual usage scenarios, you don't even know if this is really that relevant to users or not. Of course some kind of a personal context is – to some degree – in the heads of everybody discussing here. However, knowing whether or not that is representative of real users would require communicating the actual scenarios and use cases affected by the current state or the proposed change.

That said, what comes to my mind quickly are that the different options should be analyzed throughly and it should be determined with real users. To get a bit deeper, different information gathering methods can be used to:

• which settings are basic ones that every user of quiz should consider, and which ones are advanced settings
• which settings or their outcomes are not understood by users at all
• which interdependencies between settings are not understood by users from the current UI
• what are reasonable defaults for different usage scenarios

Laia: As reported by several users and John Isner in the conversations (http://moodle.org/mod/forum/discuss.php?d=72828#p326446 ) we have had about Quiz editing UI, the subtabs of editing quiz, related to the question bank, are enormousy confusing. They communicate a wrong conceptual model for the relationship of quiz and questoin bank: they say that question bank is something that is subordinate (inside) to quizzes, when in fact they are independent to all the quizzes of a course. Users are initialy led to understand the application wrong. A suitable method for switching between category and quiz views is under consideration, since the tabs are unbearably misleading, but perhaps some other kind of a navigational mode would work. I will propose a way to go about with this in the Quiz UI.

However, I am strongly in favour of your proposal (http://docs.moodle.org/en/Student_projects/Usability_issues/Tabs) of adding a separate top-level "settings" tab, under which the current settings and roles/permissions could reside (and not convolute, for example, the exparience of grading quizzes, with having too many unrelated top-level configuration tabs).

Just FYI, I came across the YUI tabview widget yesterday and it looks like it makes adding AJAX for the tab loading pretty easy.

http://developer.yahoo.com/yui/examples/tabview/datasrc.html

Isn't this one of the things you want me to work on Martin?

Yep, this is the one!

This issue has been hijacked and edited to cover the changes that will be coming about in Moodle 2.0 that are inline with the original intent of this issue.
It will now be used for the modifications that are being made as part of the changes coming into play regarding the Moodle 2.0 Navigation Implementation
See here: http://docs.moodle.org/en/Development:Navigation_2.0_implementation_plan#Navigation

Hi Tim,
I've put a bit of work into this one over the past couple of days in order to produce an initial concept patch for the global navigation block.
I've attached the patch to the issue now and if you find a couple of minutes to give it a whirl that'd be great. It's still very early on for that patch but I'd like to get some feedback from you regarding this encase I am off on a wrong tangent.

Cheers
Sam

Another bigger better patch...

Yet another patch, this time with global nav, nav bar, and settings nav
global.navigation.300709.patch

Latest Patch: global.navigation.040809.patch
There are two new icons as well which will be missing currently, t/reload.png, and t/collapse_empty.png

Latest patch: global.navigation.050809.patch
Deprecated (print/build)_navigation, and squashed a few bugs

I have a busy week this week. I will try to take a look at this some time, but don't hold your breath.

Latest patch: global.navigation.100809.patch
Cheers all who look at this for me

Hi Tim, not a worry, Martin's commiting a bit of time to have a look at this for me before he shoots off today.
If you do find any time to have a look at it I'd love to get your feedback

This is the latest patch, I've uploaded it ASAP so that you can grab it before you leave tonight Martin.
The latest changes on moodle head caused a few conflicts but I believe I have most of them sorted, hopefully no killer bugs.
This patch also has a known issue in the Javascript that I can't seem to reproduce when I want to. Sometimes moving the mouse over a link will cause the sidepanel divs mosueout event to fire... not good it closes the div. I'll look into this an any issues that I havnt' found caused by the last update tomorrow.
Have a good night.
Cheers
Sam

Hi Sam,

I've applied the patch and am seeing that the breadcrumb is now showing the course category and that the course has an icon up there as well. Also blocks seem to open/close on javascript. Is there a specification somewhere stating what are the changes that this tracker item/project nowadays implies? Thanks.

Olli

Latest patch: global.navigation.140809.patch
Some big stuff has happened in this patch, many bug fixes, and is nearly 100% cross browser compatible I think with only one known issue in IE7 when mouseover expansion is enabled and the mouse is moved across expanded elements.
Left on my todo list is to performance test this with a LARGE site
Thanks for the question Olli, check out http://docs.moodle.org/en/Development:Navigation_2.0_globalnav_proposal
I am still working on it as there is ALOT that has changed since I wrote the first version (mostly to do with my understanding of Moodle)

Cheers
Sam

Ooops, just noticed that Netbeans put `\ No newline at end of file` into the patch file several times.
For anyone applying this patch please edit the patch and remove all instance of `\ No newline at end of file` before you try and apply it.
Cheers
Sam

You could fix and re-upload

Hmm, patch seems to be missing: lib/javascript-navigation.js

Coding error detected, it must be fixed by a programmer: Attept to require a JavaScript file that does not exist.
lib/javascript-navigation.js
Stack trace:
line 131 of /lib/ajax/ajaxlib.php: coding_exception thrown
line 98 of /blocks/global_navigation_tree/block_global_navigation_tree.php: call to page_requirements_manager->js()
line 832 of /blocks/moodleblock.class.php: call to block_global_navigation_tree->get_content()
line 364 of /blocks/moodleblock.class.php: call to block_tree->formatted_contents()
line 796 of /lib/blocklib.php: call to block_base->get_content_for_output()
line 855 of /lib/blocklib.php: call to block_manager->create_block_contents()
line 312 of /lib/blocklib.php: call to block_manager->ensure_content_created()
line 40 of /theme/standard/layout-home.php: call to block_manager->region_has_content()
line 750 of /lib/outputrenderers.php: call to include()
line 704 of /lib/outputrenderers.php: call to moodle_core_renderer->render_page_t

Oops, sorry didn't see above comment. It was the malformed patch

Latest patch: global.navigation.170809.patch
Made sure that Netbeans didn't insert any rubbish into this patch.
Cheers
Sam

Still did not manage to actually do anything after applying the patch. Please beep me again when you have any documentation from the user's point of view (use cases/usage scenarios) that I could try and evaluate the user experience. Thanks!

Sam, I am waiting for this to be ready/committed before I can go ahead and change the calls to print_header() throughout Moodle. I am not yet sure what the API for $OUTPUT->header() will end up as, so I cannot make this change yet.

Maybe, once the patch is in CVS, you could start by updating a couple of "normal" pages with the new way to use navigation and $OUTPUT->header(), and edit http://docs.moodle.org/en/index.php?title=Development:Outputting_HTML_in_2.0&action=edit&section=23

Keep up the good work

Latest patch global.navigation.210809.patch
Tidied up a few more minor bugs, and have written unit tests.

Hi Olli,
I'll talk to Jordan when he's in next (he's been sick for the last couple of days) and see if I can set up a demo site somewhere so that people can have a look at it.

Cheers
Sam

More random new feedback from playing with it and looking at last patch (beyond feedback from last friday)

Blocks in general:

• B1) Should only be able to add Navigation and Settings to a page once. There is a setting for that in the block class somewhere.
• B2) I would personally prefer if the popout appeared on mouseover, without needing a click. Like menus on moodle.org.
• B3) The popout block seems to float away from the edge ... can it be anchored to the button (more like a menu).
• B4) If the defaultstyle is going to take up that bit of real estate on the side all the time then I definitely think it should scroll with the page. Currently you scroll down and even though there is space for it the popout blocks are not there (and they easily could be)

In the navigation block:

• N1) I think the topmost level item should be "Home" instead of the site name
• N2) The tooltips are mostly just replicating the name of the links (except for course shortname/fullname which is OK). Can the others be more descriptive? ie "Course category" for the categories, "Forum" for the forums (and same for all activities) etc.
• N3) I think "Switch Position" could describe the next action, like "Display as popup" and "Display as block" with a little icon showing what it will do when you press it. So something like: []<=

In the Settings block:

• S1) When adding an activity or resource, the module name being passed to modedit.php is the item name in the menu. This means it works OK for one-word modules that match the actual module name but not for others (eg try any assignment or SCORM/AICC).
• S2) Reload navigation should just be a little reload icon in the navigation menu.
• S3) Same problem with tooltips replicating the menu item exactly. If they don't add any information then leave them out.

Re B1) - I have a nasty feeling that in blocklib.php, the function that works out if a block is already present on a page is still a TODO. Needs to be fixed, and I cannot promise I will have time. I'm sorry.

Yeah, I seem to recall blocks default to not allowing multiples and one must override the default false return value of instance_allow_multiple() method.

Sam, note for the future: If you use a sane date format like 20090821, then the patches would appear in date order, and it would be much easier to find the latest one.

Having reviewed about 30% of the patch, this looks very good. One bit of evidence for that is the terribly picky and pedantic nature of the comments below.

1. block_global_navigation_tree is surely not copyright Alan Trick

2. I though we had decided not to use @subpackage.
http://docs.moodle.org/en/Development:Coding_style#Packages
Applies to other files too.

3. if ($this->contentgenerated === true) return; breaks coding guidelines. Should be on three lines with braces. There are other instances of this problem.

4. $titlebits = Array(); breaks coding guidelines. array has a lower-case a. There are other instances of this problem.

5. $properties['text'] = join(' > ', $titlebits); $properties['shorttext'] = join(' > ', $titlebits); Using > here is an accessibility problem. Screen readers will read it in a stupid way. That is why the nav bar uses a triangle symbol with some extra class="accesshide" content.

6. blocks/global_navigation_tree/db/upgrade.php First line of the comment is wrong. It mentions the news_items block.

7. As I know you are already aware, you actually need to create default instances of the nav block.

8. moodle/blocks/moodleblock.class.php typo: " that the defauTL values here still get set"

9. Why is moodle/blocks/rss_client/editfeed.php in the patch?

10. block_settings_navigation_tree PHP doc comment. Same problems as above, and also the first line of the comment mentions the wrong class. This comment is too short. Image you were explaining this code to someone sitting next to you. Surely you would say a bit more about what this class is for.

11. function preferred_width() is deprecated and no longer used. I don't think you should include it in new blocks.

12. block_settings_navigation_tree_edit_form also has a copy-and-paste comment with the wrong block name.

13. Like the way course/format/.../lib.php avoids duplicated code.

14. moodle/course/switchrole.php almost certainly does not need to do preload_course_contexts($course->id); Surely you only need the course contex, so loading all the others is an unnecessary expense.

I have got as far as Index: moodle/lib/javascript-navigation.js in the patch. That is enough for today. More later, possibly.

Hi Tim,
Thank you for the great feedback and taking the time to look at the patch, I am in the process of making the changes noted above by Martin, will also endeavour to fix up what you have noted.
Will post more notes with my next patch.

Cheers
Sam

15. e.nodeName!='BODY' does not work. In HTML tag names are upper case. In XHMTL they are lower case. You need to add an .toUpperCase() to make this work reliably.

16. sam Marshal and Petr were talking about adding classes like "ie ie8" to body, so we only have browser-sniffing code in one place. That is, you should not need to do code like YAHOO.util.Dom.addClass(e, 'ie_scroll_fix') - once that is implemented.

17. this is horrible:
tabtitle.innerHTML = tabtitle.innerHTML.replace(/([a-zA-Z0-9])/g, "$1<br />");
What does it do? Does it work with XHTML strict headers? Can't you use CSS display block or margin-bottom to achieve the same effect?

18. I don't think that class navbar should hard-code the use of the global $PAGE. It would be more flexible if the page or global_navigation to use was passed into the constructor.

19. Same comment for settings_navigation.

20. For some settings like roles assign/override/check and filter settings, we need the same links in several contexts. You seem to be doing this with duplicated code. Surely this should be refactored.

21. load_user_settings is horrible, as your comment says. If there is a particular user associated with this page, and if that is important, then create a new field $PAGE->userid with default null. Set that where appropriate, and user it here.

22. The code in navigation_xml:: convert_child is a horrible mess of if statements. Have a look at moodle_renderer_base::output_start_tag for a cleaner way of handling this sort of thing with an associative array of attributes, and having the output code omit the blank ones.

23. What is the $area field/constructor argument to navigation_cache? Please explain in a PHPdoc comment.

24. I don't think you should stick things directly into $SESSION->{$area}. Too easy to get a name collision that stops over other important stuff. I would use $SESSION->navcache or something,

25. Also, I think this code would look much more natural using arrays rather than stdClasses.

26. The use of __call in navigation_cache looks evil. Just rename check to is_present or something, and use that. It will be much easier to understand.

27. Does navigation_cache::clear really clear $SESSION->area? My knowledge of PHP references is not good enough to be sure.

28. White-space/indent problem with the PHPdoc comment on tree_block_contents

29. Nice to see unit tests.

Wow. Great work. Can't wait to see it committed.

Latest patch: global.navigation.20090828.patch
Thanks all for the feedback, changes have been made in consideration of what was said.
This patch is far more polished and now sets up the blocks on install and upgrade.
I will get Jordan to get it applied to a test site when he arrives in for the day.
Note: The upgrade code really needs to be checked, its pretty crazy stuff.

Cheers Sam

When visiting a page, the last item in the breadcrumbs correctly shows the current page, but it is also a link. That should never be the case, because a link always means: "Go to a different page". This is also a problem in the nav tree, where the item currently browsed is a link.

When switching JS off:
1. The navigation block's contents are too wide for the block, leading to some links being truncated. I see a horizontal scrollbar at the very bottom but I doubt this is a good alternative, especially for the admin block which is so tall.
2. The down-arrows on the left of each link category are probably not needed and take unnecessary space
3. The refresh and "move to block" icons are not needed

Another note Sam, I think you should consider the "Accordion navigation" paradigm with the nav tree: when you click a category, other categories get collapsed. I say this because, in practice, you will almost never need to have more than one category of links open at once.

See http://www.welie.com/patterns/showPattern.php?patternID=accordion for some examples.

Sorry to bug you, but here are a couple more tips to improve the usability:
1. When you mouse over the tabs on the left, there should be a 0.5 second delay before they popup. This will prevent unintentional hovers.
2. If you just hover to show the tabs, you should also simply hover away to hide them. Currently you have to click away from the navigation panel to hide it. This is especially annoying because of item 1. in this list
3. Related to some items I posted earlier, we should try for a navigation panel that doesn't require a scrollbar in most cases
4. When you mouse over a link category (non-linked), the cursor changes to a hand. However, clicking doesn't do anything. Either the cursor should remain as an arrow, or, if it changes to a hand, it should activate the expand/collapse action of the arrow
See http://www.useit.com/alertbox/mega-dropdown-menus.html for some good tips.

Latest patch global.navigation.20090828.01.patch
Getting very close now....

Hi Nicolas,
Just reading through your notes... thank you for having a look and think about it.
The block width is a hard one, if you turn on editing and look within the block settings you will see an option to enable JavaScript Expansion on mouse-over which was the first attempt to find a workable solution.
In saying that I really like you idea about re-jigging the CSS when JavaScript is disabled to remove any poorly used space for that environment.
The accordion navigation I'm not too sure about, but I'll have a think/chat about it and see where we end up.
As for the delay when mousing over, I will certainly implement this however I want MDL-19935 to be resolved. Implementation of this would be really simple using YUI animation, however it requires CSS to be loaded. As soon as this is resolved I will be able to implement animation quickly.
The closing when hovering away is also something that a bit of time went into, unfortunately I couldn't come up with a good quick solution that worked on all browsers. However if I get a chance I will have a look into it after this has all finally being commited.

Hi Sam,

I've just had a quick play around with the test account on http://test.moodle.org/nav/ and think the new navigation looks fabulous!

Here are a couple of small issues I came across:

• Changing between 'View my profile' and 'Edit profile' within a course results in 'Course Administration' and 'My profile settings' swapping positions in the settings block
• Following the messaging link changes the font size

Oh, that navigation indeed is an improvement . I am impressed
+1 for Nicolas' comments, too; adding 0.5 or 1 sec delay before hover (though I did not find it) and removing the scrollbars.

Also, a minor note related to Nicolas' earlier comment:

Home / ? My profile settings / ? View my profile

only "Home" and "View my profile" are links. The latter should not be, but "My profile settings" should.

Sam, just noticed that the search box in the settings docked block is not usable: when you click in the input field, the focus on the block is lost.

awesome navigation system !

tiny issues;
+ after adding a new question to the quiz, the navigation is gone.
+ the two tiny icons on the bottom of the navigation should be a little aprat ( so i/others could tell they are not one )
maybe even move them next to the "-/+" icon, inside the the header section of the block?
+ last branches on the nav tree should (probably) have different icon to tell they are the last element/node.

oh - please no Call-time pass-by-reference! This is strictly forbidden even in stable branch because it breaks completely in PHP 5.3 committing fix, please review

Also I noticed some obsolete & when assigning objects, those should be used only when dealing with arrays in PHP5

Hi all, just commited a series of minor tweaks as suggested above:
1. Fixed focus on search closing the visible tab.
2. Adding spacing to refresh/moveto icons.
3. Made text for expandable branches clickable if not a link.
4. Final element on navbar no longer a link.

Petr and Nicolas thank you both for the fix's that you have submitted... much appreciated.

Nadav I had a look at adding a question the reason that the navigation blocks are not shown is because all blocks have been disabled on the quiz-form pages.
I think that is Tim's area, when he shows up online again I will bring this to his attention and see what he thinks.

Cheers
Sam

Sam, here is some more feedback on your last updates:

1. In Firefox (3.5, firebug off), I can now focus into the search box, but I cannot type into it. Nothing happens when I try to type... This works fine in Opera though
2. When I go into a quiz module, the breadcrumbs show the Course as the last element, not the quiz as expected. This doesn't occur with the other modules I have tested
3. Can we now get rid of the "Turn editing on" buttons, since they are in the "Settings" block?

This is looking better every day, fantastic work

I suggest people add subtasks for new buglets now. Adding one right away.

Finally resolving this issue