The navigation through Moodle can be confusing and need some improvements. This document is a specification defining what problems were identified and how we will solve them. We will be focussing on improving the experience of students and teachers, and users unfamiliar to Moodle.
The following points are the cause of:
There are times where navigating from one place to another will lead to an entirely different looking navigation tree. A good example of this is the Administration block in which the 'Course administration' node will be collapsed and new node 'Module administration' will be added when going from a course to a module.
Consistency is a very important factor as someone unfamiliar with the system will not understand those sudden additions or collapsing of nodes.
Some of the navigation nodes do not contain what you would expect, or contain things that you would not expect. For example 'My profile settings' contains 'Blogs', 'Badges' or 'Messaging'. Those are not strictly related to your profile, they are related to your user account. Also, what can be found under 'Site pages'?
Notes is another example, in order to view to the Notes taken on a course level, I first need to click on 'Participants', and once the page is loaded I can see new entries in the navigation node 'Participants'. Most users will not be aware of those links and will miss out on that feature.
Proper naming of the navigation helps the user remembering where to find what they are looking for. It also helps them discovering features that they would not be aware of, such as 'Calendar' hidden under 'Site pages'. If I have no understanding of what 'Site pages' is, it is unlikely that I will expand it.
Another popular example of bad naming is the link 'My grades' under 'Course administration' in the 'Administration' block. A student is not administrating anything, his grades are not a setting.
The breadcrumb and navigation sometimes jump from one context to another. For instance, as a student when you click on 'Administration > Course administration > My grades', the navigation node on which you appear to be after clicking is 'Administration > Grade administration > User report'.
It can also happen that the user jumps from a course context to a site context, leaving the course (different breadcrumb, different navigation) without realising it and instantly feeling lost. A common reaction would be to use the 'Back' button of their browser to recover from it rather than trying to understand what happened. This behaviour can be observed when visiting someone's profile, viewing some reports, etc...
In order for the users to feel comfortable and confident, and to learn the complex hierarchy of Moodle pages we need to prevent the situations where they feel lost and frustrated.
Both the navigation block and the administration block can potentially have lots of nodes in them. A good navigation system has to be simple and concise. The navigation should not contain the entire site map.
A navigation that is:
Less confusion and frustration
Less resistance New users will feel more confident using the productThough the navigation is improved, experienced users of Moodle could feel frustrated not finding pages where they used to be. On the other hand, re-learning the navigating should be straightforward and painless.
User documentation will also suffer, screenshots and navigation patterns will have to be updated.
Although most of those themes do not change anything about the navigation itself, a few have implemented a user menu. Usually displayed at the top most right of the screen, it contains links to quickly access user specific pages. The most common links are:
Less popular links are:
To achieve our goal we have to remove the need for the administration and navigation blocks. This is a long process that needs to be broken down into sub solutions. Some will need to be developed simultaneously to avoid half-baked temporary solutions. Those solutions can be split into two categories: 'User', and 'Course'.
User solutions:
Course solutions:
The user menu is a dropdown containing links to pages specific to user. They are context independent and will always point to the same pages. The user menu can always be found at the same place in the user interface and will contain the following links:
A link to that page would be placed in the user menu. That page will contain most of what the user has control over on a site level. Their mailing preferences, changing their password, etc... but reorganised.
By adding new content to the profile page, we can trim a bit more the navigation block. The profile page is supposed to contain anything you could find about a user, and there will be links to their blog, forum interactions, notes, to send them a message, etc...
We will keep the distinction between the full profile and the course profiles, at this stage we only improve the site profile because the course profiles need more thoughts and are tied to the course solutions.
The My/ page is underused and does not contain enough valuable information for the users to visit it. We will update it to include more user-specific content. It will contain:
We need to remove the confusion between site and course profiles, only a few more informations should be available when viewing a 'Course profile', but we do not need an entirely different profile for that purpose. The course specific information will be accessible from the user profile, but be in the context of the site profile.
In order to remove the need for the nodes 'Participants' and 'Badges' from the 'Course' entry in the 'Navigation block', and the 'Grades' entry in the 'Course administration' node (for students), we will implement a new 'Quick access' menu for the course. This menu will be accessible on any page within a course, or module.
This menu will only contain links to the 3 entries mentioned above. If later on we add more links to that list, the additional (and less important) entries will be displayed in a dropdown, or a in a 'More' page.
A new grades page will be created for students to access their course grades.
It is important to keep the visible elements of this menu to a minimum. Not more than 3 elements should be displayed at a time. An exception can be made for users with more privileges who will see a 'Settings' (or 'Administration') link, and perhaps a 'Reports' one when we will work on them (see the following the other solutions below).
To unenrol yourself from a course, you would not look into the 'Course administration' node, you would rather find a link on 'My home' page next to the list of courses to unenrol yourself from them.
The same way we would have a 'Preferences' page for the user, the administration page for the module would list everything that was originally in the 'Module administration' node, but reorganised to be more intuitive. A link to that page would be placed somewhere in the general UI.
The modules abusing the 'Adminstration' block to inject new pages into their module should be updated to provide a module navigation instead. It could be a list of links in the module page, or a module navigation such as tabs, this is probably tied to the solution 'Alternative site and course navigation'.
The same way we would have a 'Preferences' page for the user, the administration page for the course would list everything that was originally in the 'Course administration' node, but reorganised to be more intuitive. A link to that page will be added to the course 'Quick access' menu.
Reports are the black sheep of the navigation, nobody agrees on where they should be and they are moved around every so often. Perhaps nobody agrees because they do not belong either in the navigation or the administration block.
Currently they are accessed from the 'Administration' block, and as we are moving the content of the block to administration pages, that is where they will end up. This is surely not better (perhaps even worse) than where they were before, so why not thinking once and for all where they should be.
/!\ Solution needed!
Idea: We could add a 'Report' menu to the course 'Quick access' menu
Now, that everything else has been sorted out, we can will be able to remove the navigation block, but first we need to sort out how to navigate at the site and course levels.
The frontpage would just be an entry point. The navigation node 'Site pages' will be displayed in a block specific to the site pages. Once you leave the context of the 'Site', you will be in a course. Most users will not go back to the front page, except to find some information specific to their institution. To navigate between their courses, teachers and students would refer to their my/ page.
Alternatively, pages like 'Participants', 'Badges' or 'Tags' could be accessed from their context, for instance in a 'Online users' block which would link to 'All participants'. The same applies for 'Calendar', but is already the case because of the block.
The concept of site would disappear as soon as you get in a course. A student or teacher would then focus 100% on the course they are browsing rather than being distracted by site elements.
The course format will be responsible for most of the navigation in the course:
The course format will also have control over the course 'Quick access' menu, in which it could inject/remove items if they wanted to.
The node 'Switch role' disappears from the administration block and we now require a 'Switch role' block to be added to the course to unlock that functionality. This block would only be displayed to users having the capabilities to switch role.
At this point, the administration block will not be displayed to any user, except the ones with elevated privileges. Administrators, managers or course creators will still have access to the administration block but it will only contain the 'Site administration' node.
In order to keep consistency when Moodle evolves and adds new features, here is a set of rules to follow.
The user header contains very simplistic information about the user, and a few links to very common actions in regard to other users. For instance it can implement a link to send a message to the user, because you might want to be able to do that regardless of what user context page you are visiting. But, 'Edit profile' should not be in it, because it is only relevant to the profile. It is very important to keep the number of available actions to a minimum, because having too many options would defeat the purpose of the simplicity and efficiency it is trying to achieve.
For it to be used, the user menu needs to be as short as possible and not being cluttered with additional links. It will contain what has been decided above, and not being changed. The users will get used to its content and thus removing nodes is a very tough decision to make. In any case, it should not contain more than 6 links, and should always contain:
The links in the menu are very important to the user, they target user context-specific pages and nothing related to the site structure or the course. A link to 'My courses' would be redundant as this information should be covered in the 'My home' page.
Every link in this page should belong to a section, the sections are only headers that help the users finding what they are looking for. A plugin that adds user preferences related to its features should define a new heading and add its links to that heading. The heading is never clickable.
The 'My home' page contains everything about a user that is private and not accessible to other users. For instance, your calendar events or your private files. The list of courses you are enrolled in are an exception, they could be displayed on the user profile, but because they are so important and need to be layed out in useful fashion, they will be part of the 'My home' page.
This page does not need to link to pages which are already accessible from the 'User menu', for instance the profile.
The profile page contains everything about the user that is public. In other words, a content specific to the user should not be displayed on the profile at all, because it would never be accessible to another user, e.g. "Private files".
There are exceptions to this rule, badges for example. As a setting allows you to define whether or not your badges are on your profile, you might not be able to see them there, so they should be available on your dashboard.
For content controlled by permissions (and not preferences), they should remain on the profile. Take 'Blog' as an example, an administrator can prevent blog entries from another user to be accessed depending on your role. As the user does not have any information about the roles of the other users, the blog link is displayed on the profile, but other users will not see it. Having a blog block on the 'My home' page would not be useful because it simply duplicates the access points, for no apparent reason to the user.
All the pages on a user context will all have their own layout where the header includes the name of the user in a standardised way, along with some information and a link to message them, and their preferences if the logged in user has the capabilities to edit them. A renderer will be responsible for creating the header, and will use the user ID found from the context defined on that page.
The navigation within the context pages will be:
For your own context Home > Your Name > Page you are on. Clicking on 'Your Name' will lead you to 'My home'.The user header contains very simplistic information about the user, and a few links to very common actions in regard to other users. For instance it can implement a link to send a message to the user, because you might want to be able to do that regardless of what user context page you are visiting. But, 'Edit profile' should not be in it, because it is only relevant to the profile. It is very important to keep the number of available actions to a minimum, because having too many options would defeat the purpose of the simplicity and efficiency it is trying to achieve.
The new user menu would be a new renderer, called from the layout files as it was the case for the login info renderer. The content of the user menu is fixed and not configurable, however it is possible to override the renderer from a theme to change its layout and content.
Placed on the top right of the site, the name of the user is displayed next to a user icon. The dropdown is displayed when the user clicks the icon or the name. On smaller screens only a user icon is displayed, and expands to reveal its content. When expanded the name of the user logged in is displayed.
When the user is not logged in, a login link is displayed, regardless of the screen size.
The 'My grades' page will display the overall grades of the student in all their visible courses. The ordering can be changed, but the default would be alphabetical.
When logged in as someone else, the 'Logout' entry becomes 'Return to Admin User'.
When the user role is switched, the 'Logout' entry becomes 'Return to my normal role'. And the name of the user is appended with the role they switch to, e.g. 'Admin User (teacher)'.
At this stage we could trim the navigation block, but we decide not to remove anything just yet as it would create more confusion: some nodes would accessible from the user menu, and others from the navigation block.
For it to be used, the user menu needs to be as short as possible and not being cluttered with additional links. It will contain what has been decided above, and not being changed. The users will get used to its content and thus removing nodes is a very tough decision to make. In any case, it should not contain more than 6 links, and should always contain:
The links in the menu are very important to the user, they target user context-specific pages and nothing related to the site structure or the course. A link to 'My courses' would be redundant as this information should be covered in the 'My home' page.
The preferences page is a list of links to sub-preferences page. The page will be generated from the navigation node 'My profile settings', though we will have to re-organise them so that each link belongs to a parent node. A link to the preferences page is added to the user menu.
The preferences page displays headings (the setting nodes) under which the links to the sub-pages will be displayed.
The nodes 'Roles' and 'Activity reports' will not be part of this page, because they are context based: they point to the course or site context depending on the page we are on. They will remain in the navigation block, but only when the user has the capability to view them. When the only node in the 'My profile settings' node is 'Preferences', then 'My profile settings' is not displayed. Here is an example when you have the capability to view the reports and roles.
The 'My profile settings' node becomes the name of the user: 'Frédéric Massart'. The 'Profile settings for Jetha Chan' becomes 'Jetha Chan'.
Each of the sub-pages should be checked to ensure that they are in the right hierarchy, the breadcrumb always looks like '(User context nav) > Preferences > Preference heading > Page I am on'.
The node 'Profile settings for User B' can be used to edit someone's settings. The content is similar to 'My profile settings', except that the node will always be displayed regardless of the presence of 'Roles' or 'Activity reports'. Currently there is no other way for a user with elevated privileges to access someone's preferences, but sooner or later the preferences will be accessible from their profiles.
Presently the repositories are configurable from the Navigation block, this is the right moment to move them to the 'Preferences' page.
Every link in this page should belong to a section, the sections are only headers that help the users finding what they are looking for. A plugin that adds user preferences related to its features should define a new heading and add its links to that heading. The heading is never clickable.
For now we will only be focussing on the site profile of the user. Later on, we will be solving the problems linked to the course context, for instances the links to 'Blog' or 'Forum interactions' automatically filtered to only display the blog posts in the course.
The contact details will be displayed in such a way that they do not look like a list any more. For instance, everyone knows what an email address is, there is no need to prefix it with 'Email address:'.
The badges will be displayed on the profile too.
We can start trimming the node 'My profile' a bit, but some nodes will remain until we sort out the 'My' page. When doing so, it is important to make sure that the nodes 'Home > Some course > Participants > User B' still contain everything it does right now, because those links point to course-based pages, and would not be accessible otherwise.
The profile page contains everything about the user that is public. In other words, a content specific to the user should not be displayed on the profile at all, because it would never be accessible to another user, e.g. "Private files".
There are exceptions to this rule, badges for example. As a setting allows you to define whether or not your badges are on your profile, you might not be able to see them there, so they should be available on your dashboard.
For content controlled by permissions (and not preferences), they should remain on the profile. Take 'Blog' as an example, an administrator can prevent blog entries from another user to be accessed depending on your role. As the user does not have any information about the roles of the other users, the blog link is displayed on the profile, but other users will not see it. Having a blog block on the 'My home' page would not be useful because it simply duplicates the access points, for no apparent reason to the user.
We need to add more default blocks to the existing page, the different available blocks will be:
We need to add a link to 'My latest badges' to the page listing all the badges.
We can now remove 'My profile' (or now called 'Jetha Chan') from the navigation block entirely. But it has to still be accessible under the node of a user in a course tree.
The node 'My courses' is also removed, users should be used to using their dashboard to access their courses.
The 'My home' page contains everything about a user that is private and not accessible to other users. For instance, your calendar events or your private files. The list of courses you are enrolled in are an exception, they could be displayed on the user profile, but because they are so important and need to be layed out in useful fashion, they will be part of the 'My home' page.
This page does not need to link to pages which are already accessible from the 'User menu', for instance the profile.
Pending
To be defined.
Navigation experiment Navigation prototyping 2.7 MDL-34838: Navigation inconsistencies Minimal by Moodlerooms Users’ personalised profiles