2

Background

Here is a nearly identical question to What's the best "Reset to Default" UI element? but with one significant difference: various fields that may be customized, but in their default state are dynamically generated based on other fields.

For example, assume I have a form to auto-generate sales lead emails:

Who is Keyser Soze?

As noted, on the previous question, resetting the default was best represented as a button because it is a momentary command: fire and forget, "press here and a different field gets updated".

But in this case, the default values are dynamic and being linked to them can be seen as stateful -- when "Use Default" is enabled, the Subject and Body fields will be automatically updated each time a backing fields such as the Contact Name are changed.

Our current UX design allows users to interact and customize these fields, which automatically clears the checkbox. If a user re-checks the "Use Default" option, the text is replaced with the auto-computed value.

Question:

Is this an appropriate UI? Most UX guides indicate that checkboxes generally they should not have immediate effect, and perhaps a slider is the better option? Is visual feedback that the fields are in "computed" vs "custom" state necessary, or is there a better alternative?

3

Wrong Problem?

First, I’ll give what I believe is the solution to the wrong problem. That solution is the same as for the Default UI Element question: a default command button. Such a button replaces everything in the text box with the default content, whether the user changed static content, computed content, or both. In the process, the placeholders for the computed content reappear because such placeholders are part of the default content.

This still applies if only the placeholder text is editable. The default button still sets the content to default, which still comes down to setting all the content (placeholder or not) back to what it was at the beginning (with placeholders).

However, I sense you really want something different. You want to revert only the changes to the placeholder content, like the contact’s name and invite type, while other changes (such changing “Hello” to “Dear”) are unaffected. Now you have some problems if you try handle it with any kind of single sweeping “default” control.

  • What if the user deleted the placeholder entirely? Can the system still tell where to re-insert the placeholder where the user wants it to be? The user may have moved or edited all the text around where it used to be.

  • What if the user changed the placeholder to static text, but then moved the static text? Does the placeholder get reinserted where it used to be, or where the static text is now? The user may be expecting either, depending on the semantics of the edits. What if the user moved part of the static text?

  • What’s to stop users from changing the placeholder to something completely unrelated to its original meaning (e.g., change “free lunch” to “replying to my email,” having changed the prior text to “Thanks for”), so that reverting to the placeholder no longer makes sense?

  • What if the user wants to revert one static string to a placeholder so it gets updated (e.g., Contact_Name), but not the others?

Right Problem?

It seems to me that if the users’ tasks call for such detailed control of the content where they revert changes to placeholders, but not changes to static text, then they probably need a general ability to:

  • Delete any arbitrary placeholder

  • Insert the placeholder that was just deleted

  • Insert any arbitrary placeholder a second time

  • Move a placeholder to a new place

  • Replace any placeholder with static text.

In other words, you basically need a template editing feature, where user can manipulate the placeholders as objects:

Textboxes with toolbar to insert placeholders at the top

A toolbar across the top allows the users to insert any placeholder anywhere any number of times. Placeholders in Subject and Body text boxes may be selected, moved (e.g., by cut-and-paste), and deleted (e.g., with the delete or backspace key). You can also give each placeholder an “x” to click to delete the placeholder, but only if usability testing indicates it’s necessary.

Users cannot edit individual characters in the placeholder content. If the user clicks anywhere on the placeholder, the whole placeholder is selected for action. The user can then type something, and that (static) text replaces the placeholder, like selecting and typing usually does in a text box. Users revert replaced and deleted placeholders by clicking the desired Insert toolbar control with the cursor in the desired location in the text box.

The page/window can open with default content in the text boxes, including placeholders. You can still have a Default command button to revert the whole thing, but I suspect you actually don’t need or want such a wrecking ball (although incremental Undo is a good idea).

It is necessary to visually distinguish placeholders from static text to help user understand why they behave differently. Graphically go with something to suggest each placeholder is a single atomic object, not a string of characters. However, you may want to provide a means to “preview” the email, displaying to the user exactly how it will appear to the receiver with the placeholders showing their content in their final format.

The General Problem

You may want to provide a means to edit the content of a toolbar control, so the user can override, for this one email, any placeholder content for all its locations in the text boxes. In this way, I’m circling back to your question at a general level, but not for the specific UI you propose.

Yes, for a given placeholder (or any individual field), I expect it would make sense to users to represent the source of the content as a state, but it probably should be an explicit state for each placeholder, not globally for all placeholders. The exact name for the states depends on your application, and probably should be something more specific than “default” or not. I expect users may understand default values, but don't anticipate the default referring to the source of the values.

In this example, let’s say a given placeholder content (wherever it occurs in a letter, however many times it occurs) can be set manually for the current letter or by linking it to a database feature known to users as “the profiles.” This binary alternative could be controlled with a “stateful” or attribute control such as a checkbox or toggle button. However, I think you may make the behavior clearer to the user if you use a control that explicitly presents both possible states. Radio buttons or maybe even a two-value dropdown would be okay for this, but a switch control may be best:

Insertion button, switch for source, text box for content for each placeholder

When the user switches to Overridden, the text for the placeholder become editable so the user can set it to any desired content. This has the advantage in that the computed/custom state is explicit and separate from the placeholder content. In addition to making the behavior clearer, this gives users the option to switch to Overridden to “lock” the placeholder at the current value so it doesn’t update. They don’t have to edit the content to break the link with the Profiles.

Switching to From Profiles reverts the text to computed. This may change the text, which, yes, is not typical behavior, but I don’t think users will have a problem with that, especially if the system remembers the custom value and reverts the content to it if the user switches back to Overridden (a simple form of undo). Then the control just changes what the user sees and uses (a Profiles value or an email-specific value), not what the value actually is in either source.

This UI to change placeholder sources could be on the email page/window itself if it’s fairly common to customize placeholders. Otherwise, it may be set on a linking page or dialog.

1
  • This is a fantastic answer and concisely covers all the scatterbrained thoughts I was having on this form. Long-term, I think we will be going with a template editor with "value objects" just as you have suggested though due to the development lead time, will be sticking to the more basic "reset to default" as a command - per the more general case. It's not perfect in all use cases, but it does reduce the cognitive load on the users by its brutal simplicity.
    – nicholas
    Apr 20 '21 at 13:52
0

If you want to do just a small change, a button would be more appropriate for resetting the field to default.

If the use case is mass-sending invites but previewing them first ... this component with checkbox that remembers the state could be appropriate.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.