[development] the past, present and future of drupal admin

[Earl Miles]

Dries Buytaert wrote:
> Usability is defined by how easy it is for users to build a mental  
> model of the site and its organization.  A mental model lets you  figure 
> out what would happen in a novel situation.  In my view of the  world -- 
> after having received many complaints about the settings  being 
> scattered -- it's easier to build a mental model if all  settings are 
> grouped together.  As Kristjan said, it's all about  being able to 
> discover settings.  I strongly vote for grouping all  settings, which is 
> what I did with the settings page rewrite ... With  Earl's patch there 
> are essentially two places to look for settings:  the settings block, 
> and the related category's block.

Indeed, there are kind of two places to look, and the division is meant 
to work like this:

Modules that come with Drupal core put their settings largely in the 
'site settings' block. *However*, systems that also have large-ish 
administration pages put their settings near those administration pages.

As I watched Drupal move through 4.6 to 4.7 and actually 'split' some 
administration tasks between settings and regular administration tasks, 
my brain hurt.

For one, how do I, the user, know which as an administrative task and 
which is just a setting? Unless I'm already familiar with the system, I 
don't. Even if I'm already familiar with the system, I may not, because 
the division may be purely based on how the data is stored, and only a 
developer is really going to know that.

Shining example, or The One That Killed Me:

Menu system. menu.module in 4.7 launches with a 'Primary Links' block, 
and you put links in it for them to become primary. But you can change 
which block that is. But where do you change it? That's right, now where 
the primary links block is, but...yes, in the settings.

Talk about a common question on #drupal-support, too. 'Edit Primary 
Links' takes you to admin/menu but if you want to just get rid of the 
link, you actually have to go to admin/settings/menu ...

So, coming back around, my personal belief is that systems with large 
administrative pages should have their settings with the administrative 
pages. Systems which have, basically, only settings, should have their 
settings in the Settings block.

Additionally, what I was trying to set up is that contrib modules should 
have their settings in the 'modules' block. If for no other reason than 
because when you enable new stuff, chances are it'll either create a new 
system (ecommerce is something I would expect to just have its own 
administrative block) or it will put itself into the modules section.

That's the hope, anyway. Perhaps I'm wrong.

And the red-flagged *new* ideas are great. Not sure that anyone will be 
able to get them into code by the time 4.8 is ready to ship, though.