Patch to give Drupal an overall administration page

i haven't had a chance to play with this, but my only comment, based on the screen shots that you linked to, is that i'd prefer that modules in sub-directories be grouped together in the list rather than placed on their own tabs.

In overall, I like the patch. The devil is in the details. First of all, I'd like to see user_access calls removed and _menu_item_is_accessible used:

$q = $_GET['q'];
// a loop here..
$access = _menu_item_is_accessible(menu_set_active_item($path));
// after the loop
menu_set_active_item($q);

second, I am not sure I like the word 'block'.

And finallly, an alter hook is needed.

Looks good. I like. Here are some minor issues:

* Don't use tabs; eg in your CSS file changes.
* Rename 'config' to 'configuration'.
* Rename 'admin' to 'administer' or 'adminsitration'. Using abbreviations in user output is not professional.
* url should be URL
* blogapi should be BlogAPI
* Don't cap each word: 'General Site Configuration' -> 'General site configuration'.
* Some titles only use lower-case sentences.
* $block[description] is going to generate warnings. You have to write $block['description'] ...

I wonder if we need a different way to have the menu system interact with the "administration blocks". One of the fundamental usability guidelines is that link names match the title of the destination page. Thus, if you have a link called 'system logs', the destination page should be titled 'system logs' too. The menu system enforces this rule. The administration blocks violate this rule ...

I'm just thinking up loud here, but maybe it would be better if the administration blocks would correspond with the top-level menu items in the administration menu, and that the administration block items correspond with the second-level menu items.

The advantages would be:
* No need for an extra hook, less code, less run-time overhead.
* Menu items, link names and page titles always match -- this is enforced by the menu system.
* The administration page automatically maps onto the menu system. Usability is all about being able to create a 'mind map' of how things works. I think this enforced consistency would help people creating a good mind map.
* Shuffling the menu items around from the ?q=admin/menu item page will also affect your administration blocks. That is, people can redefine the administration blocks using the existing menu building interface.

The more I think about it, the more I think #8 is the way to go. Is there any limiations of problems with #8 that you can think of? (Sure, it would require significant menu restructuring but that is cool. The final outcome is what matters.)

my gut feeling is that the menu system is excessively rigid for the nice /admin page we want. the menu system is too much of an engineer's solution. we need a user experience frame of mind here. i'll try to articulate this a bit better if needed.

My gut feeling still tells me that improving/extending the menu system is the best way forward, but I'll let other people review this patch too.

(Improving or extending the menu system is perfectly OK and actually needed.)

I remember a module which did the same thing with additional options and icons. Was it abandoned?

merlin: permit typical "you didn't even try it, did you?" ignorance, but some screenshots I saw on your pissed-off-confectionry site suggested an overabundance of tabs: admin/settings appeared to have everything tab'd, which makes it nearly unusable on smaller resolutions. Nor do I think that have more than 5 tabs is a good idea: there's tons of regular OS application design that lambasts applications with lots of tabs. Anyways, you can heartily ignore this comment: I've not tested the patch, going on shoddy recollection of screenshots I saw on your site, and am generally being unhelpful. Excelsior!

Tabs are great - their useability only suffers when the tabs change position when highlighted.

subscribing...

Here is a patch that accomplishes the same by leveraging the existing menu system, as per my comment above.

Note that this is a 'prototype patch'; it's quick and dirty in terms of CSS and it doesn't create useful blocks! The sole purpose of this patch is to demonstrate the underlying approach.

1. It is required that we redo the layout/structure of the administration pages so that they match those in Earl's screenshot. This has been planned anyway. In the mean time, this patch does a good job highlighting the poor organization of the current administration menu. ;-)
2. If someone wants to cool up the look and feel of the blocks, please do. In the mean time, I hope you can ignore the uglyness of the UI and the poor navigation structure. The goal is to compare it with Earl's approach and, hopefully, to debunk some of the myths surrounding the menu system.

Advantages:

1. No changes have been made to the menu system. No new hooks have been introduced.
2. Page titles automatically match menu links. This is a usability requirement.
3. Breadcrumb paths make sense. This is a usability requirement.
4. The navigation menu in the sidebar is automatically in sync with the main administration page. This is a usability requirement. (The speed by which people can learn to operate a system, depends on how easy/fast it is to build a mind map of the system.)
5. Menu descriptions are used on the main administration page, as well as for link attributes. Less strings to translate, no duplication of information, and ultimately, less code.
6. You can configure the main administration page using the existing menu administration. Earl's system does not allow custom configurations, as far as I can tell.

Disadvantages:

1. It's not (yet) possible to add 'information blocks' with no links (eg. with some basic statistics or important watchdog messages).

Here is a screenshot. Yes, it looks ugly. See explanation in the comment above. After (i) improving the CSS, (ii) adding descriptions to the menu items, and (iii) restructering the administration menu it could look exactly like Earl's screenshots. :-)

(You have to flush your cache-table if you want to play with this patch.)

Thanks for your comments/review.

The current patch doesn't allow for generic blocks (eg. information blocks, statistics blocks). Your concerns expressed in (1) and (2) can be solved by adding an extra hook. A hook that has nothing to do with the menu system; it would probably look like a simplified version of your proposed hook, or like the regular block-hook. Or maybe these can be regular blocks (in combination with a new blog region or something)?

Placing blocks of content on pages looks like an important feature of a content management system. It wouldn't hurt if there was a generic mechanism (probably the block system or something like the frontpage module) that allows people to put blocks of content on a page. There might not be a good short term solution (other than a quick hook), but hopefully, we can come up with a generic solution at some point. It's core functionality, don't you think? And it shouldn't be limited to the main administration page. One day, for example, I'd love to do something more fancy with drupal.org's and buytaert.net's front page. ;)

As for (3), not sure I understood what you were saying but I didn't touch the settings pages in this patch. I did touch the settings pages in another patch. It does attempt to remove the automatic settings pages and splits up the main settings page in sub-pages. That patch removes 2 special cases, and fixes some usability concerns while doing so. Using the regular callback system for settings pages makes sense; there is no reason to treat them as being special, nor should we restrict administrators from being able to shuffle settings pages around (currently, the settings pages are unknown to the menu system).

I don't have a solution for icons (item 5). However, I could add support for icons with a 2-line patch to the menu system.

I (obviously) prefer the approach taken in my patch but like to know what you and the others think about this? I'd like to move this forward; it's only 1.5 months until the code freeze, and committing 3 big patches in the last week isn't an option.

If you want to help (please) or if you want to toy with it (please), here is what you can do:

1. Improve the CSS: make it more sexy.
2. Add descriptions to the menu items -- they will also be used as title-attributes in the regular navigation menu.
3. Change the paths in the menu_ hooks of the modules. We want to model things after your proposed layout.

We should probably move the discussion around (3) to that other thread. That said, Drupal has a helper function to create settings pages: see system_settings_form(). It's a trivial change. In fact, many of the core's modules stopped using the _settings hook already. Just grep for 'system_settings_form' and see. I'll try to convert some of the remaining modules tomorrow. I'll post an update to that other thread ...

By the way, changing the paths of pages should be fairly straightforward. If the callbacks use the automatic argument-feature (and almost all callback functions in core do) rather than hardcoded arg(x)s function calls, it should be fairly easy to do.

If you encounter callbacks that use arg(), we might want to mark them. Using arg() in a callback is a bug because it does not allow the page to be moved by the user (through the menu module). The menu module will let you change the path, and when you do so, the page will be broken.

In short: callbacks should not use arg() and when they do, changing their position in the menu tree should be easy.

adding more chaff to menu is a very bad idea given that's always loaded and it's quite big.

It is a bad idea because there might be a performance cost. It is a good idea because it improves usability. So depending on what hat you are wearing, it can be good or bad.

It begs the question: should the user /suffer/ because the internal implementation of a building block doesn't scale? My answer is that we need to fix or improve the building block's implementation.

Moreover, we did NOT touch the menu system. We're just using the provided functionality/APIs. Frankly, it is the menu system's (internal) problem. If it doesn't scale, it is not this patch's fault. Contributed modules would be able to do exactly the same. That doesn't mean we don't have to be careful, of course.

Also, we haven't evaluated the performance cost yet, so maybe it is not noticable. Frankly, we can't tell. However, we could do a simple experiment to figure that out. We shouldn't reject this idea without factual data to backup some claims.

commenting on patch #21.
I don't get anything that looks like the screenshot in #22, but that's a detail.

I see a huge problem by the approach which I believe is being used here (use $items in hook_menu() to automatically create the entry admin page).
We now have direct links to some pages which are secondary tabs for the admin of some modules (e.g. you can directly access ?q=admin/themes/settings without going through /?q=admin/themes which may be convenient), but it has some serious unwanted side effect: we have a direct link to, e.g. ?q=admin/block/delete or q=admin/block/configure without having the block id being defined, which is very confusing.

For such an approach to work, we need to add a key or two to the admin/ items returned by hook_menu(), like:

$items[] = array('path' => 'admin/mymodule', 'title' => t('Mymodule Admin'), 
       'callback' => 'mymodule_admin', 
       'access' => user_access('administer my module'), 
       'type' => MENU_NORMAL_ITEM,
       'admin_listing' => TRUE,
       'admin_block_category' => 'Content management block',
); 

:)

Resynced with CVS HEAD.

I've installed it on a clean HEAD and it's working perfectly. I can't stress how much of an improvement it is for busy sites; the ability to switch to 'streamlined' mode and the ability to specify a separate administration theme is a huge benefit, too.

The use of the menu system to define the groupings makes good sense. I still need to dig around a bit more, but so far it gets a bit +1 from me. Three cheers for 4.8/5.0.

I'm liking merlin's approach to this. With the old menu items, I think it was exposing too much of the mechanics of things instead of presenting logical options to make things easier for an administrator. Based on the latest screenshot, it looks much more clear. (Although some of the new menu titles are maybe a little verbose but that is a minor detail at this point).

I like this patch and if it goes in, then I think it'll be fairly trivial to change menu system to not cache descriptions as they are rarely needed, instead we can have a menu_get_description($path); which rebuilds the menu in memory and provides descriptions.

(To others: when you test this patch, make sure to enable many modules.)

Here is a first review:

• I like it. Good job!
• I think that the 'administration settings' block that lets you change the administration theme is way to prominent. I like the functionality, but I don't see why it should be on the main administration page. It's a setting like any other setting and shouldn't be a special case, IMO. Secondly, by putting the setting on the main administration page, it suggests that it is a per-user setting (like the watchdog filter). It looks like a global setting and that is another reason not to put it on the main administration page.
• 'System Default' should be 'System default'.
• 'Admin theme' should be 'Administration theme'.
• 'blog APIs' is listed under 'module management' -- looks like a bug/miscategorization?
• Right now, the 'site configuration' block is at the top, and the 'site building' block is near the bottom. It would be more convenient if the frequently accessed blocks where near the top. I'd use the 'site building' block an aweful lot.
• The 'status page' Steven is working on could probably become part of the 'logs' block.

Good stuff, Earl!

patch works as advertised, and is a huge improvement to the usability of the admin section. +1.

one thing i did notice was that when visiting /admin/block, it simply dropped me back at /admin. i see that /admin/block isn't the path to get to the block admin page anymore, but we should be presenting a drupal not found page for any /admin sub-paths that are not valid...

@hunmonk - the behavior you request, a 404 instead of /admin page for admin/block is a longtime feature/bug of the menu system, and is out of scope for this issue IMO.

@merlinofchaos - that sounds fine. if you make this behavior part of menu declaration, then all modules can benefit. just add an item for hook_menu items like: 'accept arguments' => FALSE. the menu system can then issue 404 if it chooses this path and an arg is present.

the huge benefit of this is that we can deny arguments for the node/ path and give 404 instead of the home page!

just subscribing...

Very nice. The patch applies cleanly. On my basic testing I don't find any bugs. I'll continue to test and report any problems.

Some comments:

• The implementation through the menu system is clean and well thought out.
• The division by category of task makes sense to me.
• The expert mode is useful. I'd wondered if we should consider doing this through js, since with some tweaks the display could be changed through a simple css class toggle, but we'd also need an AJAX post to set the variable and that seems overkill.
• In the CSS, tabs should be replaced with spaces for indentation.
• A couple of the sections look sparse with only one item (Module management and Logs) but I think that's okay and we may add to them.
• Because it doesn't have a section, categories doesn't appear on the main admin page. Should it get a section? or possibly go under one of the existing ones, e.g., Content management?
• The item "manage users" on the main admin page doesn't fit well gramatically with the rest, since it's action focused rather than descriptive. Simply "users" might be better.
• The 'description' text in the sections (top menu items) could be more parallel. Some are full sentences and others not; one begins with a verb, others don't. There is a fair bit of repetition of the phrase "to help you". I suggest either (a) begin all with "Tools for...", e.g., "Tools for managing your site's content" or (b) skip the tools and begin with verbs, e.g., "Manage your site's content".
• It would be useful to be able to associate icons with the menu items (in a future patch). I've roughed in a patch that would enable this by adding a custom class attribute for menu items, http://drupal.org/node/42493.

Altogether, a great improvement and IMO needing only minor tweaks before being RTBC.

Here is a full-length screenshot for those who want to review the categorization and/or the help texts without installing the patch.

Dries: useful, thanks.

• Manage your site's content -> too repetitious with the preceding header. Couldn't think of a better one though: "administer your site's data"? Also note that there's no period at the end of this sentence.
• How come the menus in the sidebar block aren't alphabetical?
• Books description doesn't end in a period.
• Comments -> The moderation queue isn't in core, no?
• Also, I prefer the more European method of list punctuation, which means that there's a comma after every item in the list ("comment moderation queue[,] and edit comments.").
• Content types -> "comment and publication status".
• Content types -> no period, and don't use "and much more". No marketing.
• File uploads -> "what how".
• Forums -> "Control forums and their hierarchy and ...".
• Forums -> why are the settings under this menu item?
• Posts -> "site's" not "system". Use the same words.
• Posts -> European commas: "edit[,] and delete".
• Post Settings -> In reading over this organization, it seems odd that "Post Settings" and "Content Types" are two different screens.
• Don't use the term RSS. Use the term "Syndicated" or "Syndication".
• Don't use "RSS" or "Syndicated" "aggregator". Just use "Aggregator.
• Aggregator -> Remove "outside" and "makes available", s/polls/retrieves this data/".
• RSS feeds -> Syndicated, and "your site provides" not "Drupal provides".
• Search posts -> No period; can't you search users as well?
• European commas - "activate, deactivate[,] and administer modules.
• Blog APIs -> "which content types and engines external blog clients can use."
• Access control -> no period.
• Access rules -> European commas.
• Roles -> European commas.
• Search users -> "keyword" suggests it looks through profiles. Change to "by name".
• Speaking of profiles, I don't see it anywhere on here.
• Oh. Heh. Remove "user ". We already know it's users, cos we're under the Users block.
• User profiles -> "create customizable fields for your users", perhaps? This one needs work.
• Users -> European commas.
• User settings -> "Configure default" here, "Manage the default" elsewhere. Pick one. ("Configure" is better.)
• User settings -> European commas.
• User settings -> I think we use "e-mail". Doublecheck and standardize.
• User settings -> "user pictures."; remove "configuration". We expect that.

Hopefully next column later.

Good job. I think this would improve the usability a lot.

But I prefer "site management" or "system management" instead of "module management".

"Site" and "System" are far too general, though. Almost any portion of the admin screen could go under that heading. If modules need better-delineated sections for their own options, they can create their own menu trees and will automatically be given panels on this screen.

Merlinofchaos: Check out the Screen grab extension for Firefox.

Eh oh!

* I'd change "and much more" to just "etc.". Whether it's marketing or not FOR US, "and much more!" is used a lot as such.

* Aggregator: I'm fine with your changes though, to reduce repetition, would make it "what content [you] aggregate".

subscribing

I am not entirely happy with the approach this patch is taking (read my reasons in http://lists.drupal.org/pipermail/development/2006-July/017883.html) but I do believe in inceremental improvements, so at least this patch do not make things worse.

Comments:

1) I do not like the hackish feel the style and layout and implementation gives me. So far there is almost no quickhacks for item placements, there is always been an abstraction layer, whenever it was tabs, blocks, notification messages or page descriptions. Now suddenly such a non-standard blocks-that-are-not-really-a-blocks, why?
Why not take a step back on the layout and come up with a compromise using less prominent UI style and something that fits better with all the UIs. It's about the content, right?

I would drop the blocks style at least for now when we do not have finegrained, multi-region, inside-content block system approach in place and go for something similar to http://drupal.org/handbooks -- standard page-wide headers, 2 column links. The same style should possibly continue on admin subpages (see below)

2) why am I allowed to navigate to "content management", "site building" etc subpages using a menu tree, but I can not do it from the main administration page (the block titles are not links)?

3) there seems no logical order in menuitem order, seems like a mismash of weights and alphabetical ordering. It's hard to come up with a superstructure since added modules always mess up the order. So it's either:
-- always a-z
-- bump up -10 some most-used pages (content management > posts, user management > users), let others wrangle in flames of hell (my pick)
-- bump up all default module's items, let added stuff appear in the bottom

4) the mentioned admin subpages look different (no block style)

5) why admin subpages have no page (short or long) description?

6) expert mode: I have mixed feelings about it:
-- I turned it on and never looked back so it is useful for me
-- It's a non-Drupalish behaviour what has no previous precedence. We have came so long way with all the fancy js collapsing for UI clutter handling and now such a 1995ish behaviour.
-- The label is misleading, it's hard to understand what scary thing lies behind that link. Why not "Hide descriptions/Show descriptions"
-- I still think we could do away without that complexity and go for no-descriptions by default with descriptions in link hovers. But it needs to be tested, long texts in tooltips are not always easy to use

7) There are settings that are hard to classify:
-- RSS: is it content management or site configuration? (note that commentrss.module and atom.module want probably live near the rss settings too)
-- contact form: why it is look&feel? should it be site configuration (or content?)
-- file upload settings: content --> site configuration
-- blogAPI: modules --> site configuration (or content?)

8) site configuration > administration settings
"Choose which theme the administration pages should display in. If you choose "System Default" the administration pages theme will not be overridden." -- this overriding thing sounds scary. Why not just say as it is: system default keeps the admin theme same as you have set for your site?

9) Why the default is bluemarine, not System Default (what is bluemarine too)?

Some more comments on the wording:

• List books and control orphaned ...I'd prefer something like "Manage books" or "List the site's books." The problem is that list and control can be nouns, verbs, or adjectives, so one stumbles trying to parse it (English not being German). It wouldn't be so bad later down, once the pattern of beginning most items with a verb has sunk in, but not as the very first item.
• Create vocabularies and terms which may be used to categorize your content
• Comments ->"List and edit site comments and the comment moderation queue"
• Content type -> "Manage posts by content type, including default status, front page promotion, etc."
• File uploads -> "Control how files may be attached to content"
• Forums -> "Control forums" (The rest follows obviously.)
• Post settings -> "Control posting behavior, such as teaser length, requiring previews before posting, and the number of posts on the front page." [Aside: as I read this, I realize that the last item is misplaced. It's configuring the front page, not posts.]
• RSS Aggregator -> "Configure which content your site aggregates from other sites, how often it polls them, and how they're categorized.' By the way, I agree with the position that RSS is more familiar than syndication.
• RSS Feeds -> In addition to the missing article, this gives me no idea of how it's different from the preceding item.
• Search posts. This is redundant with the posts item above.

That's all the wordsmithing I have time for at the moment, but let me make one more comment. Now would be an ideal time to capitalize these entries. Mixed case is easier to read, and in this situation, much easier to scan.

I hope to go through the rest soon. To paraphrase Elements of Style, most editing is just deleting unnecessary words.

Dear Mr.
Some modules pertain to site configuration while they can pertain to site building in a more practical approach.
Site information, Localization, Date and time modules could be present in site building because they directly influence how the site looks and feels, and are generelly defined at first. Other modules of site configuration are more technical.

and possibly
clean URL: is there a necessity to maintain two menus and separe configuration with URL aliases?

Fabcrice: we're aware of the difficulties but its a difficult problem to solve. What _concrete_ solution do you propose? We can only proceed given concrete solutions that get sufficient support.

Earl: I propose we group all settings in a single block. See mailing list for details.

Let's do another round of minor improvements: some of kika/kristjan's comments really make sense to me - eg "Hide descriptions/Show descriptions" vs "Expert mode".

I think that after another round (or maybe two rounds), this can be committed.

@#62

1) I do not like the hackish feel the style and layout and implementation gives me.

I'm not comfortable with the dramatic difference in heights of each block. They don't line up in any nice grid-like fashion. To make this act like the handbook index page might not be a ton of extra work. That might look a lot cleaner, actually.

2) why am I allowed to navigate to "content management", "site building" etc subpages using a menu tree, but I can not do it from the main administration page (the block titles are not links)?

Consistency. No other block titles in Drupal are links that I know of. Also, all the information you would get from going to that sub-section is exposed on each block so what do you gain by adding the links?

5) why admin subpages have no page (short or long) description?

Is the description even neccessary on the main admin page? It's just another piece of help text isn't it, so small thing to fix either way.

6) expert mode: I have mixed feelings about it:

I would say just leave "expert mode" out, if all it does is hide the descriptions of each item. It should be able to be themed so that the descriptions are less-intrusive without needing to hide them.

7) There are settings that are hard to classify: RSS: ... file upload settings

RSS is content management to me.
I would be tempted to put file settings under content management.

9) Why the default is bluemarine, not System Default (what is bluemarine too)?

There shouldn't be a "system default" entry.. It should list all the names of the enabled themes, and mark the enabled one with an astrix or something.

The current patch breaks the admin/build/block/list page:
Lines 202-205 of block.module should read:

  // If non-default theme configuration has been selected, set the custom theme.
  if (arg(4)) {
    $custom_theme = arg(4);
  }

First, I want to say that the screen shot in #69 looks 100x better than the current admin interface, and I really appreciate the hard work that's gone into these improvements.

I do, however, agree with the comment in #70 regarding the columns. I'm willing to take a crack at generate sections that are the full width, but have two columns of tlinks within each block.

obviously I'm too slow on the draw ;-) I only just had time to get the patch installed.

I think this screenshot is better, especially if some of the styling is added back.

Let me know where I can help- either with the code or with the styling/CSS.

The "edit primary links" link (which appears when the primary links are not set) should lead you to the admin/build/menu page.

I'm agnostic on two-column-boxes versus full-width-boxes-with-two-columns-of-links. It seems like the sort of thing that should be handled by a theming function, and shouldn't hold up the otherwise major work done by this patch.

The 'look of the page' is important, but discussions about the specifics of formatting seem to be eclipsing the work done to reorganize the *structure* of the administrative section. The new layout is good, and has more room to grow than the 4.7 era setup.

From a usability/aesthetic perspective, the layout and styling of #78 is the way to go in my mind. I also agree with Eaton that this could easily be changed at the theme stage. Just change the width and "float: left". I like where this patch is going and will be around to chime in on changes every now and then.

Personally, I like #78 best. :-)

#78 looks nice when the descriptions are shown but might look weird in 'expert mode'?

As a lot of people already mentioned, I think this styling issue shouldn't stop the patch from going in.

The best would be to provide a theme function for that, because then a yet-to-be-created adminstration theme could even add some fancy icons or similar stuff.

Apart from that:
I can't see any serious issues anymore. I'm for RTBC, and then probably fileing some more issues against it later on.

1. I'm OK with capitalizing titles but maybe it is best left as a seperate patch. We need to capitalize all menu items then.

2. 'expert mode' vs 'compact mode'. I prefer 'hide descriptions / show descriptions' but like 'compact mode' better than 'expert mode'.

3. Don't understand.

4. The module management block is a bad idea, IMO. Should be removed.

5. 'site themes' -> 'themes'. 'site' is redundant. 'look and feel' might be more friendly?

6. 'administration settings': vague link title. It doesn't mean anything. Do you mean 'administration _page_ settings'? If so, write 'administration page' or 'dashboard'.

Note that the number of items in the left and the right column are not always well balanced. The difference is sometimes more than one, meaning something is wrong with the algorithm to split the available items in two equal-length lists.

I think the next version of this patch is RTBC. We can refine things later on.

We should also prepare some 'module upgrade instructions' to help people upgrade their modules. It's kind of a sweeping change.

- I still like to change vague 'expert mode' thing into 'show/hide descriptions'. I did not saw any strong arguments against it

- Perhaps it's wise to commit almost-barebone html admin page (something like #75) and start new issue for CSS wizardy and experiments. Arguing over title capitalization seems well out of scope at this point. There are several more related issues like too big left-indent for descriptions, support for all the default themes etc. Let's go step-by-step?

- Both initial proposal and #75ish proposal take time to learn and retrain you motor memory, so I do not really know which is better in long-time usage. My arguments against pseudo-blocks was mostly technical. What others thing, how does the feel differs?

- I somewhat missed the point in "bumping-up" the most common tasks discussion. Is bumping up to #1 placement "user list" and "posts" is good idea or not? (following the example of "watchdog logs")

Committed to CVS HEAD! :)