Pinging @danielle, @Sara, @sstead, @lin_d_hop, @Olivier, @NickWeir
PROPOSAL
Intro
This is my current understanding of what is required based on my reading to date and discussions I’ve had this week with @Sara, @danielle and @sstead. If anyone has any reservations, thoughts or alternative proposals, let me know. I’m still trying to work out a vague estimate for all of this work, as you can see it’s a massive job.
There are lots of elements to this, but we think we have come up with a way of providing most of the features we are looking at in a relatively cohesive package. In keeping with our existing design principals, we tried to design a system with the potential to allow a high degree of flexibility for power users, but which hides complicated functionality for new / inexperienced users by default and has simple initial iterations for proof-of-concept.
Approach
Our thinking to date has narrowed in on an expansion of the tagging system found in the customers interface, allowing tags to also be applied to shipping methods to begin with for a proof of concept, then to variants (in the inventory, rather than globally), outgoing exchanges in order cycles (essentially a shopfront instance) and payment methods, and then potentially things like fees at some point in a future iteration.
In and of themselves, tags on customers, variants or outgoing exchanges would have no effect whatsoever on the behaviour of those objects. This would allow tags to be used for simple information management if that is the desired use case.
The way that we propose to implement the functionality that we are looking at around customisable user experiences in the shopfront is to have a set of “Tag Rules” defined at the enterprise level that describe the effects that tags have when they are applied to customers, variants, and outgoing exchanges. This is very much going along the Zapier path of having a defined (yet highly extensible) set of options for describing interactions between tagged objects.
As a first phase, the idea would be to build a few desirable “pre-canned” (simple and work “out of the box”) rules that apply to a named customer tag, with the understanding that more complex rule types could be added later on. Rules would be grouped by the tag on customer for readability.
I’ve identified five basic rules types that I think cover the most commonly requested use cases (let me know if you think something should be included or excluded):
- “For customers tagged X: hide order cycles tagged Y”
- “For customers tagged X: show order cycles tagged Y”
- “For customers tagged X: hide products tagged Y”
- “For customers tagged X: show products tagged Y”
- “For customers tagged X: give discount of X%” (or $X)
Basic wireframe:
I propose that we do this work in a couple of phases, to give us a chance to look at what we’ve built and make sure we are going down the right path. There is a bit of background work that I propose we do before actually implementing tagging and rules.
Phase 1: Basic infrastructure + Proof Of Concept Rules
Adding the bare minimum set of features required to test that tagging is going to be an effective way of defining rules about customisation of shopfront experience, plus some very simple rules to prove the concept.
-
[Feature] Enterprise user can require login for their shopfront and display a message to users who are not logged in.
- This feature has come up in this discussion, but is not itself dependent on tags and is not overly complex, I say we build it and get it over and done with.
-
[Feature] Allow enterprise users to manually create customers for their hub (without that customer necessarily having to place an order with the hub first)
- Routing, views, controller actions for creating customers
- Logic around what to do when a user with the given email does not yet exist
- Add the customer anyway, so that tags can be added
- (Optionally?) Send an email to the address provided, suggesting they create an account
- Associate customer with user when it is created?
- what is the benefit of this?
-
[Feature] Enterprise user can shipping methods
- Add acts_as_taggable_on to shipping method model
- Add tagging input to shipping method edit interface
-
[Feature] User can manage tag rules to apply two basic rule types to their shopfront: whole order discounts for certain customers and availability or otherwise of shipping methods for tagged customers.
- Design and build the model that will contain information about which rules apply and how they are applied to the shopfront.
- Add “Tag Management” or “Tag Rules” tab to Enterprise edit interface
- Basic version allows user to create new rules, edit them, and delete them
- To begin with will aim to support three basic rules types:
- “For customers tagged X: give discount of X%” (or $X)
- “For customers tagged X: prevent use of shipping method Y”
- “For customers tagged X: allow use of shipping method Y” (eg. could show “Free shipping” for #local customers)
-
[Feature] Rules defined by the user have their intended effect in the shopfront
- For discount rule this applies when products are added to the cart
- Need to investigate whether Spree’s existing promotions infrastructure could be useful, though I suspect that getting this to work may be more trouble than it is worth…
- For shipping method availability rules, this just applies on the checkout.
Phase 2: Wholesale and Usability Improvements
Some additional user experience improvements will be necessary after the initial round to make tagging useable and intuitive. This phase will also introduce six new rule types for use by shops that want to offer wholesale functionality by showing/hiding products and/or whole order cycles, as well as offering different payment terms to customers based on tags.
-
[Feature] Tag assignment interfaces (on customers, variant overrides, order cycle exchanges) expose information about which tags are affected by rules, with links to view/edit rules.
-
[Improvement] Other as-yet-unknown improvements to usability that come out of phase 1.
-
[Feature] Enterprise user can tag variants in inventory
- Add acts_as_taggable_on to variant_override model
- Add tagging input to inventory interface
-
[Feature] Enterprise user can tag outgoing exchanges
- Add acts_as_taggable_on to exchange model
- Adding tagging input to existing interface
-
[Feature] Enterprise user can payment methods
- Add acts_as_taggable_on to payment method model
- Add tagging input to payment method edit interface
-
[Feature] User can manage more types of tag rules for implementation of “wholesale functionality”.
- Add support for six more “pre-canned” rule types:
- “For customers tagged X: hide products tagged Y”
- “For customers tagged X: show products tagged Y”
- “For customers tagged X: hide order cycles tagged Y”
- “For customers tagged X: show order cycles tagged Y”
- “For customers tagged X: prevent use of payment method Y”
- “For customers tagged X: allow use of payment method Y”
-
[Feature] Rules defined by the user have their intended effect in the shopfront
- For order cycle rules, these apply when the shop page is loaded
- Do we want some intelligent logic around which order cycle gets loaded when a choice is available and we have additional information about customer type via tagging?
- For product/variant visibility rules, these apply when the shop page is loaded
Phase 3: Cover more of the most requested use cases for customer tagging
- Build a rule creation wizard
- Add basic rules for payment method availability
- Add rules about how fees are applied
- Add more complex rule construction capabilities for power users eg. “For customers tagged W, apply a X% discount, on products tagged Y, for order cycles tagged Z”
Thoughts?
potential rephrase of info tab…
