the past, present and future of drupal admin
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?
On Jul 26, 2006, at 12:05 AM, Kristjan Jansen wrote:
Whatever happened to that (Vacouver? Civicspage? Bryght?) card sort thing?
Quick history: Dries identified last August at OSCON that the most important code in Drupal was the project module, because most of the things the Drupal community did went through it. CivicSpace improved the project module, through funding Nedjo and lots of personal contributions from Nedjo and Dries. There was good contributions to the project module from the community to help improve it, as well as many calls from the community to kill it. The administration survey surprisingly indicated that 83% of Drupal administrators spent a lot of time looking for new features and modules. We extended the project module to make it easier to categorize modules. We did several iterations of categorizing Drupal project modules. One iteration was done in Vancouver. We did some additional iterations on the mailing list and voila: http://drupal.org/project/Modules/category It's probably time to do another categorization of the modules. If you are interested in doing that categorization I can help you lead that effort. It's also worth noting that Derek took over maintenance of the project module and he could probably do with some dedicated user experience help to make it even better. No expertise needed, just a willingness to learn. Cheers, Kieran
On Jul 26, 2006, at 12:05 AM, Kristjan Jansen wrote:
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)
I think it's important to take a step back and figure out what administrators goals, and expectations are. A lot of people talk about small UI improvements when trying to improve the administration user experience. e.g. Have you seen the AJAX in WORDPRESS, OMG!!!! :-) However, our research indicated that people were spending upwards of 40 hours in upgrading their site including debugging, managing new feature requests, training their users, and porting custom modules to new APIs. We tried to help improve that with documentation: http:// drupal.org/upgrade/tutorial-introduction Our research also indicated that 83% of Drupal administrators looked for new features. So we did this: http://drupal.org/project/Modules/ category The point is we need to get big pieces like improving the upgrading process or module categorization in place, particularly if they are not bound by the Drupal distribution development process, before we dive into small UI improvements. Let me know if you want to collaborate on another set of interviews and a administration survey. Cheers, Kieran
Op woensdag 26 juli 2006 18:01, schreef Kieran Lal:
before we dive into small UI improvements.
From what I have seen in the past, and now again this is very unfair to say. Kristjan has hardly ever proposed "small UI improvements". And no, he has not got the resources like CS to put people on it to turn this into patches. Personally I value Kristjan's input a lot higher then some statistically-backed up survey, because Kristjan spends a lot of effort and time to back his statments up with research, literature, screenshots and mockups. We thank a lot of great usability improvement on his input. On the same note, a lot of his input has died a silent death, because no 'coder' (I prefer not to devide Drupalleers into coders and none-coders) took up his ideas and made them work. So, to conclude: CS's statistics show where we can improve the overall experience (Drupal.org[1]). And Kristjan has made a great post, with mockups and explanations how we can improve Your Drupal Site. Both are very important parts, both need attention. Because eventrhough a lot of effort went into improving Drupals admin, it did not become notably 'better' overall[2]. Some parts improved, others de-proved. Bèr [1] Besides the "where can I find what" and "how do I use what" improvements, we *also* need some better quality assurance. Drupal without contribs is not much. But most contribs are "not much" either. Drupal relies on somtimes absolutely crappy contribs, or stuff that is not even stable (I am pointing at myself too!). [2] http://webschuur.com/node/638 check the very well structured menu... ? -- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
On Jul 26, 2006, at 1:18 PM, Bèr Kessels wrote:
Op woensdag 26 juli 2006 18:01, schreef Kieran Lal:
before we dive into small UI improvements.
From what I have seen in the past, and now again this is very unfair to say.
You are right. I shouldn't have said before. I meant we should do this in parallel. Things improve because of many diverse approaches and efforts. I agree Kristjan's recommendations, but want to see also see the effort I outlined as well. Cheers, Kieran
Kristjan has hardly ever proposed "small UI improvements". And no, he has not got the resources like CS to put people on it to turn this into patches.
Personally I value Kristjan's input a lot higher then some statistically-backed up survey, because Kristjan spends a lot of effort and time to back his statments up with research, literature, screenshots and mockups. We thank a lot of great usability improvement on his input. On the same note, a lot of his input has died a silent death, because no 'coder' (I prefer not to devide Drupalleers into coders and none-coders) took up his ideas and made them work.
So, to conclude: CS's statistics show where we can improve the overall experience (Drupal.org[1]). And Kristjan has made a great post, with mockups and explanations how we can improve Your Drupal Site. Both are very important parts, both need attention. Because eventrhough a lot of effort went into improving Drupals admin, it did not become notably 'better' overall [2]. Some parts improved, others de-proved.
Bèr
[1] Besides the "where can I find what" and "how do I use what" improvements, we *also* need some better quality assurance. Drupal without contribs is not much. But most contribs are "not much" either. Drupal relies on somtimes absolutely crappy contribs, or stuff that is not even stable (I am pointing at myself too!). [2] http://webschuur.com/node/638 check the very well structured menu... ?
-- PGP ber@webschuur.com http://www.webschuur.com/sites/webschuur.com/files/ber_webschuur.asc
On Jul 26, 2006, at 1:18 PM, Bèr Kessels wrote:
we *also* need some better quality assurance. Drupal without contribs is not much.
in terms of code reviews, security audits, etc... no question. that said, interested readers should check out: http://drupal.org/node/63491 "Drupal Version-Module Support Matrix" (though the scope is growing beyond solely that) as always, comments welcome. thanks, -dww
Dang, this is a long post. I don't know where to start on it. A lot of it addresses the work I'm doing right now on the administration pages. And I know Kristjan isn't suggesting we throw that away, but I'm running into an issue: 1) Code freeze is in 36 days. 2) Dries and I are the only two people putting code into patches this at this time. 3) I'm in favor of any steps that are steps forward, especially if they're done in a flexible way so that we can step sideways in another version 4) We can argue for days, nay, years about the actual organization. I've been working on this for so long, though, that I'm beyond being able to talk about it in the abstract, and need specifics. Keep in mind that I effectively started working on this back in January, took a long breather to collect my wits when the criticisms came in, and then charged into it again on a whim. 5) I'm a burst type of worker. Meaning, I work really well and really fast while I'm motivated, but once my motivation becomes sapped, I don't work well or quickly. Yes, it's a personal flaw, and I do try to work on that, but it is a fact of my existence that must be accepted. Conclusion? The conversation Kristjan started is a fantastic conversation to begin sometime in September, when we're talking about the next version. And don't get me wrong -- Kristjan brings up great points and has a lot of interesting things to say, and I agree with a lot of them, straight up -- but the timing on the conversation is a little difficult, at least for me. The conversation I want to see is -- what needs to be done to get the improvements we're working on in now. Well, and this part of the conversation: Kristjan Jansen wrote:
Possible improvements (some of them silly ;)
I want to couch this in terms of "what improvements can we have ready by Sep 1."
-- 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)
I'm very much interested in this, and am working hard to have a modules page redo in by the code freeze. My initial efforts were part of the alternadmin, which used javascript tabs which had a lot of very mixed opinions -- some people truly adore them, some people are very enh on them. I also included module grouping, which brought forth a whole range of opinions.
-- there used to be links from module settings pages directly to a help pages, but now those are gone. why?
Definitely should come back.
-- 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
Spiffy idea, and not actually that hard to implement. I'll try to put this into what I'm working on.
-- 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
Ambitious. Definitely not likely in the first round, but I can see where this might be an end goal.
6) make module taxonomy http://drupal.org/project/Modules/category work closely together with Drupal administration screen structure
People keep suggesting this, but I don't buy it. How one finds modules isn't the same as how one administrates modules. The module taxonomy, when I first looked at it, struck me as relatively poor for some of the administrative organization, and takes a step back from some of the goals I have, at least, in module administration. The downside, of course, is I can't really do much work on this until the administration patch ( http://drupal.org/node/72079 ) is actually committed. Well, I can, but I feel hesitant to do so.
On 7/26/06, Kristjan Jansen <kristjan.jansen@gmail.com> wrote:
5) It's all about _discovery_ of settings, right? How does it work right now? I would imagine couple of ways:
(snip)
Possible improvements (some of them silly ;)
(snip)
-- 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
I agree that "discovery of settings" is a big problem for Drupal administrators at the moment. The way that the menu structure "grows" within the admin section of a Drupal site is extremely non-user-friendly, IMO. All Drupal modules - core or contrib - currently add or modify a whole bunch of pages to the admin section of the site (where 'pages' includes all types of menu items, e.g. normal items, tabs/subtabs, callbacks, etc) as soon as they're enabled. But they don't notify the administrator at all! They change the structure of the site, and they don't tell the site admin about it. This is not good. How can we expect poor old Joe Admin to know where to look? I like the idea of the red "new" markings on newly added menu items. I also have another idea, that takes a slightly different approach to solving the same problem. It is currently best practice for modules to list all of the functionality that they offer, and all of the menu pages for using the functionality, in the 'admin/help' section. Why not take this help text, and make it stand out to the user when a module is first enabled? For example, the path module is a core module that is disabled by default. We could make it so that when the path module is first enabled, a series of 'messages' are displayed to the administrator on the main 'admin dashboard' page, each message listing a new piece of functionality, and a link to the page where it can be used. See my attached mockup image for an idea of what I'm talking about. In the mockup image, my vision is that when the user clicks anywhere within the message, they are taken to the page that is being linked to in the message, and the message itself is deleted. The user can also delete the message without following the link, by clicking the 'X' icon in the corner. Of course, this vision would involve a lot of fancy AJAX in practice. If 37Signals were developing the next version of Drupal, I imagine that this is how they'd do it. ;-) Cheers, Jaza.
Jeremy Epstein schrieb: [snip]
I like the idea of the red "new" markings on newly added menu items. I also have another idea, that takes a slightly different approach to solving the same problem. It is currently best practice for modules to list all of the functionality that they offer, and all of the menu pages for using the functionality, in the 'admin/help' section. Why not take this help text, and make it stand out to the user when a module is first enabled?
For example, the path module is a core module that is disabled by default. We could make it so that when the path module is first enabled, a series of 'messages' are displayed to the administrator on the main 'admin dashboard' page, each message listing a new piece of functionality, and a link to the page where it can be used. See my attached mockup image for an idea of what I'm talking about.
In the mockup image, my vision is that when the user clicks anywhere within the message, they are taken to the page that is being linked to in the message, and the message itself is deleted. The user can also delete the message without following the link, by clicking the 'X' icon in the corner. Of course, this vision would involve a lot of fancy AJAX in practice. If 37Signals were developing the next version of Drupal, I imagine that this is how they'd do it. ;-)
Great idea! One step forward might be this: http://drupal.org/node/73809 Another thing would maybe be to have a link "paths" in the module table for each module. By clicking on it, a collapsed div below the module is decollapsed providing a short (one or two lines) description and a listing of all links where this module is found in the administration area. In other words, I really really do like Earl's approach of reordering the administration center by task grouping. However, sometimes you want e.g. just to disable this one setting of this one module, and then the easiest way for me as an admin would be to go to the modules page, and have the link I'm looking for directly below the module (the div providing the links would by default be collapsed). This would save me lots of clicks = lots of time. It should not be hard to implement either. best regards, Frando
Cheers, Jaza.
------------------------------------------------------------------------
On 26 Jul 2006, at 09:05, Kristjan Jansen wrote: <snip />
I have no preference formed, but gut feeling says the "ideal admin page" should contain a smart mixup of these different ideas above
I think that is where we are heading. Maybe we are not going in a straight line, but we'll get there eventually. :)
- 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.
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.
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.
I agree, people have been abusing tabs and by doing so, attribute to the problem. I think, however, that the tabs-issue belongs in a separate discussion/patch. Let's focus on practical improvements for the administration patch that Earl is working on. -- Dries Buytaert :: http://www.buytaert.net/
On Thursday 27 July 2006 00:54, 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.
Well, there's Usability, which is for expert users, and there's Learnability, which is for new users. Very often those two goals can be at odds with each other. With a highly modular system like Drupal, a person is generally an expert in one area and a novice in another (just added a new module), so it makes it more complicated. (I was a usability major in college (Human-Computer Interaction), and of course therefore went on to become a programmer. Go figure. <g>) That said, I do agree with the idea that "setting up stuff" should be fairly centralized. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On 27 Jul 2006, at 09:29, Larry Garfield 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.
Well, there's Usability, which is for expert users, and there's Learnability, which is for new users. Very often those two goals can be at odds with each other. With a highly modular system like Drupal, a person is generally an expert in one area and a novice in another (just added a new module), so it makes it more complicated.
At the risk of getting 'meta' and side-tracking the discussion, I wanted to point out that 'learnability' is about mental maps too. For example, I know how to drive nearly all cars in the world because I have a mental model of how a car works. That is, you build a mental model once, and then apply it to similar products. If a car manufacturer where to put the light switch at an exotic place, we'd feel lost and shout that the car is hard to use. Not because the light switch works differently (it works exactly the same), but just because the light switch is at a different location. People new to CMS'es don't have a mental model of a CMS. Thus, they'll apply their mental model of a program they are familiar with, and that looks most similar to Drupal. If I'd ask you to drive a tank or a train, you'd use their mental model of a car. Similarly, if people come to Drupal from WordPress, their mental model might map well on how WordPress works. If people have not been exposed to web applications, the mental model is probably going to be Windows XP and they would expect all settings to be grouped and have fancy icons. :) -- Dries Buytaert :: http://www.buytaert.net/
Op donderdag 27 juli 2006 09:54, schreef Dries Buytaert:
the mental model is probably going to be Windows XP and they would expect all settings to be grouped and have fancy icons.
Which, AFAIKT is the number one reason why Joomla works very well for not-so-frequent-maintained sites and new admins. (lets not get into a fight whether or not Joomla does things better, or so) It is just to chime in on that mental map idea. * Joomla offers a very visual "map", both in menus (dropdowns with icons) and in the dashboard (Large Icons). * Joomla has a very consistent "map" because of the separate admin area. Our flexibility (everyone can make his/her site different) defeats this very much. A consistent admin theme for core would help this consistency a LOT, because ~90% of the drupal sites' administration would be consistent again. Now we see small difference such as a main menu right on SiteA and left on SiteB breaking this "map". Bèr (The mental map in Joomla is very much spoiled by the fact they have a strange "bolt on" concept for plugins/extensions etc. That to avoid discussions about "but Jommla is not perfect either. No its not, but this particular problem has some great things for us to learn from.)
Op donderdag 27 juli 2006 12:58, schreef Bèr Kessels:
* Joomla offers a very visual "map", both in menus (dropdowns with icons) and in the dashboard (Large Icons). forgot the screenie: http://www.nuthinwerked.com/screenshots/index.html
Bèr
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.
On Thu, July 27, 2006 12:05 pm, Earl Miles said:
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.
Wait, didn't you just say exactly what you just said is bad? That some things are under admin/settings while others are under just admin, and there's no clear reason why for any of them?
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.
Random data point: For whatever reason, when my brain says "I want to change the settings for the foobar module", my hand clicks the modules link. Why? I think it's because my brain thinks modules -> settings rather than settings -> module. I'm not sure how common that is, but after more than a year my hand still won't pay attention and go where it's supposed to. Which brings up yet another question: Should settings be clustered by the module that provides them in the first place (admin/settings/foobar), or by the type of activity to which they belong (admin/content_types and so forth)? Right now we do a little of each, which I can't see as a good thing. --Larry Garfield
Larry Garfield wrote:
On Thu, July 27, 2006 12:05 pm, Earl Miles said:
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.
Wait, didn't you just say exactly what you just said is bad? That some things are under admin/settings while others are under just admin, and there's no clear reason why for any of them?
Only if either I misspoke or you misread.
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.
Random data point: For whatever reason, when my brain says "I want to change the settings for the foobar module", my hand clicks the modules link. Why? I think it's because my brain thinks modules -> settings rather than settings -> module. I'm not sure how common that is, but after more than a year my hand still won't pay attention and go where it's supposed to.
And this is why I want modules to have their settings in the modules section.
Which brings up yet another question: Should settings be clustered by the module that provides them in the first place (admin/settings/foobar), or by the type of activity to which they belong (admin/content_types and so forth)? Right now we do a little of each, which I can't see as a good thing.
By 'right now' do you mean current Drupal or the patch I'm working on?
On Thu, July 27, 2006 1:06 pm, Earl Miles said:
Larry Garfield wrote:
On Thu, July 27, 2006 12:05 pm, Earl Miles said:
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.
Wait, didn't you just say exactly what you just said is bad? That some things are under admin/settings while others are under just admin, and there's no clear reason why for any of them?
Only if either I misspoke or you misread.
Either is possible, I guess. :-)
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.
Random data point: For whatever reason, when my brain says "I want to change the settings for the foobar module", my hand clicks the modules link. Why? I think it's because my brain thinks modules -> settings rather than settings -> module. I'm not sure how common that is, but after more than a year my hand still won't pay attention and go where it's supposed to.
And this is why I want modules to have their settings in the modules section.
Which brings up yet another question: Should settings be clustered by the module that provides them in the first place (admin/settings/foobar), or by the type of activity to which they belong (admin/content_types and so forth)? Right now we do a little of each, which I can't see as a good thing.
By 'right now' do you mean current Drupal or the patch I'm working on?
Current Drupal. I've not tried your patch yet. --Larry Garfield
On 27-Jul-06, at 1:41 PM, Larry Garfield wrote:
Random data point: For whatever reason, when my brain says "I want to change the settings for the foobar module", my hand clicks the modules link. Why? I think it's because my brain thinks modules -> settings rather than settings -> module.
This makes the most sense to me also. Since I know or can guess what controls the setting I want, I'd find it easier to go admin/<module>/settings for sure. (For ui, you could have "configure" links down the side of the modules page) -Rowan
Earl Miles wrote:
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 ...
I actually didn't know that setting could be used to get rid of the links until now. I've been deleting the call from themes. -- Neil Drumm http://delocalizedham.com/
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.
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 model. Just my 2 cents, -- Dries Buytaert :: http://buytaert.net/
On 7/28/06, Dries Buytaert <dries.buytaert@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 model.
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. ;-) Cheers, Jaza.
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.
Clearly, people have different opinions, experiences and expectations. There is no ideal solution so let's agree to stop arguing about it. The answers to all (y)our questions can be solved by a simple cardsort experiment. We have the categories (block titles), the top-level links and their descriptions. All we need to do is organize a cardsort experiment, invite all our users to take part, and we're done. :) -- Dries Buytaert :: http://buytaert.net/
With all this discussions on administration and such. My 2cents are: it is all about familiarization with the interface. If you are to admin a site, you have to get familiar with the interface whichever way it is. I don't think it is bad the way it is today, but that may be that I am just familiar with it. No way will be obvious to all people no matter what to do. Maybe all that is needed is for the documentation team should have a "quickstart guide" and a more comprehensive document, and that should be all there is to it.
Dries Buytaert schrieb:
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.
Clearly, people have different opinions, experiences and expectations. There is no ideal solution so let's agree to stop arguing about it.
The answers to all (y)our questions can be solved by a simple cardsort experiment. We have the categories (block titles), the top-level links and their descriptions. All we need to do is organize a cardsort experiment, invite all our users to take part, and we're done. :)
Of course there is no perfect solution, but it's not that difficult to unite Dries' and Jeremy's view, for example. Of course the proposal is not The One Way, but at least I think it covers two ways of using the admin interface: We organize the whole adminstration area as Dries and Earl Miles proposed (so task-specific, and settings seperated). However, additionally, we extend the module listing. Below each module in the listing, we have a collapsible div that is collapsed by default. This div, when expanded, contains a short description of the module and a listing of *all* links ("administrative tasks for this module:") where this module has settings/tasks/whatever placed, similar to the listing we have in the help section. Then, if I just need to tune this option of this specific module, and I have no idea wether it's a setting or something under 'Content Managment', then I just go to the module listing, and with one more click I am where I want to be. For some task, this might save a lot of clicks, especially for experienced admins who know exactly what they want. So by doing this we open two ways for users, without confusing them. regards, Frando
Dries Buytaert wrote:
Clearly, people have different opinions, experiences and expectations. There is no ideal solution so let's agree to stop arguing about it.
I am officially removing myself from this conversation. I have a patch that I want in, and I put a lot of work into this. I don't want to take a step back NOW and start arguing this part of it again, we've been over this road over and over and over again, and what we end up with is a lot of talk and no code. Code freeze is in 34 days. To those of you who can do it better: Fine. Do it better. Otherwise, help get this patch in, because otherwise Drupal will continue with its current administrative interface, which only a few people like. I won't be pulled in 12 different directions. I picked a direction with this, and I went with it. I like to think I have a decent feeling for UI and usability. I've created several of them over the course of my career, and the customers usually like how I organize and flow. Maybe I'm self-deluded, maybe not, but I do no, agreement on this is nowhere to be found. I certainly know where *I* expect to find things, and I've laid out my reasoning (and I imagine I'll do it again and again and again) and I'm done. I'm ok with tweaking and a little bit here and there, but if you want to do it totally differently, put up. Otherwise, help out.
I am officially removing myself from this conversation.
I have a patch that I want in, and I put a lot of work into this. I don't want to take a step back NOW and start arguing this part of it again, we've been over this road over and over and over again, and what we end up with is a lot of talk and no code.
Earl, your patch is an improvement and will be committed. If someone stands up to refine it, that's cool too. -- Dries Buytaert :: http://buytaert.net/
I have a patch that I want in, and I put a lot of work into this. I don't want to take a step back NOW and start arguing this part of it again, we've been over this road over and over and over again, and what we end up with is a lot of talk and no code.
Earl, your patch is an improvement and will be committed. If someone stands up to refine it, that's cool too.
agreed, I am a believer of gradual improvements so let's work on http://drupal.org/node/72079. There is no time to do a big-time interaction design overhaul for a code freeze. Let's take these ideas from this thread forward in separate threads/issues. Liking the proposal of 'new stuff you can do' boxes on module enabling. Can be combined with Basecamp-style contextual hints 'stuff you have not done yet'
Op vrijdag 28 juli 2006 14:22, schreef Dries Buytaert:
There is no ideal solution so let's agree to stop arguing about it.
Indeed! The current situation allows *me* to set up an (almost) perfect menu for the owner of a weblog-Drupal. Or for the webmaster of a complex portal site. Or for a client who manages the content of his brochure website. Together with one or two nice HTML-ified nodes (type page), containing icons and other fancy stuff, you have the Perfect Admin Interface.... ... For your situation ... Bèr PS: The only thing we *might* need is even more flexibility (granularity in access permission most of all). Because sometimes some all-or-nothing forces you to give a client a lot of complex interfaces- E.g. "administer nodes" is required if you want to allow your moderator to put nodes on the frontpage, but that means he gets about five admin pages "for free".
Dries Buytaert wrote:
The answers to all (y)our questions can be solved by a simple cardsort experiment. We have the categories (block titles), the top-level links and their descriptions. All we need to do is organize a cardsort experiment, invite all our users to take part, and we're done. :)
This is the first statement I've seen here that actually resembles a scientific approach. My 2 cents as someone just learning the Drupal code base but who knows a fair bit about quality: Usability isn't found through abstract arguments, and it especially isn't found by text-based email debates without rigorous models or inline examples. It's found, often iteratively, by the combination of empirical data and theoretical models. So if you want to do an overhaul of the admin system, do it right. Build and organize a collection of user stories and mental models; email isn't an adequate organization. Use empirical data, including a cardsort survey if that's right, but ideally including observation in context. Anecdotal feedback can identify the big issues, but generally doesn't create a complete picture of the usability issues. Sorry if this sounds like it's coming from left field. I get frustrated when I see the same people who insist upon hard, reliable data for things like database optimizations and use rigorous models for code design, then turn around and approach usability through force of personality. Gary
participants (13)
-
Bèr Kessels -
Derek Wright -
Dries Buytaert -
Earl Miles -
Frando (Franz Heinzmann) -
Gary Feldman -
Jeremy Epstein -
Khalid B -
Kieran Lal -
Kristjan Jansen -
Larry Garfield -
Neil Drumm -
Rowan Kerr