After proposing "minimally" viable product changes to the Admin UI in #1495552: [Meta] Improve overview page, I thought about how to further integrate related, proposed changes into the UI. This issue is a separate proposal.

These designs build on the previous one (see #1495552: [Meta] Improve overview page first). It rests on a few principles: there are many overlapping identifiers shared between rule config objects that inherently reveal their connection to one another, which could really tie together navigation. Overall, components provide extreme extensibility for rules, yet they are underutilized at major moments of value. And, there is a major overlap for when a site builder needs individual conditions and actions, as well as, condition sets and actions sets, yet the navigation between their sections is very difficult. See more below.

These are some of the things going on with this mockup:

Reaction button links:
+ :: add another event
- :: remove this event
δ :: schedule this rule
Φ :: execute now

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

mitchell’s picture

Will post higher quality version later. Compressed for bandwidth purposes.

dasjo’s picture

a general note: for me, the multitude of interlinked UX-related issues is getting confusing. while i find it great to have momentum on this, having a [Meta] Improve overview page + [Meta][2] Improve overview page + several related issues created makes no sense from my point of view.

regarding contents i like some ideas here:
- better filtering as tags are visible and can be used for navigational purposes. the downside is that the sidebar consumes horizontal space.
- better overview & easier navigation for different rule plugin types (rules & components like conditions, events, ..) seems like a good idea.

i don't think listing all the events for reaction rules in the proposed styles - stacked within a column - makes sense. the ui will get cluttered.

generally, my proposal would be to keep a clear distinction of global editing functions and the edit form of a single component:
we should describe any a rule / component by providing some information on what it does in the overview.
but the real editing functionality to sub-parts of the rule / component (events, conditions, actions) should not clutter the overview page but remain in the edit page.

regards

mitchell’s picture

Title: [Meta][2] Improve overview page » Create "vertical_tabs_interlinked" branch
Project: Rules » Rules UI Mockups
Version: 7.x-2.x-dev »

while i find it great to have momentum on this, having a [Meta] Improve overview page + [Meta][2] Improve overview page + several related issues created makes no sense from my point of view.

Thank you for pointing this out. I've moved the issues related to mockups to this new project, and have left the api related change issues.

i don't think listing all the events for reaction rules in the proposed styles - stacked within a column - makes sense. the ui will get cluttered.

That's very similar to how it works on the current overview page. I've made the text editable. What seems better to you?

we should describe any a rule / component by providing some information on what it does in the overview.

"Generating human-readable labels" seems to be a highly anticipated feature, see #1244738: Provide a description field and #1331556: Debug log: add component name. I haven't added that to the mockups yet, because I haven't been able to think up a complete example.

a general note: for me, the multitude of interlinked UX-related issues is getting confusing. ...the real editing functionality to sub-parts of the rule / component (events, conditions, actions) should not clutter the overview page but remain in the edit page.

That's why I'm naming this branch "interlinked" to get a good sense of what are the implications of this. I can see what you mean that, so far, it looks cluttered. My main reasoning behind this is that rule/component configuration pages seem to not make much use of all the left-right real estate. Their names, parameter, and provided variables usually take up only 1/5th of the left column, and the right column, which takes up only ~%15 of the page width, includes a redundant edit link and a delete link.

If the including the sub-parts of the rule / component are unappealing so far, then I wonder how you might feel with a mockup that makes use of modal dialogs the way views ui does. Right now, I'm curious about each of their potentials, and also how the two might benefit from one another.

mitchell’s picture

Title: Create "vertical_tabs_interlinked" branch » Explore embedded / interlinked configuration screen
Status: Active » Needs review
mitchell’s picture

Title: Explore embedded / interlinked configuration screen » Overview page: Interlinked Design
zhangtaihao’s picture

Might be worth keeping in mind that modules (and concepts) like http://drupal.org/project/transformers exist. Given that Rules execution relies heavily on available variables being provided, asserted, and selected, surely there must be some way to generalize the whole affair of configuring bits of Rules altogether. EDIT: ... into a totally graphical interface.

dasjo’s picture

for me, it gets quite confusing when issue titles are changed too often

dasjo’s picture

Issue summary: View changes

referencing execute button issue