Posted by eigentor on December 3, 2007 at 12:12am
To make a start, I tried my luck with a working version. Since it was easier to do, I published it as Google Doc.
http://docs.google.com/Doc?id=dgzwvm6w_9hgp9w2
Beware, long load time because of big images!
The approach is deliberately ambitious. As I also write in the doc, we will cut down later anyway. I'm aiming at enticing other designers to try their luck. We need different approaches, compare and discuss.
In the end, the best ideas, if compatible, should be nailed down into the new Admin theme. So in the present situation, I dont see redundant work as a problem, since ideas will differ a lot for sure.
To make the mockups available also here, I have included them as attachments. But please read my musings in the doc. ;)
| Attachment | Size |
|---|---|
| Content-type-above-fold.jpg | 80.18 KB |
| Content type-2.jpg | 81.87 KB |
Comments
Woot! This a kick-arse
Woot! This a kick-arse start. I'd love to see this implemented as a contrib theme.
Bevan/
i love it!
i love it!
--
Drupal training in Scotland
Go Eigentor!
Feedback:
Here is an already completed
Here is an already completed admin theme. It's not like this mockup though; http://www.nerdliness.com/article/2007/12/02/drupal-admin-theme
Bevan/
Geales adjusted mockup
This is great: you shortened it even more by introducing three collapsibles that make a lot of sense. And even the idea with the status shown in collapsed state is incorporated. Great!
Also Wording a good idea. But in this case I would also replace the first words. Because "default options" and neither "default" sais ANYthing about what the checkboxes are about (why didn't I notice before?) It must be "Default publishing options" or Publishing default or something like this. If you check Drupal by correctness and preciseness of wordings - oh boy.
I'm sure the cellar is full of corpses.
Life is a process
Life is a journey, not a destination
Details
It's a detail, but...
When I saw you separated Core and Contrib config in the top menu, I initially thought it was a good idea. Now I'm leaning towards the opposite: does it really make sense? Is the difference relevant in an admin context? What if you have a contrib performance module, shouldn't it appear next to the core performance options?
I also wondered how this can be adapted to other admin pages. Can we find a way to easily use the columns idea anywhere?
On the IRC meeting I talked about having 3 "regions" so module developers could place parts of the admin elements where they want, like '#column' => '2', but I don't know if it's a good idea.
Options too long with many modules
The separation is mainly due to the enormous length of my... sorry of the options dropdown, especially with a lot of modules installed. It sometimes exceeds the viewport, especially with screens that have only 800px of height.
Making them as flat as in the default css is a bit hard to click for me.
So I thought of this solution. Sure: beginners wonder in which dropdown to find an option. But for that you get a shorter list which is more quick to search for a module.
Sure - the solution may be good, and may be bad. Better we discuss before I code!
Life is a process
Life is a journey, not a destination
The rule of seven
In psychology class, way back at university, I learned the rule of seven. This rule says: a human brain is capable of holding only a certain amount of unrelated items in short time memory. This amount is 7 +/- 2 (depends a bit on the stuff you're trying to remember).
This has led to my rule of thumb: any menu level should have less than 10 items. If a user tries to interpret a menu of say 15 items, once she arrives at number 15 she'll be thinking "what was number 1 again?" A menu of 15 should be split up in submenus.
Now have a look at /admin. Even a default Drupal install has 13 items under Site configuration. This already is too much. With a bunch of contrib modules this can grow completely out of hand.
So there you have it: one of my gripes with the Drupal admin page.
Going back to eigentor's enormous length of... the options dropdown. I think it should be cut into pieces ;-)
The hard school of life
+1 to gaele: I mostly try not to use more than 7 elements on one level especially in Menus because of this. Yet it is no dogma, some peole may be able to hold 6 or 8 or 5 or 9 items. But as an average, it should work.
The question that keeps me more busy is: can it be confusing that you may have to look quite often in both dropdowns because you the f**** cannot remember where your searched setting belongs. We are talking about usability: only trying out can tell.
I had a look at other admin forms.
What strikes me most: there are a lot of very short admin forms (compare: file system, input formats or image import.
But holding a largely useless design diploma ;) I won't be beaten that easily.
The three columns are a grid, and you gotta use it in a flexible way to ensure the CI. In these examples: file system or similar forms with only four or five fields, it would make sense to use a colspan of 2 (the first two). The last column could be used from time to time for an extra help or introductory text. Just as I said, try to see it as a CI layout or magazine layout: the concept has to be flexible enough to match the weirdest scenarios and still convey a sense of continuity (coherence, identity?).
In the case of larger tables like in input formats it makes rather sense to me to use all three columns for the table: full width.
This will be some work, and If you would be easily convinced, you were no longer my friends ;))). This is gonna be a lot of work. We will see. In the next week, I got some time off and will try to cover 4-5 scenarios and we will see what it's worth.
But I won't give without a fight. The concept thrills me because of its unusual approach. And if drupal were innovative in design as much as it is in structure (taking for granted that the usability boost, which depends largely on Javascript and the graying out of columns not in focus because otherwise it was confusing. is there) - whooee, imagine. Computer magazines citing drupal as employing new concepts in every way. And stating: after half an hour of use, you never wanna go back elsewhrere again!
Life is a process
Life is a journey, not a destination
Very nice
elv brings up a really good point (#comment-22100) about "Config Core" and "Config Contrib." The problem, I think, is that there isn't a standard way for contributed modules to integrate their settings pages and forms into the administration pages.
What I mean is, where do you put your module's settings page and menu items? Path auto, for example, is in "Administer -> Site configuration -> Pathauto" but it could just as well be found in "Administer -> Site building -> URL aliases -> Path auto". Login Security could have a separate "Administer -> User management -> Login Security" settings page but it hook_form_alters itself into "Administer -> User management -> User settings" instead. Sometimes it's actually a little difficult telling whether or not Login Security is even installed. In an ideal world, any module that inserts its settings into another module's settings page would respectfully put itself at the bottom of the page or in a clearly identifiable fieldset.
Neither approach here is wrong. I think that the first approach of creating separate settings pages and menu items is more common but currently I prefer the second; the fewer administration pages and menu items the better. I really like the mockups here, though, and see it offering an answer to a problem that's much too easy to overlook or ignore.
Like eigentor says (#comment-22105), after installing a few modules, installing a few more and then a few more... suddenly there are dozens of different settings pages and you have very similar-looking menu items (like the core "File uploads" and the contributed Upload path's "File upload paths"). It can also be potentially confusing. I often notice that I'm wondering things like, "Is Log Watcher in 'Administer -> Logs' or 'Administer -> Site configuration?'"
It's a mess. While I'm on the subject of messes, my major complaint with Drupal's administration interface is with the inconsistent use of terminology in paths and titles. (Administration pages like "URL aliases" uses "path" but not "aliases" in its path at admin/build/path, "Post settings" uses "node-settings", "Taxonomy" was changed to "Categories" in the transition from 4.7 to D5 but "taxonomy" was kept in the path, and so on -- and in none of these examples is the same term found in both the path and the title of the particular administration page.) Over time this stuff gets messier, more confusing, and harder to memorize. Considering the excellent reputation Drupal has with Clean URLs and SEO, the administration paths could use some redesign love and be at least a little more consistent.
Founder, CEO
http://www.larks.la
Founder, Lead Burrito Analyst
http://Droplabs.net
Organizer, Drupal Adventure Guide
http://DowntownDrupal.org
Changes in D6
christefano: yeah this is really a mess. There's been a very long topic about the modules page redesign, a part of the discussion was about accessing all modules settings from a unique place. The final patch doesn't implement this idea though.
My guess is both approaches can be used together: a central page with ALL settings, and settings for specific stuff where it makes sense to have them from a user/workflow standpoint. Multiple entry point for settings wouldn't bother me.
Regarding Categories/Taxonomy, last time I checked this issue there was a patch to switch back to "taxonomy" everywhere again. (here)
Regarding the third column...
I find the three column grid a little disorienting, as I don't really know where to look first. That's just my initial impression. Nothing is big enough to stand out, and I'd need to play with a live demo to tell if the color difference is enough to direct my eye upon page load.
Also, regarding the third column... I feel it is inappropriately labeled Workflow, but this goes back to the whole idea of Drupal's titles and naming conventions being confused in some areas. When you think about a node's workflow, you're thinking about what happens when it gets entered, published, moderated, removed, etc. Workflow shouldn't include something like a third party module setting to use a content type as a profile or whether or not a node can have an attachment. It seems instead like the third column is a catch-all container for content type options, one group of which contains the options for workflow. I saw something posted above about the use of the word setting/options, so I'm not really sure what the column should be named... really "Settings" just seems to fit. : ) (With then the option groups being Workflow, Nodeprofile, Comments, etc.)
Information architecture
This is about information architecture, or a lack thereof. Look at /admin:
A division between core and contrib config is certainly wrong. It doesn't really mean anything. The current admin menu structure, with often 20+ item lists, is also unworkable.
What is needed is:
So, who wants to work with me on this?
What do you do often, what do you do less often?
There are several axes of problems, some modules do one thing only (synonyms) and doesn't seem to have any admin settings. Others add lots of functionality (views, cck, location). Some modules let you turn on off functionality for node types in their own form, others attach that option to the content management -> content types.
Then there are things you do often, things you don't do often.
Guidelines are clearly needed for all of these.
Here are guidelines for one obvious problem. It won't shorten the admin form.
All modules should delegate per type settings to the content management -> content types creation/editing process.
All modules should provide global defaults for all per type settings in their own administration page.
But the question is how often do you need to change your pathauto settings? Each time you add a new nodetype. Do you remember to set that? Not always. Will pathauto clutter up the node type creation form? Probably, but "everyone" uses that module, and it is an important module.
Perhaps modules should be required to flag if they have functions that apply to per node type and let the green confirmation dialog link to all the administration pages that needs to be reviewed after a new node type has been created? Have you ever forgotten setting permissions for a new node type you just created?
Similar hooks could be required for modules which needs review after new roles have been added, new users etc. Then the forms don't have to be too long, and the admin can make an informed decision on what to do next after the action which was just completed!
gaele is asking a good question "What is the difference between content management, user management, site building and site configuration?" Also, is that the only way to look at the process? Is there other ways of categorizing the work process?