[development] the past, present and future of drupal admin
merlin at logrus.com
Thu Jul 27 17:05:37 UTC 2006
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.
More information about the development