As part of working on implementing easier to use input formats in Drupal 7 (reaching to WYSIWYG sooner or later), I started with cutting through the clutter. A possible rule to follow to simplify the content editing user experience is to remove (hide) filter options when appropriate. How does this work in Drupal?
Drupal allows setting up multiple input formats, each with different filters. The filters have specific (possibly different) configuration in each input format. The default Drupal core options allow admins to restrict filter format access to certain roles, and there should be one format accessible to all roles, so if someone has content submission permissions, she can add content to the site in the default format at least.
Input format clutter
There comes the input format clutter. Many sites have multiple input formats. Least restricted formats are used for site pages, about boxes, blocks, commonly stuff produced by the administrator for. There might be a bbcode format for forums and comments, a wiki format for wiki pages, etc. Some roles have access to multiple input formats, and choosing the right one each time complicates their life. So several contributed modules emerged to solve this problem, hiding certain input formats or prioritizing them by setting the default intelligently depending on configured circumstances. I reviewed four modules in the hopes that we can get some of this functionality into Drupal 7.
The most simple module of all reviewed, it just saves the last used node editing format for each user id, and loads it back when editing new nodes. It has a limitation to only deal with nodes, so input formats used elsewhere (blocks, comments, etc) are not looked at. Also, if the user edits a bbcode formatted forum topic, his next static page submission will also default to bbcode, which might not be desired. So remembering input formats this way does not look like a desired core functionality to me.
Filters by node type
This is a bit more complicated, presenting a matrix with all the content types and input formats available on the site. Then the admin can decide on the input formats to be possible to use with each content type. The core system on the role based restrictions on top of this setting, so it is possible to set up wiki markup only wiki pages, bbcode only forums as well as full HTML static pages. This module eliminates the need to select input formats at all. Again, it is restricted by its limitation to only deal with content types, but this is the most common use case.
This module sets a more ambitious goal. Setting default input formats per user role, per content type. Because one user might have multiple roles on the site, the module also allows setting weights for these assignments. So if a user has two roles, and there are different default input formats set up for the two roles, the user gets the "lighter" input format (the input format with less weight set).
This module allows setting of default input formats per role with weights, regardless of node types. Yes, this is a much older module, which does a similar thing as the previous module, but it lacks the node type angle. On the other hand, it comes with a slightly more comprehensible UI (it still needs some docs to be understandable though). The weights are not configurable here, but there is one weight value for each role, so the result is effectively the same.
The Better Formats module
By far the most promising module to yet emerge in this battle for ease of textual-input-format selection, the Better Formats module is a really good looking attempt to replace at least three other non-compatible, yet needed modules; Filter Default, Default Filter, and Filter By Node Type. If it gets popular, it'll be a good solution to keep an eye on for inclusion into core.
What's core worthy for Drupal 7?
From the list of modules developed here, there is a clear need for better input format limits in Drupal 7 core, so admins can cut through the clutter and offer a simpler user interface for their users easily. A generic fixed list of input formats for all possible input fields does not really cut it.
What do you think? How should we approach this? How can we provide a comprehensible user interface to limit input formats? What level of limitations are needed for core?
In the meantime, to bootstrap configurability for input formats, I submitted weight and drag and drop support for the input formats themselfs, which should allow admins to customize the order of input formats to their preference. Check out the issue: http://drupal.org/node/222183
Ps. Note that all the above modules got the "filter" name wrong. Filters are the individual components of input formats, and all above modules deal with input formats not filters. This might be misleading for some.