Reader Request - Submit While Using Tabs

I've always wanted to do something like this: "Reader's Requests."  Well, there was a question posted on the "Welcome, Make Yourself at Home" post from Jason (see, now I imagine reading this with my awful Casey Casum impression):

I was wondering how you handle submitting when using a tabbed iform. (one HTML page with multiple tabs via JavaScript)

Example: (abominal pain)
Tab 1 - Lower abd pain - has 3 prechecked selections
tab 2 - Upper abd pain - has 4 prechecked selections.

When you submit, how do you submit the orders on one tab without the orders on the other tab also being submitted?

-Jason

This is an excellent question: as it's phrased, it can't be done; you can't submit some of the items in a web form. However, there are ways to work around these limitations. Let's take a look at a few of them to see what the pro's and con's are.

Assumptions

There are some things to keep in mind when using tabbed iForms. They're great for keeping your screen real estate in check, but they can be tricky when dealing with patient safety.

As a general rule for ALL iForms, you want to make sure that the user "sees" and effectively is choosing everything that ultimately gets ordered through it. That means that if you want to place a CBC, you make sure that somewhere on the page, (1) it has a checkbox that says it's for a CBC, (2) it has a bundled order that says that it includes a CBC, or (3) somewhere on the form it says that if you submit the form, it will order a CBC by default. It's a big no-no to do otherwise.

This is where using tabs can get tricky.  How do you keep using tabs while making sure that the user actually wants to order everything that you've pre-selected?  On a standard non-tabbed linear iForm, you make certain assumptions that the user has agreed to what's pre-selected by the sheer fact that they made it to the bottom of a page (think Terms of Service when installing software; some companies make you scroll all the way to the bottom before you can accept).  On a page with tabs, you need to make sure that they at least "see" everything that's pre-selected.

Method 1 - Put the Submit Button on the Last Tab

This can really only work if you have two tabs of orders.  Since you open the form on the first tab, you can assume that the user "agrees" to order everything pre-checked on it.  Then, before they can submit the form, they must go to the second tab to find the submit button.

There are some problems with this approach.  Like I said, you can only really have two tabs or at least only have pre-checked items on the first and last tab. Also, it would require some good user communication or training to avoid the flurry of phone calls / complaints when the users try to find the submit button.

Effectiveness	High	The user cannot submit unless he/she visits both tabs
Flexibility	Low	You are restricted to two tabs to do it "right"
Difficulty	Minimum	If you're already using tabs, it just requires you to move your submit button
User Friendliness	Awkward	Honestly, if you're considering this method, I'd recommend a "wizard" interface instead (think TurboTax).  For example, see what this jQuery plugin does: FormToWizard Plugin

Method 2 - Don't Pre-Check Anything Unless It's on the First Tab

Like I said above, you can treat the first tab just like any other iForm with pre-checked items since they'll visit that tab by default every time, but they're not "forced" to visit any other tabs.  That being said, you can limit yourself to only pre-checking items on that first tab and nowhere else.

It's not very friendly, but bluntly effective and requires no additional scripting.

Effectiveness	High	The user will not get "blindsided" with orders that they didn't see.
Flexibility	Low	You're restricted to pre-checking items on the first tab.
Difficulty	Minimum	If you're already using tabs and choosing things to pre-select, you're already there.
User Friendliness	Fine	This approach doesn't change the user experience; it just prevents you from giving them pre-selected options that they may have wanted otherwise.

Method 3 - Don't Pre-Check at Load, but Pre-Check on Tab's First Visit

If you're handy with your javascript, you can leave all but the first tabs items unchecked but programatically select the specific items in the tab on the tab's first visit.  This could be useful for an iForm that has, let's just say IV Fluids. Not all patients using this orderset will need IV Fluids, but your customer has asked that they want the Saline Well to be pre-checked if the user wants IV Fluids. To this end, you can leave everything including the Saline Well to be unchecked until the user first clicks on the IV Fluids tab. Once the tab is first clicked, the Saline Well checkbox gets selected and it's completely transparent to the user.

The tricky part here is how to make sure that you only make updates to the tab elements on the first visit. The last thing you want to do is make changes to the form elements after a user has specifically set them.

Effectiveness	High	The user will not get orders that they didn't "choose"
Flexibility	Medium-high	This approach has some good applications, especially if you want to have "mini ordersets" within your larger iForm.  That is, "If you visit Tab X, you'll initiate the X protocol" by pre-selecting certain items.
Difficulty	Medium-high	You'll want to make sure that your scripting works correctly and only triggers on the tab's first visit or you may overwrite what a user has selected (or intentionally un-selected).
User Friendliness	Pretty good	But you'll want to communicate that pre-selected items are only pre-selected if you visit the tab.  You may come across a user that starts using your iForm, gets comfortable with it, knows what to expect on each tab, and assume that the pre-selected items will order even if he/she doesn't visit the tab.

Method 4 - Reset the Tabs Each Time They're Changed

This works best for iForms whose tabs are not separate sections of an overall orderset, but rather separate exclusive orders (think Emergency IV Fluids vs. Routine IV Fluids, or maybe a Peds Orderset vs. an Adult Orderset). Jason's example above involves choosing between Upper Abdominal and Lower Abdominal Pain, so it fits here.

In this case, you'd want the inactive tab(s) to clear when a new tab is chosen. That is to say, uncheck everything that is not on the current tab (you may also want to clear textboxes and what-not, but that depends on how you've mapped the iForm; most of the time, if the corresponding checkbox is unchecked, it doesn't really matter what's in a supporting textbox or combobox).

With this method, you'd do something similar to what I described in Method 3. When you select a tab, you programatically select whatever items on that tab that they want to be "pre-checked" but then you'd go one step further; you uncheck everything else (I mean everything else, not just those things that were pre-checked). This is one of the few times that you can override what the user has requested.

With this method, you can effectively send "half of the form" by making sure that all items are unchecked in the inactive part of the form.

Effectiveness	Very High	Not only will the user not be blindsided by orders they haven't seen, they'll only order those items on the current screen.
Flexibility	Medium	While this provides all the functionality you could ask for pre-checking items, it's pretty limited to the type of ordersets that have exclusive selections.
Difficulty	Medium-high
User Friendliness	High, but with a caveat.	If you mix this method with other tabbed iForms that work differently and don't remove the orders from other tabs, your users may get confused. I'd exercise caution if you're going to mix them and make sure that there's clear communication about how each works and where they're used.

Method 5a - Prevent Submission Until All Tabs Are Visited

If you can track when a tab has been visited at least once like in Method 4, you can track each of your tabs and make sure that the user visits all of them before you allow them to submit the form (set the enabled attribute of the submit button to false). This will effectively force your users to view the entire iForm, just like scrolling to the bottom, before they can submit it.

The downside is that the user has to click several times before they're allowed to finish, even if they don't care about a particular section. The upsides are that there's less scrolling and better screen-real-estate management possible and that it visually separates the information that the user sees at any given time.

Effectiveness	High	The user sees every tab and effectively approves of the current state of things.
Flexibility	High	You can pre-check whatever you want on whatever tab you want and can have more than two tabs.
Difficulty	High	You need to be able to know when ALL of the tabs have been visited at least once to enable the submit button.
User Friendliness	Medium	The users may be confused about why the submit button is "greyed out," so you'll need to provide some documentation / communication / education. Some users complain particularly about a "click-count" and this method may require the user to click on tabs that they don't care about AND don't have anything pre-checked. To this end, Method 5b is preferred.

Method 5b - Prevent Submission Until All Required Tabs Are Visited

Just like in Methods 4 and 5a, you'll need to be able to track when a tab is first visited. The difference from 5a is that you only need to require the user to visit tabs that have something pre-checked.

Effectiveness	High	The user sees every tab that has at least one item pre-checked so you have their implied approval of the orders.
Flexibility	High	You can pre-check whatever you want on whatever tab you like and have more than two tabs.
Difficulty	High	Higher than 5a, given that the logic is more complex. You have to either hard-code each tab to say whether it's required at start-up or determine that programatically. You'll also want to find a way to show the user which tabs are "required" to visit.
User Friendliness	Medium-high	You'll still need to provide education and some people may still complain about a "click-count," but it's a little bit more defensible than Method 5a. You'll need to train your users how to recognize which tabs are required, then make sure that they know what to do.

Wrap-Up

Each site is different and requires its own level of finesse. Personally, I use Method 5b for our tabbed iForms (you can see some examples in the iFormLibrary) and, if I need to do something exclusive like Jason describes up above or like I mention in Method 4, I'd probably try to avoid using tabs and stick with sections that show / hide based on user-input.

I don't say that because the solution is a bad one. I just value consistency and want to make sure that the user experience is intuitive. If I throw too many variations in that look similar, our users are more likely to make mistakes, and even though I'm not a "clinical person", patient safety is still #1.