On 27 Mar 2005, at 2:11 PM, Gabor Hojtsy wrote:

To be precise, we decided that it should be very easy to set some clean theme for the admin interface, but it is not going back to the separate look and feel, since it will still be possible to use the same theme/layout for the admin pages. :)

Yes, however the clean admin theme will be the default. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On 27 Mar 2005, at 2:25 PM, Moshe Weitzman wrote:

perhaps disable all blocks beside navigation while in admin. that would guarantee that a 3 column site collapse into a 2, thus giving more breathing room ... i didn't attend that session so perhaps more sophisticated proposals were made. Certain themes like kubrick and co. are still completely unusable when this happens.

The idea is to get a clean consistent admin interface that works for everyone, regardless of theme .. and then allow the designer to override it with his own theme / look.. IF THEY KNOW WHAT THEY ARE DOING. -- Adrian Rossouw Drupal developer and Bryght Guy http://drupal.org | http://bryght.com

On Sun, 27 Mar 2005 21:03:10 +0200, Steven Wittens <steven@acko.net> wrote:

Adrian Rossouw schreef:

...

On 27 Mar 2005, at 2:25 PM, Moshe Weitzman wrote:

...

perhaps disable all blocks beside navigation while in admin. that would guarantee that a 3 column site collapse into a 2, thus giving more breathing room ... i didn't attend that session so perhaps more sophisticated proposals were made.

Certain themes like kubrick and co. are still completely unusable when this happens.

The idea is to get a clean consistent admin interface that works for everyone, regardless of theme .. and then allow the designer to override it with his own theme / look.. IF THEY KNOW WHAT THEY ARE DOING.

I thought we were going to leave this up to the themer, as it's mostly a theme issue. Really, CSS positioning issues appear on more than just the admin, so it's not an ideal solution.

I would default it to 'off' for most core themes, as they have a very usable admin section.

Steven Wittens

This is really not the "wording" that I would advocate, although the result is essentially the same as what you're going after. Drupal should ship with a default /admin theme, which provides a consistent backend UI for all Drupal installs. This should be part of a new default theme, which has yet to be designed (I'm suggesting that we replace Blue Marine as the default with something totally new and much improved -- to set the bar for and motivate new themers). This /admin theme can be overridden in individual themes if there is an /admin directory provided which contains the appropriate styles, etc. This means that Kubrick themes would use the default Drupal /admin theme but other themes, notably ones shipped w/ Drupal could provide their own /admin themes. I wrote up a reply to the CiviCRM guys about some questions they had w/r/t to remotely theming their application, which will eventually ship with CivicSpace. The general idea is that we can extend the /admin theme idea to other third-party components, so if your theme comes with a /civicrm directory, you can override the defaults, allowing Drupal distros to better customize the complete look and feel of the package. My reply:

For this release it would mean we integrate with Drupal's themeing system and provide a user a choice between CiviCRM's stylesheet and Drupal's theme.

If you want a seperate style sheet for the civiCRM output, you *could* include a separate sheet in the drupal theme - but you will have to make sure that there are no naming collisions with other element's classes or IDs.

This is actually a very interesting discussion that I can shed some light on. It was decided at DrupalCon to rip out the site admin UI from the community admin UI and make administering your site occur in a visually isolated environment. There were a number of reasons for this, but I'll speak more directly to the technical implementation that CiviCRM can benefit from. In particular, Drupal will now ship with a default admin theme. This theme will be used for all pages generated in /admin (i.e. /admin/block/) so that theme developers need not worry about the look and feel of the admin area (since more and more themes, like the ported Kubrick theme, don't deal with the wide tables of the admin UI). However, if a theme comes with an /admin directory then those styles will override the default Drupal admin theme. The purpose of this is to allow designers to control all the visual aspects of a site if they desire, but makes it optional so that they can focus on the frontend without worrying about mucking up the backend. CiviCRM could follow a similar approach, where a default theme is provided, but if a theme comes with a /civicrm directory, the selected theme would override the defaults. This would make it very easy for CivicSpace or any other CMS to apply its own styles or themes to CiviCRM while making it possible for CiviCRM to have its own identity when shipped independently. Anyway, I thought that this would help move the discussion along. I'd be interested to hear your thoughts, ideas, opinions or concerns about this approach. Chris

IMHO, this seems like a rediculous use-case against the development of a consistent admin UI. While there may be many among us who run numerous Drupal sites, I don't think that it's all that difficult to fix this problem. All we need to do is put a place for the site's name or logo in the header and you're done. The benefits I think far outweigh this issue, which can easily be remedied. I don't see this as being an intrinsic problem in separating out the admin UI, it's simply a design problem. Chris On Mar 28, 2005 4:15 PM, Adrian Simmons <adrinux@gmail.com> wrote:

Chris Messina wrote:

...

Drupal should ship with a default /admin theme, which provides a consistent backend UI for all Drupal installs. This is what we used to have, and it has bad usability for those of us that maintain several drupal sites. If all admin sections look the same how can you tell which site you're on? And what happens when you happen to be making changes to more than one site at a time - there's potential for great confusion when the only thing to differentiate the sites is the url in the location bar.

Consistent admin UI and a consistent admin theme aren't quite the same thing.

-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com

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