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...

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.

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...

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 !!

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

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).

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

Cheers
Sam

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

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

http://docs.moodle.org/en/Development:Navigation_2.0_globalnav_proposal

Cheers
Sam

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

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

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

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.

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.

Cheers
Sam

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.

Cheers Sam

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

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

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

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.

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.

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

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

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