Make it possible to select multiple event sources when adding an event

[Mads]

I'm a bit surprised that I could not find this suggestion already...but hopefully then it's not just an oversight by me...:

In the Edit Events dialog you can only add events from one source at a time, it should be possible to select multiple sources and add the same single (OR multiple there as well) events from those sources in one go. The event source selection should filter the events-list so that only the events that are common for the selected sources are shown.

In pictures...you should be able to do what I have imagined(!) doing in the bottom picture here:

[JackDunaway]

+1! Not mentioned, but also support Shift+Click for inclusive range selection (this is intrinsic to the Tree Control, so goes without saying...)

[altenbach]

Limiting multiple selections to event sources is still too narrow.

We should equally be able to select multiple events for the same source.

(For example "Key down" + "key repeat", etc.).

[Mads]

Yes, altenbach, absolutely. I do mention that you should be able to select multiple events as well as sources, but I did not include that part in the title 🙂

[Christina_R]

While I certainly sympathize that this dialog is tedious for the multiple event case, your proposal violates a number of user interface design principles.

The dialog is designed such that the items inside the box (the Event Sources and Events lists) show and modify attributes of the selection in the Event Specifiers list. You can't have subordinate controls modifying their master's selection.

I would love to hear alternate proposals, but keep in mind that the dialog has to support all three of the following use cases:

1) different event sources with different events,

2) one event source with multiple events and

3) multiple event sources with one event.

If you remove the Event Specifiers from the design, you can support 2 or 3 but not 1.

[Mads]

Christina, I think the source of the problems you point out comes from the fact that the event specifiers list is automatically highlighted when you work with a given source.  You have a two-way communication between the controls even at single-click selections - and the direction of the flow is designed not with creation of events as the primary mode, but  editing of existing events...that's why the event specifiers list is on the left and the source list is on the right - you expect the user to work his way from specifier to event.

In the case of event case creation however the user will normally work in a way that would require the source list to be the leftmost control, the events list in the middle - and the resulting event specifiers list on the right...If you kept this ordering and kept selections from causing any effects in the right to left direction (other than by the use of the buttons) then things would flow better.

I might overlook something here, I cannot say that I've tested the above mentioned comments so there might very well be holes in the logic, however I *am* sure that there is and should be  (dictated by the need) a way to allow people to add events from multiple sources in one operation.

[Christina_R]

So, if I understand correctly, you're proposing that we have a completely different dialog for "Add events case" than "Edit events handled by this case." Then you would presumably also have to have a new right-click option for adding events to an existing case, and design how you would show the existing events at the same time as your new way of adding them. And would you not be able to edit those pre-existing events without dismissing that dialog and going to the Edit events one?

[Mads]

No I would just change how the current dialog is orientated:

The way I see it the current window puts the main focus on how to change events you have already specified. You go from left to right - first you select an event that has already been specified...then you can change the source of that event, and finally the type of event.

The problem with this approach is the fact that 9/10 times the dialog is used to add new events, not change events you have already defined (because you most likely defined those just right the first time...).

If we reorientate the window so that the list of already specified events is the leftmost control...then things begin to flow in the way you think when you are adding events:

 1. Select source(es), 2. select event(s) 2. add to list. 4. Complete.

You might think that it's a bit less intuitive if your intent was to edit the already specified events...(the user threshold is relatively low though - after all there is a clear direction here where you go from "sources" to "result" in the left to right direction)...but it's an OK sacrifice if it optimizes the GUI for its primary task (adding/defining new events).

[Christina_R]

It's hard to picture this without a mockup, but it sounds like with your proposed dialog you can't edit an item in the list (the Event Specifiers, which you've moved to the right). It wouldn't make sense to select an item on the right and have the lists on the left update because the list on the right is now an accumulation of operations from the left two lists.

So if you did need to change one of those, you would have to delete it and then add the corrected version?

[Mads]

Requiring you to delete specified events instead of editing them would be a clean solution yes.

You delete those that you do not want, and add those you want...- It makes more sense than to select one you do not want - to edit it into something else.

Allowing "backflow" by highlighting things in the source and events list as a reaction to clicks on an item in the specifiers list would have illogical consequences (related to your original reaction I would say).

I've just been thinking out loud here so far. Finding the exact solution would definitely require a mockup or two yes... 

[Christina_R]

Here's a VI mockup of the current dialog (front panel only) in case you want to try dragging things around and making some pictures: mockup VI.

For any design you'd like to propose, I suggest that you run through the following sample use cases and make sure they are all reasonable workflows:

1) Adding handling code for the value change of an OK button.

2) Adding handling code for the "mouse enter" event for all controls on the panel.

3) Adding handling code for the  "mouse enter" and "mouse leave" event for a single control.

4) Adding handling code for the "mouse enter" leave for one control and "mouse leave" event for a different control.

5) Changing existing handling code from the value change of one button to the value change of a different button.