Consolidate filter options in the UI when configuring a format

Here's a patch that makes the suggested changes from the summary. It also improves the Vertical Tabs integration for the default filters included with Filter module to provide some relevant information.

Video: http://screencast.com/t/LpkUnDjhme

Vertical tabs may only contain advanced options that the user may safely skip over and ignore entirely (assuming safe defaults).

The first vertical tab is always shown. That's where a user selects their filters, so no problem there. The second tab that is added (filter order), also has reasonable defaults. For many users, manipulating the filter order *causes problems*, and they would be better off if they left them at the defaults.

The other options for filters are already in vertical tabs. If they are absolutely "not skippable", then they should not be in tabs either with this logic. However they also have reasonable defaults, so having them in tabs is okay.

I don't see the argument of this increasing dangers actually being valid. There are no controls that are hidden that do not provide defaults.

Hm, yeah I realize this is a different use-case than Vertical Tabs that we have elsewhere in Drupal. We don't have a pattern of "it's okay to put stuff in the first tab because it's not hidden". But at the same time, we also don't have a pattern of making vertical tabs appear/disappear based on another part of the form anywhere else in Drupal.

Our use of Vertical Tabs is largely based on a general agreement within Drupal, but still with quite a bit of ambiguity. I don't think it's exactly written down anywhere other than stating it occasionally in issues (like this one). Ironically, these two issues show up earliest in Google for me:

sun: #1834472-4: Use vertical tabs on WYSIWYG profile form
quicksketch: #1144806: Nodewords' use of Vertical Tabs on settings page actually hinders usability

And here are a couple off-site references:
http://patternry.com/p=vertical-module-tabs/
http://www.slideshare.net/Bojhan/drupal-7-interface-pattern/21

There isn't any clear definition of whether the first tab (which is not hidden) gets any special consideration anywhere that I've seen. Since it is not hidden, I assume users would give it the same attention as visually similar elements, such as a fieldset which is uncollapsed, while remaining vertical tabs have a similar weight as to collapsed fieldsets. Though obviously vertical tabs provide more information via their summaries and are faster to cycle through (one click to switch from A to B instead of two clicks to collapse A and expand B).

Regarding the hiding of filter order, I still believe that default ordering is going to be safer *most of the time* than if an average user fiddles with their order themselves. You're right that there's no guarantee that filter order will be correct given the number of filters out there, but modules try their best to provide an order than makes sense by default given the task they are trying to perform.

For the most part (correct me if I'm wrong here), the filter whose position matters most is the "Limit allowed HTML tags" (or other sanitization filters that take its place). What if we moved this filter from being a normal filter to a sort of general "security phase" that had its own group of subfilters that always ran in a predictable weight? All other filters positioned above or below the security phase would have their weights adjusted based on the position of the security phase. Let's say we give this phase a weight of 0 by default, and any filters placed above it would be given negative weights. Any filters below it would get positive ones. That allows modules to very specifically choose whether or not they're going to introduce dangerous markup that needs to be sanitized before output. Thus, we end up with a result that the filter weight becomes more reliable and can therefor be relegated to a less prominent location on the page. Again, keeping in mind that many admins have no idea what order of filters is dangerous or not, it seems like if we can provide them with reliable defaults that discouraging them from making changes could result in more secure Drupal configurations.

Another bonus of consolidating the "security phase" into a single position would be moving duplicative filters into combined configuration. For example "Limit allowed HTML tags" is largely an alternative to "Display any HTML as plain text". It could combined into an option on the HTML filter to just say "What should be done with not-allowed tags". Providing no tags would result in the same effect as "Display any HTML as plain text".

Mostly trying to think of options here... this page is such a UX disaster (see original video) there has to be some way to clean it up.

Another pattern where we have "Weight + Enabled state" at the same time is the "Display fields" tab on entities... This would actually meet the requirements of:

1) Providing order and enabled state in a small area.
2) Provide summaries of the configuration.
3) Not use vertical tabs.

However I find that UI to be a terrible experience. There's a reason why you don't see many sites or libraries out there including the "Expandable configuration within a reorder-able table" pattern. ;)

@sun: Are you implying that the current form configuration is the best solution we have available, or that it's not worth changing? Clearly the single page of configuration is better than the 3 pages we had before, all with disconnected options and the "Configure" link going to the "Edit" tab in which you had to again click "Configure". That was just ridiculous. Despite the improvement from Drupal 6, I think we can make further improvements here.

Great, I'm glad to hear we've got the door open on options. I've got a half-dozen ideas on making filter-order more predictable, thus less dangerous. Assuming we could figure out a way to "be smarter than the user by default" (which I don't think is going to be difficult in this scenario), does putting filter order in a vertical tab seem acceptable?

I did a bunch more research into vertical tabs and how they're "supposed to be used", but the only other place that seems to discuss vertical tabs more than drupal.org is LukeW, who suggests that vertical tabs (or "finger tabs" as he calls them) are best used for situations where there are alternatives to each other. So the tabs are considered mutually exclusive options. That's clearly not how we're using them unfortunately, so I'm not sure if his analysis applies to us. He talks about finger tabs in this blog post and in his book. The book is copyrighted by this Flickr image summarizes the most important point that is relevant to us, which is using vertical tabs serves the important function of reducing the distance that the eyes have to travel to complete a section of the form. I think my patch here meets that same goal for at least individual filter configuration, though it probably causes a lot of eye movement as tabs are disappearing/appearing.

In no situation did I find that vertical tabs are intended to be used as "optional settings that may be skipped", and from the usability testing I watched in Baltimore, users who have not encountered a form previously tab through every vertical tab at least the first time they fill out form to see what options are present. I'm not sure where this idea originally came from and I don't think it's a bad rule to abide by in the interfaces we've created so far. However in this case I feel it provides a boost in usability. Provided we can find a way to make filter order safe by default, I don't think the original proposal should be taken off the table.

New issue to discuss making the filter order less dangerous by default: #1835188: Make configuration of text formats more secure by default

it detaches and splits the status and order controls into two independent operations

The status and order controls are already two independent operations:

Many site administrators have NO IDEA how to configure filter order. Assuming we can make filtering safe by default, putting the order in they way of administrators may cause more damage than good.

This is a great suggestion @kattekrab. Although I personally believe that filter order is better if users do not see them (stated several times in the above comments), consolidating the filter state and the order into a single tab seems like it should reduce clicks and increase discoverability. This essentially would use the same pattern we have for other reorderable lists, such as taxonomy terms or menu items. However in those places, the order is for aesthetic purposes, rather than enacting changes in functionality. I'd be worried users would assume the same thing here, which may be why enabled state and order are separately currently.

So in summary: I think @kattekrab's approach is both positive and negative. If it's more preferable to @sun then I'm happy to compromise on it. If the approach is equally disliked or the entire consolidation is still frowned upon, I personally would keep them separate still.

Possibly related to #1168246: Freedom For Fieldsets! Long Live The DETAILS., at some point this patch broke due to the new use of #type = 'details'. Here's a reroll. An update to my demo site (http://quicksketch.org/wysiwyg) should be up-to-date in the next hour or so, with all the latest core changes.

I'd still love to include this functionality. It significantly shortens the filter form and hides information that is peripheral to the task for which most users will be coming to this page. In the world of auto-configured filters based on your editor configuration, the filter settings become significantly less important. I think that moving the filter enable state near the filter settings also increases usability, since the user can see the settings appearing as they enable a filter.

Not sure if the current patch still applies, I'll let testbot have another go at it.

#24: filter_ui_rearrangement-1834682-24.patch queued for re-testing.

So: postponing until the CKEditor stuff is almost done.

The additional editor configuration on the text format configuration page makes this issue more important than it had been previously. But the overall changes are independent from CKEditor and Editor issues. This is just about consolidating options provided exclusively by Filter module, so no need to postpone.

I'll take another pass at updating this patch.