Commerce Product Constructor
Today I’ve made another decision to postpone using Commerce in our project where customer needed simple e-shop. I’ve actually made such decisions several times already, and that makes me feel unhappy.
I would like to say that I really enjoy Commerce presentations, (like everyone of you, huh?), and test installations are working great!
The idea of Drupal-way, and Rules, and Views-everywhere rocks.
But… Commerce is being developed for a long time already, and you still can’t show it to your customers if they need to log in to admin section of their website!
Why?
That’s node display + product entity problem.
In Commerce, product entity is a primary thing, and this is an item that holds product-specific data like SKU and price.
And this product can be displayed in several nodes at the same time, when you select specific product in product-reference field of the node.
That is a very strong Commerce point, - but at the same time, that is a weak point why we can’t show Commerce admin section to our customers now.
Imagine that you have a simple store where you sell T-shirts.
Each t-shirt has size attribute and color attribute.
To create end-user product that is displayed in store to your visitors, you need to
1) Create 1 product entity per each attribute intersection (so, you have to create 1 product entity for ‘color: red, size: s’, then 1 entity for ‘color: green, size: s’, and so on, so if you have 5 colors and 4 sizes, that is 20 product entities!
2) then you go to node creation, create ‘display’ node and in product reference field you select all your created t-shirts. That is a difficult thing to do when you have 100 t-shirts, each having 20 product entities, so you have to select 20 entities that you’ve just created from 2000 product entities that you already have in your store.
Do you think you will be able to explain this to you customer?
At the same time, from architectural point of view, the product entity approach is a feature that allows to do things like stock management, image handling, unique sku for each attribute combination, multiple display pages for single product - in a right way.
So, I think that what most of average e-stores need - is a good interface where product entities are created automatically in background, while keeping product display node primary thing to website admin.
I am not the only one who had this idea :)
There is already a couple of modules that are trying to address the issue, from different sides:
Commerce Bulk Product Creation and
Commerce Product Display Manager
Personally, I don’t think that Commerce Bulk Product Creation alone makes it a lot easier to manage your store. It has a really nice generator of products, but it looks like it is supposed to be used once for a product creation. It doesn’t maintain the dynamic connection between node display and product entities, so you can’t quickly update product entity when you edit display node (well, there is product-reference connection, but it’s not usable). And if you need to change price for all combinations of attributes of specific product, you are in trouble.
Commerce Product Display Manager is trying to solve the problem in a different, more dynamic way.
You get separate tab on product display node, called ‘Products’, where you can see all back-references to product entities.
But you can’t create product entities from display node here.
Actually, you will be able to do it soon! Read this - the maintainer of the module says that he committed some code that allows website admin to create product entity from product node.
But, there is still a long way to go.
To my understanding, what we need is a combination of Commerce Bulk Product Creation and enhanced Commerce Product Display Manager, with significant amount of ajax magic, so the everyday workflow of e-store admin looks like this:
For product creation:
Admin goes to node/add/product and enters basic product information, like title and description.
There is also fieldset which is a much more compact version of current Bulk Product Creation.
When user selects all the necessary options and uploads image, it clicks “Generate” button and the fieldset is ajax updated with a list of generated product entities.
Admin clicks ‘Save’ and that’s it, we have a display node with all product entities generated.
For product updates:
Admin goes to node/%/edit and there is a fieldset which is rendered as a list of all product entities, with ‘edit’ link on each item (it’s very similar to current Product Display Manager functionality, but I think it’s important to show the product list on the main node edit tab, not on separate tab, because it is a primary node information.) I think it would be great to have some fields like product entity price exposed for in-place editing here.
There is also an ajax-enabled product generator feature available here, too.
From implementation point of view, this can be a new widget type (so it will appear near ‘autocomplete’ and ‘select list’ when you manage fields in your product display node)
This approach won’t work for every store, but imho it will work relatively good for a big amount of websites.
Or, may be the proposal described above has some serious flaws which I don’t see? Feel free to leave your feedback.
When we have functionality similar to this, I think it will be a lot easier to convince customers that Drupal Commerce is the best e-commerce platform ever!
Anton Sidashin
senior developer, Pixeljets co-founder
I'm a web developer specializing in PHP and Javascript, and Drupal, of course. I'm building Drupal projects since 2005, and I was working as full-time senior engineer in CS-Cart for a while, building revolutionary e-commerce software. In my free time, I enjoy playing soccer, building my body in gym, and playing guitar.
Drupal.org ID: restyler
Comments
I agree, this separation is a reminder of the same challenge in ubercart of having to first create your product attributes, then attach them to a product utilizing two different (and equally confusing) UIs. One UI to do it all.
I agree that what we ultimately want is "bulk product management", not just "bulk product creation" (though different parts of the "management" part could come from different directions, e.g. bpc and the display manager).
And to that end, we need to introduce a new entity type (call it "Product Set") that is created during bulk creation and serves to tie the created products together. Once that is in place, it would not be too difficult to have the UI basically deal mainly with "Product Sets" (there will be a terrible terminological confusion)---i.e. go to the "Create Product Set" page (now bulk product creation) to create products, go to the "Edit Product Set" page to change properties shared by all products in this set or add new elements, etc. Of course, at least in the UI, the name "Product Set" is terrible for that, but you get the general idea.
Display nodes cannot do double duty as Ersatz product sets as a product can show up in more than one display, and in order to make this all work there has to be a SINGLE 'product set' (if you used Magento, you will call this a 'configurable product', which is just another horrible name for the same thing).
Oh, and suggestions on how to improve the UX of the bulk creation form are very welcome in the issue queue.
Part of the problem for bpc (and perhaps for the product display manager folks) is that until this at least works somehow, few developers are interested in pitching in (because if you can't sell a commerce site to a client ...). At the same time, the time of the maintainers is limited, too (especially if you can't sell a commerce site to a client ...), delaying creation of something that is usable enough (as a complete client-ready solution) ... chicken, egg.
Well, I’m not sure that adding another entity level is a good idea now, though it might be a good idea in future. I can’t imagine lots of use cases for average stores, when you _really_ need product set and it is very different comparing to ‘display node’. To my understanding, that is really important for website where admin needs to show the same product set in several display nodes, but imho that’s not so popular feature. (Or, I misunderstood your suggestion :)
In a way, my suggestion would be more to (a) have product sets tying "product variants" together (& enabling their creation in bulk & enabling their modification in bulk ...). (b) Optionally displaying product sets directly, without having to associate with a display node (the most common use case, perhaps, as you indicate) and (c) still retain the option to reference product sets and products from nodes and have these act like they do now.
But yes, this is all more about the future.
And the idea would clearly be to use product sets to try and HIDE complexity (rather than expose more complexity). At the end of the (very long) day, the idea would be to have commerce_product_set_ui module that acts as a drop-in replacement of sorts for the commerce_product_ui module.
The main reason why I would not simply want display nodes to act as product sets in the long term (besides being very happy that we are over "everything is a node") is that nodes are not quite right to fulfill the task, so this would remain somewhat cludgy (and I still would have to explain to my customers why they have to think of a "product" as "site content").
I'm fresh back from my sailing trip through the BVI and ready to dive into contrib development and see what bugs have been turned up for core. One of my contribs that has very high priority is the Inline Product Form module, which will follow the design set forth here: http://drupal.org/node/1181862
I'd be interested in feedback on that thread, as it's my attempt to do just what you're describing - hide the product entity relationship from the casual store administrator and simplify "product group" administration at the point where Commerce currently establishes such groups, display nodes.
Depending on how this develops, it could easily be a 2.x feature, but I'd like to tease out ideas surrounding defining and administering product groups even further before committing to a solution in core.
I've decided that, for bpc (in so far I can make such decisions, but right now, I seem to be the only one who does bpc development) that "product group" / bulk edit functionality is a 2.0 thing (though, of course, bpc 2.0 could be here much more quickly than commerce 2.0).
I'll post some comments to the thread you reference, though I think ultimately, using display nodes as "product groups" (a slightly better term than "product sets") is a bit of a step backwards (in the sense that it smells of the "everything is a node" mindset). At the same time, doing things in this way is a good strategy to boost UX right now with what we have.
Perhaps it would be good to create a project for the commerce product groups (or however we might want to call them), to have a place to hash out some of the high level questions---it would be great to have support for such groups in commerce core (which then, in simple settings, could even take the place of display nodes, i.e. be displayed directly in the frontend), but I think this could just as well live in contrib. And given the clean separation of api and ui modules in commerce right now, we could develop a drop-in replacement for commerce_product_ui that hides the products in favor of "product groups", to see how well that would go.
Commerce Inline Product Form mockups are looking good. I’m glad to see that there are some steps in this direction. I think we really need ‘clone’ action for each created entity to populate fields for new product.
Hmm, I feel the same. I think there is really a great conceptual gap, yet. And I didn't see a promising approach in the contrib space. The inline form - Ryan mentioned - is fine for some really simple use cases, but not for the most use cases. It seems really odd to think somebody should administer - create and maintain - each single product on its own. It is fine to have technically each product variation as own product, with own sku ... and so on, like the great amazon, but to think thats all what needed, is a short jump. It's like shipping views, without providing an UI. Still a really great piece of software, but in reality very limited usable. It's a little bit pity. But so often we hear this very same problem in the crowd, I guess we will see a solution in a couple of month.
Agree 100% with this article. The only way I'm currently able to be working on a DC project is because I ony require 3 products for it. Otherwise im still recommending Ubercart.
Lest it appear that the project itself is recommending another project, the above comment came from a company that builds Drupal sites but has only gotten involved w/ DC in the last couple of months afaik. (Fortunately comment name links are nofollow, so Google won't be confused.)
The quickest way to make DC better for larger stores is to use it and propose / develop solutions... and for most of the instances where large product catalogs were required that we've seen or developed, automated import / update scripts were used - hence the lag in on-site administration usability but the availability of both Feeds and Migrate integration.
I'd also like to point to this issue to reiterate here that even though it's painful in the intermediary, things are going according to plan. With limited resources, we had to prioritize what made it into 1.0 or face never getting it out. Focusing our 2.0 efforts on the store administrator, particularly as it pertains to managing products and orders on-site, has always been the plan. It's one I still take seriously.
hopefully you all get it together because right now all the commerce projects in Drupal are a mess. The issue you point to has not been even touched in 6 months in terms of input. It appears that this project has an un-warrented level of complexity and awkwardness which needs to fixed before this can be considered a real solution.
The issue hasn't been touched because it's still the plan and we've been executing it for the last 6 months. : P
We're happily accepting specific feature requests and patches to help reduce the complexity of the project, though, so feel free to read up on why the systems were designed the way they are and join in (either in Commerce itself or projects designed to simplify it for new users like Commerce Kickstart).
Yes, thats right, the feeds and migrate integration are fine parts for existing shops and for the initial setup. But they don't help anything at doing the daily work of an shop admin. At the moment you simply can't administer a product portfolio with drupal commerce. You have to use an solution outside of drupal and than import/reimport again. That is okay for some bigger solutions, where the user may have such separate system. But the the small and middle range shops - the longtail - want the all in one thing. But we will see what 2.0 provide. I will gladly help to test what comes along ;).
Well written post. I made a similar points & recommendations here as an issue for the Commerce module. It was unfortunately shot down. I'm not sure DC should have been pushed as a solution yet. I used the same shirt example in the comments on that issue, and it was disregarded as an edge case.
Perhaps it's an edge case simply because DC isn't a good solution for stores that have products with multiple attributes. I'm behind on a project because I shot myself in the foot with DC.
I hope DC becomes great, it has lots of potential. Maybe 2.0 is when we'll start to see it
Well, I think we both clearly indicated our positions, I’m pretty sure Commerce Guys (Ryan!) listen to the feedback of the crowd. There are two options now - to sit and wait until someone will be able to come up with solution, or to get your hands dirty with Commerce code :)
Totally agree. I haven't grasped Drupal enough yet. It's been a while since I've done real coding and it wasn't PHP. One day I will find the time to get up to speed!
A quick update on this: The bulk product creation module now (with the just released beta1) has the option to silently create display nodes that reference the just-created products. Together with something like the product display manager, or better yet, Ryan's inline product forms as a kind of "edit in place" functionality, I think that would allow for a pretty decent user experience with just a few hook_form_alter/hook_menu_alter implementations.
(Think using the bulk creation form as you main creation form, and a view of the display nodes as a "replacement" for the product listing---in essence, having users edit products via display nodes, but create products/display nodes via the bulk creation form---the only thing left to do would be to auto-delete the products if the associated display node is deleted.)
Not the most pretty solution, but something that could be done today, more or less.
How about we do it the ubercart way ?
I like the way ubercart handles it's attributes. How about you can define attributes (size, collor .... with ther respective extra value price). Then when you create a product display, you choose the attributes you want available, then the products are generated with their calculated price and attributes ... (and offcourse referenced automatically)
Anybody knows what the status of a better product / display handling in Drupal Commerce is?
I'm pretty sure that a rule is sufficient to automatically create a node when you create a new product (at least for the common case). There is a thread for this here : http://drupal.org/node/1300170
It's not an optimal solution, bur it's not an hack either. Hope it helped.
I totaly agree.
Commerce is a good TECHNICAL module, but will be useless until it will solve (or remove/replace) the separation between Product and Product Display problem...
I guess a wrong technical solution has been chosen at the beginning, use cases must have been seen from a developer point of view and any way in a user way. I can't understand why a such complex workflow would have passed the use tests otherwise.
Still no solution, still abandoned in profit of OpenCart which is a very good eCommerce solution, but non-Drupal solution (so limited).
Hi, I am working with commerce and was asking myself if there was any way we could help in the shaping of the UI.
if there is anything we can do, let us know.
Just wanted to post an update here that feedback and ideas from this post and other discussions like it have resulted in the new product administration experience in Kickstart 2.x. Store admins now no longer see any of the node / product entity separation, and the online entity form gives you a single place to create product displays with all their variations through the node add / edit form. We've seen significant improvement in the UX in our testing and look forward to more feedback!
Additionally, even though the modules are packaged in the distribution, they are available separately and will continue to be developed as contributed projects. I hope you get a chance to take a second look and post your feedback in the Commerce Kickstart issue queue.
Hey Ryan!
It looks like Kickstart is an impressive piece of work (I’m reading most of CommerceGuys posts) and is gaining the momentum - I plan to install and play with it on this week. Thanks for your work!
Post new comment