4

I often work on pages containing forms with complex requirements and subforms. The example below has these attributes:

  • The default button -- that is, the button that will be "clicked" when the user hits Enter -- is indicated by white text / dark blue background button.
  • Focus is indicated by a light blue halo.
  • Required fields are indicated by an orange bar (their related label has an orange star).
  • The General List Info fields and the data in the table are the data that is part of the main form and ends up getting saved when Submit is clicked.
  • The requirements for the main form are Author and Update Date.
  • The contents of the Find Cars for List groupbox is a subform that adds any rows from the database that match the filtering fields into the table. One of the fields must be filled to avoid an error (there's no indication of it before hitting the Add to List button).
  • The fields and buttons above the table are another subform that allows the user to set the preferred color for rows or remove them from the list.
  • The requirements for the Cars List subform vary based on intended use. To update rows, the first Rows to Affect field and Preferred Color are required. To remove rows, only the first Rows to Affect field is required.

Please ignore any silliness in the content or design other than the way conditionally required fields are shown.

enter image description here


The Core Question:

How do I best front-load the form requirements in cases like this? I want to help users avoid getting errors, but toggling requirements as they change introduces (IMO) confusing behavior. E.g., if the user is tabbing through the Cars List subform, it looks like Preferred Color is required even though the user's intent may be to use the Remove Rows button. Should I simply drop any attempt to show the requirements for complex forms, and just let users click buttons to get error messages?

  • that "required on blur" idea is epic fail to me. Make it beautiful: if author is not empty: Update date become required and vice versa. – ADOConnection Feb 18 '16 at 7:44
  • Sorry, but I'm not sure I understand what you're suggesting. Author and Update Date are always both required for the main form. Also, nothing becomes required on blur. Fields in the example can become required on focus though. Can you please describe what fails and what might work better given the scenario? Thanks! – Ryan Horn Feb 18 '16 at 21:33
  • @ADOConnection do you have any feedback for the question in my previous comment? – Ryan Horn Mar 8 '16 at 16:08
1

The confusion of the design is that you have 4 different potential actions in a single form. Multiple actions, with different requirements, take action on the same form. It is best to provide clear direction to users.

Think of the form as a puzzle. I present you 4 different puzzles, for simplicity lets say that they are all 10 pieces each and all a single color. Not very exciting, but easy to know what piece belongs to what puzzle.

I'm not going to ask you to pick 1 puzzle and put it together. Despite it being easy to know what piece belongs to what puzzle, I offer you two choices:

  1. Pick up a bag of 40 puzzle pieces, decide which puzzle you want to put together and then pick out the appropriate pieces out.
  2. Ask you which puzzle you want to put together, then hand you a bag of 10 puzzle pieces for that particular puzzle.

Unless you are really bored, you'll pick option 2. Make each of those puzzles a 100 piece landscape and you'd be crazy to pick anything but option 2!

I'm unclear on how this form interacts with its destination, so this may be missing something...

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Each action is very clear now. I'm adding, or modifying, an existing list which has 3 major section: author, update date, list of cars. If I want to edit the list of cars I enter into that task flow.

An add button brings up a dialog, or adds a new row to the table that allows inline table editing. In either case the action is very clear and the resulting fields are clearly part of that action.

Removing a row is as simple as selecting the desired row and clicking the remove button. Still want the user to type in a row number? Bring up a dialog to ask them. Again, the action and the resulting fields are clearly related.

How do you edit? You could add another below the table and support editing the highlight row. You could also provide an inline edit button for each row that enters into an edit mode for that row. Again, the resulting fields that appear as a result of the action have clear purpose.

In the end, you're not presenting a bunch of actions with appropriate fields mixed in. You're asking the user a simple question first: "What do you want to do?" When they tell you what they're action is, you poll for the necessary information.

  • Thanks for your response. Unfortunately, I'm bound to the layout above. Remember my comment above about critiquing the way I'm showing complex requirements (not the form itself). The forms I'm working on are based on an expert user base and a concession to favor expert users over new users. I'm leaving out some detail for the sake of brevity, but my question remains: Given this form layout, how best can I illustrate requirements before the user clicks a button? – Ryan Horn Feb 17 '16 at 18:16
  • I shall ponder and update my answer if inspiration strikes. It is definitely a challenging task to stay within the current structure. – Evil Closet Monkey Feb 17 '16 at 18:26
  • did you have the opportunity to consider any other solutions? – Ryan Horn Mar 8 '16 at 16:11

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.