8

I am working on a reporting form for an electronic healthcare record application used by physicians to generate reports on usage. There are two different report types.

Only one type of report can be created at a time, Report Type 1 or Report Type 2. The user would need to select the report type. The form would look like this:

Mockup showing two radio buttons, a date range and two labeled drop-down lists

download bmml source – Wireframes created with Balsamiq Mockups

The other entry field labels below Report Type would be consistent, but the options in the select list would change based on which Report Type is selected.

My question is whether using radio buttons to dynamically change the form field options is a good user experience. Since the labels aren't changing (Measurement Period, Name of User and Report Name), it might not be apparent to the user that the "form" has changed, even though the values of what can be selected will change. I'm wrestling with whether or not that matters to the user. Since they have selected a different report type, can I expect that they will discover the reason the options have changed in the form?

I'm trying to avoid using tabs to have separate forms for the report types, because the page already has tabs that have different reporting forms and results.

Improve this question
6
  • Hi user31850. Welcome to the UX Stack Exchange! Can you give a bit more context? Who are your users? What is the application used for? You may also want to see this related question.
    – Graham Herrli
    Commented May 16, 2013 at 18:41
  • Like a lot of UI, it's hard to explain without providing a screen shot, but I don't have those privileges since this is my first post. I'll see what I can do.
    – Dmacatude
    Commented May 16, 2013 at 20:08
  • 1
    @Dmacatude If you provide a link to the screenshot someone can add the image to the question for you.
    – Matt Obee
    Commented May 16, 2013 at 21:33
  • we discussed this same problem in great length here: ux.stackexchange.com/questions/39124/…
    – erik_lev
    Commented May 16, 2013 at 22:31
  • 1
    The main problem I'm working through is that if you switch between Report Type 1 and Report Type 2, you wouldn't see any different in the form, but the options under the select lists would be different. So, I'm not sure that revealing the rest of the form would do anything to alert the user that something is different. The remaining form fields would clear if they switched the report type, so maybe that is sufficient. Now that I think about it, maybe changing the report type label to Report Type 1 Name would give an indication that the options under that select list are different.
    – Dmacatude
    Commented May 17, 2013 at 12:49

4 Answers 4

Reset to default
3

Do not be ambiguous: go ahead and use two different pages

mockup

download bmml source – Wireframes created with Balsamiq Mockups

Improve this answer
2
  • Can you explain how my proposed solution is ambiguous? I'm not saying I disagree with yours, but since the form is almost the same except with different options, I'm hesitant to make the user navigate to two different pages for a very similar form entry workflow.
    – Dmacatude
    Commented May 17, 2013 at 14:06
  • 2
    You said that your solution is ambiguous: it might not be apparent to the user that the "form" has changed. And I agree with you. It is exactly because the forms are slightly different that it can be confusing, therefore separating them will avoid confusion.
    – Gildas Frémont
    Commented May 17, 2013 at 14:15
2

The application I work on has a ton of reporting, input, and selection interfaces with various dependent fields, and I run into these kinds of issues all the time. I've come up with a few guidelines to make this interaction as pleasant as possible:

  1. Never force a workflow on a person (i.e., you can't choose the dates or fill out the form before selecting a radio button). You have no idea what's in a person's short term memory when they come to the page. They might be thinking "I need to run a report on on June 1st through 15th," and here you are presenting them with a completely different choice: "Do I need report 1 or 2?". By the time they figured out what report version they want, they forgot the date. Now they have to look that up again somewhere, and look, you've just wasted their time, brain cycles, and made them feel a little stupid.
  2. When context changes (going from report 1 to 2), retain whatever is still valid from the previous context and clear out anything that's invalid. I'm guessing that the date range is still valid regardless of what report is selected. Maybe even some of the options in your pickers are still valid. Run all your fields through validation, and re-validate if a person tries to submit a partially complete form. Flag any blank fields with helpful errors.

Here's an example workflow from one my input interfaces. It's not a report, but the principle is the same.

clearing out dependent pickers workflow

Your goal should be to make capturing whatever is in the user's short term memory easy and conform to their workflow. Make it your job to deal with all the messy bits.

Improve this answer
3
  • I like what you've pointed out. In addition to a manually entered date range, there will also be a select list that allows them to select a quarterly and annual range - I failed to mention that initially. Hopefully predefined date ranges will jar their memory. The date field entries would be retained if they switch report types because the date options are the same between both report types. The Report Name would be different so that would need to reset (but it would be obvious to them why it changed based on the report type selection), but the Name of User could possibly be included in both.
    – Dmacatude
    Commented May 17, 2013 at 19:52
  • Are you letting your users customize the report name? If so, I would recommend retaining custom names when switching reports.
    – Stasome
    Commented May 17, 2013 at 21:46
  • The report names wouldn't be customizable. Although, upon export they could choose to rename the file.
    – Dmacatude
    Commented May 20, 2013 at 12:17
1

Why not populate the remainder of the form only after the report type has been selected? Alternatively, you could have the elements of the form visible but deactivated and visually down-played with desaturation or some such device.

Improve this answer
0

I agree with plainclothes, don't display any fields before the user makes the selection, this way it will be clear that the content will change once a different radio button is selected

Improve this answer
1
  • The path would be: Select radio button 1 or radio button 2 > display whichever form is selected > select the other radio button. When that happens, the first form would already be in view. Not revealing it is not an option since the first selection has already been made. I proposed earlier that maybe the field labels do change for entry fields where the select list options change to give the user feedback that the form has changed. I think I'm leaning towards my own answer...Thanks to everyone so far for the feedback.
    – Dmacatude
    Commented May 17, 2013 at 17:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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