Hi all,
This discussion has been created to generate feedback about the proposed navigation structure that will be coming along as part of the changes in the Navigation 2.0 implementation.
To help Tim I have a created a mock up tree that outlines the proposed structure after discussions in the office, and reading through the user comments left on other Navigation discussions.
The mock up can be viewed here: Navigation mockup
Please feel free to post any comments or ideas you have here; I'll be watching this discussion closely to see your feedback.
For more information on this please read through the discussion that Tim created: What is the structure of a Moodle site?
As well as the general discussion created by Martin: Navigation 2.0
Cheers
Sam
Ciao Sam.
Let me contribute with my first 3 cents.
At first sight and talking about the "Settings" column of the page http://samhemelryk.info/tree.php: why do a root level item is reserved for "Category Administration"? As a "silly" end user I would like to find it just before the "Courses" item in the "Site Administration" root level because courses are flowers growing inside categories.
Second cent:
for both, "categories" and "courses" I would define two different children item: "Edit" and "Add" instead of the current situation where:
Why do it is used "Add" for courses and "Create" for categories? Why do this difference?
So, summarizing, my suggestion is:
Site Administration
Let me contribute with my first 3 cents.
At first sight and talking about the "Settings" column of the page http://samhemelryk.info/tree.php: why do a root level item is reserved for "Category Administration"? As a "silly" end user I would like to find it just before the "Courses" item in the "Site Administration" root level because courses are flowers growing inside categories.
Second cent:
for both, "categories" and "courses" I would define two different children item: "Edit" and "Add" instead of the current situation where:
- for categories, only "Create a new category" is available
- for courses, only "Add/edit courses" is available
Why do it is used "Add" for courses and "Create" for categories? Why do this difference?
So, summarizing, my suggestion is:
Site Administration
...
--> Categories
Ciao.
--> Categories
----> Add
----> Edit
--> Courses----> Edit
----> Add
----> Edit
...----> Edit
Ciao.
Hi Daniele,
I agree with you, and maybe `Category Administration` should be moved into the Site Administration branch between Users and Courses. It would make sense to move it and I can't think of a good reason to leave it where it is... in saying that I will for the time being and encourage others to comment on it.
If no one comes up with a reason why it should stay where it is I will move it!
There is currently a task in the tracker MDL-17500 which has been created to cleaning up the user interface for adding and editing courses and categories.
At the moment the items under courses are just a copy of what is presently available in Moodle, however it will be changing as per the issue MDL-17500, and we should be able to split into Add/Edit for each.
As for the third point I will certainly change `Create` to `Add`
Cheers
Sam
I agree with you, and maybe `Category Administration` should be moved into the Site Administration branch between Users and Courses. It would make sense to move it and I can't think of a good reason to leave it where it is... in saying that I will for the time being and encourage others to comment on it.
If no one comes up with a reason why it should stay where it is I will move it!
There is currently a task in the tracker MDL-17500 which has been created to cleaning up the user interface for adding and editing courses and categories.
At the moment the items under courses are just a copy of what is presently available in Moodle, however it will be changing as per the issue MDL-17500, and we should be able to split into Add/Edit for each.
As for the third point I will certainly change `Create` to `Add`
Cheers
Sam
Performance-wise, I take it that in the real version, the sub-tree under a course will be loaded on-demand using AJAX. Otherwise loading the page would take a very long time on large sites. (It already takes a significant amount of time to load.)
Hi Hubert,
Absolutely the idea will be to initially load only the relevant part of the tree, and have the unexpanded branches loaded by AJAX or by refreshing the page.
Whilst talking through this with Martin and Tim the idea of caching also came up, and we will look into ways in which we can cache the generated structure of the tree to try to ease the burden on the system when this thing gets generated.
Cheers
Sam
Absolutely the idea will be to initially load only the relevant part of the tree, and have the unexpanded branches loaded by AJAX or by refreshing the page.
Whilst talking through this with Martin and Tim the idea of caching also came up, and we will look into ways in which we can cache the generated structure of the tree to try to ease the burden on the system when this thing gets generated.
Cheers
Sam
Hi Sam,
the mockups look good, but I'm also interested in the AJAX loading thing. I thought this through with my AJAX marking block development as I needed a PHP fallback for the AJAX-tree thingy. There were several cases to take account of:
My solution was to provide a degraded list of just the main assessments with unmarked work, which is loaded every time using PHP. If AJAX can be used, it's loaded on top and allows for a more fine-grained tree structure with individual student names. Trouble is that it's heavy and could do with slimming down.
What sort of solution are you looking at for 3?
the mockups look good, but I'm also interested in the AJAX loading thing. I thought this through with my AJAX marking block development as I needed a PHP fallback for the AJAX-tree thingy. There were several cases to take account of:
- A grade browser, JS enabled - no problem: just load AJAX
- A-grade browser, but screen-reader in use so AJAX must be switched off - check for user profile setting and use PHP instead if needed.
- Sub-A-grade browser or one which has JS turned off - problem.
My solution was to provide a degraded list of just the main assessments with unmarked work, which is loaded every time using PHP. If AJAX can be used, it's loaded on top and allows for a more fine-grained tree structure with individual student names. Trouble is that it's heavy and could do with slimming down.
What sort of solution are you looking at for 3?
I don't know what Sam et al. are planning for this, but my initial reaction to this case is to not allow the user to expand the subtree under the course, and just provide a link to the course itself. (Or provide a link to a page that has the course subtree expanded.)
i have no preferences of my own BUT...
every teacher i showed this demo to insisted
it should expand into the course resources and activities
since it reminded them other LMS systems they used
and were already familiar navigating (mentally).
every teacher i showed this demo to insisted
it should expand into the course resources and activities
since it reminded them other LMS systems they used
and were already familiar navigating (mentally).
In reply to Nadav Kavalerchik
Re: Proposed navigation structure for Moodle 2.0
by Martin Dougiamas -
Yes, that's what I hear from people too.
Another reason is that it replaces the "Jump to" menu at the top-right of every page which no-one seems to see or use.
Another reason is that it replaces the "Jump to" menu at the top-right of every page which no-one seems to see or use.
> the "Jump to" menu at the top-right of every
> page which no-one seems to see or use
Really? That surprises me. I use it all the time. But I guess I have never really asked my colleagues if they use it.
-- Art
> page which no-one seems to see or use
Really? That surprises me. I use it all the time. But I guess I have never really asked my colleagues if they use it.
-- Art
Hi Matt,
First up thanks for the feedback and comments, the AJAX enhancement is certainly an interesting area, you are right the tree certainly still needs to be usable without the ability to expand via AJAX which does mean it needs enough information to be useful right from word go.
However the potential amount of information that can be displayed is huge, and the drain on resources would outweigh any benefit on a large site.
In order to keep the navigation tree useful and functional the tree will load only information that is immediately relevant in regards to the current context level of the tree, with an additional limit on the number of levels shown forwards of the context.
When JavaScript is disabled the context of the tree should always be the context of the user (as without JS there is no way to expand), this means that the user will see the immediate tree backwards (if there is any) and the next X levels of the tree that are relevant.
When viewing a course the user will see the categories and subcategories that the course is in (but none of thier other children), the course itself, and X many levels within that.
As for what X is, thats a good question. I'm currently thinking that it should be configurable by the end user, and although I have not talked through this with Tim yet.
I think it would be usefull if you could also define a different X for different contexts, so you could set a high X on CATEGORY, or SYSTEM contexts, and a lower X on COURSE which is potentially far more taxing on the system.
Currently this is conceptual, it is still very early and the point of this dicussion was to pull up questions like this and see what people think, if you have any ideas please let me know
First up thanks for the feedback and comments, the AJAX enhancement is certainly an interesting area, you are right the tree certainly still needs to be usable without the ability to expand via AJAX which does mean it needs enough information to be useful right from word go.
However the potential amount of information that can be displayed is huge, and the drain on resources would outweigh any benefit on a large site.
In order to keep the navigation tree useful and functional the tree will load only information that is immediately relevant in regards to the current context level of the tree, with an additional limit on the number of levels shown forwards of the context.
When JavaScript is disabled the context of the tree should always be the context of the user (as without JS there is no way to expand), this means that the user will see the immediate tree backwards (if there is any) and the next X levels of the tree that are relevant.
When viewing a course the user will see the categories and subcategories that the course is in (but none of thier other children), the course itself, and X many levels within that.
As for what X is, thats a good question. I'm currently thinking that it should be configurable by the end user, and although I have not talked through this with Tim yet.
I think it would be usefull if you could also define a different X for different contexts, so you could set a high X on CATEGORY, or SYSTEM contexts, and a lower X on COURSE which is potentially far more taxing on the system.
Currently this is conceptual, it is still very early and the point of this dicussion was to pull up questions like this and see what people think, if you have any ideas please let me know