624834 - Improve UX for multi-tabbed dialogs.

Status: RESOLVED FIXED

(Websites Graveyard :: drumbeat.org, defect)

Description

[Paul Osman [:paulosman]]

We use multi-tabbed dialogs in Batucada for project editing, profile editing and account preferences. At the moment, each tab is a separate page view which, while functional for users without javascript, presents some serious UX problems: 

1) It's cludgy. 
2) It's confusing and error prone. Clicking on a tab will cause non submitted data on the previous tab to be lost. 

Need to fix before we launch the initial release.

Comment 1

[Ned Schwartz]

I agree and have been thinking about ways around this.

One solution is to add a class to js-enabled modals and target that class in a jquery selector to convert the links on the tabs (and the various submit buttons) to ajax calls that slide the next pane in.

I like this approach as it follows good unobtrusive js practices: as paul points out, the app is still very usable for those without js.

Comment 2

[Paul Osman [:paulosman]]

Sounds good to me. 

One point though, do the tabs have to be populated with remote content? I wonder if we could pre-load all of the tab content and just hide content not on the active tab. In fact, we may *have* to do this, so it's all part of one form. Imagine for instance clicking on "Edit Project", filling in a new short description, then clicking over to Detailed Description and filling that in. When the user clicks on "Submit" on the Detailed Description tab, their new short description should be saved. 

Also, I'm noticing that we've mixed paradigms somewhat in the tabs. Some are like I describe above (cut up parts of the same form) whereas other tabs, like "Links" and Image Upload are distinct / separate functions. Curious to know if you have thoughts on this. 

Finally, whatever we do, we should make sure to play well with browser history (i.e. http://bugs.jqueryui.com/ticket/4587).

Comment 3

[Ned Schwartz]

What you say about having unsaved data is a very good point and something I thought when looking at the designs. I went ahead with the implementation as specified as I understood that it would be best to move forward and get things working and then double back and ask these questions. 

I am glad you raise them now though!

In fact the modal really should have one submit button as you say; that is the implied UI model that is in effect. It is confusing to have the multiple submit buttons above and outside the forms. 

I am not sure how this effects users who don't have javascript: do we still store the forms separately and serve them as separate pages for those users, or do we send them one long form? If the former, ajax requests could be served a page (from the server or 'pre-fetched' via ajax) that is has a set of tabs compiled form all the separate forms in that modal.

To address what you say about separate paradigms, I think if we in-line all the forms (and switch between them using js tabs), then they would all have to be submitted simultaneously. This is easily done using jquery and ajax. I am thinking something like: hide the submit buttons on the individual tabs, add a "super submit" that loops through all the forms in the modal and submits them. Or right some sort of dispatcher on the server that recieves the massive form with the data from all the sub-forms and dispatches requests to the various models with the appropriate data.

The "state" of each form would need to be maintained from tab to tab: this isn't a problem if the tabs remain non-destructively as nodes of the html document: the input values will be preserved. A js warning could be poped up onunload if there is unsubmitted data in the form (by marking fields as 'dirty' as their values change and checking this in the unload event).

Finally as far as history goes, it should be simple to add #hash state to the tabs. There are many good jquery history plugins. This is a good discussion of the field: http://stackoverflow.com/questions/116446/what-is-the-best-back-button-jquery-plugin

Comment 4

[Ned Schwartz]

Another thought is to save each setting via ajax as each individual input loses focus without ever having to hit 'submit' (cancel would have to be able to restore all the original settings). This is how OS X does things.

Alternatively, (and perhaps a little more performant as far as server requests) each tab could submit via ajax when it loses focus.

Comment 5

[Paul Osman [:paulosman]]

(In reply to comment #3)
> To address what you say about separate paradigms, I think if we in-line all the
> forms (and switch between them using js tabs), then they would all have to be
> submitted simultaneously. This is easily done using jquery and ajax. I am
> thinking something like: hide the submit buttons on the individual tabs, add a
> "super submit" that loops through all the forms in the modal and submits them.
> Or right some sort of dispatcher on the server that recieves the massive form
> with the data from all the sub-forms and dispatches requests to the various
> models with the appropriate data.

I don't think this solves it. Think of the User Profile dialog, where you have "General Info" with fields like "Full Name" and "Location" as well as "Links". Links are associated with User Profiles, but they are not part of User Profiles. You can't submit that form when a user clicks "Save" on the General Info tab or similar. I think we're going to have to treat each tab as a separate form. This will work as-is for users without JavaScript, which is a nice side effect. We can tweak and improve later. I'm thinking that this is demonstrating that things like Links don't belong in the User Profile dialog, so maybe we'll split it out in a future release and move to something similar to what you're describing here. 

(In reply to comment #4)
> Another thought is to save each setting via ajax as each individual input loses
> focus without ever having to hit 'submit' (cancel would have to be able to
> restore all the original settings). This is how OS X does things.
> 
> Alternatively, (and perhaps a little more performant as far as server requests)
> each tab could submit via ajax when it loses focus.

I don't like the extra round-trips or the idea of introducing a new state (saved but not committed). Why don't we use localStorage? Am I crazy, or can we just chuck the form values into localStorage, falling back to cookies on older browsers. We could even use something like this: https://github.com/brianlovesdata/tastyStorage ?

Comment 6

[Ned Schwartz]

> I think we're going to have to treat each tab as a
separate form.

If we do that - I vote we put the submit and cancel buttons inside the panel as opposed to in the title bar. Having the buttons outside the actual form/tab implies that it applies to all tabs.

I still think the buttons will have to submit via ajax. That should be simple enough though.

> Why don't we use localStorage?
localStorage is a great idea! And that looks like a wicked implementation. 

One problem with each tab being it's own form is; do we allow users to move between tabs with unsaved data? what happens when they edit one tab, move to the next and hit save (or close?)do we warn them? This seems confusing.

I think that if we have tabs then their needs to be a single submit/cancel for all tabs.

I am not sure why links need to be saved separately?

Comment 7

[Paul Osman [:paulosman]]

We've settled on a partial solution for launch, enough to close the bug. Will probably revisit tabs in a future iteration, but that'll warrant another bug anyway.