[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ui-best-practices-working-group] [platform-ui-dev] Blocking UI: Wizard Dialog modality

Just FYI, in our experiment we replaced all dialog boxes. Not just settings and preferences. We replaced all wizards, confirmation dialogs, and property pages that weren't locked in place by the Eclipse platform.

Anything that opened asynchronously became a notification. Anything that opened synchronously became an edilog. In the case where you had a background operation that needed to prompt the user for something, you'd either embed interactive controls in the notification (for simple user responses like confirmations) or you'd allow the user to click the notification to open an edilog (for really complicated stuff).

For output-only stuff (progress dialogs, etc.), we'd embed feedback within the control that launched the operation.

I'd be in favor of the Eclipse platform using the same paradigm and eliminatingÂall dialog boxes.

We don't need to dive all-in right away, though. We could start with the low-hanging fruit you mention and then move on to the rest of the stuff based on how we like the initial set of changes. I suspect they will be very well received.

 - Stefan

On Wed, Sep 14, 2016 at 8:18 AM Doug Schaefer <dschaefer@xxxxxxxxxxxxxx> wrote:
BTW, Iâve seen a lot of IDEs that use âeditorsâ for project settings and preferences instead of dialogs. That may be the lowest hanging fruit for us.

From: <platform-ui-dev-bounces@xxxxxxxxxxx> on behalf of Stefan Xenos <sxenos@xxxxxxxxxx>
Reply-To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Date: Wednesday, September 14, 2016 at 11:12 AM

To: "Eclipse Platform UI component developers list." <platform-ui-dev@xxxxxxxxxxx>
Subject: Re: [platform-ui-dev] Blocking UI: Wizard Dialog modality

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


Inactive hide details for Mickael Istria ---09/14/2016 09:57:16 AM---On 09/14/2016 03:51 PM, Eric Moffatt wrote: >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
_______________________________________________
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