Better UI for hierarchical prioritization form

I have been thinking of a solution with two parts:

In the top half ("enabled"), a tabledrag thing like the blocks.
The other half would be a static list with checkboxes or dropdowns or buttons, having all the "disabled" and "inherit" rules.
Clicking "enable" or "override" in one of these rules would make it appear in the tabledrag.

The idea is, what is in "inherit" or "disabled" does not need to be sorted. Instead, these items should be displayed in hierarchical order.
The same conceptual problem exists in the blocks configuration, but I think it does not matter as much, because there is no hierarchical order of blocks, and there are not as many variations of the same thing.

What I would need is a tabledrag that allows to add and remove items. I know this is possible (did it in multicrud module), but a bit tricky..

Thanks, this would be great!
So far I hesitated to waste time on a solution that I was not sure about, when everything worked so fine for me with the text-only form :)

I am going to produce a demo maybe for tonight.

The ugliest demo in the world..
http://static.dqxtech.net/crumbs-admin/

Not implemented in the demo:
- If you switch one of the below things to "enabled", it should appear in the drag interface at the top.
- Better visualization of the hierarchy of rules. (e.g. with nested list style)
- Description area in the right column, reacting on row hover.
- We may use buttons or clickable icons (enable, disable, use default) instead of the select options.

On the Drupal Camp Gent 2012 I gave a session on Crumbs, where I also mentioned the issue of the configuration form feeling not intuitive for some users.

The feedback was that the draft in #5 is going in a good direction, while pure tabledrag would feel clunky and not as nice.

Of course, I do not deny your

In this state it is ergonomically worst than the textarea...

---------

As a design guideline, we do not want to let the user make choices that have no meaning.
E.g.,

• Sorting stuff in the "disabled" or "inherit" section has no meaning.
• Hierarchical sorting ("tree tabledrag") in the "enabled" section would have no meaning.

The other design problem is that all "disabled" items visible at all time.

- I do not understand why you have to differentiate "disabled" and "disabled by default". Reducing this to "disabled" would clarify the interface.

I want/have to distinguish user choice from programmer choice.

Things in "disabled by default" are sitting there because the programmer said so. If you uninstall and reinstall Crumbs, the rule will still sit in the "disabled by default" section. Also, if a new rule enters the game, where the programmer said it should be disabled by default, it will start in this section. If the programmer changes the setting in code, the rule will move back to "inherit".

If a rule is sitting in "disabled", that means the user chose to not have it enabled. If you uninstall and reinstall Crumbs, the setting will be gone. If the programmer changes the default setting, it will have no effect, because it was an explicit user choice.

- I also think that "inherit" section could be shown in an other way. Using nested elements the criteria inheritance and actual status would be clearer. For example you could have a box titled "comment" containing 3 smaller sortable boxes "comment", "reply" and "skip". Each of these contains a set of icons allowing to choose between "Enabled", "Disabled" or "Inherit" except for the main one which do not have "Inherit" choice (it would be non sense). You may use a color code to indicate when a criteria is active or not to ease inheritance understanding.

Not that quick :)
- comment.reply, comment.skip and comment.comment can be sorted not just within the comment box, but also outside of it.
- setting comment.* to "inherit" does make a lot of sense, because it would inherit its weight from the global * wildcard thing. In fact, that is what all plugins do by default.

What if rules were all disabled by default ?
I think you may weight the pros and cons of having this distinction.

If you install a new module, e.g. Organic groups, then I want that those breadcrumb rules are automatically enabled, because they give you exactly the breadcrumbs that you expect.

However, some rules should only be enabled if the administrator chooses so, because either their effect may be undesired, or because they have a painful performance penalty.

Another solution would be to look at themes. While theme settings are not saved by the user, they are taken from the theme info file. If it changes, settings changes too (without considering drupal's internal cache system). Once saved by the user, even if the info file changes the theme settings are stuck in the database.

This is sometimes a bad thing. In many systems in Drupal, is hard for a user to see if something is overridden, or if it is just the default behavior. I always thought this distinction is useful to clarify how things work under the hood.

This wildcard would not be necessary with a clear and usable sortable list. User could directly drag his selection on top of the list.

The wildcard also specifies the place where new rules enter the board. I consider it useful :) although, there could be other ways to do this ..

Maybe I am just mad insisting on my point :)

There is one difference with the blocks interface:
In the blocks interface, whatever is sitting in "disabled" is actually disabled.
In Crumbs, we do have the "inherit" section, where the status of each rule depends on the parent wildcard rule.

It would be very sweet if the interface could visualize this somehow.
I am aware the current textarea-based interface does not really visualize the connection. But at least it was cheap to build :)
(probably the blocks-style tabledrag is also cheap to build, so..)

I finally agree that #14 is the solution.
Even after playing around with yet another fancy solution locally, #14 still appears to be the best.

My rationale so far had been that we want to visualize the parent/child structure.
I no longer think this is necessary.

We need a patch for #14 !

I know I should rather be working on a patch implementing #14.

Nevertheless, here is one funky experiment I made, check out this branch:
http://drupalcode.org/project/crumbs.git/shortlog/refs/heads/7.x-1.x-adm...

I produced this a while ago, and want to share it because.. i don't want it to rot.
Still, #14 is the way to go.

Patch: Admin form based on tabledrag.
Branch: http://drupalcode.org/project/crumbs.git/tree/refs/heads/7.x-1.x-admin-t...

Happy testing!

Grm, did I not post a patch??

Timing:
I want to make at least one more stable release from the current -dev, before I merge the tabledrag in.

Notes:
- "Inherit" section is merged with "Disabled by default" section, it is now called "Inherit / automatic", indicating that the user has not made an explicit choice for these plugins. We can still find other ways to visualize.
- Probably it only works with js enabled, due to the way I use the tabledrag. We might change this, but for now I just want something basic to work with.
- We are now using system_settings_form().
- Display options moved to a separate config page, admin/structure/crumbs/display.

Left to do:
- Improve descriptions for plugins
- Show which plugins are "inherit" and which are "disabled by default".
- For "inherit" plugins, show which weight / status they inherit from the parent plugin.

Optional / future:
- Buttons to push plugins into another section (enabled, disabled, inherit)
- Optional submodule "crumbs_labs" to bring back the text-based config, and maybe also the exotic thingie from #19. This should be easily possible thanks to the hook_element_info() approach.

I hate all those procedural callbacks.
Here is an attempt to move the stuff into objects.
- element types 'crumbs_weights_tabledrag' and 'crumbs_weights_textual' (not implemented)
- one class per element type
- one class instance per element instance
- reduce the form-related code in crumbs.module, leaving only some generic stuff.

Please test the 7.x-2.x
(note: there is also a crumbs_labs submodule which gives you the textual form back)

Which browser?

Weird. It doesn't happen on my Chromium.

Probably the theme. I use Rubik atm. Will try with Seven later.

Ha.. got it :)
We could hide the asterisk with CSS.
I'm a little too lazy to figure this out with JS ...
(CSS can hide the asterisk both on rows and on the warning message at the top)

Follow-up: #1961858: More useful information on crumbs tabledrag form.

We have a working 7.x-2.x, but we need some fine-tuning on the design.

#25 / #27
In the most recent version, the key is formatted with <code> tags, and appended by a space. This way the drag asterisk should be easier to distinguish from the wildcard asterisk on most themes.

Do you think this is enough? The drag asterisk has its benefits after all..

Grmmm
I am working on a big site now, and it turns out the tabledrag becomes really unpractical.
You need to scroll a lot, and you need to drag very far.
And if you don't know what to look for, you are doomed.

What's the benefit of dragging stuff to different sections?

This is what everyone has been asking for..

If the plugins are just listed in alphabetical order with a dropdown offering numeric priorities, "disable", and "inherit"

There is a crazy proof-of-concept implementation in the crumbs_labs module, under admin/structure/crumbs/weights/expansible.
Mayyyybe the dropdown (select) would be easier than the graphics..

If we actually do a weights select dropdown, then the list of options should be updated whenever another plugin key is activated..
E.g. if only 1 plugin key is enabled, you only have one weight option on that plugin key, and two weight options on every other plugin key.
If 10 plugins are enabled, you have 10 weight options on the explicitly enabled plugin keys, and 11 weight options on the plugin keys that are currently on "inherit".

simplytest.me fails to apply the patch.. any idea why?

After wget:
If I apply it, it says "unrecognized input". If I "less" it, it tells me it's a binary.

The browser seems to have no problem displaying the patch. So, I copied into a text file, which applies just fine, and I am re-uploading it here.

Tried, it works!
(I did not submit, atm I am more interested in the look & feel)

The downside is you have to scroll a lot to see all plugin keys with an explicit weight.

I think the solution is a collapse/expand tree, where those plugin keys with explicit user-specified weights are always shown, but those with "inherit" are shown only if the line is expanded.

We could use the collapse/expand mechanic from the "expansible" thingie.
If you run this with javascript disabled, you will see it is not that different from your "dropdown" version. Only with text fields instead of dropdowns.

I don't know if you dare to touch the javascript stuff. I could give it a shot myself.
We want to keep the collapse/expand, but not the psychedelic graphical stuff.

And probably a good idea to come to a decision about default weights:
#2074473: Improve handling of default weights for plugin keys.

DrupalCon is coming, and this is one of the top issues to discuss.
#2094933: Crumbs BoF/meeting on DrupalCon Prague 2013?

Link to duplicate

I made something new. But I need help with the design of the buttons.

I would like to share this on jsfiddle or sth, but don't know an easy way to export a website to jsfiddle with all the resources (css, js).
http://stackoverflow.com/questions/23039039/how-to-export-a-website-to-j...

Features of the new UI in #45:
- Tabledrag area for explicitly enabled rules. Currently at the bottom, but I consider to put it into a modal/popup dialog.
- TreeTable to visualize the hierarchy, where you can switch the status of rules (inherit, disable, enable), but not the weight.
- Rows/groups in the tree table are expansible, and the expand/collapse is animated.
- Live synchronization between the two areas.
- "Focus group": You click on any row, and it will highlight all other rows that inherit from the same parent. Again, this is synced between the tabledrag and the treetable widget. If the group is enabled, it will show up green if focused. If it is disabled, it will show up red if focused.

The challenge I think is the design of the Inherit/On/Off buttons in the tree table.

Here is a tag to play with:
https://github.com/donquixote/drupal-crumbs/tree/1404018-48-crumbs-ui

Thanks for the feedback so far!

https://piratenpad.de/p/crumbs-ui

New approach here:
#2462377: Plugin weights UI, part II