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.