Wednesday, February 23, 2011

Nested sandbox editors?

I received an interesting question in the mail today regarding Sandbox Editors and the advice I offered in a previous post:

I am using the Contact example with the SandBoxEditor and Editor for the basis of my app. When I have a listView which pops up a dialog should my dialog always use a separate repository instance to work with the detail record? If the detail record pops up a new dialog to gather some additional information should it also use a separate repository instance.

I guess what I am asking should I always protect a parent view from changes in a child until the user make the change permanent? Is this what you would do in a real application?

The essence of the question is in this one line: “should I always protect a parent view from changes in a child?”

First of all, I always avoid the word “always”.  But seriously …

The point of the separate repository is to isolate the editing context from the main application context. Within the sandbox I would tend to use the second, isolated repository everywhere … unless I thought the user experience required secondary isolation in which case I would “sub-sandbox.”  I’d be surprised if this is really what the user wants.

Let’s step back a bit. Early in my Sandbox Editor post I stressed that some folks prefer seeing the provisional changes propagated across the UI … as they happen. In my mind that is a perfectly reasonable experience. If the user expects it and the view design supports that expectation, all is well.

For example, if the grid and the detail form are side-by-side on the page, I personally would expect the grid to update as I typed in the detail form.

However, when the editor hovers on top of the grid (as it does in the Intersoft sample), I’m more inclined toward the sandbox editor. Even then it’s an option, not a rule. You have to feel it out with your users.

Notice that John Papa’s Book Club application has only one “DataService”. He does not sandbox. Changes in the overlay editor are reflected immediately in the grid. Is that good or bad?

Back to your question: should you “sub-sandbox”? Only you know what makes the best user experience for your application. The way you design the screens may influence your decision.

Myself, I would not sub-sandbox. To sub-sandbox would make it more complicated for me and, more importantly, seems likely to confuse my users. I would try to arrange the view so that they expected to see values propagate to the parent window. Maybe I wouldn’t have a parent/child window.

You won’t know what is “best” until you give your users a chance to try it. Maybe you can show them both designs (in a paper model) and see what they think.

2 comments:

Anonymous said...

If the user is editing a dialog box that has a save and cancel button, do you not think that it is confusing for them to be seeing the changes showing on the parent form and knowing that they have not yet saved or cancelled the current changes they are making?

Ward Bell said...

I agree with you that an overlay, modal editor with save and cancel buttons probably favors a sandbox approach.

I am also saying that not everyone agrees. I've seen plenty of UIs where pending changes in the dialog were mirrored parent in the main form. To my knowledge, users were NOT confused ... or at least no one reported that they were confused. That doesn't mean they weren't confused. I'm only saying that we don't have the data.

My other point in this post is that much depends upon how you structure the view. You don't HAVE to use a modal dialog for editing.

I'll tell you what I do find confusing: modal dialogs on top of modal dialogs. Maybe someone should reconsider that rather than embark on a russian-doll arrangement of nested sandboxed editors.