[meta-issue] Additional categories admin/config
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | base system |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | IA, Usability |
Jump to:
As part of #546956: [meta-issue] Overhaul of Information Architecture we have identified the top-categories that can house 60/70% of the modules that will live in a Drupal install. However as we pointed out in that issue already, we need to create a few more categories to house 20/30% of the other modules - so that their is consistency in categorization.
For example, back in D6 - one could have a category "User Interface" , "User interface", "UI" ect. We want to create a sensible default category and go with "User Interface". Its important to note, that every category should be able to house a few modules - and not optimized or designed for just one module (this can be done by the module itself, if its truly that required).
More background :
http://www.d7ux.org/d7ux-information-architecture-a-detailed-view/
http://yoroy.com/nl/2009/reorganize-drupal-admin-items-within-d7ux-frame...
http://spreadsheets.google.com/pub?key=r3NqKYK4UMfelsw-YQsKxdA&single=tr...
The goal is to discuss and decide upon this additional categories, please be aware of our 3 week time-schedule.
Examples :
admin/config/management => Management
admin/config/user-interface => User Interface
admin/config/e-commerce => E-Commerce
#1
subscribing
#2
See http://drupal.org/project/usage for which modules are heavily used (but don't only look at those! :)
#3
Yes. To make any sense of this. You skip the TOP 20 of modules. Because those are very likely providing their own meta categories anyway, due to their popularity + amount of integration/add-on modules.
#4
@sun nah nah. The goal is that no module is allowed to provide his own meta category. I will personally file this as an UX bug if someone does.
This is the "free for all" that Webchick mentioned the other day we want to get rid of.
We should think of sufficient Categories to fit them all more or less in.
#5
This is not how Drupal works. It never worked that way, and I'm very sure that no one on this earth wants to have it work that way. Drupal is a modular and highly flexible system. If you want non-modular and unalterable top-down decisions, then you go install Joomla.
#6
#627048: Configuration page: User interface category
#645968: Configuration page: Workflow category
#7
After some discussion with Sun on IRC about the difficulties to put into reality the categories and get module authors to support the model:
One thought Mark Boulton had and I liked it was to keep the config page only to system settings. The links to all module settings could be on the module page. Given the fact that we now have the config link besides each module and will hopefully get the filter field in, it is much easier to find a module there than on the config page.
Personally I find the config page unscannable with descriptions on even only with core modules. It feeels pretty much the same as the old /admin dashboard.
Still the categories can be pursued, but the important part imho was that all modules belong under this top level menu item. (modules/config)
The categorization is a tough battle. If it goes well - config may be fine, but only with descriptions off. If not - the alternative I propose could be reconsidered.