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

[Kristjan Jansen]

This was meant to be a followup for http://drupal.org/node/72079 but
it grew too long and abstract so I brought it over here. I know that
long rants are out of vogue nowadays, but I was not able to help it

== The purpose of admin pages ==

Can we sit back for a while and say: what is the reason to have admin
pages? what does admins do on those pages mostly?  Is it for
monitoring how your site is doing? Tinkering settings? Administering
content or users?
(some answers are here:
http://www.surveymonkey.com/DisplaySummary.asp?SID=1425065&U=142506581557)

There has been several thinking schools on what should be in main
administration page:

- administration is mostly about monitoring and then optionally some
tinkering. This thinking brought us the chat log as most prominent
thing in /administration page. It's questionable whenever the raw chat
log really gives you the 'dashboard feel' or you need more structured,
more digested information visualization a la
http://www.measuremap.com/ or http://heartbeat.skype.com/ (shameless
plug ;)

- administration is all about (finding and then tinkering) settings
and administering content. This is the approach what current
http://drupal.org/node/72079 is taking

- administration is tuning the settings for backend, content
administration might belong to a frontend side (famous "theme for
admin" discussions and splitting administration into 2 halves)


There are more ideas around though:

- administration frontpage is a friendly-tone introductory story with
links to most-used admin section and there also some relevant RSS
feeds (Wordpress) . It's similar to our no-nodes-yet frontpage +
drupal planet

- already mentioned dashboard idea combined with a contextual tips
that should grab you attention:

  USERS | there is 21 people applying for an account, waiting
  COMMENTS | there is 12 comments to be moderated, check also your spamlist
etc

- add here 37signals "placeholder" idea and your other favorite
toolkit's admin pages

I have no preference formed, but gut feeling says the "ideal admin
page" should contain a smart mixup of these different ideas above


== Structuring the admin menu ==

I have tried to sort the admin items and had a look on various sorting
proposal too. There is always a common pattern happening during the
process:

Some initial, logical task-based clouds are formed:

-- Content management
-- User management
-- Layout / Styles / Look and feel / Site building
-- Logs / Statistics
(-- Help)

Now we are left with 2 tricky groups:

-- Site settings / Site configuration / System settings
-- Module management

This is the point where we hit the head to the wall.

- should all settings existing in Drupal belong under "Site settings"
or should some of them belong in the logical task clouds named above?
Content management has loads of different settings: for nodes, for
comments etc. Same goes for user management, there is also config
stuff under stats etc.

Historically the settings used to be all in a separate section, then
there was a big initiative to move task-specific settings
(content/user/layout/logs settings) under the specific groups (at the
time tabs, subtabs and menus were fleshed out in Dries' experimental
site), then over the time these settings creeped back too
admin/settings since "nobody could found them" and now the latest
proposal moves them back to task clouds. This clearly shows there is
no "right" or "wrong" placement really.

- Now add not-enabled-by-default and custom modules into the picture
and it becomes even more fuzzy. There are dozens of modules what
partially belong under several task clouds and partially stand on
their own. Just some quick examples (not totally exact) -- spam.module
has to do with content (comments) and statistics, e-commerce and
civiccrm modules are empires on their own. Nothing really fall simply
to our predefined clouds, abstract menu system allows to inject almost
anything into menu structure. As it has been said before: Drupal UI is
victim of it's own modularity.

- Related problem: there are settings where are hard to decide into
what task cloud they belong, examples would be RSS, contact form, file
upload settings, blogAPI and name-your-favourite-contrib-module.

- Another bit about "Module management" -- is it purely meant for
turning on and off modules or should there be an access to each
modules settings?
There was time before the menu system when in module list every module
had a "configure/settings" link next to them -- the historical roots
of the _settings() hook. Now as every module can populate pages
anywhere there is no single entrypoint for module settings any more


Whatever smart card sorting we do there is never a point when we could
come up with ideal administration menu structure. Sure, it should be
done but it fixes a small part of the whole experience. So what does
it left us? There are several areas we could work on:

1) comprehensive style guides for developers to find the right menu
layout for their contributed modules was already mentioned. Do we need
"menu police"?

2) Map out what we have. There is a requirement for a script what
generates a full menu tree based on:
- default modules
- all core modules
- all contributed modules (yay)

in addition for just pushing out [ul] list, it should also mark tabs
and subtabs in order to analyse the situation better

3) Gather existing work. My collected pointers:

http://www.surveymonkey.com/DisplaySummary.asp?SID=1425065&U=142506581557
http://www.oscms-summit.org/events/drupal-usability-issues
http://www.flossusability.org/wiki.pl?CivicSpaceMenuLearnings

Whatever happened to that (Vacouver? Civicspage? Bryght?) card sort thing?

4) sort out the "tabs mess" what have happened. Although it was a hard
struggle to get it working, it was obvious from the start that
open-endedness of menu tree and strict UI limits of the 2-level tabs
can never properly work. Over the time poor tabs got misused and
mistreated, the notorious "tabs inside tabs" in content filters and
several other places, abusing the "tab title should be a task-specific
verb like "list", "configure"" rule. Add primary and secondary links
as "tabs" too and it gets even more messy.

5) It's all about _discovery_ of settings, right? How does it work
right now? I would imagine couple of ways:
-- out-of-the box experience, users rely on logic of predefined menu
structure, optionally turn to cross-links or read help (they need to
go a separate administer/help page to do it)
-- enabling more core modules. How discovering the new menu fresh
items work I do not know, possibly exploring the menu tree with "hey,
this is new" moments (or relying on browser's not-yet-visited link
differentiation). There is also new help sections available in
administer/help but there is no direct path between enabling<>help as
in reading contributed readme's (see below)
-- enabling contributed modules. It's mostly about reading
readme.txt/install.txt where is (hopefully) a setup/settings guide
with menu paths and there might also be help pages

Possible improvements (some of them silly ;)
-- improve the module intialization and feature discovery flow: tie
closer module listings, enabling modules and  related help/usage
guide. (do I remember correctly there were once a "help" link on each
module in module config screen? I am not saying this is the way to go
though)
-- there used to be links from module settings pages directly to a
help pages, but now those are gone. why?
-- for recently enabled modules' menu item add red "new" markings so
they stick out while browsing the admin pages. It can be problemsome
though: enabling many modules in the same time takes you to go reddie
hell. But this is just a suggestion for direction not a concrete
proposal
-- work on integrating search and admin pages so people can rely on
search for navigating administration. Index help texts, have
alternative wordings and synonymes and task-centric phrases for menu
titles and feed that data into a autosuggest search field a la
Spotlight in OSX Preferences panel

6) make module taxonomy http://drupal.org/project/Modules/category
work closely together with Drupal administration screen structure
- try to sync the structures and labels
- give some stucture for module configuration pages?