Preview: DotNetNuke Control Panel Module Grouping
After lingering in limbo for some time, I am pleased to be able to provide some screenshots of my upcoming DotNetNuke Module Container project. This project is expected to be released into beta sometime in mid-November, though I may circulate to a few interested parties before any public release.
The project is designed to address a common usability concern with the default DotNetNuke control panel, which is perhaps best illustrated pictorially:
A Scary DotNetNuke Menu with Many, Many Options
As users of the framework have surely noted, the list of modules available to an administrator is lengthy and highly-confounding. While experience mitigates this difficulty, it remains a significant challenge for new administrators to understand which module to select from this imposing list.
This project attempts to group this set of modules into manageable containers where each module is grouped by function (e.g. administrative modules, e-commerce modules). By way of example, a clean DotNetNuke 5.1.4 install with ALL core modules installed (and grouped into logical containers) would be reduced to a very understandable list:
A compact, minimized DotNetNuke control panel module list with groups by function. Note that the image above continues to utilize the default DotNetNuke control panel; the containers do not require any adjustment to that component.
After a container is selected and instantiated, a user is prompted to select from one of the modules contained therein:
Interactive selection of a module within a grouping after selecting the group from the control panel.
The selection process utilizes jQuery, minimizes the number of post-backs, and (in my opinion) greatly increases overall usability.
This module is expected to be released sometime in mid-to-late November for public consumption. A limited beta may be made available prior to this date, subject to interest.
Your feedback is appreciated. Does the lengthy DotNetNuke module list bother you? Would you (or your administrators) find a solution of the type outlined above useful? Please leave a comment and share your thoughts.
B
Some additional screenshots:
Selecting administrative modules configured in their own container
Screenshot illustrating the process of selecting modules to be part of a grouping
Chad
October 20, 2009 @ 9:39 am
Wow, this would be sweet! Anything like this would make deploying DNN to an end-user so much the easier!
Will Strohl
October 20, 2009 @ 9:40 am
This is EXACTLY the kind of innovation that the DNN core needs! 🙂
Cuong Dang
October 20, 2009 @ 9:58 am
this is an interesting approach, it will help to eliminate the long/confusing dropdown list of modules for site administrator. Great work!
Cuong Dang
October 20, 2009 @ 10:00 am
I’m interested in beta testing it. Also, you may want to join the experience team meeting sometimes as you will have many great inputs 🙂
Ralph Williams
October 20, 2009 @ 10:22 am
This looks great!
I am reminded of one other thing that I would love to see in the Control Panel, the option to select your container when you add you module to the page.
Michael Jackson
October 20, 2009 @ 10:47 am
Once you are up to speed I think it would make the already cumbersome UI less efficient. It really doesn’t add enough additional info. How does it attempt to categorize the modules? Can we add new categories? When the host adds new modules do they place them in categories? Modules are sometimes so multi faceted that it makes some hard to categorize. Can modules be in more than one category? That might help.
What I think would be more helpful is a help button next to each module that would display a synopsis of it’s capabilities and in that have a link to the docs / home page…
Brandon Haynes
October 20, 2009 @ 11:21 am
Hi Michael,
Fantastic feedback! I really appreciate your constructive input here.
Couple points that I’d like to clarify that might not have been apparent from the preview details above:
1. My primary motivation here was to abstract all the seldom-used “administrative” modules into a separate grouping. I find that I very rarely use these modules (but still need them from time to time) and wanted to de-clutter the module list accordingly. Just grouping these modules into their own container would, in my opinion, make the UI much more efficient:
Screenshot of the administrator modules grouped into their own container
2. All of the containers are created by an administrator; each portal may have as many (or as few) groupings as is necessary to optimize the user experience. Modules may be assigned to a grouping, multiple groupings, left on the original module drop-down, or any combination thereof:
Screenshot illustrating the process of assigning modules to a container
3. I agree that some modules are difficult to assign to one of the groupings I listed in the entry above; in my opinion, such modules would receive their own container (if they contained many controls that were individually instantiated) or omit being grouped entirely (as is the HTML module in the screenshot above). For example, many e-commerce modules have many components (product details, basket, checkout, et cetera). It seems reasonable to want to group these together.
4. Modules may be in zero, one, or multiple categories.
Otherwise I agree that, for experienced administrators, this would add some additional complexity to the process (in particular, it would add one additional post-back to the process). However, the 5.x permission process does allow this to be significantly mitigated with a solid set of deployment permissions (for example, it is facile to allow advanced users to see all modules on the list itself, while others see only the groupings).
B
David O'Leary
October 20, 2009 @ 11:44 am
I do like the idea of allowing hosts to categorize and sort modules. But from an interface standpoint, what I think would be even better would be to get rid of the drop down all together and instead use an intelligently auto-generated mega menu that lets the user see the modules description by hovering over the appropriate spot.
Ian Robinson
October 20, 2009 @ 11:53 am
Great idea and great work Brandon. The additional clarification in your previous comment is very helpful as well.
I think it’s important for everyone to remember that this (as with every extension for DotNetNuke) is just giving us (the community) more abilities and may not be necessary in every scenario (to say the least).
One of the primary drivers for using DNN is the ability to create a web site and hand it off to less technical content administrators. We all know this can be challenging, and we need to take steps to make it easier for as wide a range of administrators as possible.
As I see it – any additional abilities/options (such as this) that we can provide to the community to help make the task of enabling content admins of all skill levels is effectively bolstering a core piece of most DotNetNuke implementations.
In other words – keep up the good work. 🙂
Mitchel Sellers
October 20, 2009 @ 11:57 am
I have to say that from a UI perspective, this looks “flashy’ but honestly for most of my users, this would not be a desired effect. As at a minimum this adds one additional click and interface that must be touched to add content to a page. Lengthening the time to setup pages.
I can understand the desire to get “Administrative” and “Seldom used” modules off to a different location, but I’d prefer a toggle on the control panel, possibly persisted to the users profile, and then focus on making the list easier to navigate, such as using a list search extender from the Ajax Control Toolkit or something similar.
As it is, the most common complaint is that there are too many actions to setup a module on a page, and this adds one more step to that. However, I do think it is a very nice UI and in some cases, it does make things a bit more trivial, and allows you to handle modules that might not have the best names for users that are not as experienced with DNN.
Ian Robinson
October 20, 2009 @ 11:57 am
@David – It seems to be a key piece of Brandon’s implementation is integrating into the existing control panel (correct me if I’m wrong). Where do you see this mega menu being placed or how would it be integrated into a user’s site?
Ian Robinson
October 20, 2009 @ 12:01 pm
@Mitchel – I’m thinking that in the scenarios you are describing where users are complaining about clicks to get things done – this extension obviously wouldn’t make any sense. However, if your users are just trying to figure out HOW to get things done – this may very well make a lot of sense to use.
@Brandon – can you speak more to the intended audience or potential implementation scenarios that you are targeting? I know removing the clutter is a primary driver, but it might be helpful to spell out some other scenarios in detail.
Also, you it might be helpful, again, to remember that this seems to provide for a lot of configuration abilities – so if you wanted to only “break out” a certain few modules into categories you could do so. The example in Brandon’s screenshots may be a little extreme for a lot of implementations.
Brandon Haynes
October 20, 2009 @ 12:34 pm
@David I agree that the drop-down is an inherent limitation (that I have long-salivated to remedy); however, because it is part of the default control panel, it’s modification is out of scope here.
@Ian You are correct, my architectural constraints required that no changes be made to the default control panel or the core. While there are arguably better ways to improve “module addition” behavior (e.g. a flag on the control panel), changes to the control panel itself are specifically out-of-scope here (I do have a reason for imposing this limit). That said, much of what I have done could (and probably should) be included in an augmented control panel.
My primary motivations here were two-fold: first, to reduce the administrator-module clutter that exists in 5.x where the modules were elevated to first-class status. Second, to better-enable cases where the definition of multiple modules would be useful, but the framework behavior interferes with the resultant utility. For example, e-commerce packages often include several modules (details, catalog, basket, checkout, etc) that are rarely instantiated (often only during site creation); these must either be separate entries on the module list (the DotNetNuke store module consumes five entries) or instantiated en masse (via multiple definitions, a does the blog module). These entries interfere with usability, despite the fact that they’re very infrequently used. While unassigning the entries from the site is one solution, grouping them as I have outlined above seems even better.
Perhaps obviously, this approach is targeted at a novice administrator (in fact, anyone reading this blog entry is probably advanced well-beyond such an audience). I think even sophisticated administrators could benefit from having those modules that are used only on an infrequent basis removed from the list (how many of us have ever instantiated the “Site Wizard” module?) — here, the price of an extra click would seem to be an appropriate exchange, in my opinion.
Otherwise Ian is correct that my “everything-in-a-group” screenshot was perhaps a bit too draconian; I could easily see a happy balance of an administrator group, “advanced modules” group, and then everything else staying where it’s at. However, different audiences will have different needs — I know of several administrators who would benefit from having only a few things from which to choose (e.g. HTML, Announcements, and Forms and Lists).
@Mitchel Oddly enough, there’s only about 15 lines of UI-related javascript going on here; the bulk of the work really deals with the module definition manipulation. It’s great that jQuery allows for such efficient UI-niceties!
I really appreciate all the feedback from everyone involved!
B
Gifford Watkins
October 20, 2009 @ 2:05 pm
Well, I love it. I can see incorporating this into a default installation.
My issue with all modules available is giving clients (admins) more than they are expecting. I start every client off with one module; the text/HTML module. Then as they acclimate to that one module, I introduce more modules… once the admin gets the hang of adding pages/modules and editing.
The fact that all the admin modules are all now available would be great in cases where granular admin mod permissions are desired.
Regarding the actual UI. Perhaps consider something along the lines of the Settings for modules; just a little plus sign with a drop down with an interface similar to the polymorph module.
This module certainly opens up a can of worms; total mod availability vs. limited (and grouped) module availability. Good stuff !!
Greg Brown
October 21, 2009 @ 12:44 am
I think it greatly depends on who your admins are. If they are somewhat computer savy they would probably agree with Mitch – less clicks is better. But if they are like my soon-to-be admins they are barely computer literate. In this case it would be a GREAT feature.
I’d like to beta test it too Brandon.
Eoghan O'Neill
October 21, 2009 @ 6:06 am
Nice work Brandon. Although when i visited this page I expected your blog entry to have something to do with DNN skinning. To avoid this possible confusion I’d say you should give the project a title that doesn’t have the word ‘container’ in it.
Herb Benton
October 21, 2009 @ 11:45 am
I think this type of innovation is excellent! I would be interested in being a beta testor as well!
Great post!
Brandon Haynes
October 21, 2009 @ 12:16 pm
@Eoghan You’re completely right, and I have no idea how I managed to accidentally reused the reserved DotNetNuke term “containers.” I’ve updated the title accordingly.
delin
December 15, 2009 @ 12:13 pm
where can i dowload it? thanks
stephan schneider
January 5, 2010 @ 12:41 pm
looks really great! How is the status on this? Is there any Demo or beta version available?!
Stephan Schneider
March 17, 2010 @ 4:03 am
This looks realy great. Is this still a beta, or was it released. I could not find any way to test or download this. I would realy like to test and use this in future projekcts.
@Brandon: I’d like to beta test it too, maybe you can contact me
Brandon Haynes
May 15, 2010 @ 10:59 am
@Stephan: Unfortunately, I haven’t put out a release for this project yet. Shortly after prototyping it, I got word that the Ribbonbar control panel was in the works, and idled to make sure that it didn’t conflict and/or replace any of the functionality I had in mind. Seeing now that it does not, I will likely package up a release in the near future.
B