Wireframes! - Rules UX reloaded by fluxkraft

fago's picture

As introduced recently we've started working on a new Rules UI as part of the fluxkraft project.

So after quite some planning and discussion we came up with some wireframes that should show how we imagine the new Rules UI to work. The wireframes are not very detailed - expect the details to change - but still the wireframes should show the overall idea.

So let's have a look at them and discuss :-)

Browse rules screen

Browse Rules screen

This is the screen as known from "Rules" and "Components" tabs. It provides an overview of all rules matching the criteria. The idea here is to provide a visual summary of what's configured in a rule via icons. Each rule element (event, condition, action) gets its icon and a summary if you hover over the icon. Also note that events, conditions and events all get their own geometric shape.
On the right side you see a list of available operations, while we plan to leverage drop down buttons to hide away not so common operations like "disable", "export", ...
Oh and yes, we really need to implement a long overdue feature: descriptions for rule configurations.

Ok, so once you edit a rule you'll get to next screen:

Rules edit screen - overview

Editing and adding a new rule all happens on one screen. It gives a detailed (not directly editable) overview of the whole rule:

Rule edit overview with (closed) condition group

If you add or edit something you won't leave the screen - part of the screen will reload to show you the necessary form, while after submitting the form it will reload again and replace the form with the summary of the edited area.
For example, when you'd click on the summary or icon of the "Post tweet" action it replaces the summary of the action with an edit form without leaving the page. Once you submit the form it brings you back an updated summary on the overview, while the whole rule won't be saved until you press "Save" at the overview page.

For adding a new event, condition or action a greyed out empty element will be already visible. Clicking on it will load the add screen there. More experienced users can also hover over the small points between the icons on the left and get an "Add action" drop down there. This drop-down allows you to add an action at a certain position instead of adding it at the end and moving it around afterwards. Also, it's an "Add action" drop-down as there other not so common choices like "Add loop", but that's hidden away by the drop-down button by default.

Rules edit screen - add event

So this is how an "add screen" for events, conditions or actions would look like - in this example we are adding a new event:

Add event selection

So instead of the big "select box" which we have now, we'll group available events/conditions/actions by categories ("groups"). Each category will get its own icon which integrating modules can provide. (Yes, we need to come up with a style-guide here!) Once you click on a category item, the list of available items below is instantly filtered by the category. Also, we think that adding a search-box and an optional description to each listed item would make sense here.

With that new screen we should be prepared for the number of available events/conditions/actions increasing significantly!

Editing a condition group

As you may know Rules supports groups of conditions and actions, i.e. condition or action plugins containing other conditions or actions - such as logical OR or AND elements or LOOPs. If you have a look back to the "Rules edit screen" you notice a condition group there which contains two conditions. In the overview this renders just as known from the "browse rules" screen, so you get an overview of what's in there. If you edit this condition group, you'll get to that screen:

Rule edit overview with open condition group

The list of contained items (conditions here) will move from the horizontal line to the usual vertical arrangement on the left with the summary of each item on the right - so it renders the same way as top-level conditions on the "rule edit overview" screen. Above of the contained conditions the settings of the whole condition group are rendered and may be edited with the usual approach: A click on it replaces the summary with an edit form and submitting that brings you back to an updated summary.

Editing a condition within a condition group

So, now what if you edit a condition within a condition group? We'll just repeat the pattern and turn the condition into edit mode:
Rule edit screen editing a item contained in a condition group

Of course, this could be nested arbitrarily as you can do that now. While it will work, it won't look very nicely with multiple nested groups - just as now. I do not think this is the 90% use-case to cater for, so that should be enough.

New stuff?

Oh, yes there is some new stuff on the wireframes. First off, you see a small stopwatch which allows you to schedule any rule on its own without having to create a Rules component first. This should make the powerful scheduling feature much easier to use and bring sophisticated repeat and postponing settings. But let's have a closer look at this in a later discussion.

Next, you may notice the "Test rule" area at the bottom. The idea behind that is that you can run a test of your rule even without saving it - on some real data but without executing anything. For that we'll probably allow events to provide some testing-data and fall back to require users to provide some test data, e.g. provide a node-id for testing it. That's the idea - there are no more details on that for now.

Feedback!

So what do you think about this UI? Which ideas suck and what do you like? Do you think it will help to simplify Rules so much that an average users could make a clue of it? Or editors could use a stripped-down variant having less available events/conditions/actions?

Let's discuss :-)

Thanks go to grienauer for working out the wireframes and to the rest of the fluxkraft team for providing ideas and feedback!

AttachmentSize
Browse Rules screen69.2 KB
Add event selection49.79 KB
Rule edit overview with (closed) condition group32.12 KB
Rule edit overview with open condition group44.07 KB
Rule edit screen editing a item contained in a condition group52.18 KB

Comments

Really interesting!

Itangalo's picture

A few comments:

1

Of course, this could be nested arbitrarily

Not very many people could say this in a credible way. :-)

2
The "stopwatch" functionality seems like a good way to make Rules Scheduler more known and used. Great idea.

3
Same thing with "test this rule" – a good way to make the "execute component" functionality more known and used.

4
The first wireframe image contains "share" buttons. Is this "export", or is it something new?

5
Icons kick ass, assuming they will be implemented. For me, writing an action is pretty easy, but creating a suitable icon on (say) 64x64 pixels is really difficult. Could I ask for a standard library of 20–30 icons to choose from, as a fallback?
Also, the descriptions will be critical, since many icons will be difficult to interpret (even if they are unique). I can imagine some hard-core Rules users will prefer a slim text-only interface. But I have no doubt that icons will be of help and much appreciated by the majority.

6
I got the feeling that the extended search/filtering capabilities to browse existing rules is extended, compared to current Rules UI. Is this true, and are there any thoughts on how they can be improved? I've heard site builders talk about problems keeping order among the rules.

7
Will Rules components and reaction rules live on the same page? (Please say yes!)

Awesome work. Looking forward to seeing more stuff, and the discussion around it.

Thanks for the feedback! Same

fago's picture

Thanks for the feedback!

Same thing with "test this rule" – a good way to make the "execute component" functionality more known and used.

Yes, but I'm not sure yet whether we should really execute the rule or just print out which actions would be executed with which parameters. E.g., if you'd have a page redirect in there and we'd really execute it - it would redirect you away from your unsaved edit form. :-(

Maybe we could add a checkbox like "Dry run" which is checked by default?

The first wireframe image contains "share" buttons. Is this "export", or is it something new?

There will be export, but we also plan for enabling the sharing of rules with a community site where people can browse rules and easily take them over. We've got some ideas here, but we are not sure how far we'll be able to take that.

Icons kick ass, assuming they will be implemented.

True - good catch. Icons are per category, i.e. per module by default while probably will allow for optional per action icons also. So the hurdle isn't necessary for adding a new action, but when integration a new module. While not every module will need its own category, many will. I guess we could provide a fallback icon which just has a background in Drupal-styling and gets a few configurable characters from the category - e.g. just two or three letters.
I think it's important to have unique icons per category as else distinguishing them becomes difficult, so auto-generating some default would probably be better than a library?

I got the feeling that the extended search/filtering capabilities to browse existing rules is extended, compared to current Rules UI. Is this true, and are there any thoughts on how they can be improved? I've heard site builders talk about problems keeping order among the rules.

We have not really thought about that - more in the relation of making add action/event/condition screens usable with lots of items. Any ideas on how to improve the filtering options? I guess a filter by categories used would be useful?

Will Rules components and reaction rules live on the same page? (Please say yes!)

I've not planned or thought about changing that. Why do you think that would be better? Less hopping around?
If we'd not have the separated UIs, wouldn't users confuse reaction rules with rule components easily?

Just some quick

Itangalo's picture

Just some quick comments/replies:

Maybe we could add a checkbox like "Dry run" which is checked by default?

I personally don't think page redirects is such a big issue, so just executing the rule seems like a a good default to me. A bigger issue might be sending out e-mails, so having a "dry run" option might be called for anyway.

I think it's important to have unique icons per category as else distinguishing them becomes difficult, so auto-generating some default would probably be better than a library?

+1 to that!

Any ideas on how to improve the filtering options?

Filter by category, search on included plugins, and a free text search (especially if descriptions are added).

If we'd not have the separated UIs, wouldn't users confuse reaction rules with rule components easily?

After a lot of pondering, I don't think reaction rules and Rules components are that much different at all. If you remove all events from a reaction rule, you end up with something that is very similar to a rule component. I think (correct me if I'm wrong) that all component types could be provided with events and then treated as reaction rules – except the condition components.

On the other hand, components have parameters and provided variables in a way that reaction rules don't.

Hm.

Maybe it isn't such a good idea to have them on the same screen. If there's good search/filtering UI, then having them all on one screen is easier. Until then, having them separated is probably easier for most people.

Icons

Grienauer's picture

I will provide an icon template and styleguide and hopefully also a bunch of predesigned standard Icons for starting...
It would be a big help if I know which icons I have to design for a good starting point... ...maybe in an separate issue queue?

hopefully the mock-ups give you a good overview of our plans...

why not use CSS font

bennos's picture

why not use CSS font icons?!?

there is a drupal module
http://drupal.org/project/fontello

which integrates with the icon api
http://drupal.org/project/icon

and both modules are integrating the fontello.com open source icons.
http://fontello.com/

Think other icon provider can also be used.
CSS Icons can be scaled and colored.

Would be a flexible solutions.

Rules

Group organizers

Group categories

Categories

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: