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:
- the focus is on integrating most of the screens into a single page
- the overview page becomes a total control page
- actions and action sets are still missing
- conditions aren't done but have a workable starting point, see also #1495718: Add option to convert a set of conditions or actions to a component
- the need for modal dialogs is very low but might be able to improve certain parts
- removed import/export ui options based on logic of #1496184: Factor out import/export ui elements to a sub-module
- merging component creation and editing screens within broader config options (hopefully). Related: #1495718: Add option to convert a set of conditions or actions to a component
- merged rules scheduler, vbo-style #1490158: Execute rules items immediately, and events configuration into "Reactions"
Reaction button links:
+ :: add another event
- :: remove this event
δ :: schedule this rule
Φ :: execute now
Comment | File | Size | Author |
---|---|---|---|
#1 | rules-overview-redesign-tighter.jpg | 87.09 KB | mitchell |
#1 | rules-overview-redesign-tighter.bmml_.txt | 18.85 KB | mitchell |
Comments
Comment #1
mitchell CreditAttribution: mitchell commentedWill post higher quality version later. Compressed for bandwidth purposes.
Comment #2
dasjoa 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
Comment #3
mitchell CreditAttribution: mitchell commentedThank 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.
That's very similar to how it works on the current overview page. I've made the text editable. What seems better to you?
"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.
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.
Comment #4
mitchell CreditAttribution: mitchell commentedBranch is @ http://drupalcode.org/project/rules_ui_mockups.git/tree/refs/heads/inter... with one previous diff.
Comment #5
mitchell CreditAttribution: mitchell commentedComment #6
zhangtaihao CreditAttribution: zhangtaihao commentedMight 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.
Comment #7
dasjofor me, it gets quite confusing when issue titles are changed too often
Comment #7.0
dasjoreferencing execute button issue