[development] the past, present and future of drupal admin
jazepstein at gmail.com
Fri Jul 28 10:41:00 UTC 2006
On 7/28/06, Dries Buytaert <dries.buytaert at gmail.com> wrote:
> I have data points that suggest the exact opposite. One or two years
> ago, I was very much in favor of what you are saying about the
> categorization of settings and actually moved many setting pages
> around to do exactly that. That is no longer the case today as I got
> too many complaints about it not being intuitive.
> You are suggesting that users should discover settings by:
> - Checking the module specific block,
> - or by checking an existing block related to the module/functionality,
> - or by checking the settings page.
> That is 3 possible locations. How will the user figure out where to
> look? You assume that it is intuitive and the user will get it right
> without a problem. Clearly, that is not the case. The assumption is
> flawed. We can't rely on it. That has been proven over and over
> again and is exactly why I changed my mind about this.
> Instead, I'm suggesting that the user should discover settings by:
> - Checking the settings page.
> It doesn't assume anything and provides a well-defined location. It
> is a much easier pattern to learn, and looks like an easier mental
Dries: I would argue that your suggestion does, in fact, assume quite
a lot. From what I can see, there is one very big, very difficult
question, that has not been addressed so far in this discussion, and
that we really should be addressing:
What is a setting?
First of all, we ourselves don't have a clear definition of what a
setting is within Drupal. I'll take a rough guess, and say that
settings are 'global' values (such as the site's name), and that a
setting should only ever have one 'instance', or one 'set of values'.
This is in contrast to non-settings, which are 'per-instance' values,
and that have multiple instances, or values, which are tied to data
entities within Drupal (such as the name of a menu item). Of course,
stating this definition is much easier than actually applying it to
the real-world Drupal, where there are many grey areas as to what
constitutes a 'global' or 'per-instance' value.
Secondly, if we don't even know what a setting is (and even if we do
know), then how can we ever guarantee - now or in the future - that
we, as core and as contrib developers, have managed to separate all
'settings' from 'non-settings' within the administrative area of a
site? Is it realistic to have the goal of being able to say: "all the
settings are in the 'admin/settings' area, and there are no settings
anywhere else in the admin area"?
Thirdly, considering all of this, how the heck can we expect regular
users and site admins to understand what a setting is, and hence to
know whether to look for something in the 'settings' area, or in some
other area? Do regular users and site admins even care what the
difference is between a setting and a non-setting? When such a person
wants to 'administer the users' on their site, do they really want to
think about whether to look in 'admin/user' or 'admin/settings/user'?
I don't think so.
So, in answer to your statement, I don't think that it's easier for
users to "discover settings by checking the settings pages", because
we cannot assume that users know what constitutes a setting (just as
we cannot assume that we've correctly drawn the line between settings
and non-settings). Instead, I would argue that users have a mental map
that groups tasks logically (with 'settings' and 'non-settings' tasks
bundled together within logical groups); and hence, I would advocate a
return to the previous system of putting settings alongside their
other logical tasks within the admin area.
Just a quick example from another piece of software (and yes, people
can complain that Microsoft is evil and that it produces buggy
software, but they can't complain that its software is terribly hard
to use). In Windows XP, the 'control panel' groups administrative
tasks logically. There is no 'settings' icon within the Windows
control panel. However, within the 'Display' area, there is a
'settings' tab (for 'global' settings, such as your screen
resolution), along with 'sets-of-data' things, such as colour schemes
and screen savers. Same with the 'User Accounts' area: the management
of individual user accounts is right in there with the 'general user
settings'. Certainly something to consider.
> Just my 2 cents,
> Dries Buytaert :: http://buytaert.net/
And mine. ;-)
More information about the development