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