Free Idea: Use Liquid for Discounts

[Ryan Alyea]

Since I desperately need more programmable discount codes, here's an idea I came up with I'll let you guys have for free:

Use Liquid for discount codes. It does what I need, mostly a bunch of if/else statements. Why not use Liquid to have it output something like "1234567890,5.00,buy 3 get 4th free" where the first part is the line item id, the second is the amount of discount, and the rest is a comment to the customer about why the discount exists. Something like "order,5.00,some title" would be a whole order discount code.

(However, I very much prefer line item blaming for discount codes. I need to know why a discount code was given. If it was for buy 3 get 4th free on one product, I need accounting for that one product being discounted, so shopowners can use DeepMine to see they are not making much money on the free item, not just lower totals in general.)

This way, I can upload a few Liquid scripts that are each run during the discount page (last page?) of the order process. It doesn't need to do a pingback to my server, which I'm assuming is why this feature has been delayed for years. Plus, this can be run on the cart page too.

Liquid is chosen for it's security. While uploading any kind of scripting language to run would work, Liquid is already used heavily in Shopify.

[Christopher Saunders]

Liquid is really just a templating language though, I don't see this being a really good general purpose solution.  While it might seem to work for a bit, once we get into anything more complicated it'll just fall apart.

I was thinking about a language to use for general purpose discounts, and was thinking lisp would be a good solution.  Everyone cringes, because parenthesis scare them, but if you look at it from a UI standpoint, building an s-expression is pretty simple and making a discount builder would be drastically easier since everything can be abstracted away with macros.

It's also nice because then anyone who knows how to program can simply go in and write up crazy discount logic.

There's also been talk about going with Javascript, which is an alright alternative.

--
 
 
 

[David Underwood]

We've been throwing various ideas around with regard to fully programable discounts for a while now. The main issue is that the internal representation if discounts is still in flux, and we want to get it properly nailed down before we release an API since once we do that making further changes will require deprecations.

Rest assured that we want to release something that's as flexible as possible. We just don't want to half-arse it only to have to come back later and say 'yeah, that last version wasn't very good, we're changing everything now'. Hope that clarifies things :)

-David Underwood

 Developer Advocate, Shopify

--
 
 
 

[L Creek]

I hear what you are saying David, and I get the rationale behind it. But when the time frame for a critical software development is measured in years (with nothing ever released), you guys are killing your app developers. I know this topic has been beaten into the ground and I won't start up with the bird in the hand vs. two in the bush, but at some point  you have to just bring a product to market-- delaying a product feature like discounts for several years is insane.

But instead of that old argument I will offer this instead, why not introduce simple basic features now in a modular fashion (so you can roll out more and more later)?

It seems to me that if we were able to do three simple functions via api, the average developer could finally build many of the killer apps we've been waiting for:

1) Create the type of Discount (which includes the rules applied)
2) Create one time use codes (or deactivate codes)
3) Set time frames for coupon code life

For number one, the type of discount (percentage, dollar off etc.) would be modular (you could then expand out the choices to more and more complex options- buy X get one free etc.). So too would the rules applied (applies to any order, orders over X amount, orders with certain products etc.). Since both the rules types would be modular, just start out with the basics. Simple percentage or dollar off, and apply to any order. Two types, one rule. VERY simple.

This minimal functionality obviously won't be enough to handle every user's needs, but would work for a lot of (most?) applications right off the bat. Then roll out more and more types and rules as you have the chance to dream them up and test them. And if you start with the basics and roll more out as you go along (when they are ready, however shopify decides that they are) you don't have any "oopsies" or "changing everything now" scenarios you mentioned. Structure (method) stays the same, only the options available change.

#2 and #3 are simple. Once a discount is created, you just have a one-to-many of discounts and code. Each code gets a start and end date for coupon life (or could be left open until canceled). Codes can only be redeemed once and they expire. That's it.

So instead of punishing the majority of folks who could at least get by with the very basic system described above by making them wait many years for a perfect system to be written, get them up and running and bring a whole new class of apps to market... NOW. Then, as you get the chance to implement uber cool new rules and types, you roll them out incrementally by folding them in.

Timing arguments aside, how would that not give Shopify the chance to ultimately make the product as complex and nuanced as they want, while at the same time give developers the vital tools they have been waiting for since the beginning of apps? Is there any reason an approach like that wouldn't work?

I've already abandoned the product I was working on before because it was apparent that this functionality was not coming down the path anytime soon. I just checked back to see where things stood a year(?) later, and no progress. It can't be that hard... it just can't.

[Christopher Saunders]

Hey,

No, you're right a basic API isn't hard.  We also don't want to roll out an unstable API.  Discounts haven't been worked on that much because of various other things going on at the moment.  It's a matter of priorities.

With that being said, I'm looking into what would be needed to add in the necessary functionality for various discount types.  A major one being BOGO, but not requiring the user to add a code, it just works at checkout.

We've sort of started work on an API, as you can see with http://bulkdiscounts.shopifyapps.com to kind of see how it would work.  For simple things like % off or $ off orders over a certain amount it's alright, but other parts it's a bit janky.  

Nobody likes janky and I just don't have a timeline quite yet and don't want to make any promises.

--

Chris // API & Integrations Developer @ Shopify

--
 
 
 

[Dave]

And in the meantime, since you can mechanize Discount Codes, it is trivial to add whatever cool App functionality you want to any shops that let you install your App in them. 

Think of it as practice. I know I do. My clients use my Discount Code Apps for many things, and keep their issues private with me. So, the day Shopify releases a proper API... I have tons of code and ideas that are proven, that I can implement for the unwashed masses as needed with a more general App. 

So you can complain, and suggest how easy it would be to deliver XYZ, but the fact is, you can actually make Apps that deal with Discount Codes.. now... nothing stopping you...

Dave

[Christopher Saunders]

Until we remove the current admin and your mechanize scripts break :/

Hopefully, we'll have an API out before that happens.

--
 
 
 

[Dave]

Why wait years for an API improvement when Mechanize will do fine.

I still cherish the day when a small Mechanize script I wrote helped a shop put $860,000 USD in the bank in 12 hours with over 13,000 successful orders :/  Boo-yah to Shopify for that one... 

Please do let us know a few weeks in advance when we can finally start migrating out code out to the new Discount's API!!

[Christopher Saunders]

On 5 October 2012 19:03, Dave <hunk...@gmail.com> wrote:

Why wait years for an API improvement when Mechanize will do fine. 

I still cherish the day when a small Mechanize script I wrote helped a shop put $860,000 USD in the bank in 12 hours with over 13,000 successful orders :/  Boo-yah to Shopify for that one... 

Please do let us know a few weeks in advance when we can finally start migrating out code out to the new Discount's API!!

I don't know when the Admin2 goes fully public.  You've surely heard about it, and if I can recall, Mechanize doesn't execute Javascript.  So once that rolls out your stuff is going to just break.  Hopefully before then there'll be a discounts API that you can migrate to.

--
 
 
 

[Dave]

Um.. You're kinda right there. But, looking at the Admin2, and the new markup, it is plain as day, that scripting DOM to do your bidding remains possible. No matter how you deny automation, if a human clicks buttons on a DOM driven page, and selects form elements, that can be automated. Mechanize is just one way to do that. The new markup is different sure but in the end, it is nothing but DOM and Javascript. 

If you write any code at all and test it, using say Cucumber and RSpec for Rubyists, then surely you've seen Webrat at work too plunking away during tests? 

Even though Discount Codes are one example of automating monotony... there are probably dozens of use cases where you could automate tasks using scripting. 

So, as long as Shopify continues to render DOM and work the web, I will script with {mechanize jasmin webrat selenium et al} to avoid manual labour...