Usability: Hide irrelevant settings on the Performance settings page [#203908]

Problem/Motivation

In admin settings, several more advanced or custom items are dependent on the choice of another item. Thanks to jQuery, some of them are already hideable, while many are not.

Proposed resolution

Since this is a noticeable usability issue, the original author has added this feature via the supplied patch, which affects the following admin pages:

On admin/settings/performance the 'Minimum cache lifetime' and 'Page compression' stay closed, until cache is enabled. Also, the warning message for 'aggressive cache' is only shown, when 'aggressive cache' is chosen.
On admin/settings/site-maintenance the 'Site off-line message' textarea stays closed, until 'Site status' is set online.
On admin/build/themes/settings, custom logo as well as custom favicon fields are only shown, when default logo resp. favicon is disabled.

Remaining tasks

The provided patch fails on Drupal 7.x and 8.x, 8.1.x and 8.2.x

'Minimum cache lifetime' is now 'Page cache maximum age', and is no longer 'closed' or hidden.
The "site off-line message' textarea, now 'Message to display when in maintenance mode' is always visible.
I'm guessing that custom favicon and logo fields are theme-dependent, however, as of 8.1.x, these are always visible.

As these settings are not relevant in 8.0.x+ I'm reverting the ticket's version to 7.x. I'm unclear if this is relevant to 7.x, should be confirmed.

Original report by Pancho

In admin settings, several more advanced or custom items are dependent on the choice of another item. Thanks jQuery, some of them are already hideable, while many are not.

Since this is IMHO a noticeable usability progress and adds to a more consistent interface, I have added this feature now on the remaining suitable admin pages:

On admin/settings/performance the 'Minimum cache lifetime' and 'Page compression' stay closed, until cache is enabled. Also, the warning message for 'aggressive cache' is only shown, when 'aggressive cache' is chosen.
On admin/settings/site-maintenance the 'Site off-line message' textarea stays closed, until 'Site status' is set online.
On admin/build/themes/settings, custom logo as well as custom favicon fields are only shown, when default logo resp. favicon is disabled.
No string changes are involved, so it might still get into D6... Has been tested, but feel free to test more!

Comment	File	Size	Author
	hide_settings.patch	13.48 KB	Pancho

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

Pancho

UTC+2 🇪🇺 EU

CreditAttribution: Pancho commented 3 January 2008 at 13:21

Solves #147764 as well.

Comment #2

catch

he/him

English

CreditAttribution: catch commented 3 January 2008 at 14:54

Status:

Needs review

» Needs work

///On admin/settings/site-maintenance the 'Site off-line message' textarea stays closed, until 'Site status' is set online.

So I take my site down for 5 minutes to do some simple maintenance, find another issue which is going to take hours to fix and want to change the message - then I can't change the message unless I put my site online? No thanks ;)

Comment #3

Pancho

UTC+2 🇪🇺 EU

CreditAttribution: Pancho commented 3 January 2008 at 16:22

Status:

Needs work

» Needs review

Sorry, the description in my original post was not correct. It should read:

On admin/settings/site-maintenance the 'Site off-line message' textarea stays closed, until 'Site status' is set offline.

Obviously, the textbox is hidden on client side, so of course you don't have to unpublish your site to change the message. It's just about reducing cruft in the admin section.

The patch (that you obviously didn't try ;-) works well.

Comment #4

catch

he/him

English

CreditAttribution: catch commented 3 January 2008 at 16:19

OK now I tested it, but still CNW I'm afraid.

So I have an old message (we'll be down for 15 minutes) and I set my site offline for 3 hours. I have to show the 15 minutes message until I've typed up my new message and saved the form - giving lots of visitors the wrong information and also adding an extra step to taking my site offline (because I now have to save the form twice instead of once).

Comment #5

Pancho

UTC+2 🇪🇺 EU

CreditAttribution: Pancho commented 3 January 2008 at 16:34

Status:

Needs review

» Needs work

Please help me, cause I still don't get it... :)

When you take your site down:

You switch the "Site status" radios to "Off-line".
Immediately, the "Site off-line message" textarea is shown and you can change your message from "... 15 minutes..." to "... few hours..." or whatever.
The maintenenance mode is not activated before you click on "Save configuration". At the same time, the new message is saved.

So I don't see any extra step, I don't see why one would need to save twice, and I don't see why there would be given any wrong or out-of-date information...

Comment #6

yched CreditAttribution: yched commented 3 January 2008 at 16:35

I guess not, since the textarea will be JS-enabled the moment you _select_ the 'offline' radio, right ?

edit : that's a crosspost with #5
How does it degrade, though ?

Comment #7

Pancho

UTC+2 🇪🇺 EU

CreditAttribution: Pancho commented 3 January 2008 at 16:41

yched: Right, it's exactly the way it works with custom date formats in 'admin/settings/date-time' or in the pictures fieldset of 'admin/user/settings'.

edit: It also degrades the same way as it does in the two mentioned cases - w/o JS all fields are shown, nothing is hidden.

CNR IMHO.

Comment #8

catch

he/him

English

CreditAttribution: catch commented 3 January 2008 at 17:27

Status:

Needs work

» Needs review

My fault, js didn't refresh in my browser properly. Sorry Pancho I'm clearly an idiot!

I checked the rest of the pages you mentioned in #1 and this all seems very sane to me.

Only think I'd say is this seems to work better visually (at least in Garland) when the form being toggled is in a fieldset - gives more of a sense that the options are expanded, rather than just a bit of the page appearing and dissappearing. I noticed this on the admin/settings/maintenance page - it doesn't technically need a fieldset with such a short form, but the majority of core forms have them around most elements now so a single fieldset with #collapsible => FALSE, there would make things more visually consistent. This is a minor niggle though.

Comment #9

Bevan CreditAttribution: Bevan commented 7 January 2008 at 09:23

Status:

Needs review

» Reviewed & tested by the community

The DHTML needs to either be highlighted when it changes (with the highlight fading away) or the changes need to scroll into view. Otherwise the user may not notice the form has changed. Another option is to have the fields 'disabled' (greyed out) but visible. (See this critical d6 issue before you attempt the latter approach; http://drupal.org/node/204756).

I tested js behavior on all of the pages plus also admin/build/themes/settings/garland. I also tested form settings were saved on admin/build/themes/settings/garland. (I didn't test form submission and retrieval on the others).

Passes coder.module code review.

Comment #10

Bevan CreditAttribution: Bevan commented 7 January 2008 at 09:23

Status:

Reviewed & tested by the community

» Needs work

woops

Comment #11

Bevan CreditAttribution: Bevan commented 3 February 2008 at 01:15

Version:	6.x-dev	» 7.x-dev
Component:	base system	» javascript
Assigned:	Pancho	» Unassigned

Still applies cleanly. Still needs some animation to keep the user orientated. Still a great enhancement to the UI. Too late for D6. Any takers?

Comment #12

Bevan CreditAttribution: Bevan commented 3 February 2008 at 01:16

Title:

Usability: Make several admin settings hideable

» Usability: Hide irrelevant settings on the Performance settings page

Comment #13

Sutharsan CreditAttribution: Sutharsan commented 31 August 2008 at 20:53

Component:

javascript

» usability

Moving all usability issues to Drupal - component usability.

Comment #14

Dave Reid

he/him

English

Nebraska USA

CreditAttribution: Dave Reid commented 20 January 2009 at 04:49

Component:	usability	» system.module
Issue tags:		+Needs usability review, +Usability

Comment #15

Tor Arne Thune CreditAttribution: Tor Arne Thune commented 4 February 2011 at 01:58

Version:

7.x-dev

» 8.x-dev

Still a valid issue, in 7.0. Moving to 8.x, as I don't see this UX change getting into 7.x.

Comment #16

Bojhan CreditAttribution: Bojhan commented 23 March 2012 at 19:21

Issue tags:

-Needs usability review

I am pretty sure we did UX improvements on this page?

Comment #17

23 March 2012 at 19:21

Version:

8.0.x-dev

» 8.1.x-dev

Drupal 8.0.6 was released on April 6 and is the final bugfix release for the Drupal 8.0.x series. Drupal 8.0.x will not receive any further development aside from security fixes. Drupal 8.1.0-rc1 is now available and sites should prepare to update to 8.1.0.

Bug reports should be targeted against the 8.1.x-dev branch from now on, and new development or disruptive changes should 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.