2 deleted 6 characters in body
source | link

To find the answer I referenced Luke Wroblewski's Web Form Design. He has an entire section that talks about selection-dependent inputs, which is more or less what I was trying to do. Here's what I found:

Wireframe A, B and C: PositivesWireframe A, B and C:

Positives: 100% pass rate. It keeps the initial options visible. Negatives

Negatives: It's not clear that the header is selectable, there's a slow completion speed and it's not completely accessible(that's changing though)

Wireframe D: PositivesWireframe D:

Positives: Average satisfaction scores. Low number of user errors. Rates well with eyetracking. It keeps the initial options visible. Negatives

Negatives: The user can't see or access their initial options. It's slower.

Wireframe E: PositivesWireframe E:

Positives: Near perfect satisfaction rating. The header and inputs are close to each other. It keeps the initial options visible. Negatives

Negatives: If the number of inputs is substantial then the method breaks down quickly. The combination of the page jump and the movement of the initial options cause confusion.

Wireframe displayed in the comments by DesignerAnalyst: PositivesWireframe displayed in the comments by DesignerAnalyst:

Positives: Rates best in eyetracking. Near perfect satisfaction ratings (the eye doesn't have to travel too far once they select a section. It keeps the initial options visible. Negatives

Negatives: When the number of initial options grows it doesn't do well. There is confusion about mutual exclusivity of each tab.

I ended up going with a version of Wireframe D. The form is going to be substantial and will probably grow from the first implementation. It's a complex subject matter so I wanted to help reduce user error and confusion. Although they can't keep track of their initial options I'm giving them a back button so they can go back to the first page to see what they chose. It's not great but for phase one it works. I may display a header on each page to show their selections. In my particular instance the initial inputs are going to build a form for the person, so I'm actually altering the wireframe a bit and putting each selection on its own page. Each separate section has the potential to be somewhat lengthy so this will help the user to digest the information. The print button is on the very last page under and image of their form.

Luke talked about a few other designs that I didn’t come up with in his book but they didn’t seem to work for my purposes at all. If you’re facing this problem or any other problems related to web forms I would check his book out and read up. It’s a great resource.

To find the answer I referenced Luke Wroblewski's Web Form Design. He has an entire section that talks about selection-dependent inputs, which is more or less what I was trying to do. Here's what I found:

Wireframe A, B and C: Positives: 100% pass rate. It keeps the initial options visible. Negatives: It's not clear that the header is selectable, there's a slow completion speed and it's not completely accessible(that's changing though)

Wireframe D: Positives: Average satisfaction scores. Low number of user errors. Rates well with eyetracking. It keeps the initial options visible. Negatives: The user can't see or access their initial options. It's slower.

Wireframe E: Positives: Near perfect satisfaction rating. The header and inputs are close to each other. It keeps the initial options visible. Negatives: If the number of inputs is substantial then the method breaks down quickly. The combination of the page jump and the movement of the initial options cause confusion.

Wireframe displayed in the comments by DesignerAnalyst: Positives: Rates best in eyetracking. Near perfect satisfaction ratings (the eye doesn't have to travel too far once they select a section. It keeps the initial options visible. Negatives: When the number of initial options grows it doesn't do well. There is confusion about mutual exclusivity of each tab.

I ended up going with a version of Wireframe D. The form is going to be substantial and will probably grow from the first implementation. It's a complex subject matter so I wanted to help reduce user error and confusion. Although they can't keep track of their initial options I'm giving them a back button so they can go back to the first page to see what they chose. It's not great but for phase one it works. I may display a header on each page to show their selections. In my particular instance the initial inputs are going to build a form for the person, so I'm actually altering the wireframe a bit and putting each selection on its own page. Each separate section has the potential to be somewhat lengthy so this will help the user to digest the information. The print button is on the very last page under and image of their form.

Luke talked about a few other designs that I didn’t come up with in his book but they didn’t seem to work for my purposes at all. If you’re facing this problem or any other problems related to web forms I would check his book out and read up. It’s a great resource.

To find the answer I referenced Luke Wroblewski's Web Form Design. He has an entire section that talks about selection-dependent inputs, which is more or less what I was trying to do. Here's what I found:

Wireframe A, B and C:

Positives: 100% pass rate. It keeps the initial options visible.

Negatives: It's not clear that the header is selectable, there's a slow completion speed and it's not completely accessible(that's changing though)

Wireframe D:

Positives: Average satisfaction scores. Low number of user errors. Rates well with eyetracking.

Negatives: The user can't see or access their initial options. It's slower.

Wireframe E:

Positives: Near perfect satisfaction rating. The header and inputs are close to each other. It keeps the initial options visible.

Negatives: If the number of inputs is substantial then the method breaks down quickly. The combination of the page jump and the movement of the initial options cause confusion.

Wireframe displayed in the comments by DesignerAnalyst:

Positives: Rates best in eyetracking. Near perfect satisfaction ratings (the eye doesn't have to travel too far once they select a section. It keeps the initial options visible.

Negatives: When the number of initial options grows it doesn't do well. There is confusion about mutual exclusivity of each tab.

I ended up going with a version of Wireframe D. The form is going to be substantial and will probably grow from the first implementation. It's a complex subject matter so I wanted to help reduce user error and confusion. Although they can't keep track of their initial options I'm giving them a back button so they can go back to the first page to see what they chose. It's not great but for phase one it works. I may display a header on each page to show their selections. In my particular instance the initial inputs are going to build a form for the person, so I'm actually altering the wireframe a bit and putting each selection on its own page. Each separate section has the potential to be somewhat lengthy so this will help the user to digest the information. The print button is on the very last page under and image of their form.

Luke talked about a few other designs that I didn’t come up with in his book but they didn’t seem to work for my purposes at all. If you’re facing this problem or any other problems related to web forms I would check his book out and read up. It’s a great resource.

1
source | link

To find the answer I referenced Luke Wroblewski's Web Form Design. He has an entire section that talks about selection-dependent inputs, which is more or less what I was trying to do. Here's what I found:

Wireframe A, B and C: Positives: 100% pass rate. It keeps the initial options visible. Negatives: It's not clear that the header is selectable, there's a slow completion speed and it's not completely accessible(that's changing though)

Wireframe D: Positives: Average satisfaction scores. Low number of user errors. Rates well with eyetracking. It keeps the initial options visible. Negatives: The user can't see or access their initial options. It's slower.

Wireframe E: Positives: Near perfect satisfaction rating. The header and inputs are close to each other. It keeps the initial options visible. Negatives: If the number of inputs is substantial then the method breaks down quickly. The combination of the page jump and the movement of the initial options cause confusion.

Wireframe displayed in the comments by DesignerAnalyst: Positives: Rates best in eyetracking. Near perfect satisfaction ratings (the eye doesn't have to travel too far once they select a section. It keeps the initial options visible. Negatives: When the number of initial options grows it doesn't do well. There is confusion about mutual exclusivity of each tab.

I ended up going with a version of Wireframe D. The form is going to be substantial and will probably grow from the first implementation. It's a complex subject matter so I wanted to help reduce user error and confusion. Although they can't keep track of their initial options I'm giving them a back button so they can go back to the first page to see what they chose. It's not great but for phase one it works. I may display a header on each page to show their selections. In my particular instance the initial inputs are going to build a form for the person, so I'm actually altering the wireframe a bit and putting each selection on its own page. Each separate section has the potential to be somewhat lengthy so this will help the user to digest the information. The print button is on the very last page under and image of their form.

Luke talked about a few other designs that I didn’t come up with in his book but they didn’t seem to work for my purposes at all. If you’re facing this problem or any other problems related to web forms I would check his book out and read up. It’s a great resource.