Variant Selectors
Stephanie Powell
I've seen a few emails about variant selectors and product optioning.
I've been working on this and have put together a prototype with basic
product optioning using radio buttons:
http://www.hackerpanda.com/spree/screenshot1.png (product without option
types / values)
http://www.hackerpanda.com/spree/screenshot2.png (product with option
types on page load)
http://www.hackerpanda.com/spree/screenshot3.png (product after one
variant has been selected -- price updated)
http://www.hackerpanda.com/spree/screenshot4.png (product after another
variant has been selected -- price updated)
http://www.hackerpanda.com/spree/screenshot5.png (product when variant
with no in stock has been selected -- price updated)
Here's the commit:
http://github.com/stephp/spree/commit/f2c4ec86ac957734eea0a72f9cd7c1ea316413b2
And here's are some details:
- On the product page, all product option types and values are listed.
In the example (screenshots 2 - 5), Size & Color are the option types,
S, M, L, XL, Red, Green, Blue are the option values.
- There is a hidden select dropdown box which contains all of the
variants for that product. The select dropdown passes the variant id
when the form is submitted (item is added to the cart). In the example,
the select box contains 10 variants (different combos of available size
+ color t-shirts).
- When a radio button is clicked, javascript is used to change the
select box value and update the price on screen. The quantity box and
add to cart button are disabled if the item is out of stock or not all
option types have been selected.
- I know some folks are not fond of logic in the javascript. In order to
have this on page functionality, the javascript is necessary. However,
all meaningful text can remain in the products/_cart_form view in order
to maintain localization. I also didn't code this as noconflict jquery,
but it can be modified in the future.
I just pulled in the latest railsdog/master branch to rebase -- the
functionality was working prior to the rebase and now I'm getting some
strange checkout bugs.
This commit is just a prototype at this point. I just thought I'd throw
it out there in case anyone was trying to solve a similar problem.
Perhaps it would best fit in an extension. Thoughts?
~Steph
mwlang88
I'm going down more or less the exact same route. One thing I need to
do is associate specific images with specific variants. A click of
variant choices should cause the main image (and thumbnails) to
change, if one uploads images specific to a variant. Someone else
mentioned they were working on the mods to make images assignable to
variants last week. I'm not sure where they're at with their
efforts. But but I definitely agree that both yours and the image
handling for specific variants is needed functionality in spree.
Just my two cents,
Michael
On Jun 29, 3:43 pm, Stephanie Powell <st...@endpoint.com> wrote:
> Hi all,
>
> I've seen a few emails about variant selectors and product optioning.
> I've been working on this and have put together a prototype with basic
> product optioning using radio buttons:http://www.hackerpanda.com/spree/screenshot1.png(product without option
> types on page load)http://www.hackerpanda.com/spree/screenshot3.png(product after one
> variant has been selected -- price updated)http://www.hackerpanda.com/spree/screenshot4.png(product after another
> variant has been selected -- price updated)http://www.hackerpanda.com/spree/screenshot5.png(product when variant
>
Stephanie Powell
images specific to the variant, also, with minimal javascript changes on
the frontend (1 or 2 lines). Again, it may be javascript heavy, but with
any frontend usability feature like this one, it's going to be
unavoidable. Brian Quinn -- I remember you mentioning something about
images / variant -- have you made any progress on that? I thought we
discussed this, IIRC.
I'm not quite sure I think this should be part of the core
functionality, though. I had envisioned making an extension called
'advanced-variant-display' or something like that . I'm all for having
this included in the core, I just don't think this is a "one size fits
all" solution and would prefer to allow flexibility as an extension
rather than the core code. However, the problem with extensions is that
there may be conflicts if other extensions override _cart_form.html.erb.
~Steph
Sean Schofield
Ultimately I agree that this is probably more appropriate for an
extension since we want to limit the JS requirements on the client
side if at all possible. Right now, we are just using in checkout so
that's manageable.
I'm not too worried about extension conflicts. If one needs
customization beyond what you're planning I think the sensible thing
to do would be to fork your extension. It looks like you'll only need
to modify cart_form partial as far as views go. Image changing would
definitely be a nice plus (and reduce the need for someone to create a
potentially conflicting extension.)
One other "nice to have" would be the ability to change variants based
on selection. In other words, if the blue color is only available in
Large then your size choices would reflect that once you selected a
color. I'm thinking a multi dimensional array/matrix in JSON with the
possible choices could work.
Anyways, sounds like a nice idea. You'll have to make sure to
coordinate with Michael so that you're taking into account any changes
we settle upon w/regards to the master variant, etc.
Sean
Stephanie Powell
Sean Schofield wrote:
> I really like the idea of advanced-variant-display extension.
> Ultimately I agree that this is probably more appropriate for an
> extension since we want to limit the JS requirements on the client
> side if at all possible. Right now, we are just using in checkout so
> that's manageable.
>
> I'm not too worried about extension conflicts. If one needs
> customization beyond what you're planning I think the sensible thing
> to do would be to fork your extension. It looks like you'll only need
> to modify cart_form partial as far as views go. Image changing would
> definitely be a nice plus (and reduce the need for someone to create a
> potentially conflicting extension.)
>
Well, in general for Spree to be an extensible project, we need to thing
long term that there will be conflicts for extensions. Overriding views
is fine for a simple implementation of Spree, but I'm just noting that
ecomm solutions with a full feature set needs to have features that
don't risk overriding view conflicts. This is fine for now, though.
> One other "nice to have" would be the ability to change variants based
> on selection. In other words, if the blue color is only available in
> Large then your size choices would reflect that once you selected a
> color. I'm thinking a multi dimensional array/matrix in JSON with the
> possible choices could work.
>
Yeah, I'm not sure I want to go down this path. I thought about it,
though. It gets pretty complicated once you start adding more than 2 or
3 option types. For example, if you had a set of 4 option types A, B, C
& D all with several option values. If someone selects A, B, C, then
you could dynamically populate the option values available for D.
However, then what if the user selects an option for D, then changes the
B option type value. Would you redisplay the available A options? or D
options? It isn't good usability when you have all these options showing
and hiding based on multi-dimensional option types, which is why in my
solution I went with the "Out of Stock" message. Of course, you could
force a certain order of option types so that every time you change an
option type, all option types get reset. For example, once the user
changes the B option type value, then C and D would get reset. However,
this is definitely not a "generic" solution.
> Anyways, sounds like a nice idea. You'll have to make sure to
> coordinate with Michael so that you're taking into account any changes
> we settle upon w/regards to the master variant, etc.
>
> Sean
>
>
I'll probably continue to work on this, however, I have bigger fish to
fry, so if anyone's depending on it, go ahead and just grab the code.
~Steph
Brian Quinn
grimen
> >http://www.hackerpanda.com/spree/screenshot4.png(productafter another
mwlang88
I'm starting to have to tackle this myself, and am thinking the
simplest thing to do is to stop attaching photos altogether to the
product model and start attaching them only to the variant model. Is
this anywhere close to where your solution is going?
Michael
BrianDQ
some jQuery cleanup in this branch so it's taking a while.
You can check it out at: http://github.com/BDQ/spree/tree/variant_images
Paul Callaghan
product images onto variants (and have no images assigned to the
product itself).
I'm not keen on this, and would prefer to retain a core set of images
for the product and just use images-on-variants to highlight
particular features of a variant. That is, I want the option of using
both mechanisms. I can't think of any reason why this can't be done.
However, has anyone considered a lighter alternative, of attaching
images to the option values that help to select a variant?
Example: see http://www.parasolsdirect.co.uk/products/antibes-parasol-round-3-5m
and click on the "colour swatch" link.
The thinking is to provide image(s) to help the customer make a choice
on one option at a time. We could have similar images for construction
material, finish, ...
Will this approach work for any of you? I'm particularly interested in
what kind of products or scenario don't fit into this pattern.
Paul
Brian Quinn
From BDQ's extension, it seems like the plan is to move all of the
product images onto variants (and have no images assigned to the
product itself).
I'm not keen on this, and would prefer to retain a core set of images
for the product and just use images-on-variants to highlight
particular features of a variant. That is, I want the option of using
both mechanisms. I can't think of any reason why this can't be done.
Brian Quinn
Sean Schofield
like to not overwhelm people with configuration options if they're not
required. In fact, I'm leaning towards thinking that the variant
image stuff could even be an extension as opposed to core.
Probably the most cited feature that people like most about Spree is
its "lack of features you don't need." Now many stores will need this
feature of course but this is where a comprehensive demo app showing
how the extensions are assembled together would come in play.
Many people would probably just start to clone the fancy demo as their
starting point but there's nothing wrong with that. Others would
start small and add only what they need (merb approach.) This would
also have the side benefit of not forcing everyone to agree on an
approach. Someone else could always develop a per variant
implementation if they felt strongly about it.
Sean
Sean Schofield
> simplest thing to do is to stop attaching photos altogether to the
> product model and start attaching them only to the variant model. Is
> this anywhere close to where your solution is going?
How is the variant refactoring going? Hopefully you and Brian can be
productive without a lot of merge conflicts. I think your variant
refactoring (the basic stuff - not images) would be very useful to
have if you were still planning on that. Extra bonus would be some
help managing "variant" related tickets in Lighthouse (identifying
issues that are no longer problems as a result of your fixes once
done.)
> Michael
Sean
Sean Schofield
> 1 - The sample data for "Ruby on Rails Baseball Jersey" includes images for
> all variants (except XL), suggest you do a bootstrap before testing.
OK
> 2 - You now get an "Images" tab, like Variant / Option Types, Properties, etc
> on the admin Product edit UI.
This is now possible even if we move this to an extension right?
(Adding menu items through extension.) If not, I believe there's a
patch in the works.
> 3 - For non-variant products all images attach directly to the Product
> model.
I think its better to keep images for product on the main tab. Some
stores won't even have variants so why confuse things? Of course I
could follow easily enough myself but if we're going to differentiate
between product and variant/option value images then why mix them
here?
> 4 - For products with variants you get a drop down to allow you select which
> variant the image links / attaches to. The list also has an "All" option
> which will link the image the Product.
Drop down works well I think (again, the "All" could be removed for simplicity.)
> 5 - The customer facing product show view now displays the related
> thumbnails as different variants are selected. This is quite jQuery
> intensive.
I bet it is :-) Another argument for extension. You provide a nice
default implementation but maybe I want to change the main image when
I change variants, etc. I look at view stuff outside of admin as
being more of a reference then something set in stone. That said, it
seems to work well.
> 6 - The link_to_delete helper has been re-written to submit via an jQuery
> ajax request.
Is this used elsewhere or just here?
> 7 - There's a global activity indicator for all jQuery ajax requests (you'll
> see it when you do a delete).
I can't seem to get my delete working. I get a JS error (in firebug)
when I click the delete icon.
$("#popup_container#).draggable is not a function.
I can't say for sure but I think I was having similar problems with
the product groups. We should probably figure out what's causing this
(I'm sure I won't be the only one - even if it works for you.)
BTW, this is on FF 3.0.x
> Enjoy!
> Brian
Sean
Sean Schofield
> images to the option values that help to select a variant?
>
> Example: see http://www.parasolsdirect.co.uk/products/antibes-parasol-round-3-5m
> and click on the "colour swatch" link.
>
> The thinking is to provide image(s) to help the customer make a choice
> on one option at a time. We could have similar images for construction
> material, finish, ...
I actually could see the argument for both. Images for variants and
option values. Not sure if Brian's code could be made DRY in this
respect (I'll let him comment - I haven't studied the code.)
> Will this approach work for any of you? I'm particularly interested in
> what kind of products or scenario don't fit into this pattern.
I can see use cases for both. Parasol's is a great example of where
it would be nice to have a tiny image in the select drop down.
Simply having an image associated with the option value would be
enough, end users could do with it what they wish.
I could also see a situation where Brian's approach would work fine as is.
Finally, I could see use cases where images for both would be nice.
You display the color swatches below the main product image and then
when user clicks on them, you change the main product image to the
matching variant.
Again, I don't think its crucial that we have all of the front end JS
implemented. Just that its easy to administer from back end and that
its modeled consistently in most apps (at least ones using the
extension if we go with extension.)
> Paul
Sean
Brian Quinn
I agree that it might be useful to keep images with product. I'd also
like to not overwhelm people with configuration options if they're not
required. In fact, I'm leaning towards thinking that the variant
image stuff could even be an extension as opposed to core.
Brian Quinn
> 3 - For non-variant products all images attach directly to the Product> model.I think its better to keep images for product on the main tab. Some
stores won't even have variants so why confuse things? Of course I
could follow easily enough myself but if we're going to differentiate
between product and variant/option value images then why mix them
here?
> 4 - For products with variants you get a drop down to allow you select whichDrop down works well I think (again, the "All" could be removed for simplicity.)
> variant the image links / attaches to. The list also has an "All" option
> which will link the image the Product.
> 5 - The customer facing product show view now displays the relatedI bet it is :-) Another argument for extension. You provide a nice
> thumbnails as different variants are selected. This is quite jQuery
> intensive.
default implementation but maybe I want to change the main image when
I change variants, etc. I look at view stuff outside of admin as
being more of a reference then something set in stone. That said, it
seems to work well.
Is this used elsewhere or just here?
> 6 - The link_to_delete helper has been re-written to submit via an jQuery
> ajax request.
I can't seem to get my delete working. I get a JS error (in firebug)
> 7 - There's a global activity indicator for all jQuery ajax requests (you'll
> see it when you do a delete).
when I click the delete icon.
Paul Callaghan
On Mon, Jul 13, 2009 at 9:38 AM, Brian Quinn<brian...@gmail.com> wrote:
> I think we should have variant images in core because [...]
I'm in two minds about where to put this functionality.
We could have it in the core but "hide" it from the unwary with a config option, eg Spree::Config[:allow_variant_images] which defaults to false - and so we get the current images-to-product functionality unless requesting otherwise.
However: it shouldn't be too hard to put in an extension, so I have a slight preference for this.
Paul
Brian Quinn
On Mon, Jul 13, 2009 at 9:38 AM, Brian Quinn<brian...@gmail.com> wrote:
> I think we should have variant images in core because [...]
I'm in two minds about where to put this functionality.
We could have it in the core but "hide" it from the unwary with a config option, eg Spree::Config[:allow_variant_images] which defaults to false - and so we get the current images-to-product functionality unless requesting otherwise.
Sean Schofield
> interface a little and I think it's clear and understandable? Plus it makes
> it very easy to add additional image related fields like Title /
> Description. Keeping all the images in one place is vital, I think it'll
> really confuse people to have Product images there and Variant images
> somewhere else.
I can see your point on this. I liked seeing the images right there
on the main tab without having to click over but if you have lots of
images (or variant images) I can see why this becomes necessary.
> I've intentionally kept the images tab very simple, especially for
> non-variant products (you don't even see the Variant column or drop down on
> that add / edit form).
I didn't realize this. This is much better (now that I understand it.)
>> Drop down works well I think (again, the "All" could be removed for
>> simplicity.)
Maybe we could have it be blank? I'm open to what others think on this one.
> If we keep both Product and Variant images here 'm open to better ways of
> allowing a user choose how to specifiy what an image is related to. And
> don't forget this list only appears for Products with Variants.
Well I'm coming around to your approach.
[snip]
>> I can't seem to get my delete working. I get a JS error (in firebug)
>> when I click the delete icon.
>
> What are you trying to delete?
Everything is working now (despite not changing anything on my end.)
I think maybe I did a full restart of my dev server this time ...
Sean Schofield
> when I click the delete icon.
>
> $("#popup_container#).draggable is not a function.
I figured out the problem here. This seems to be related to an older
version of the Firebug addon for Firefox. I was able to reproduce the
problem and then verify the problem went away after upgrading the
Firebug addon to latest version.
Sean