Posted by Merlin on Thu Jun 29, 2006 8:54 am.
It was brought to my attention that my previous article needed screenshots. I could edit the previous article, but I don't think most people would see them, so instead, we get this blog post addendum.
Admin page -- this is the top level admin page.
alternadmin-ss3.png
System settings page -- this page is just the normal system settings page with the fieldsets replaced by tabs.
alternadmin-ss2.png
Modules page -- significant changes here. Note the links, and that active modules are grouped together for easier administration.
alternadmin-ss1.png
Thumbs up
Thumbs up to changing the Drupal interface to match mockups for good! I think that's the proper way to set it up rather than what we at the moment.
Rock!! Earl superb job, that
Rock!! Earl superb job, that certainly makes a whole lot more sense. I'm all for getting this into core so let me know if you need help with it. I also think we could tie in the proposed JQuery for core as well to provide some nifty effects to power this interface (item #3 on the list is to implement a few effects throughout core).
jQuery
From my perspective, Having tabs as a High Priority would be extremely useful to this effort.
I may have some time on Monday and I'm going to try to put forth the first wave of the patch which creates an overall admin page and implements something close to the hook I talked about in my previous article. That's the first step.
The second step will be to add stuff to the modules page, prior to the tabs.
The third step will likely be tabs.
After that, I also have an idea that is good for both the blocks and access control page.
Picture this:
granted permissions all permissions +---------------------+ +---------------------+ ->anonymous user<- | access content | | block module | authenticated user | access comments | [Remove] | administer blocks | some other role | post comments | [Add]| etc | | | ..... | | +---------------------+ So what you've got is, essentially, the two list boxes. On the left, the box contains all current permissions for the selected role. Permissions that are unsaved are marked somehow to give the user a visual understanding that these will be added when you click save. On the right, all permissions in a little scrolly box. Not sure how to make this degrade gracefully. That's possibly an issue.Even better than I imagined
Really nice, Earl. Really really nice.
Grouping?
I'm curious how you are grouping these items (in screen shot one)? I assume you just set up some categories and dropped the modules in.
What about grouping by the taxonomy term(s) on drupal.org? That might be an easy way to add new modules to the system. If we can agree on a project taxonomy already, that might make it easier to agree on these items. The difficulty would be with the meta-data. There's already a lot of contention. I would advocate for an automatically included .category file (like the project modules does with the license). This might not help people using cvs, but it would help the majority of users who download their packages from drupal.org
-M
tabs -vs- fieldsets
I really like the idea of tabs -vs- fieldsets. fieldsets are pretty clumsy IMHO. every time you open or close one, you may end up losing your spot on the page and then have to scroll back to it. annoying.
Personally, I'd like to see all fieldsets in Drupal replaced with tabs :)
Looks very nice Earl.
The categories are
The categories are determined by the directory the module exists in; it's so that multiple modules in the same package can be together so they can be enabled/disabled together. This is primarily for module packages like ecommerce and CCK that suffer *greatly* because it's hard to tell what package they belong to.
It might be nice to pick some categories instead, I suppose. That's a fairly large task, though. And may not actually end up helping the real problem.
horizontal&vertically expanding nav + tabs + bradcrumb +JS
looking to your draft images it looks really great, with tabs administration become more clear, easy to understand ,sort and manage however growing (thats a +) and consequence complexity (thats -) of the with tier, level, cataregisation of the sections and sub sections (ie taxonomy management, permission management is seems to complicate -as horizontally expansion of tabs goes too wide etc.
Mark has pointed the same issue with a solution and Merlin came up with JQuery solution thrown into -JQuery item sorting would bring a big ease imho- The perfect solution seems match drop down horizontal expanding nav on top level + tabs under it + bradcrumb + and JS drag and drop, expand, sort -a mix and match to an optimum result for the need i presume
i was looking to the www.opensourcecms.com demo's they all come different (different needs different solutions) yet similar mix and match of dropdown menu's + tabs even some js to try to find a solution for their problem -some similar if Drupal controlpanel.module Civic's administration.module + tabs mashed up together
http://demo.opensourcecms.com/plume/
http://demo.opensourcecms.com/cms/
http://demo.opensourcecms.com/jaws/
http://demo.opensourcecms.com/modx/
http://demo.opensourcecms.com/toendacms/
user:Admin or admin -sometimes case sensitive
pass:demo
apology -missed some lines and typo bit...
at the first paragraph should read
........however growing popularity and the with the contributions (thats a plus+) and its consequence -more complexity (thats a minus -) of/to DRUPAL. Also administration solution needs to be open to further expasion -kind of future proof' of the with tier, level, catagorisation of the sections and sub sections (ie taxonomy management, permission management etc. is seems to complicate -as horizontally expansion of tabs goes too wide etc.
........
- i could not re-edit my post
Modules page mockup
I feel the modules page is now more confusing, not less. Also, is there a reason why individual modules (event, na jtools) etc are given their own tabs? That seems to create a lot of clutter, in my opinion.
I have no usability experience, but as an admin, I visit the modules page mainly to enable or disable modules. I feel just two tabs would do:
The enabled modules could be the default view. When I add a module, I now know I need to visit the disabled modules page to enable them instead of hunting around the module list in the current module page implementation.
I wonder if having an exposed filter called, say, 'View modules by type' with fields for 'drupal core modules', 'contrib modules' and 'custom modules' would be a better way for showing the separation between module types instead of presenting them as tabs and cluttering the interface. When a field is chosen, it would display a page listing those specific modules. I don't know where to place this exposed filter or even whether mixing tabs and filters is a good idea.
Showing the number of enabled modules is a nice touch, as are the links to module settings and help pages.
Alternative
How about default drupal tabs called 'list' and 'type'? When you click on 'list', you would have sub-links called 'enabled modules' and 'disabled modules' and when you click 'type', you would have links called 'core modules, 'contributed modules' and 'custom modules', each with pages displaying the relevant modules. The default view at admin/modules would be the 'enabled modules' page.
Next to each module you can put in the links to 'settings' and 'help' and may be 'version number' that pulls in the $id similar to Robert Douglass' module.
The category module uses this kind of administration interface and it really makes things really simple and uncomplicated.
The grouping is really,
The grouping is really, really, really amazingly necessary.
To see why: Set up a test installation of Drupal.
Grab: CCK, ecommerce, event and og.
Now, try to enable CCK. =)
Comments
I like screenshot #1.
I like screenshot #2, however, it doesn't address an important problem. That is, there are other settings under ?q=admin/settings. They can only be accessed from the navigation menu. I think we need to treat them equally and it's a bigger problem than the 'tabs vs fieldset' one.
I'm not sure what to think of screenshot #3. Why do people insist on doing multi-module-file modules? I've always advised them not to. Now, they are faced with the drawbacks, and they want us to work around the problems they created. I think this is a fundamental problem, and maybe one that needs to be fixed using meta-data files instead.
I'd like us to proceed with #1 and #2, and put #3 on hold for a little longer. We might be able to come up with different (and better) solutions once we moved modules to their own directories. Looking forward to see the first patches. Rock on, Earl.
Large Module Packages
I think for #2, when we figure out the solution to #3, the links below settings will work themselves out. I.e, my answer is "they shouldn't be beneath settings so much, but instead they should be accessible from the modules page".
To answer multi-file modules:
1) Drupal's design is very modular.
2) Some modules are very large.
3) In the spirit of modularization, some modules modularize themselves as well. With ecommerce, it would be completely unwieldy to have all of that in a single module. Different ecommerce installations will have different needs. So it makes a lot of sense that something like ecommerce will break itself up into the components, allowing an administrator to pick and choose the ecommerce components necessary for their particular version. Putting them all into the same module package makes sense; if they were distributed separately, it would be very difficult to find the components. Remember, right now one of the biggest problems people have with Drupal is finding things.
4) It's simply part of CCK's design. Each field module takes advantage of Drupal's hook system. They must be modules.
5) At this point, Views is now a 4 module package; there's the core Views module, but there are also modules that include optional functionality. One of these modules is the UI. It would not be practical to distribute this functionality separately (can you imagine downloading Views, not getting the UI, and having to download a second module to even use it?) but having the ability to remove the UI from a running system that doesn't need to change Views around is actually valuable. Why load that 1500 lines of code in daily use? And the theming wizard? It's a useful tidbit but it doesn't need to be in the core views.module -- but distributing it separately would make it difficult to find. Those who need it most would be the least likely to get it.
Personally, I think multi-module packages are a good thing for Drupal. These packages, as long as they are properly maintained and continue to grow, will be some of the premier uses of Drupal. ecommerce, in particular, is a very important aspect to certain types of websites, and there's a lot of money there. CCK will theoretically be folded into core...at which point, we're going to need some kind of a solution for identifying CCK modules (or whatever it's called once it gets into core) and grouping them together. Right now, it's a nightmare to pick out which modules represent field types. Grouping them by module distribution is the path of least resistance in the sense that it works and it solves the immediate problem, but it does leave this particular future problem.
I hope to work on #1 today.
Drupal menu tabs or CSS/JS tabs?
I also like the look of the mockups- the settings page looks much more navigable that way!
Are the tabs you're using the Drupal-type menu local task tabs, or CSS/JS tabs like:
http://phrogz.net/JS/Tabtastic
http://www.barelyfitz.com/projects/tabber/
They are JS tabs; the code
They are JS tabs; the code is taken from the tabs in the jstools module, though it actually just implemented them directly.
+4 for sorting modules
There's four people using Drupal at my workplace and all of us agree that modules need to be sorted... I have experienced ecommerce, views, category and cck all being installed and it's not pretty. Here are a few characteristics of my ideal system:
Hopefully this gives people a few ideas. I like the direction that the admin overhaul is going.
Rick
Dependencies Tab
I second the comments about the need for related packages of modules -- many of us have server constraints and can't afford to load in anything we don't really need. The modularity of these package groups saves the day. I would hate to not be able to use any part of Organic Groups because I don't have the resources to load every OG module on my system when I don't even need all of them.
For the modules admin page I really like seeing all the enabled modules together on one page, so I definitely think that tab is necessary.
I totally agree some way of grouping packed modules is needed, but having several tabs for specific groups is going to break down quickly -- which groups 'justify' a tab? What about modules with multiple dependencies, where do they get listed?
My thought is that another tab would be a 'dependent modules' tab where you would see a list of all modules that have dependencies along with sublists of dependent on and required by relationships. That would help you easily see which related modules are enabled and disabled (maybe going back to the collapsible fieldsets on that page for each of those groupings). Some modules would be listed in more than one grouping, if appropriate.
That should be flexible enough to allow for any number of module packages and dependencies and still only take up one tab. I'm thinking of something like the PEAR package installer system where you scroll through the list of packages, and each one clearly indicates dependencies (and prevents you from installing a package with dependencies if the required packages are not installed). That makes you do too much scrolling, though. I'd rather have things summarized neatly on one page.
Also, if we have the dependency data available (I assume this is getting into the meta data that has been discussed) what about a place to display error messages about dependency problems. If you use collapsible fieldsets, you could force open any groups with dependencies problems and highlight an error message. (OK maybe I'm getting carried away here...)
Anyway, love the way this is heading Earl, nice job!
That might be
That might be an easy way to add new modules to the system. If we can agree on a project taxonomy already, that might make it easier to agree on these items. The difficulty would be with the meta-data. There's already a lot of contention. I would advocate for an automatically included .category file (like the project modules does with the license).
What eventually got worked
What eventually got worked out is that modules in Drupal 5 will have a .info file, and in the .info file there is a 'package' designator.
Post new comment