[drupal-devel] Admin theme.
Tom Dobes
tomdobes at purdue.edu
Tue Mar 29 08:44:06 UTC 2005
Chris Messina wrote:
> 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.
I've resisted the urge to argue up till now. :-)
I'm not sure I can see what the real advantage to having a separate
admin UI would be for the average Drupal user.
* Here's what I got from the reading the thread up till now: *
1. the install / upgrade should look different than the usual Drupal theme
2. Certain fixed-width themes do not work well for the admin section.
3. A differently-themed admin would be nice to provide a common admin
interface between Drupal and other web-based apps.
4. Theme designers should not be responsible for theming the
administration section.
* and now... responses: *
1. I agree with this 100%... When people are installing/upgrading, they
are making major changes to their site and thus the pages should be
styled differently. However, I would argue that the install/upgrade
tool should look different from ANYTHING else the user sees while using
Drupal... including the admin section. I disagree with the point that
install and admin UI should share a theme.
2. I have tried out a lot of Drupal themes and I can say that most of
them have VERY usable admin sections. However, I must agree that some
are very painful to use when it comes to editing content or using the
admin section. While this could be alleviated by selectively turning off
blocks, I do not think that can completely solve the problem. On one
site, I use the greenthing theme with only one sidebar, and I frequently
encounter problems with important widgets being obscured in the admin or
editing interface. So... something needs to be done to make admin (and
content creation/editing) easier with fixed-width themes.
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.
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. The few themes
that do have problems need to use the same solution we work out for #2
above. I would hope that very few theme designers would elect to take
this option.
* Now here's what I like about Drupal's current approach to admin: *
1. There's no awkward switching between admin interface and user
interface. My first Drupal site was an old install with separate admin
and user interface. I found that I ended up keeping a user tab open and
an admin tab open and constantly switching between them. This was
annoying and counterproductive. I love the way I can effortlessly
switch back and forth between admin and non-admin tasks. I love the
fact that, while on admin pages, I don't lose my links, menus, and
custom blocks... they're still there so I can quickly hop back to the
exact section of my site that I need.
2. It's more user-friendly for non-root users. Most of the sites I deal
with have more than one administrator. Typically, each administrator
has varying permissions. 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?" reaction
the first time they entered an admin page... They might think they've
somehow entered an area where they shouldn't be or be fearful that they
might break something. I work with people who are somewhat reluctant to
update their sites as it is... they don't need another usability barrier.
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. One of the complaints we have about the
administration section as-it-is is that there are "too many options" and
that people can't find what they're looking for as quickly as they would
like. IMO, the ideal solution to this is to put the configuration with
site features next to those site features. On the forum page, have a
"configure" tab that would lead to forum administration... same with the
search page, or the image gallery. Provide a tab containing the book
overview/reorganization admin page on the book index. I know this isn't
globally applicable and that a lot of settings should still remain in a
centralized admin or at least be referenced there... but distributing
administration a bit would help usability in many areas.
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. There is no separate theme, there is no clumsy switch
between "user-land" and "admin-land". On the other hand, there is a
CLEAR division between the site and the installer/upgrader. They look
different, which gives the user a clear message that they're making
important changes to their site and they should pay attention.
* But what about fixed-width themes that don't handle the admin section
well? *
My suggestion is that we allow theme designers the option to fallback on
a core theme for admin if they so choose. My hope is that this option
will mostly be used by fixed-width themes, as they are really the only
ones I've encountered that have problems.
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.
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.
Tom
More information about the drupal-devel
mailing list