Visual noise and the psychological effect known as "the tyranny of small decisions are at play in the admin UI where all details wrappers are expanded by default on pageload nullifying their utility (their purpose is to collapse information until it is needed).

The proposal is simply to collapse the details wrapper by default and either create exceptions for the first details where the only content on a page is wrapped in details so that the user never arrives at a UI where everything is collapsed, or remove those first sections from Summary and details wrappers entirely.

Style changes references below that accompany this are in a separate issue #2048369: Remove border from details/fieldset

Examples

Admin/content on load (current):

Image 8

admin/content on load (proposed):

image 9

admin/configuration/site_information (current):

image 3

admin/configuration/site_information (proposed):

imag 2

Pages and forms that would be affected

(eg. would need to have first details wrapper changed to "open" or remove the wrapper)

admin/appearance/settings and /seven -> open "Toggle display"

admin/appearance/settings/bartik -> open "Color scheme"

admin/modules -> open "core"

admin/config/people/accounts -> open "Contact settings"

admin/config/search/settings -> open "Indexing status"

admin/config/regional/settings -> open "Locale"

admin/config/system/site-information -> open "Site Details"

admin/config/development/performance -> open "Clear cache"

admin/structure/views/settings/advanced -> open "Caching"

core/install.php configure site -> open both the first and second sections since both have required fields

Some of these, like performance may need to open the second set as well, or combine them.

CommentFileSizeAuthor
#19 Screen Shot 2013-10-21 at 10.08.45 AM.png52.86 KBtkoleary
#19 Screen Shot 2013-10-21 at 10.08.59 AM.png58.61 KBtkoleary
#1 Screen Shot 2013-06-13 at 10.02.01 AM.png44.93 KBtkoleary
Screen Shot 2013-06-13 at 10.10.30 AM.png56.47 KBtkoleary
Screen Shot 2013-06-13 at 10.10.44 AM.png40.43 KBtkoleary
Screen Shot 2013-06-13 at 10.10.59 AM.png50.05 KBtkoleary
focus.png55.21 KBtkoleary
Screen Shot 2013-06-13 at 10.26.57 AM.png7 KBtkoleary
Screen Shot 2013-06-13 at 10.27.16 AM.png88.54 KBtkoleary
Screen Shot 2013-06-13 at 10.28.01 AM.png33.64 KBtkoleary
Screen Shot 2013-06-13 at 10.30.01 AM.png53.81 KBtkoleary
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

changed images

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
FileSize
Screen Shot 2013-06-13 at 10.02.01 AM.png44.93 KB

Image added to summary

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

Added styling

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

Image added

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

Upsized images

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

changed image

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

style changes

jessebeach’s picture

jessebeach CreditAttribution: jessebeach commented

I support collapsing filter details by default on listing pages. They produce visual clutter and suggest to a user that the fields need to be filled out.

Kevin and I had a long discussion about what to do with details sections on pages like the site configuration form. Leaving all of the details sections open produces significant visual clutter. Closing them all by default puts burden on a user to perform an extra click just to get to a form element. By opening the first details section of a form by default (if that form happens to be exclusively composed of details elements) gives an impression of importance to the top-most details section while conveying secondary status to the following details sections.

Bojhan’s picture

Bojhan CreditAttribution: Bojhan commented

Thanks! This feels like the garland design. It does reduce impact. I am not sure about auto collapsing, we have to check many forms to see if it makes sense, not sure if that is part of the visual change.

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented

@bojhan

Auto collapsing (accordian behavior) is *not* a part of this proposal.

An admin theme could implement that if it wanted to.

I will detail the forms in core that would require an override to open the first details wrapper.

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented

Pages and forms that would be affected (eg. would need to have first details wrapper changed to "open") are:

admin/appearance/settings and /seven -> open "Toggle display"

admin/appearance/settings/bartik -> open "Color scheme"

admin/modules -> open "core"

admin/config/people/accounts -> open "Contact settings"

admin/config/search/settings -> open "Indexing status"

admin/config/regional/settings -> open "Locale"

admin/config/system/site-information -> open "Site Details"

admin/config/development/performance -> open "Clear cache"

admin/structure/views/settings/advanced -> open "Caching"

core/install.php configure site -> open both the first and second sections since both have required fields

Some of these, like performance may need to open the second set as well, or combine them.

Dave Reid’s picture

Dave Reid
he/him
Primary language English
Location Nebraska USA
CreditAttribution: Dave Reid commented

For the 'Update options' fieldset - it doesn't even need to be visible unless items have been selected, so it could be collapsed and then automatically expanded if items are selected.

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented

I was thinking exactly the same thing

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented
Component: system.module » Seven theme
Issue tags: +CSS, +Novice, +CSS novice

This looks like a Seven theme issue to me, correct me if I'm wrong. I don't think we want to affect fieldsets in other themes.

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented

Actually, the changes are proposed in system, but the styling should be in Seven in the first place. We might be better off splitting the default state of the summary elements into at least one separate issue.

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented

@LewisNyman

That's a good idea. Starting the other issue here #2048369: Remove border from details/fieldset

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Title: Clean up look of summary and details to remove visual noise » Make summary and details collapsed by default

And changing the name of this to reflect that it's just about collapsing by default.

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

styleing

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented

edited

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
Issue summary: View changes

edited

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented

Unpublished #5 and added to summary

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented
Component: Seven theme » markup
Issue tags: -CSS, -Novice, -CSS novice

Nice, this change affects multiple modules with potentially a case-per-case decision. I guess markup is the most sensible grouping component, hopefully we can avoid splitting this down into sub-issues.

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented

dup #1892182: #type details: Rename #collapsed to #open, or this one is meta?

nod_’s picture

nod_
Primary language French
Location Lille
CreditAttribution: nod_ commented
Status: Needs work » Active

no patch

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented

@nod

No, this can essentially be Sun's follow up to #1892182:

3. The previous two points probably cover 80% of the details for which #open was added. The remaining ones can probably be left for a follow-up issue.

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented

#17: I think you misunderstood nod_: an issue can only be marked "needs work" if there's a patch that needs work. Since there's no patch, the "needs work" status was inappropriate.

I think the principle behind changes being proposed here makes sense, but the proposed changes to the admin/content page don't make sense to me. Maybe if the "Update options" <select> was always visible, it would be different, but hiding all the key features of that page by default makes no sense to me.

tkoleary’s picture

tkoleary CreditAttribution: tkoleary commented
FileSize
Screen Shot 2013-10-21 at 10.08.59 AM.png58.61 KB
Screen Shot 2013-10-21 at 10.08.45 AM.png52.86 KB

@Wim Leers

hiding all the key features of that page by default makes no sense to me.

Until the user has actually selected something they can do nothing with the update options. It is a classic example of context. The only time the user needs to see the update options is when they have something to update.

The best real-world example of this is your gmail operations. You only see operations on an email or emails when one or more is selected.

image

image

Wim Leers’s picture

Wim Leers
Location Ghent 🇧🇪🇪🇺
CreditAttribution: Wim Leers commented

#19: oh, I see, I didn't realize you wanted these fieldsets to be opened automatically upon selection. That makes sense. Just having it closed by default, and not opening when appropriate would be wrong IMHO. But what you're saying now makes sense. Thanks for the clarification :)

Bojhan’s picture

Bojhan CreditAttribution: Bojhan commented

I get how this applies to filters, which makes sense. But I still dont get how this applies to anything else.

Bojhan’s picture

Bojhan CreditAttribution: Bojhan commented
Issue summary: View changes

added exceptions

LewisNyman’s picture

LewisNyman
he/him
CreditAttribution: LewisNyman commented
Issue tags: +Usability
Bojhan’s picture

Bojhan CreditAttribution: Bojhan commented
Version: 8.0.x-dev » 8.1.x-dev
jibran’s picture

jibran
he/him
Primary language Urdu
Location Sydney, Australia
CreditAttribution: jibran commented

Why is this moved to 8.1.x? If we can agree on it then it is just a novice patch which removes '#open' from details.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.7.x-dev » 8.8.x-dev

Drupal 8.7.0-alpha1 will be released the week of March 11, 2019, which means new developments and disruptive changes should now be targeted against the 8.8.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.8.x-dev » 8.9.x-dev

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 8.9.x-dev » 9.1.x-dev

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.