Re: [platform-ui-dev] Blocking UI: Wizard Dialog modality

[Stefan Xenos <sxenos@xxxxxxxxxx>]

Jim said:

> Well, the user can be half-way a wizard and then set the state in such a way that the wizard is not valid anymore. For example if someone is in the 

> "create a class wizard" and then deletes the underlying project.

Although that's true, it's not a justification for blocking the user's access to the app. Such problems throw checked exceptions which we already handle. If the user were to delete a project while in the middle of creating a class, they would see an error message describing the problem. They would know what went wrong and be able to recover from it. We're basically faced with two choices here:

1. Prevent the user from ever requesting two operations at once since they might ask for something contradictory.

2. Allow the user to have multiple operations going on at once and if they ask for something contradictory, tell them about the problem and give them the tools to fix it.

Provided we tell the user why the operation failed, I don't think that the possibility of the user requesting two contradictory things is itself a serious enough problem to warrant restricting the user's freedom.

  - Stefan

On Wed, Sep 14, 2016 at 8:12 AM Stefan Xenos <sxenos@xxxxxxxxxx> wrote:

Eric said:

> Why not just make non-modal Dialogs / Wizards 'Editors' (i.e. site them in the editor area with their own tabs...)

Strongly agree. Years ago I actually coded a toolkit to make it easy to implement such things, and I could probably reproduce something similar if we wanted to experiment with it.

Mikael said:

>  I don't think this would fit. One expects an editor to be a way to view and change a file. Dialogs have another purpose which is to "actively" interact with user

> without necessarily being related to a file or a modified artifact.

I disagree. I ran this experiment once by implementing this paradigm in an Eclipse-based product. The user feedback we got from it was overwhelmingly positive. In one case we ran the opposite experiment of replacing several of these editors (we referred to them as "edilogs") with dialog boxes and there was immediate negative feedback. Users prefer the edilogs.

> IMO, dialogs and editors are better being kept separated, or it will become more complex for users to figure out where to find the interaction they want and what kind of

> effect they can expect from the items shown in the usual editor stack.

Users are already familiar with the paradigm of having an editor that isn't associated with a file, since this is what any modern web browser uses as its UI paradigm. We've all used a wizard embedded in an editor every time you've signed up for a forum account, and most of us probably never noticed. If anything, users are more familiar with this than they are with dialog boxes.

In the case of my experiment, above, we ran a lab UX study and none of our participants were confused by it.

Eric said:

> Fair enough...try 2...how about having a single window hosting all currently active Wizards / Dialogs, each with their own tab

Sure, it's good to consider lots options when brainstorming, but your first suggestion was brilliant. Let's not give up on it so quickly.

  - Stefan

On Wed, Sep 14, 2016 at 7:43 AM Eric Moffatt <emoffatt@xxxxxxxxxx> wrote:

Fair enough...try 2...how about having a single window hosting all currently active Wizards / Dialogs, each with their own tab (think of it as a specialized Detached Window) ? If neither of these approaches work then you're limited to the 'many windows' paradigm.

Eric


Mickael Istria ---09/14/2016 09:57:16 AM---On 09/14/2016 03:51 PM, Eric Moffatt wrote: >

From: Mickael Istria <mistria@xxxxxxxxxx>
To: platform-ui-dev@xxxxxxxxxxx
Date: 09/14/2016 09:57 AM

Subject: Re: [platform-ui-dev] Blocking UI: Wizard Dialog modality
Sent by: platform-ui-dev-bounces@xxxxxxxxxxx

---

On 09/14/2016 03:51 PM, Eric Moffatt wrote:

Why not just make non-modal Dialogs / Wizards 'Editors' (i.e. site them in the editor area with their own tabs...)

I don't think this would fit. One expects an editor to be a way to view and change a file. Dialogs have another purpose which is to "actively" interact with user without necessarily being related to a file or a modified artifact.
IMO, dialogs and editors are better being kept separated, or it will become more complex for users to figure out where to find the interaction they want and what kind of effect they can expect from the items shown in the usual editor stack.
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev

_______________________________________________
platform-ui-dev mailing list
platform-ui-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/platform-ui-dev