Improved promotions form #1509

jhawthorn · 2016-10-07T22:42:05Z

I think it is universally agreed that the promotions form is too complicated and confusing.

Existing form:

I felt that one of the biggest problems with this form is that it is difficult for an inexperienced user (and even users with years of spree/solidus experience) to know how to create a new promotion that activates when they want it.

A user needs to know

What "Apply Automatically" means (that it will be applied to all orders)
What "Path" means (probably not used by most stores)
To get a single promotion code (a very common use case) "Number of codes" must be set to 1 and then "base code" can be used as the desired promotion code.
How the promotion code generator works and how to download the codes when specifying multiple codes.

To make this easier to use, I've created a set of radio buttons to help guide a user to their desired behaviour without knowing the meanings behind all these magic fields.

These radio buttons are only used by JS and aren't persisted.

Redesigned page

Designing things is usually not my forte, but I think this is an improvement. I started by splitting the fields into three sections, with the last one being the new radio buttons.

Radio buttons

Work to do:

There will be updates needed after Promotions remember their base code #1410 (or equivalent) is merged
Figure out what to do on the edit page
Fix specs

gmacdougall · 2016-10-14T16:00:43Z

Thanks for working on this John. I feel it is an improvement.

jordan-brough · 2016-10-14T17:19:43Z

Very 👍 on this! If we merge #1524 we'll want to take that into account also yeah?

Mandily · 2016-10-14T22:23:50Z

This is awesome! 👍 Way better than what we have now. With regards to the questions in your "work to do" section:

Multiple activation types could mean we use checkboxes instead of radio buttons if we want to allow a user to make any combination of options. If we wanted to restrict them to certain combinations, it might be better to make that combination a new radio button option.
Tooltips: the new bootstrap layouts will allow for substantial helpful information to be added to the sidebar, so we might want to just make a note of what we'd like on the page for the time being and then add that information when we switch this page over to the bootstrap layout in the future.

jrochkind · 2016-10-14T22:56:31Z

Definite huge improvement.

Whether part of one PR or not, I think the "view" and "edit" screens for existing Promotion need attention too. Might make sense to make part of same PR for 'edit' at least, since that's actually the same partial I think, if you don't attend to it it could make it even worse.

One of the problems with "edit" screen is it is currently, is that it's not possible to show actual base code for multi-code promotions, since it's not preserved. Current edit screen just picks the first code in the database, and labels it 'base code' in the UI, which isn't right. PR #1410 would make promotions remember their base code, which could allow view/edit on an existing promotion to make more sense.

jhawthorn · 2016-11-01T21:24:17Z

Multiple activation types could mean we use checkboxes instead of radio buttons if we want to allow a user to make any combination of options. If we wanted to restrict them to certain combinations, it might be better to make that combination a new radio button option.

Though we do allow combinations in the data-model (both a code and a path, for example), I think it's an uncommon use case that we might as well just hide in the UI for simplicity.

Tooltips: the new bootstrap layouts will allow for substantial helpful information to be added to the sidebar, so we might want to just make a note of what we'd like on the page for the time being and then add that information when we switch this page over to the bootstrap layout in the future.

Sounds good.

mamhoff

I've left a completely minor nit, but am fine with the UI changes and like the new code better (like splitting up the Coffeescript by calculator).

mamhoff · 2016-11-02T09:47:10Z

backend/app/views/spree/admin/promotions/_form.html.erb

    </div>
  </div>

-  <div id="expiry_fields" class="three columns omega">
-    <%= f.field_container :overall_usage_limit do %>


This is a super-nit. Should we be mixing old- and new-style Hash syntax in the same line? I feel like if we touch the line anyways, we could just switch it over to new if nothing stands against it.

This should be slightly nicer than seeing an error after a round trip to the server. Disabled elements are skipped for HTML validations, so this works with the hidden elements.

jhawthorn · 2017-02-02T22:12:32Z

I have rewritten this to work after the changes in #1524.

I've gone with a very simple solution for the "edit" action, and I'd like to make further improvements in a separate PR.

We didn't previously allow editing codes on existing promotions. The code field was marked readonly and the controller didn't support it. I've made this (hopefully) more clear by just printing the code as text.

This is ready for review

tvdeyen

Great improvement. I created a follow up for further improvements #1702

isaacfreeman · 2017-02-05T01:08:18Z

This is a big usability improvement from a small change. 👍

Could we provide some additional indication to users that clicking a radio button will reveal further controls? Most radio buttons don't do that, and the initial state has no controls to the right, so it might not be obvious. This could be as simple as adding an ellipsis ... after the labels for those radio buttons that bring up other fields.

Beyond the scope of this pull request, I feel like these four radio buttons are conceptually closer to being Promotion Rules than attributes of the overall Promotion. They're all conditions under which the promotion will be activated. I appreciate that would entail a significant change to the code, but I wonder whether promotions would be easier to understand if we could push more features down into Rules.

kennyadsl · 2017-02-05T09:30:09Z

backend/app/views/spree/admin/promotions/_activations_new.html.erb

@@ -0,0 +1,66 @@
+<% activation_type = params[:activation_type] || 'single_code' %>
+<div class="row" id="js_promotion_activation">


@jhawthorn why you are not using dash but underscores to separate words for all elements ids?

jhawthorn added UI changelog:solidus_backend Changes to the solidus_backend gem labels Oct 7, 2016

jordan-brough mentioned this pull request Oct 14, 2016

Add promotion code batch #1524

Merged

mamhoff approved these changes Nov 2, 2016

View reviewed changes

jhawthorn force-pushed the promotions_redesign branch 3 times, most recently from 48d85ce to 708d915 Compare February 2, 2017 20:48

jhawthorn removed the WIP label Feb 2, 2017

jhawthorn changed the title ~~[RFC] Improved promotions form~~ Improved promotions form Feb 2, 2017

jhawthorn force-pushed the promotions_redesign branch from 708d915 to d3d4a53 Compare February 2, 2017 21:33

jhawthorn added 2 commits February 2, 2017 13:55

Simplify promotions form

374b931

Add required attributes to Promotion fields

6b9b720

This should be slightly nicer than seeing an error after a round trip to the server. Disabled elements are skipped for HTML validations, so this works with the hidden elements.

jhawthorn force-pushed the promotions_redesign branch from d3d4a53 to 6b9b720 Compare February 2, 2017 22:01

jhawthorn added the Code review needed label Feb 2, 2017

tvdeyen mentioned this pull request Feb 3, 2017

Promotions form further improvements #1702

Closed

8 tasks

tvdeyen approved these changes Feb 3, 2017

View reviewed changes

jordan-brough approved these changes Feb 3, 2017

View reviewed changes

jhawthorn merged commit bf04986 into solidusio:master Feb 3, 2017

jhawthorn deleted the promotions_redesign branch February 3, 2017 20:03

kennyadsl reviewed Feb 5, 2017

View reviewed changes

jhawthorn mentioned this pull request Apr 4, 2017

Promotions with multiple codes: codes locked and cannot be edited or created #1819

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improved promotions form #1509

Improved promotions form #1509

jhawthorn commented Oct 7, 2016 •

edited

Loading

gmacdougall commented Oct 14, 2016

jordan-brough commented Oct 14, 2016

Mandily commented Oct 14, 2016

jrochkind commented Oct 14, 2016 •

edited

Loading

jhawthorn commented Nov 1, 2016

mamhoff left a comment

mamhoff Nov 2, 2016

jhawthorn commented Feb 2, 2017

tvdeyen left a comment

isaacfreeman commented Feb 5, 2017

kennyadsl Feb 5, 2017

		@@ -0,0 +1,66 @@
		<% activation_type = params[:activation_type] \|\| 'single_code' %>
		<div class="row" id="js_promotion_activation">

Improved promotions form #1509

Improved promotions form #1509

Conversation

jhawthorn commented Oct 7, 2016 • edited Loading

Redesigned page

Radio buttons

Work to do:

gmacdougall commented Oct 14, 2016

jordan-brough commented Oct 14, 2016

Mandily commented Oct 14, 2016

jrochkind commented Oct 14, 2016 • edited Loading

jhawthorn commented Nov 1, 2016

mamhoff left a comment

Choose a reason for hiding this comment

mamhoff Nov 2, 2016

Choose a reason for hiding this comment

jhawthorn commented Feb 2, 2017

tvdeyen left a comment

Choose a reason for hiding this comment

isaacfreeman commented Feb 5, 2017

kennyadsl Feb 5, 2017

Choose a reason for hiding this comment

jhawthorn commented Oct 7, 2016 •

edited

Loading

jrochkind commented Oct 14, 2016 •

edited

Loading