[development] WordPress' project Shuttle: Administration redesignproject

[Jeff Eaton]

> -----Original Message-----
> From: Dries Buytaert [mailto:dries.buytaert at gmail.com] 
> Sent: Monday, May 15, 2006 9:59 AM
> 
> Looks nice and professional.  (This discussion probably belongs on  
> the theme development mailing list.)
> 
> I'd like to see a dashboard in Drupal 4.8/5.0.

I'm not convinced that this would be a good idea -- at least, not in the
forms I've seen it so far. While I think there's no arguing with the
idea that Drupal's administrative interface needs work to achieve
WordPress levels of usability, there are a couple of fundamental issues
that need more than a menu and page reshuffling to solve.

1) A streamlined and user-friendly administration UI is very
task-dependent.

Community blogs, Ecommerce/Storefronts, Community sites, News Portals,
etc. CAN all be shoehorned into a single workflow, a single dashboard,
but I think the experience will suffer greatly. WordPress has the luxury
of focusing exclusively on blogging. If you look at its administation
dashboard, it combines features from four specific Drupal modules, one
of which lies in conrib (trackback). It's perfect for a
your-blog-at-a-glance overview, but almost useless for other types of
sites.

2) Drupal modules have absolute flexibility in how they manage their own
configuration.

They can add a new hierarchy of menus. They can sit under the /admin
hierarchy, or add a block full of links that's only visible to
permissioned users. They can add their options to other screens. They
can form_alter their way into any other UI, if necessary. Achieving the
kind of streamlined, polished admin UI that WP demonstrates -- while
also working with contrib modules -- is its own herculean task. We don't
have the luxury of shoving everything into a 'plug-ins' page.

I think the real solution lies in optimizing drupal core's
adminsitration interface for four key tasks: site setup and
configuration, basic batch operations on content, user permission
management, and viewing statistics.

Providing a default 'dashboard' that gives access to those tasks, and
supporting a system where other dashboards could be swapped in to
replace it, would let use focus on the basics. Those additional swap-in
dashboards could be optimized for the needs of specific sites, rather
than just adding more-and-more-and-more features to the 'core'
dashboard.

That's my thought. It comes with no code, and thus is worth less than
the existing implementations, but I worry that pursuing a 'monolithic
redesign' for the admin screens will gain us very little if it tries to
be all things to all people.

--Jeff