[development] the past, present and future of drupal admin

[Jeremy Epstein]

On 7/26/06, Kristjan Jansen <kristjan.jansen at gmail.com> wrote:
> 5) It's all about _discovery_ of settings, right? How does it work
> right now? I would imagine couple of ways:

(snip)

> Possible improvements (some of them silly ;)

(snip)

> -- for recently enabled modules' menu item add red "new" markings so
> they stick out while browsing the admin pages. It can be problemsome
> though: enabling many modules in the same time takes you to go reddie
> hell. But this is just a suggestion for direction not a concrete
> proposal

I agree that "discovery of settings" is a big problem for Drupal
administrators at the moment. The way that the menu structure "grows"
within the admin section of a Drupal site is extremely
non-user-friendly, IMO.

All Drupal modules - core or contrib - currently add or modify a whole
bunch of pages to the admin section of the site (where 'pages'
includes all types of menu items, e.g. normal items, tabs/subtabs,
callbacks, etc) as soon as they're enabled. But they don't notify the
administrator at all! They change the structure of the site, and they
don't tell the site admin about it. This is not good. How can we
expect poor old Joe Admin to know where to look?

I like the idea of the red "new" markings on newly added menu items. I
also have another idea, that takes a slightly different approach to
solving the same problem. It is currently best practice for modules to
list all of the functionality that they offer, and all of the menu
pages for using the functionality, in the 'admin/help' section. Why
not take this help text, and make it stand out to the user when a
module is first enabled?

For example, the path module is a core module that is disabled by
default. We could make it so that when the path module is first
enabled, a series of 'messages' are displayed to the administrator on
the main 'admin dashboard' page, each message listing a new piece of
functionality, and a link to the page where it can be used. See my
attached mockup image for an idea of what I'm talking about.

In the mockup image, my vision is that when the user clicks anywhere
within the message, they are taken to the page that is being linked to
in the message, and the message itself is deleted. The user can also
delete the message without following the link, by clicking the 'X'
icon in the corner. Of course, this vision would involve a lot of
fancy AJAX in practice. If 37Signals were developing the next version
of Drupal, I imagine that this is how they'd do it. ;-)

Cheers,
Jaza.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new_admin_tasks_list.png
Type: image/png
Size: 4451 bytes
Desc: not available
Url : http://lists.drupal.org/pipermail/development/attachments/20060727/4418b7cf/new_admin_tasks_list.png