Rationalising the configuration settings

Rationalising the configuration settings

Martin Dougiamas གིས-
Number of replies: 30
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Plugin developers གི་པར Testers གི་པར
The admin page is growing huge and messy, with many options on many pages (Variables, Filters, Editor, Modules, Calendar etc ...)  - I think it's time for a rationalising / reworking.

One idea I have is to keep most of the same configuration settings pages that we have in 1.5 but put them under one set of tabs (perhaps two or three rows deep) at the top of the page. Another is to have some sort xtree-like browser on the side to access them all.

Anyone got any good ideas or examples of other systems that do this well? To save you time, the icons of Cpanel and PHP Nuke are not what I would call good examples. དགའ་འཛུམ་

It has to scale well (Moodle people love options).


དཔྱ་སྙོམས་ཀྱི་སྐུགས་ཚུ།: -
In reply to Martin Dougiamas

Re: Rationalising the configuration settings

Andrea Bicciolo གིས-

Also for me tabs are a good way to rework the page. I would also suggest a subdivion inside tabs among "basic" and "advanced" settings, where applicable.

In my opinion icons are not a good way of representation since it is difficult to find a good metaphor for all those settings and the same metaphor may not work well for all people around the world.

In reply to Martin Dougiamas

Re: Rationalising the configuration settings

Howard Miller གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
I think the way Gallery 2 does it, with a combination of navigation and tabs is quite intuitive. Dare I say, nice CSS layout too!
Attachment gallery.jpg
In reply to Howard Miller

Re: Rationalising the configuration settings

Anjin Sing གིས-
Did you ever try s9y PHP weblog software - Serendipity www.s9y.org?
Try the newest 0.8 build and view the admin settings.
I think this is a good idea for the conf settings.
In reply to Anjin Sing

Re: Rationalising the configuration settings

Martin Dougiamas གིས-
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Plugin developers གི་པར Testers གི་པར
Rather than making us install it can you include a screenshot?
In reply to Howard Miller

Re: Rationalising the configuration settings

Darren Smith གིས-

I love the look of these tabs approve

I also like the buttons which, when clicked, expands to show additional options - like when you add a resource.

Imagine the following screen capture with tabs and nicer such buttons approve

Attachment admin.jpg
In reply to Howard Miller

Re: Rationalising the configuration settings

Martín Langhoff གིས-
UI ambiguity warning: in the "Gallery" screenshot posted above, with tabs and "save" button, it is unclear whether clicking on a tab will lose my settings. If the settings are kept when I change tab (without hitting 'save'), do they become effective immediately, or only when I hit 'save'?

In the web context, 'tabs' tend to lose form data if made with links (sloppy web coders!) and yet, if we turn the tab links into submit actions, where they become effective immediately. In desktop apps, tabs 'keep' the edited settings around until the changes are okeyed or cancelled.

Adding tabs to the form is _good_, but it may be tricky to do it in a way that is clear and non-ambiguous.
In reply to Martín Langhoff

Re: Rationalising the configuration settings

Howard Miller གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
True. Currently in Gallery (only Beta at the moment), if you click the tab you loose the settings. I assume you JavaScript gurus out there could sort that one out? I'm strictly server-side myself དགའ་འཛུམ་
In reply to Howard Miller

Re: Rationalising the configuration settings

Eloy Lafuente (stronk7) གིས-
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར Testers གི་པར
Yeah, tab clicks should save changes if necessary. I discover how "unnatural" it is yesterday, adding some entries to one glossary. I forgot to "Save Changes" and directly I pressed the "Normal View" tab instead and, obviously, the new entry wasn't there.

Ciao དགའ་འཛུམ་
In reply to Eloy Lafuente (stronk7)

How to treat config tab changes without saving

John Papaioannou གིས-
I also agree that "losing" the changes you made to a tab shouldn't happen, it's frustrating. So here's a quick suggestion for how we might do it:

  1. When the admin clicks "variables" (i.e., take me to the configuration screen), append something like ?config=start to the querystring. This will create an empty object $SESSION->editing_cfg.
  2. One of the standard Moodle includes in setup.php looks for the existence of $SESSION->editing_cfg, and:
    1. if we are in some URL which is part of the configuration screen, have tab changes submit the form data as well as change tab. All submitted data will be kept in $SESSION->editing_cfg. (If there's no javascript enabled, we just lose this functionality. This is a "graceful degradation" IMHO.)
    2. if we are not in the config screen (say the admin made a few changes, then clicked the "site home" link without saving), redirect() to a dialog saying "you have unsaved changes, save or discard?". Saving will write the settings into the db, and the $SESSION object will be unset either way. This will prevent the admin doing anything until they answer the question, but this isn't a bad thing to do IMHO.
  3. Of course, saving the settings also unsets $SESSION->editing_cfg.


In reply to Howard Miller

Re: Rationalising the configuration settings

Urs Hunkler གིས-
Core developers གི་པར

The one and only place where the user can decide to make changes permanent is the "save" or "save as..." button. Every time I just try some configuration settings in Moodle I even miss the "cancel" button in the Moodle interface. I just want to cite: "Don't make me think!"

Anybody using computer interfaces learned, that she can browse through all screens, change every option to explore the possibilities, have a quick walk through the tabs to find the one with the searched information without the need to be careful not to change anything accidentally.

If a tab change would now save any of these "trials" or "casualties" without explicit user decision it could do more harm then give benefit.

In reply to Urs Hunkler

Re: Rationalising the configuration settings

Martin Dougiamas གིས-
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Plugin developers གི་པར Testers གི་པར
I agree with Urs here, there needs to be an explicit save button, just the same as Windows and Mac OS.

If the tabs indicate multiple parts of one process or something then it's OK that the settings should be "saved" to the session so it appears that tabs have just "gone behind", but then there should still be a single big "Save" button to save the whole page.
In reply to Martin Dougiamas

Re: Rationalising the configuration settings

Howard Miller གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
If, as seems to be the way this is going, we are going to increase the use of tabs, can something similar be done with the 'Variables' page as well? It's nice that it is split up now, but it's getting very long on the page.
In reply to Howard Miller

Re: Rationalising the configuration settings

Martin Dougiamas གིས-
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Plugin developers གི་པར Testers གི་པར
For sure, same problem ...
In reply to Martin Dougiamas

Re: Rationalising the configuration settings

Howard Miller གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
Oh yes དགའ་འཛུམ་ Exactly the same problem. But now I'm a bit confused!

Each admin option points to a page that (like variables) itself be a huge page. I take it you are attempting to rationalise the whole lot under one interface? So stuff like (for example) LDAP settings and suchlike would all come under this rationalised interface?

A good thing probably, but sounds like a big job (never mind the interface issues).
In reply to Howard Miller

Re: Rationalising the configuration settings

Martin Dougiamas གིས-
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Plugin developers གི་པར Testers གི་པར
If it's worth doing, it's worth doing properly.   It won't be too bad, because the navigation can be centralised to one file and just included into various pages.
In reply to Martin Dougiamas

Re: Rationalising the configuration settings

John Papaioannou གིས-
In reply to John Papaioannou

Re: Rationalising the configuration settings

Chardelle Busch གིས-
Core developers གི་པར
Oooh, I really like these tabs Jon.  I think they should also take the place of the breadcrumbs nav bar (and we could get rid of the Jump to at the same time--I don't know anybody that uses it)!!

Char 
In reply to Chardelle Busch

Re: Rationalising the configuration settings

Martin Dougiamas གིས-
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Plugin developers གི་པར Testers གི་པར
Please let's stay on topic .... མིག་ཁྱབ་   (and you can get rid of the Jump To menu in your own theme any time you like)
In reply to Martin Dougiamas

Re: Rationalising the configuration settings

Chardelle Busch གིས-
Core developers གི་པར
Sorry Martinblack eye,

But I do like this style of tabs the best so far for adim--tabs and links all on the top and not any on the side.
In reply to Chardelle Busch

Re: Rationalising the configuration settings

Howard Miller གིས-
Core developers གི་པར Documentation writers གི་པར Particularly helpful Moodlers གི་པར Peer reviewers གི་པར Plugin developers གི་པར
I use it སྐྱོ་བ།

Do I need psychiatric help? དགའ་འཛུམ་
In reply to Martin Dougiamas

Re: Rationalising the configuration settings

Andrea Bicciolo གིས-

Just to trow some more ideas into the "rationalizing" discussion:

Moodle Home Page: currently there are two links for admins, after login, in the "Administration" block:

  • Configuration
  • Admin...

Cliking "Configuration" currently leads to a subset ("/admin/configure.php") of the whole Admin panel ("/admin/index.php"), reachable clicking "Admin...". It seems to me a duplication.

My proposal is:

  • Replace "Configuration" with "Settings"; the link lead to "/admin/site.php". In this way the link behaves much like the course setting, leading directly to the front page course settings
  • Administration... links to "admin/index.php" where the "index.php" is the new configuration page we are discussing of.

In reply to Andrea Bicciolo

Re: Rationalising the configuration settings

Martin Dougiamas གིས-
Core developers གི་པར Documentation writers གི་པར Moodle HQ གི་པར Particularly helpful Moodlers གི་པར Plugin developers གི་པར Testers གི་པར
In the old days ALL the links on the admin page were in the admin block (anyone else remember this?).  Configuration survived the change because it's used so much and I wanted it to be obvious for new admins where to go.

I think there's still probably confusion between Configuration and Site Settings ... Site Settings should become just another tab under Admin called "Site Home Page" or something.

I think we can keep Configuration in the admin menu, but make EVERYTHING in the admin pages available from there.
In reply to Martin Dougiamas

Re: Rationalising the configuration settings

Pieter Ruts གིས-

As a newby (and finishing computer-studies student) I'd like to remind that you should keep Administration and Setting functions in two different sections. To make it the most flexible.

If you plan to organise Moodle in a way that is similar to ITIL, there is a big difference between administration and settings.

To change a setting has a very big impact. I want to make it clear that these things should be pretty unaccessible, even for the users with administrator-rights. To take the law of Murphy in account...

But still then, the grouping of settings and administration using tabs is the most similar to the Windows environment, which is used a lot more than the other ideas.