singup_status_mailer settings UI cleanup
| Project: | Signup Status |
| Version: | 6.x-1.x-dev |
| Component: | Signup status mailer |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Follow-up from #228159: Custom emails sent upon status change. The current UI for the settings pages is pretty harsh. ;) It's just a pile of fieldsets for each status/action combo on the site. Inside each fieldset, there's a dropdown for if the notifications should happen or not, a text field for the subject, and a textarea for the body. If token is installed, there's a nested fieldset with the possible token replacements inside each fieldset.
Things are even worse on the per-node override. The notification selector now has 3 choices: "Disabled", "Use default (currently 'XXX')", and "Enabled (custom)". If this is set to "Use default", there subject and body fields are disabled with the current site-wide default text filled in as the #default_value and there's a note saying if you want to change these, you either have to select "Enabled (custom)" or change the site-wide defaults (with a link to the site-wide defaults page).
Some ideas:
A) We should probably move the token help to a single fieldset at the bottom of each settings page, instead of embedding a separate copy inside each of the settings fieldsets.
B) We should only include a link to the site-wide defaults if the user has "administer signup status mailer settings" permission.
C) If there's JS, we should hide the subject and body fields if notifications are set to 'Disabled', and reveal them if they're set to 'custom' or 'default' (if the default is to have them enabled).
D) On the per-node settings pages, if a given setting is currently saved as 'use the defaults', and the site-wide templates are included but disabled, if the user selects 'custom', we should enable the form elements and add a note saying something like "You're overriding the site-wide defaults for this [node-type]". Currently, to override, you actually have to save the form as 'custom', and then the page reloads (and you loose the site-wide defaults to start from).
E) I wonder if a pile of fieldsets is the best approach here. Maybe Vertical tabs support would be nice?
#1
FYI, here's what the current UI looks like:
#2
Here's a patch for A. This seems like an improvement to me. Thoughts?
#3
Based on an IRC discussion with deviantintegral, we agree (A) is a step forward, so I committed #2 to HEAD. A few other ideas:
F) The labels on these fieldsets don't make it immediately obvious what the difference is between "first set" and "status changes". Those fieldset labels could use some help.
G) We should probably add an intro paragraph with help text describing WTF is going on here. ;)
H) For non-JS users (ouch) we should probably include a list of of anchor links pointing to the start of each fieldset in the intro text. We can wrap these inside a
<div class="js-hide">so that they don't even appear for JS-enabled browsers.#4
Patch for (B): We should only include a link to the site-wide defaults if the user has "administer signup status mailer settings" permission.
Users with 'administer signup status mailer settings' see what you see in the screenshot in #1 above. Otherwise, they get:
#5
Better help text for (B) based on feedback from deviantintegral.
#6
Committed #5 to HEAD.... Next. ;)
#7
Based on more IRC discussions w/ deviantintegral, greggles and ezra-g, I committed a change to HEAD so that all the settings for each status are inside a single per-status fieldset. Then, there are separate form elements (hopefully with clearer labels) for each action (new vs. update) within each status fieldset. How's this look?
#8
Here's a better screenshot on a node of type "Event" with a more realistic title. Previous screenshots were of a node that used "signup untimed" for both the type and title, which was confusing. ;) This should make things more clear for realistic use-cases.
#9
Patch and screenshots for H -- anchors that skip down to the fieldset for each status when JS is disabled. Pretty straight-forward. Screenies of what you see with the patch attached with JS disabled and enabled in the browser.
#10
The improvements for H look good.
#11
Committed #9 to HEAD. H is resolved.
#12
Finally figured out the right way to do the jQuery goodness in here so that when a given select element is clicked I operate only on that select element's "own" related fields. This resolves (C) and (D) from the original post. A little hard to demonstrate with just a screenshot -- a little movie would be best. ;) But, the basic story can be found in the doc block for the Drupal.behaviors.signupStatusMailerNotificationSetting jQuery function:
Whenever the notification box is set to "Disabled" ('none'), all the e-mail fields and help text is hidden. If it is set to "Enabled" on the side-wide settings page ('default'), show the e-mail fields. When it is set to "Enabled (custom)" ('custom'), the e-mail fields are shown and enabled. When it is set to "Use default (currently 'Enabled')" ('default-enabled'), the e-mail fields are shown but disabled, and the help text is revealed. Finally, if it is set to "Use default (currently 'Disabled')" ('default-disabled'), the e-mail fields are hidden but the help text is shown.
Screenshot shows the initial state on a node-specific settings page that shows all the possible cases there. Basically, whenever any setting moves to any value you see on that page, the form elements beneath it change to look like they do in this screenie. However, for the full effect, I recommend grabbing HEAD of signup_status, applying the patch, and playing with it for yourself.
#13
It's not quite perfect yet, but #12 seems like a big improvement, so I committed that to HEAD. Back to active for further enhancements, though those are going to have to wait until mid September when I'm back online.