Rules/Actions thoughts

[Daniel Siemer]

So, in IRC a while back, the concept of rules and actions came up to replace the current applications configuration.

We need to make it as clear as possible to the user what actions will be taken based on a rules list that could easily have overlapping conditions in it.  In the case of overlapping rules, collapsing the set of actions isn't too bad an idea, except for visual display actions, which we should probably only have one of.  

I have a concern that disabling applications is presently easier than it will be using a rules system, and harder than notifications could be under the previously proposed changes to the Applications tab.  Under this system you would need to add or modify a rule to disable them, and know where to place it in the list of rules so that it got evaluated early.  

Some things that we can consider, are whether to use a flat or hierarchical set of rules, and the same for the condition set for each rule.  

Attached is a pretty rough image from interface builder.  It has a list of rules on the left, conditions for that rule up top, and a list of actions below that.

Yes, this would be a major change to the backend of how Growl works, but the other proposed designs aren't without their work either.  Im not sure that it is any less cluttered, or easier to support ultimately than the previous thread of designs, but the number of rules a basic user needs is minimal (default + disabled mainly), and for the power user, it can add lots of power.  We can keep the types of conditions limited initially, and add new ones (like regex, or time of day) later on.  

[Evan Schoenberg]

Rather than a list of rules on the left, I would still organize rules by application (plus an 'all applications' default set at the top).  This would let us allow disabling/enabling on a per-application basis, either by a checkbox at the top of the rules area ("enable notifications" checked by default; unchecking it grays out the rest of the pane) or by a rule 'suppress notifications' which could be easily placed within that application's context. The checkbox is probably more intuitive for most of our users.

 

I don't think 'also perform default actions' is needed; instead, I would have an action which stops any further actions, and also have smart handling to avoid duplicate behaviors (1 sound per notification max, 1 display per notification max, etc).

-Evan

--
You received this message because you are subscribed to the Google Groups "Growl Development" group.
To post to this group, send email to growl-de...@googlegroups.com.
To unsubscribe from this group, send email to growl-developm...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/growl-development?hl=en.

[Peter Hosey]

On Nov 14, 2010, at 10:15:16, Daniel Siemer wrote:
> It has a list of rules on the left, conditions for that rule up top, and a list of actions below that.

Maybe someday, but in the interest of simplicity (both for users and for us), I'd recommend this instead:

- Sidebar: Applications and notifications, plus “All notifications”.
- Upper view: List of actions for selected application/notification/magic meta-item.
- Lower view: Action editor for selected action.

The sidebar could be an outline view, with notifications subordinate to applications, with checkboxes on all of them (with the same meaning as now: “do nothing for this application/notification”). The only one that shouldn't have a checkbox is “All notifications”, since that would be our current “Hide all notifications” option.

> Im not sure that it is any less cluttered, or easier to support ultimately than the previous thread of designs, but the number of rules a basic user needs is minimal (default + disabled mainly), and for the power user, it can add lots of power.

Clutter is a major concern. Our current UI already gives much power to power users, but it's confusing for novice users.

What I've suggested above should be easily comprehensible to novices, while still giving more power to power users. It'd also be much easier to implement, since we wouldn't also have to add the regex matching and date matching.

What you showed might be good for 3.0, as an evolution of what I described above.

[Peter Hosey]

On Dec 23, 2010, at 08:31:38, Evan Schoenberg wrote:
> I don't think 'also perform default actions' is needed; instead, I would have an action which stops any further actions, and also have smart handling to avoid duplicate behaviors (1 sound per notification max, 1 display per notification max, etc).

I'd suggest having the inverse of “also perform default actions”: “Don't perform inherited actions”, or something like that. For example, I might set it to speak every Adium notification, but “don't perform inherited actions” (don't speak) for “Message Received”.

I don't think we need a “stop actions” action, since the actions need not be user-orderable. I suggest we fix the order of actions at:

1. Display (visually)
2. Play sound
3. Speak
4. Custom actions added by plug-ins

[Daniel Siemer]

I think we can go one better for simplicity for the basic user. If we
provide a meta action type (multiple actions, a display), and move all
the misc settings for displays that are presently in the applications
tab to the configuration for each display action, and Chris's idea for
allowing multiple configurations for any given display type. We could
have a tree of applications/notifications, with just one pop up box
per item, the meta action to take (and thus no need for separate
panes, just one big tree list). The pop up could have a disabled and
default options, eliminating even a checkbox (but not on the meta
"Global default" since that would be turning off/hiding all. I know
its not a very shiny UI, but it is simplistic, and it doesn't remove
any capability if we move settings to their appropriate actions.

The fancy rules UI can be put off, but I think improving the UI
experience for the new user in 2.0 should still happen.

[Peter Hosey]

On Dec 23, 2010, at 09:33:59, Daniel Siemer wrote:
> If we provide a meta action type (multiple actions, a display), and move all the misc settings for displays that are presently in the applications tab to the configuration for each display action, and Chris's idea for allowing multiple configurations for any given display type. We could have a tree of applications/notifications, with just one pop up box per item, the meta action to take (and thus no need for separate panes, just one big tree list). The pop up could have a disabled and default options, eliminating even a checkbox (but not on the meta "Global default" since that would be turning off/hiding all.

This might be better shown than described, because I have no idea how it would work.

[Daniel Lee Siemer]

Two shots of a rough mockup, first is of an applications tab done with a tree, and a single selection. Its not flashy, and yes, it harks back to older versions, but it should be simplistic for new users to figure out (and yes, I forgot the icons on the apps, I was fudging the mockup) . Second is of an actions tab concept, showing a meta/combination action (naming needs some work there). Apologies this took so long, holiday's and other things got in the way.