Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.How can we improve the Rules UI for Drupal 8?
Rules-specific proposals
Workflow-related ideas
Which UI changes in Drupal 8 can we leverage?
Let's start a discussion
Comments
Comment #1
dasjoComment #2
Honza Pobořil CreditAttribution: Honza Pobořil commentedCurrent UI is too much code-like, so it is not understandable by non-IT people. I recommend to go this direction:
Many people from business are used to use UML Flow chart like diagrams and often this kind of diagrams are used as assignment of us, programmers. The world will be much better place if non-IT people will be able to "program" Drupal by interface similar to tool they know (Visio etc.). Imagine Drupal Commerce where marketer will be able to configure automated emailing based on customers' actions.
Good inspiration is Kentico CMS (shitty CMS in .Net, but with good UI): http://devnet.kentico.com/articles/kentico-cms-7-advanced-workflow
Check this video too, UI is described here: https://www.youtube.com/watch?v=x-lS45CGCvI)
Comment #3
dasjoComment #4
dasjoBobík - thanks for your suggestion. i'm adding Rules Transformers as a reference, which is a Drupal 7 based solution that implements such an interface for Rules
https://www.drupal.org/project/transformers
Comment #5
fubhy CreditAttribution: fubhy commentedI am adding NoFlo UI as a reference
https://github.com/noflo/noflo-ui
Comment #6
dasjorestructured & added Drupal 8 style guide references
Comment #7
dasjoComment #8
LewisNymanHey, thanks for kicking this off. If we end up creating a new UI, can we consider a process of getting the UI elements generic enough that they can be pulled back into the style guide and reused by other modules?
Comment #9
dasjodefinitely!
a major goal of rules 8.x is make things even more reusable: for example we want "Embeddable Rules UI components to integrate actions & conditions"
http://d8rules.org/content/overview-rules-8x-features
the Rules UI should not be its own beast but try to leverage as much of the patterns & UI components that we have in D8 already.
-> borrow add dialogs from Views UI or Block UI?
-> try to come up with a draggable table solution that works for nested rule configurations?
talking about process, we'd be willing to take advice in how to set up a proper process of developing such a new interface. it doesn't have to be a revolution, but at least we should solve some of the current pain points that new site builders have with understanding the rules UI.
Comment #10
LewisNymanThe highest level we can start at is the user stories that contain the most UX pain? I think it makes sense to do as much work as we can with existing UI components and noting the need for new ones.
For the record, I'm pro a transformers like UI. I just think we need to plan the implementation so the CSS and JS is set up to be reusable elsewhere. Maybe I want to use those connecting lines to show relationships between other entities? Just an example.
An IFTTT style teaser for every rule is good, the biggest challenge there is assigning icons to represent every entity/action in the system (and creating new icons where we need them).
Comment #11
dasjoas everything in D8, the UI should be responsive. with transformers this could lead to scrolling around in every direction?
this hasn't been written down yet or specified well at all, but the idea is the following:
currently, to implement any nested logic you have to think inside-out. create any rules components, define their parameters and then you can use them in an outside rule.
fago's point to not include something like rules_conditional within rules core itself was to keep things simple. on the other hand, i think for any logic that requires some if/else statements, it requires you to create lots of components and isn't user friendly.
rules in D8 will allow nesting -> at least on the api level we will allow for something like conditional rules or subrules within rules. yay :)
displaying arbitrary nested rules in the standard table format would lead to a bit of indentation, which probably isn't too bad. i think it would be great to be able to create the nestings top-to-bottom. if there too little space, we might have to hide the underlying logic, create summaries and/or allow to dive into deeper levels of the logic.
just some more ideas, would be happy if anyone can provide a structure where to put them :)
Comment #12
fubhy CreditAttribution: fubhy commentedResponsiveness is out of question for the NoFlo-ish UI, true... But that's not a blocker though. It's fine to not have that UI on mobile devices as long as the basic (and equally functional) UI works. Who is going to use that UI on mobile devices anyways? Who does site building his/her smartphone or tablet? :P I mean... You know that I am all +1 on responsiveness and UX for mobile users but we gotta stay realistic ;)
Comment #13
dasjoi'm all in for fancy stuff as an optional extension, but the assumption that users won't do complex things on mobile is dangerous.
from my perspective, responsive should never limit the user in the set of actions they can perform. even if i won't build complex rules from my mobile, i probably want to fix/adapt some settings here and there...
Comment #14
LewisNymanWe can't have a functional mobile UI in Drupal that breaks when certain modules are downloaded. It's a blocker.
Comment #15
dasjo@lewis what do you mean by "that breaks when certain modules are downloaded"? can't follow :)
Comment #16
Bojhan CreditAttribution: Bojhan commentedHmm, I am not sure I understand the goal here. What resources are available for this? I was in the understanding that you didn't scope nor budget for UX work.
The best you can than do is optimise your UI slightly, fundamental changes to go for a different UI model. Like the visual programming language ones shown above, would require significant work from both a UX person and developers. I think its important to understand, that small optimisations are fine - but they will not be groundbreaking.
Comment #17
fubhy CreditAttribution: fubhy commentedCorrect. But you don't have to use the NoFlo-ish UI for that. You can always use the 'normal' one of course.
Comment #18
dasjo@bojhan: you are right - we didn't scope for a whole redesign of the UX and the main idea was to re-implement the existing rules UI based on Drupal 8 best practices in an as-much-as-possible-reusable way.
we are about to finish milestone 1 before drupalcon amsterdam and UI implementation is planned for milestone 3, so this feels like a good place to start the overall planning.
fago nico and others have put effort into re-thinking the rules UI as per the fluxkraft mockups linked from the issue. currently we don't have the funds to promise anything, but like everything in drupal we can make it happen together with the community.
the main idea here is to brainstorm possibilities for a better rules UI. both iterative improvements and revolutionary ideas are welcome.
the most effective i guess would be to get into a deeper discussion about how to implement the current rules UI based on D8 best practices and UI components taking possible nesting of logic into account.
Comment #19
Honza Pobořil CreditAttribution: Honza Pobořil commentedBtw, I think there are some UI changes what could occur in data structure changes.
For example this use-case:
should not require to break it to one Rule and one Component because of "wait 1 week", but it should be in one rule, one flow chart where "wait" is only one of actions.
I think this should improve simplicity dramatically. It should be useable for every "typical corporate man" who knows flow charts.
Comment #20
LewisNymanIf some parts of the Drupal interface works on a phone, then they click a menu link and it's totally broken, that affects the user experience and breaks the trust the user has built up in the 'product'. Fubhy already mentioned that we could just degrade back to the normal form so nvm
Comment #21
sascher CreditAttribution: sascher commentedI know there is some sort of duplicated functionality with the rules transformers module, but I was wondering if any of the elements used in Maestro could be included.
Comment #22
paean99 CreditAttribution: paean99 commentedIt seems to me that a plugin system would be the best approach.
I mean, a system where the logic of the rules module would be separate from its UI. Then i, as a user, could have 'transformer' plugin and 'NoFlo UI' plugin installed and i could switch from one to the other with just a radio button or select list. And i would always have the default UI for 'graceful degrade'.
If the system was really separate, it would also facilitate developers to create or adapt new kinds of UIs for Rules.
I am not measuring the necessary changes in the code here :p
edit: i am not just talking about a myUiHook_Rules kind of plugin, but more about a theming UI (css, javascript, ...). There is all kind of javascripts libraries out theres that could be used and the ease for the UI developer would be a great boost.
Comment #23
deggertsen CreditAttribution: deggertsen commentedI haven't read all the posts above but I Just wanted to throw this out there. It sounds like what we're wanting to accomplish is something similar to what Infusionsoft has done with their campaign builder. Here is a link to where their campaign builder is explained:
http://ug.infusionsoft.com/article/AA-01060/180/Marketing/Campaign-Build...
Just thought if we're having this discussion about UI improvements that this might add to the discussion.
Comment #24
dasjomany commenters here seem to like the idea of a flow-chart like implementation. from my point of view this is very much out-of-scope for Rules itself but could be implemented as an alternative UI like https://www.drupal.org/project/transformers.
as stated in #11 and the following, the Rules core UI should be responsive and cater both newcomers as well as advanced users. i think we should focus on applying https://www.drupal.org/ui-standards and solving problems like adding & overview in a common way together with other complex modules likes Views UI, Panels UI, etc.
Comment #25
dasjothe UI-standards link is pretty dated.
check out #2293627: [meta] Document Human Interface Guidelines and make Seven style guide
Comment #26
a.milkovskyContrib for rules filtering https://www.drupal.org/project/rules_filter
Comment #27
dasjoWe had some good Rules UI discussions last night. I have documented it in this google doc:
https://docs.google.com/document/d/1cQ-uJB7bFvXR1YKkj8T72ZOzXGNhuIv334eH...
We are already working on some UI tickets, see the roadmap #2245015: [META] Rules 8.x Roadmap. I will create a meta issue for the UI now.
Comment #28
dasjoComment #29
LewisNymanToday I went over some really high level UX stuff with Josef, so I can understand the problems better. We add a few rough personas, user stories, and user journeys to this document: https://docs.google.com/document/d/1cQ-uJB7bFvXR1YKkj8T72ZOzXGNhuIv334eH...
The next steps after this would be to map out the user journeys, and identify weak steps.
Comment #30
XanoFollowing our discussions at the Drupal Dev Days I split off plugin selectors to their own module. Let me know if there are any specific issues I can help with.