Replace collapsible-fieldsets with Summaries

I think the Calendar icon in OS X Leopard shows the real date now.

Regarding the "summaries" idea, I agree the main problem is that it has to be implemented in modules. It can't imagine a way to automate this.

Thanks for starting this thread.

There was some discussion after the Bay Area Drupal Camp on this, specifically this comment here that I made showing how Joomla! uses an accordian-like block that contains the information.

Another point that I made is that there is a lot of screen space available in the block section and if the header was shrunken in the admin theme.
But the whole thread is worth reading through.

This: http://lists.drupal.org/pipermail/development/2007-November/027327.html is NOT the way to go.
Collapsible fieldsets inside collapsible fieldsets. Yuck.

subscribing

This would be a worthy effort. I'd like to point out that I started doing something similar (albeit imperfectly) with Ubercart. Configuring a store is so complex that our forms could be unwieldy. I introduced settings overview pages where you can view a summary of settings and click on a panel if you want to go to its form page to adjust any of the settings. The difficulty was of course making sure that as settings got added to the form, a corresponding line was added to the overview page.

Proposal: If you're going w/ a single line of text, you should use the Forms API. Add a key to every element array that will handle its setting preview line. This will be fairly simple for most things. For more complex needs, you could simply allow this to be a function instead that gets called and returns the preview string. Putting this in the form itself will help module developers comply, and it will also allow you to use hook_form_alter() during development to start dropping these in. If you put out something usable in the next few months, I'd be happy to try and support it w/ Ubercart.

  // Small code example; key names should not be considered my official recommendation... just placeholders.
  $form['some_select'] = array(
    '#type' => 'select',
    '#title' => t('Your choice'),
    '#options' => drupal_map_assoc(array('red', 'green', 'blue')),
    '#default_value' => 'red',

    // The basic key to either set the title of a fieldset or add to a settings summary page.
    '#preview' => t('Your choice is !choice.', array('!choice' => variable_get('some_select', 'red'))),

    // Alternately, if this were more complex allow...  Do not allow override of #preview?
    '#preview callback' => 'some_select_func',
  );

This is just a quick idea... I'd be happy to chat more about whether or not this is feasible or a way forward.

See also http://drupal.org/project/util:

"There is also a counter for each fieldset that numbers every module in that group and reports on how many are enabled. Example: Core - optional [9] of [23]"

@12 This is something I have also been thinking about, and I believe has been discussed or mentioned in the Usability group. I agree that after enabling a module, the user's attention needs to be focused on; permissions for those modules, settings for those modules, and maybe help for those modules.

subscribing.

This is definately a good idea. I suggest creating a new form element (i can't think of a better name than summary) and slowly converting existing fieldsets to summaries.

This isn't the full solution to the issue here, but I believe it's a good start in the right direction. I'm using hook_form_alter() to add #summary keys to various form element arrays. Then, I have at the moment a function that will build a summary for an entire form (drupal_get_form_summary()). The same code/logic will be used to create a summary for a single fieldset based on its #summary (or #summary_callback return) value.

I've borrowed Bevan's code from a mock-up for the node edit forms and applied it instead to the page admin/settings. What if that looked like the following? (HTML put into a static page but originally created by the attached module.)

http://www.bywombats.com/drupal6/summaries-demo

You'll see that I've only added summary data to the admin theme and clean URLs settings (shortest ones!). For any given menu item, you can double click its nav item or content fieldset or use the edit link to go to the actual form page. Links, titles, etc. were extracted from the menu array generated by system_admin_menu_block(), and I had to get around D6's new automatic inclusion system by keying some forms to their include files and including them when building their summaries.

The code isn't perfect for every use case yet, but I'm interested in feedback at this stage in the game before I pursue this solution further.

I think this is worthwhile venture. I'm not so sure about the fade effect but thats minor.

Sure thing. You think it should just pop between summaries w/ no intermediate effect?

If so, that should be an easy tweak. (EDIT: Done, and I agree... I like it better.)

Very cool. I think the original idea here was to use summaries instead of fieldset titles/legends, which is more difficult, but possibly more useful. I can't think of a use case where this type of interface would be useful.

Aye, it's mostly proof of concept, but the underlying code that builds the summaries will be used to extract information for fieldsets and alter their display.

I'm not convinced simply replacing the fieldset title is the best thing to do. I envision rather a description class text that appears either under it or perhaps displays on mouseover (lightweight tooltip?) containing the summary data. People get used to fieldset names, and having them dynamically change would at least screw with my mind and probably people less familiar. It's also helpful when doing support, tutorials, etc. to say, "Click on the Publishing options fieldset" to find those settings instead of trying to guess at a summary.

Re: this interface, it is of questionable merit on the core Drupal settings forms. While it may not benefit power users, for the newbie coming to Drupal I think it'll be quite helpful. Furthermore, it's a huge bonus to Ubercart that we provide settings summaries for admin trying to find a particular setting they need to adjust. People unfamiliar w/ what's in each form can also view the settings at a glance to even see what's available. (How many times have I heard people wonder at aggregating CSS files?)

I'll press ahead and post a second demo when I have fieldset summaries getting added to forms, and I'm open to suggestions for implementing the display of those.

Just to note that if you haven't seen the Views 2 UI yet, it's got summaries working very effectively in there.

Hadn't seen that. Will have to check it out.

People get used to fieldset names, and having them dynamically change would at least screw with my mind and probably people less familiar. It's also helpful when doing support, tutorials, etc. to say, "Click on the Publishing options fieldset" to find those settings instead of trying to guess at a summary.

I agree.

subscribing

Maybe not confusing when it would have a format like:

Publishing: published, sticky
or
Publishing: published, promoted

I think there should at least one static keyword, preferably the first word in the summary that may function as the label for a fieldset.
Again, have a look at the views 2 UI, that's how it's done there, seems to work.

Re: Views 2 UI. To be honest, I just tried it out yesterday evening and found it harder to use than the existing UI. Part of that is probably familiarity, but part of it is also the truncated field names (and some other things related to the placement and functionality of AHAH added elements that will probably be ironed out). For example, the first two basic settings are "Name" and "Title." Without the description text or a little more info, I couldn't tell which was used where. I think Views 2 would be well served by tooltips, but I digress... I'm just not sure that's a very newbie, user friendly solution for forms in general.

rszrama: this is valuable feedback! Please add your comment here:
http://groups.drupal.org/node/8429

@gaele in #9:

I came up with this idea for the Utility module, and I was happy to see it implemented by litwol and dmitrig. Unfortunately, it was yanked from the current release of Util, but the code still exists somewhere in the CVS system.

What if we could expand on this idea core-wide? Dynamic fieldset titles? "Core - optional [9] of [23] enabled" only appears in the admin/build/modules page right now, but if this concept could be patched into all fieldsets on a node/edit page, then the collapsed Comments fieldset would read:

Comments [currently set to read/write]

And the Pathauto fieldset would be titled:

Pathauto [currently set to automatic]

I believe this concept is so easy to implement, and so non-impactful on a current release candidate, that I'll bet it could even be rolled into Drupal 6.1! Think about it. It doesn't change any functionality, nor does it add or remove anything that users depend on for their day to day admin tasks. Nobody would have to re-learn the Drupal admin interface either.

About the only way this could be a bad thing is if a language translation had to be made for every site that upgraded from 6.0 to 6.1, but even still, it'd be easy enough to do, since all the output would already be wrapped in t().

Everybody, please sound off. If this idea has merit, I will be more than happy to mentor a DROP task for this. It's an easy way to gain a more usable node/edit form *right now*.

Hi Senpai,

- Summaries should be really summaries, i.e. easily scanable, so:

Comments [read/write]
Pathauto [automatic]

- Each field is different. Some are complicated. E.g. how would you summarize the menu settings of a node? But that should not withhold us to start.

I think #29 is a good plan.

Menu settings for a node:
"no menu item"
"in menu: [menu-name]"

Some fieldsets that's going to be hard, but just about everything has either an unset or default setting, so you could say "not set" "default" "custom".

@gaele in #31:
Each fieldset's legend is comprehend-able right now for the average user because it states, in somewhat generic terms, what the fieldset contains. If we begin tossing [read/write] "tags" at the end of these legend strings, we run the risk of alienating all site admins who don't implicitly know what the three settings of comments-per-this-node are. Observe:

Comments [read/write]

To me, that looks like "Comments are set to read & write.", but to a budding site admin, it'll mean, "I don't wanna read or write comments right now, so I'd better not click that one."

I think we should attempt to explain what the settings are; being as brief as possible of course. This is just an intermediary step towards getting rid of the node fieldset altogether, but if the process of helping, I'd hate to see us somehow confuse the node/add form any further! :-)

Usability testing at UMN indicated that replacing or modifying fieldset titles would not likely help newbies navigate forms -- although we didn't test that explicitly of course.

I think summaries could be used elsewhere effectively. See how views2 wireframes implement this feature.

B/

The big issue which stood out for me during testing was that new users would just open fieldset after fieldset looking for stuff. I always figured people would ignore them because they're collapsed, but that's not the case at all :( So they hide absolutely nothing.

Please keep in mind that usability is not just about designing for newbies (or designing for the "average user" for that matter). A system is usable if it adapts itself to the experience level of the user. It is perfectly imaginable to e.g. have all fieldsets opened for newbies, while offering an option to activate summaries for more experienced users.

See screenshot on for a take on this. See also couzinhub's screenshots above too http://groups.drupal.org/node/8365#comment-29208

Bevan/

I think Bevan's latest suggestion (and similarly couzinhub's 2nd mockup) are the best takes on summaries so far. Each summary is close to the title of the tab, while the title is static, and it's easy to scan down the tabs/headers.

The only thing I'm concerned about (and this goes for all summary proposals), is how to actually make this work. How can some jQuery code understand the changes you have made to form elements in a fieldset and express that in a clear and simple fashion on the related tab? What if a fieldset has 50 checkboxes? What would its summary be? Unrealistic example, but we need to be this flexible.

We probably need some sort of setting added to fieldset elements in Forms API, like rzsrama has suggested, in order to help jQuery build the summaries. A lot of forms would have to be modified to accommodate to this though, but that's probably acceptable for D7. I'm not sure what's the best way to go about this - would be interesting to hear what some core developers have to say (chx?).

I should also mention the newly created Node form layouts module that allows us to try out different alternatives on our own Drupal installations. So far it includes vertical tabs and accordion instead of fieldsets. No summaries yet, for above reasons.

Would be terrific if someone could pick this back up.

@Moshe, I'm still pursuing this and might like to chat with you about the technical specification detailed below. I don't mind letting someone else take care of the presentation, but I'm working fast to finalize my #summary spec. so I can use it in Ubercart 2.x. There's a quick summary demo on my D6 dev site that should be publicly accessible.

Quick explanation: Those items were built directly from the form array for the cart settings form. I'm basically overloading the #summary attribute on those form elements so that summaries can be generated one of several ways:

• If #summary is a string, display the element summary as #title: #summary. When a fieldset uses this method, its child elements are ignored and #summary should provide an adequate summary of all its child elements.
  

    //  Ex: The first item in the demo represents this element.
    $form['general']['uc_add_item_redirect'] = array(
      '#type' => 'textfield',
      '#title' => t('Add to cart redirect'),
      '#summary' => url(variable_get('uc_add_item_redirect', 'cart'), array('absolute' => TRUE)),
      //...
    );
  

• If #summary is an array, treat it one of three ways:
  1. If the only value in it is FALSE, then do not display anything for the element and insert the summaries for any child elements instead. This is particularly helpful for fieldsets. By default, fieldsets will display as the title with 'children' items (indented) for each child element.
     

       // Ex: The first two items in the array are actually in the same fieldset, but
       // I wanted individual summaries of its child elements instead of as a whole.
       $form['general'] = array(
         '#type' => 'fieldset',
         '#title' => t('General cart settings'),
         '#summary' => array(FALSE),
       );
     

  2. If the first value is FALSE, then use the next value as the full text of the summary. This differs from the string usage in that we don't automatically add in #title. This is particularly helpful for summaries that either don't need the full #title or need to alter it somehow.
     

       // Ex: The fifth item in the list is a fieldset summary that can't use the
       // the #title because of the way it displays the summary.
       $form['continue_shopping'] = array(
         '#type' => 'fieldset',
         '#title' => t('Continue shopping link'),
         '#summary' => array(
           FALSE,
           t('Continue shopping !type is: !link',
             array('!type' => variable_get('uc_continue_shopping_type', 'link') == 'link' ? t('link') : t('button'),
             '!link' => l(variable_get('uc_continue_shopping_text', t('Continue shopping')), variable_get('uc_cart_continue_shopping', '')))),
         ),
       );
     

  3. If the first value is a string, we expect it to be a valid function name and pass the remaining values to that function as arguments. The return value of this function is used as the full text of the summary. I actually don't have a demo for this yet. : )
• If #summary isn't present, use a sensible default based on the form element #type, i.e.
  • Textfield - #title: check_plain(#default_value)
  • Select/Radios - #type: #options['#default_value']

Relevancy to this issue: The original post was simply about summarizing fieldsets, but there still needs to be some way for us to get the summary representation of the items in that fieldset. I believe the spec. outlined above provides for this and much more, including comprehensive fieldset and even form summaries. How about a short line of summary text for a fieldset, but when the title on hover pops up a tooltip containing the summaries of all the component elements?

Unresolved issues:

1. One showstopper is how to handle updating the summary when someone changes the options. This can be done in the background, but realistically I wonder if it's even necessary. Perhaps the thing to do is to change the summary text to some sort of "Settings have been changed." message when a component element's value changes.
2. Summary context and data movement... how can I let the code know where the summary is being displayed and how much data should be passed around?
3. Is the following enough/stable to build the full altered form array?
   

     $form_state = array('storage' => NULL, 'submitted' => FALSE);
     $form = drupal_retrieve_form($form_id, $form_state);
     drupal_prepare_form($form_id, $form, $form_state);
   

I'll attach my w.i.p., but please note this is not a patch and is still in development. The main function is _summary_build() that can be renamed as necessary. Also, code will be moved out of this function... particularly the whole switch() for the default summaries.

Those are all reasonable use cases ... Do we have any fapi elements which are overloaded like that? we don't usually do that, Your last case sounds like a call for #summary callback and #summary arguments.

hehe I was actually about to include a #4 under unresolved issues dealing with the non-standard syntax but held off to see if it came up upon review. ; )

So, I wasn't sure if I should follow the menu schema and include callback/argument keys or not, and if I did I didn't know whether to use underscores like other multi-word fapi keys or spaces like menu keys (i.e. #summary callback vs. #summary_callback). Also, I wasn't exactly sure how to implement the other keys...

What do you think of this (inspired by menu title keys)?

• #summary should contain summary text as before.
• #summary callback would be optional and default to the function that renders the summary as #title: #summary. I suppose I would then provide a few other functions that handle the cases of points 1. and 2. above - one that does a "pass through" of sorts and another that displays purely #summary.
• #summary arguments would be ignored unless a callback was specified I suppose?

EDIT: Got further on this but don't have a chance to post code... will tomorrow.

Ok... my demo link from above is updated... don't mind the CSS on that as it's not complete. I ditched the module and implemented a .inc that's in our store module for now. However, I have in place a system as recommended by Moshe that actually worked out quite well using #summary, #summary callback, and #summary arguments. The code is a lot leaner now, too.

Comments should be self-explanatory except for the last two functions which are w.i.p.

Alrighty... just a quick note on the specs... I'm using this in Ubercart to summarize entire forms along with individual fieldsets and fields. I believe the spec. can be used as is to summarize core forms/fieldsets and provide the help tips that this issue was hoping to add, but that'll require some more action integrating it w/ FAPI in a usable way and making sure summaries.inc is fleshed out completely. I know I still need a few more default functions, and there are no Drupal-usable theme functions in there atm.

So, the summaries are created by scraping data from form arrays. Elements should use the #summary, #summary callback, and #summary arguments attributes in their arrays like so (examples from Ubercart's uc_cart.module):

• #summary - This should be the basic summary text. With no other options, this text will be displayed in a summary that uses the format of #title: #summary. Example:
  

    $form['general']['uc_minimum_subtotal'] = array(
      '#type' => 'textfield',
      '#title' => t('Minimum order subtotal'),
      '#description' => t('Optionally specify a minimum allowed subtotal for a cart to proceed to checkout.'),
      '#summary' => uc_currency_format(variable_get('uc_minimum_subtotal', 0)),
      '#default_value' => variable_get('uc_minimum_subtotal', 0),
      ...
    );
  

• #summary callback - This should be the function the element gets passed to to figure out the summary. Most summaries won't need to change this, but I'll present three examples here of where it makes sense.
  1. First, for fieldsets, if you don't want to list the title of the fieldset with the elements w/in as children, you can specify 'summarize_form' as the callback. This will get a summary of the fieldset's child elements in place of the fieldset itself.
     

       $form['general'] = array(
         '#type' => 'fieldset',
         '#title' => t('General cart settings'),
         '#summary callback' => 'summarize_form',
       );
     

  2. Second, for elements that have default summarize functions (ex: summarize_checkbox) but you want to call it directly w/ specific arguments.
     

     // This function is defined in summaries.inc for use by modules.
     function summarize_checkbox($form, $true, $false) {
       if ($form['#default_value']) {
         return $true;
       }
       else {
         return $false;
       }
     }
     ...
       // This is a use from a form in uc_cart.module.
       $form['completion']['uc_new_customer_email'] = array(
         '#type' => 'checkbox',
         '#title' => t('Send new customers a separate e-mail with their account details.'),
         '#summary callback' => 'summarize_checkbox',
         '#summary arguments' => array(
           t('Anonymous customers are e-mailed user details.'),
           t('Anonymous customers are not e-mailed user details.')
         ),
         '#default_value' => variable_get('uc_new_customer_email', TRUE),
       );
     

  3. Third, you can summarize an entire form or fieldset with a replacement function when it doesn't make sense or is impossible to try and construct a summary out of child elements. Your callback should expect to receive the element array for the part of the form being summarized as its first argument.
     

       $form['panes'] = array(
         '#theme' => 'uc_pane_sort_table',
         '#pane_prefix' => 'uc_cap',
         '#summary callback' => 'summarize_uc_cart_panes'
       );
       ...
     function summarize_uc_cart_panes() {
       $items = array();
     
       $panes = uc_cart_cart_pane_list(NULL);
     
       foreach ($panes as $pane) {
         $items[] = t('!title is !enabled.', array('!title' => $pane['title'], '!enabled' => $pane['enabled'] ? t('enabled') : t('disabled')));
       }
     
       return $items;
     }
     

• #summary arguments - This should be an array of arguments to pass on to the summary callback. This is useful when passing info to a custom callback or to pass additional arguments to default callbacks. In the example below, I'm passing FALSE as an argument to the default element summarizing function. This means I should display the contents of #summary as the full summary and not include the element's #title. You can view the default element summary function in the code in uc_store/includes/summaries.inc.
  

    $form['continue_shopping'] = array(
      '#type' => 'fieldset',
      '#title' => t('Continue shopping link'),
      '#summary' => t('Continue shopping !type is: !link', array('!type' => variable_get('uc_continue_shopping_type', 'link') == 'link' ? t('link') : t('button'), '!link' => l(variable_get('uc_continue_shopping_text', t('Continue shopping')), variable_get('uc_cart_continue_shopping', '')))),
      '#summary arguments' => array(FALSE),
    );
  

It is kinda hard to follow whats being said here. It would be terrific if you could take a couple of screenshots from ubercart and mark them up with boxes and arrows so we know whats happenning where. if you are looking for a tool to use for this, Skitch or Imagewell do the job on OSX.

Thanks for the recommendation. Will do it as soon as I can (read: a few days given the upcoming holiday and family coming to town).

Moving issues from User experience project to Drupal core usability component.

Patch #43 no longer applies.

Erm... it wasn't really a patch, but yeah, it was written for D6. I'll hopefully have a chance to revisit this for UC on D6, but I don't have an ETA for a D7 port. Gotta make sure it works and is useful first. : )

How much of this equals the vertical tabs we have now in some places? Can this be marked fixed or?

Since we're not using vertical tabs everywhere, it seems like it'd be nice to have the summary pattern for individual fieldsets too - worth keeping open IMO. I'm going to move this to D8 though.

You can actually accomplish this in D7 by using the #attached['js'] on the fieldset and using the .setSummary function in the JS file, but not having a #group => 'additional_settings' or similar property in the fieldset.

I create the simplify module for just this purpose (to clean up the node add/edit pages). http://drupal.org/project/simplify

It doesn't do much but it does fix the clutter issue.

le tag…

Subscribing.

This was briefly mentioned at the DrupalCon London accessibility BoF, as a new UI pattern which will need an accessibility review.

http://groups.drupal.org/node/168744/

Has anyone considered whether the new HTML5 <details> and <summary> elements could be used here?

Marking as duplicate of #1168246: Freedom For Fieldsets! Long Live The DETAILS., which is working on a much more modern (html5) approach.

nothing to review here, so removing tag.