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?