[drupal-devel] Admin theme.

[Chris Messina]

Tom, thanks for your thorough response. You raise some very good
points and helps clarify my reasoning for wanting to *at least* have
the *option* of an admin theme. A few responses:

> 3. A differently-themed admin would be nice to provide a common admin
> interface between Drupal and other web-based apps.
> 3. This is a valid point... a common admin UI among applications would
> be nice.  However, I'd be willing to bet that the majority of Drupal
> users will not be taking advantage of this, as they'll be using Drupal
> alone... or perhaps with a different combination of other apps.

I also think that being able to integrate with certain third-party web
apps (like CiviCRM, Gallery, or even phpMyAdmin for example) would be
a much more attractive proposition if you could theme those apps just
by providing the appropriate stylesheets in a correctly named
subdirectory. I agree that this doesn't have universal appeal just
yet, but it's something to think about, since the changes that we're
discussing for the admin theme could be generalized for other
purposes.

An admin theme also helps with documentation and creating accompanying
screenshots, which I think, moving forward, will become a very
important piece of Drupal.


> 4. For the most part, theme designers don't need to worry about the
> admin section.  The sane defaults provided by the default theme
> functions and the CSS rules in drupal.css provide a nicely usable
> administration section in nearly every theme, while maintaining a
> pleasant feel with the site's own layout/color scheme.  

As a themer, this is actually not true. There is far too specific
markup and presentation-ese in drupal.css. And it sucks that in all of
my themes that I've released to date, the markup in drupal.css kills
my layouts.

Drupal's default admin UI should output semantic XHTML that anyone can
theme to the their heart's content. Floating left the three admin
boxes is far too specific an implementation for this to be considered
a "sane default". Instead, that's moving toward the "admin theme" I've
been discussing. So hey, maybe in the default Drupal admin theme, the
three fieldsets *do* get floated left, but as a themer, if I just want
plain XHTML for the admin section, I should get it!



> 2. The fact that the site keeps a common
> interface between the VERY few admin screens they occasionally visit and
> the user screens they often visit is a big plus.  Without that
> consistency, there would be a significant "what's going on?"... They might think they've
> somehow entered an area where they shouldn't be or be fearful that they
> might break something.  
 
You touched on something extremely important here, which is actually
one of the primary reasons that I think there needs to be a more
obvious distinction between *site admin* tasks and community or
content tasks. Think of the admin section this way: you might give
your kids the key to the car and they can operate the radio, change
the climate control, etc., but you don't want them mucking around in
the engine with the same abandon.

That's how I'm looking at the admin theme. I mean, this is like the
nuts and bolts of Drupal -- and we need to figure out what goes in the
regular dashboard and what gets put under the hood. The point is 1)
make things easier to find because they're more sensibly located and
2) remove the perceived sense of risk that providing too many
one-click-away options provides.

Let me give you an anecdote to illustrate the problem. At the FLOSS
usability sprint, we had people who were not familiar with Drupal
user-test CivicSpace. We had them "explore" the admin menu system and
tell us what they expected to find "behind each door" (or menu item).
We also had them organize the various tasks that each menu item
represented in a card sort (see this page for more info:
http://www.flossusability.org/wiki.pl?CivicSpaceSaturdayMorning).

What was extremely interesting to me was how few of the participants
actually *clicked* on any of the menu items when describing them. They
were freaked out that anything they clicked on might cause a meltdown
of some kind because we didn't manage their expectations. If, on the
other hand, it was obvious what actions would lead to big consequences
and sequestered these "big red buttons" appropriately, there is a good
chance that they would have clicked around more freely, sensing that
there would be no or little risk.

Just as your point about people getting confused about "what's going
on?" is a valid one, we also need to worry about people subconsciously
freaking out about "what will happen as a result of this immediate
action?" I think that we can "tunnel" people's behavior much better in
Drupal by having obvious boundaries between the engine and the
interior (so-to-speak).


> 3. The distinction between administration and site viewing is blurred...
> if we continue along our current path, it will disappear.  This is a
> good thing.  The ability to switch between editing and viewing posts
> with tabs is terrific.  

Let's be very clear about this. I don't want to go back to "the way
things were" (tm). I never experienced the "old Drupal" so I wasn't
there when this change was made -- however, I can tell you that this
was probably one of the best changes that came to Drupal. It moved a
content-specific task closer to the place where you'd expect to
complete that task, and that's a good thing. So in no way am I
suggesting that we undo that kind of change.

However, site admin-specific information, tasks and related aspects of
running a Drupal site should be cordoned off. This would include
global settings for your site, like clean URLs, which modules are
enabled and watchdog statistics. These are things that a site admin or
admins would need to focus on, and would be off little use for the
community or external-audience of a site.

The one tricky thing is managing the case where an admin needs to see
the site as the public sees it, but I think that, given some thought,
we can figure it out.


> From a theming perspective, I like the way Gallery and Gallery2 handle
> administration and install/upgrade.  They provide a user interface which
> expands to encompass the admin interface when users have appropriate
> permissions.  

While this is okay and a good idea, I think that there will, as you
pointed out, be exceptions to the applicability of this approach. As
you suggested, when you're in the forums, perhaps there's a new tab to
configure forums locally. That's great and should be done (moving
tasks to where you expect them to be is GOOD)!

But what about clean URLs or user administration? What about
configuring your upload directory? Or what about selecting the
site-wide theme? These are the kinds of one-off tasks that you set
once and tend to forget about, compared with everyday "admin-*like*"
tasks, like editing content or moderating comments.

Certainly our UI should expand to offer role-specific admin tasks, but
that's not a general-enough solution to cover everything -- and that's
where the admin section (control panel) comes in.


> For admins who want to provide a custom admin/content editing theme (or
> for the case of embedding Drupal within a distribution of software with
> a common admin UI), I suggest the use of Bèr's sections.module, which
> chooses the site theme based upon the current path.

Perfect.

 
> Unfortunately, I was unable to attend DrupalCon, so I may have already
> missed my opportunity to vote on this issue... but if the majority of
> people don't agree with me, I hope that at the very least we can
> maintain the ability for site admins to turn off the separate admin
> theme and maintain the excellent admin/site integration we enjoy today.

I think it's very important that we do have this discussion and flesh
these ideas out, since this will be a significant change for Drupal. I
do not, however, think that this is going backwards. We're actually
moving forward in the direction that we were already going and making
the split between site-admin tasks exist in a special admin-only place
and moving more of the community tools and functionality closer to the
place of action.

Chris