D7UX Microproject - Trigger UX
| Project: | Drupal |
| Version: | 7.x-dev |
| Component: | trigger.module |
| Category: | task |
| Priority: | normal |
| Assigned: | JoshuaRogers |
| Status: | needs work |
| Issue tags: | actions, D7UX, d7ux-microprojects, trigger, Usability |
UX miniprojects are here to encourage more User Experience people to participate in the Drupal Project.
Objective of this microproject:
To consider Trigger module and what modifications could be made in order to support a better end user experience
There is a corresponding Project Framework page for this element on D7UX.org here
Next steps:
- Post any information that's helpful for a newcomer to Drupal who will be addressing the UX aspects of this issue. Sceenshots are probably best, a demo site would be great.
- Leave a comment if you would like to volunteer as a DEVELOPER or USABILITY mentor for this issue.
- The UX Volunteer for this project is free to choose the channels and media to work in, but will use this issue to report their findings for review and feedback.
- Drop by in #drupal-usability in IRC and talk to Leisa or yoroy if you have questions or feedback on this process, this is a trial so any input on how to improve is appreciated.
Note that we do not expect the output of every microproject to be implemented or implementable. Any usability gains from this process are a boon to D7, but getting more UX people into the Drupal community and finding ways for them to work more effectively with developers are our core goals.
And please, play nice. The issue queue can be quite intimidating for newcomers so let's try to be extra welcoming here.
Go!
#1
UX Volunteer: Marcus Blankenship (pending acceptance)
UX Mentor: TBC
Dev. Mentor: TBC
Please volunteer if you'd like to mentor on this microproject in the comments below.
Please understand that UX Volunteers are often new to the Drupal community and as such they may not be aware of work done to date.
We do and do not wish to 'reinvent the wheel' so pls take a moment to call out the relevant people/projects so that they can get familiar as soon as possible. Thank you for your help with this.
#2
Never spotted this before.
As someone who has not really used trigger much, I must say one of the big things that struck me was that actions and trigger are so far apart in the UI.
Wordkflow wise I would assume it would be common to:
1. Create action
2. Use trigger to act on action.
or:
1. Go to trigger.
2. Not see action.
3. Go to actions, add action,
4. Go to trigger...
So the two are tightly coupled in workflow, however in the admin backend, the two are totally separate. Having the modules be aware of each other could help a lot.
In trigger, have an option to "create action" in the list of options that are presented - and clicking that can take you to a page where any context relative fields are prefilled.
In Actions, have a link to go to trigger the actions.
#3
Some screenshots
Actions overview:
Configure an advanced action
Triggers for node
#4
The most critical part, IMO, would be to merge the UIs for administering Actions & Triggers, or at least to have them in the same section of the /admin screen. As it is, I've seen Drupal users who didn't even realize the relationship between them.
Maybe there should be a multi-step, "wizard"-style form that would let you define an action and then immediately define the conditions under which it would be triggered.
We should probably compare the Actions/Triggers UX to the UX for Ubercart 6's Conditional Actions module. I believe they are much more integrated in that system. I can't find a good link w/screenshots for Conditional Actions off-hand, but here's something from the docs: http://www.ubercart.org/docs/user/7657/configuring_conditional_actions.
There's also the Rules module to compare, of course (www.drupal.org/project/rules).
#5
Something to note: technically, actions are not tied to triggers. They are a core Drupal concept (an extension of system.module) that could theoretically be used outside of the context of the trigger module.
With that said, the actions administration page is way too isolated right now. I took a moment to make a rough sketch of how I think the triggers administration page could better incorporate actions administrative functions:
With an interface such as the above, it's possible that either: (a) the actions page could go away when the trigger module is enabled, (b) the trigger page could replace the actions page when the trigger module is enabled, or (c) both pages will exist, but will be much more interconnected than they are currently.
Disclaimer: I am not a usability expert. This is just my rough idea of how to create a more usable triggers/actions interface.
#6
Actually having the Actions page, without trigger enabled is a usability bug, because you can configure actions, but you can't do anything with them. Actions live in system.module so that Rules can meddle with them, in its current form it doesn't make any sense. So, if this were to go in, I think, the "Actions" page should disappear.
Also note that this would be so much cooler with harmonicas as in #492834: Hover operations for flooded state screens. I like the screenshot in #5, though.
#7
After thinking about it for just a little bit, I came up with this alternative. From an end user perspective, action and trigger seem to be two parts of the same thing. Since that's the case it seems that the user would have the greatest chance of understanding if "triggers" and "actions" are treating as though they have relation in the interface.
In this design Trigger is moved to be a child of actions. Instead of "Comments, Content, Cron..." as the top tabs, it's broken down into the two logical steps: Add action and assign trigger. The first tab "Add action" is the action page as it now exists. The second tab, "assign trigger" is a slight redesign of the trigger page. Each cateogory of trigger appears in a fieldset instead of a tab.
I think this might lend to a more simple interface.
#8
#9
Okay, it certainly isn't done, but I would like some feedback. It still needs a little CSS to even up the layout. It also needs javascript to narrow any options that aren't available. That's a must. Other than that, how does it feel in practice?
I'm mainly concerned with the workflow. (Everything else should be a relatively simple patch.)
#10
#11
The last submitted patch failed testing.
#12
I like the pattern embodied in #7 screenshot. (Haven't tried the patch yet.) It reminds me of setting up rules for inbox filtering interfaces in email programs.
#13
Josh, the patch you have attached is for update module.
Could you re-roll a patch for the changes you've made for Actions / Triggers so we can review?
#14
subscribe
#15
Sorry about that! Somehow that update for #13 must have slipped by me! I know it's after code freeze, but since this is usability... I'll see if I can't post a new patch in the next day or so. (Yeah. I was playing with the update module at the time and seemed to have crossed my patches.)