One annoying thing about having a million things to do is that no matter which of those million things I’m doing, there’s 999,999 other things that I’m feeling guilty about for not doing. But all of them are important at one level or another. Today I didn’t do some Views debugging that I really meant to do. Instead, after my housemate took his first look at Drupal, all those thoughts and ideas I have about Drupal’s administrative interface came to the surface.

In this article, I want to talk about the whole process of the work I’ve done, what led up to it, the road ahead, why it’s important, and where I hope it will go.

Different Approaches to Drupal Administrative Tasks

There appear to be at least three different camps about administration UI in Drupal. In one camp, there are people who want the barest UI possible that allows them to select the options they want. No bells, no whistles, organization doesn’t really matter. They’re interested in the features of the site, and administration is an afterthought. Drupal’s design makes it incredibly easy to do administration activities as an afterthought. The hook_settings() makes it ‘easy’ to have a settings page which goes in the right place. Uh, kind of. admin/settings/* turns out to be…well, awful. Especially since not everything is there. But the settings page, being automatic, isn’t suitable for all tasks. So worse than that, a number of tasks get split between admin/settings/* and admin/*.

Take, for example, admin/menu and admin/settings/menu — from a purely technical perspective there is a reason that admin/settings/menu exists…but holy cow is it hard to find if you’re not entirely sure how Drupal’s administration is laid out.

Another camp — and by this camp I mean primarily CivicSpace — is trying to create administration UI to appeal to new users. This is excellent. They have surveys that they’ve used to figure out what new users want. This is…well, to my mind. not so excellent.

“But wait,” some say, “how can the surveys be wrong?”

Well, I only have my perspective to give here, but my perspective is that the new users don’t actually know exactly what they want. Oh, they know in broad terms what it is they want to do, but I don’t feel that the questions posed in the surveys are necessarily the right ones.

This is not to say that the results of those surveys aren’t important. Certainly the tasks outlined by those surveys must be given great weight. But many of those tasks are used only early on in system building, or in the “getting to know you” phase. They fall off later. You don’t want those tasks to be in the way as much as you want them to be easy and intuitive.

A third camp points to Mambo/Joomla! and WordPress and shouts “See! See! Look what they gots!” And, well, that’s very nice, but Drupal isn’t Mambo, Joomla!, WordPress, Plone, Xoops, PHPNuke, or any of the other CMSes. They all have their own ups, downs, ins, outs and what not. The administration of a Drupal system must be very Drupal-centeric. It’s nice to go out and look at those UIs (I’ve done so a little bit; I still need to look at WordPress’, though I spent a good hour or two clicking through Joomla!’s very javascripty flash-bang-gee-whiz admin UI) and there are some lessons to be learned from them. Perhaps there are pieces we can emulate. Perhaps there are not.

My Camp: Make It Work, Dammit

Alright, so there it is in four words. I want an administrative UI that works. That’s a lot harder than it sounds. Four words doesn’t tell me anything about what needs to go where, how tasks should be organized, and what this UI will even accomplish.

But here is what it does tell me.

• The UI should not have too many clicks. Organization requires some level of drill-down, but how many levels becomes too many? Personally, I think three is borderline, but occasionally necessary. So I’m going to try and put the rule at “two levels when possible, three when necessary”.
• The UI should not be cluttered. This one, right there, is one place Drupal consistently and overwhelmingly falls down on. Everywhere you look, Drupal is filled with clutter. Forms are displayed item after item after item with no organization at all. The node entry form is a nightmare to work with, and it nearly always has too much information or information that is difficult to use. Part of this is due to its flexibility, and part of this is due to the fact that Drupal’s system basically encourages this.
• The UI should be well organized, grouping important tasks together. This means that we need to analyze all of the administrative tasks, come up with an organizational system, and apply it.
• The UI should, above all, not be the thing that people talk about. Once it’s there, the administrative UI should be functional. It should allow people to do what is necessary without impeding them. It should not have flash-bang-gee-whiz just for the sake of flash-bang-gee-whiz. Pretty pictures are nice, but the theming of the UI should always be for the mildest design. It should included the elements that are necessary, group them in ways that make sense, and let the user get on with the job the user is most likely interested in doing.

How I Got to This Point

Some months ago, I did some work on the administration module along with David Reed. That module starts off with a similar premise to the new work (that I’m getting to, I promise) does: Use a central administration UI which is essentially a link farm, and let Drupal’s administrative pages do their jobs. It did so by actively rewriting the system’s menus, which I found to be a very invasive process, prone to errors, and creating a very difficult install/uninstall process that leaves the very users this system was designed to help scratching their heads. CivicSpace has the advantage of distributing this with their build; but that isn’t all that good for regular Drupal.

While working on this module, we had a nice, skinnable design and went with some collapsing boxes and some other niceties. The code we wrote wasn’t really the best, easiest, most flexible code in the world, and every time I went back I always felt somewhat lost trying to figure out exactly where and how things were happening. This came, in part, because David and I really had a couple of different approaches, and I think we were trying to go middle-of-the-road and appease each other. In any case, I think we came up with something that is marginally functional, but in the end it does not do what I really wanted something like that to do.

And here is why: Drupal’s actual administrative pages suck ass. It’s not just the organization that’s wrong, as I had actually thought going into this. Unfortunately, no, it’s worse than that. While there are some pages that are (by dint of their brevity) relatively good, there are other pages that are nearly unworkable. block administration, menu administration, module administration, access control administration are all headache-inducing pages.

Worse, since 4.7, Drupal has these collapsing blocks. I’ve never really been fond of the collapsiblocks, and I think it’s because as an organizational tool, they actually make things worse for me. They are functionally equivalent to tabs, but they require a lot of scrolling, a bunch of extra clicking…and in general aren’t terribly friendly. I eventually went ahead and used them in the Views UI, but I’m really not happy with the solution. It’s better than the one that just has it all out there for you, but it’s not ideal.

For the moment, let’s just say I’m enamored of tabs. Perhaps I won’t be in the near future, but I like them for their ease of clicking, and for anyone who’s used Windows for any length of time, extremely familiar. Heck, Drupal uses its faux tabs all the time (though I like them less).

Where I am now

Today I spent a good 4–5 hours working something out. It’s rough, there’s a lot of work to do. Right now the main administration skin is hard-coded, though I actually want to have an API that constructs this via hooks and system settings for maximum configurability. More on that later. What I want to get to right now are two things I’ve done.

First, I’ve bastardized system settings; I replaced all of the collapsible fieldsets with tabs. I immediately found this settings page to be far, far easier to work with. Sure, the tabs I’m using are fixed size, so there’s an extra scrollbar in the div, but there are two important things I’ve noticed.

1) When I switch tabs, I don’t lose context of what the other tabs are. When you open a fieldset, anything that was below it slides off the bottom of your window. I don’t know about you, but if it’s not in front of my face, I’m liable to forget it.

2) It’s only one click to change tabs, not two. Reducing the number of necessary clicks is a good thing. Doing so in a way that doesn’t add clutter is ++good.

The second thing I did was to bastardize the modules page. This is one of the pages I mentioned above that is atrocious to work with. Modules are grouped poorly. The module settings pages are completely unrelated to the actual modules page. It’s difficult to pick out what’s actually activated.

Honestly, I didn’t even do that good of a job with it. I think a second rewrite of it could lead to another leap in usability, but the one I came up with at least groups modules with their package (i.e, all ecommerce modules are actually together), gives you a tab with just your enabled modules, links to the help and settings to the module, and lets modules also provide administrative links.

Where is This Going?

So I called this module a proof-of-concept module. And it is. I don’t intend for this to be a module, I actually want to use this as sort of a launching pad toward core. However, there are several problems with writing administrative code for core.

• Getting agreement and buyin on anything is difficult, because there’s a lot of disagreement.
• Writing core patches to have them turned down due to disagreement is a real motivation killer
• Getting core patches accepted is as much work as actually writing the code.
• I’m using some javascript that I think the PTB will frown on.

It’s possible that this could lead to another discussion about contributing to contrib and contributing to core, but I’m not interested in that discussion right now. Besides, part of my motivation is that I’m pretty lazy about some things, and politicking is one of them.

Ok, so this is something that, theoretically is a Drupal core effort. But as a module, it can be tried out safely, be usable in the existing 4.7 systems out there, and it can be refined. People can point, poke, prod, we can take what we like, and what goes into core will, hopefully, be better because of this kind of prototyping work. As a plus, it can actually work. For me, for you, for whomever wants it.

Let's talk API

Yes, let’s! Right now, I’m floating ideas around in my head, but for administrative tasks, I’m thinking of a series of hooks that modules can respond to.

• hook_admin_block — If a module wants to provide an entire block to the administrative interface, it responds with an array of appropriate information. Right now it’s name, title, content, and position (left or right). This’ll likely grow and change.
• hook_admin_item — If a module wants to provide an administrative item, it can return an array of them here. Each entry needs to be, at the very least, a link to the item, and a block name, so it knows where to put the link. And we probably also need to provide some kind of weighting system so that important items can float to the top.
• hook_admin_module_link — I’m not calling it this in the code right now, but I wasn’t sitting down trying to write the API definition at the time, but trying to get something started. I like this name more — and the hooks can be consistent this way. This hook lets modules add links on their modules page. To go along with the settings and help links, modules can also have their administrative links live there.

And while we’re at it, here are the categories I’m going with:

• Content Management
• User Management
• Logs/Statistics
• General Site Configuration
• Site Building

Also, the front page needs easier access to the settings (which are, basically, what theme the administrative site uses and how the blocks are organized).

Conclusion

Yes, I’m finally about done blow-harding on this topic. You can go look at the alternadmin module if you’re interested. You can post your comments here. We can talk about why my changed designs work or don’t work; how they can be further refined; how the existing pages can be further refined; how to categorize (I think I’ve got a pretty good handle on that, but I’m sure everyone will have a slightly (or extremely) different opinion).

But I am very interested in input. I’m also interested in help. I’ll happily give commit access to anyone who seriously wants to help add pages to this thing. Show me how you’d rewrite the menu system. Or the block system. We don’t have to stop with just rewriting administrative pages either. For the blocks system, I actually have alternative database ideas. Hopefully I’ll get a chance to work on them.

Ok, let the rips begin.