Drupal Commerce - The Product vs Display Conundrum and How to Explain it to a Customer
description
Transcript of Drupal Commerce - The Product vs Display Conundrum and How to Explain it to a Customer
DRUPAL COMMERCE THE PRODUCT VS DISPLAY CONUNDRUM
(AND HOW TO EXPLAIN IT TO A CUSTOMER)
Richard Jones, Technical Director, i-KOS
NYC Camp July 2012
HELLO!
• Richard Jones
• CTO i-KOS
• London-based Drupal agency specialising in Commerce
• @richardjones
QUICK INTRODUCTION TO DRUPAL COMMERCE
• Built for Drupal 7
• "Small-core" philosophy
• 1.0 launch at DrupalCon London 2011
A COMMERCE FRAMEWORK
More than just a shopping cart
BASIC FEATURES
• Shopping cart
• Checkout
• Customer profiles
• Multiple product types
• Rules based pricing
• Payment API
• VAT and tax
Drupal Commerce Reported Installs
0
5,000
10,000
15,000
20,000
May
201
1
Jun
2011
Jul 2
011
Aug
2011
Sep
2011
Oct
201
1
Nov
201
1
Dec
201
1
Jan 2
012
Feb
2012
Mar
201
2
Apr 2
012
May
201
2
June
201
2
July
2012
WITH GREAT POWER COMES GREAT POTENTIAL FOR CONFUSION
SO WHAT'S THE PROBLEM?
• Drupal Commerce has product entities and product display nodes
• Probably the single most important concept to get your head around
• Either really obvious or really confusing
WHY IS IT THIS WAY?
• Products often have multiple variations
• Size, colour etc
• You need to know which one of the variations the customer wants
• You need don't want to display multiples of similar things
THE UPSIDES
• Single product display can represent multiple products
• Fine control of variables for each variant
• Stock and pricing
• Alternative displays for different contexts
THE DOWNSIDES
• If your products are simple you have to create 2 objects to create 1 product
• If your products are complex you could end up with thousands of variants
• Admin user experience
ELIMINATE THE DOWNSIDES
• Two main problems to solve
• Duplication of effort when it seems a waste of time
• Manual creation of hundred of variations
PLANNING YOUR PRODUCT STRUCTURE
• Consider when the product display is used and when the product is used
• Anything product variant specific goes in the product (eg colour, image)
• Anything generic about the product goes in the display (eg marketing description)
PLANNING YOUR PRODUCT STRUCTURE
• Anything you need in the following scenarios should go in the product
• Confirmation email
• Order tracking
EXAMPLE STRUCTURE
PLANNING YOUR PRODUCT STRUCTURE
• Can also have multiple product types
• Where products have different descriptive elements
• Or you need separation for logic
PLACING YOUR TAXONOMY
• If you need to have search or navigation based on taxonomy apply the taxonomy to the product displays
• You could have alternate taxonomy for admin
ENOUGH PLANNING...Let's see the implementation
BULK PRODUCT CREATION
• With the product display system number of variants can multiply quickly
• A product with 5 sizes, 3 colours and 2 fits gives you 30 products for 1 product display
• Bulk product creation set them all up
• Then delete the ones you don't need
IMPROVING THE OWNER EXPERIENCE
• A store admin doesn't want to hear that they have to do something twice no matter how well you explain it
• Use inline edit module
EXPLAINING AND TRAINING
• Getting this message across is the key to acceptance of commerce
TERMINOLOGY
• Find the terminology that fits with the client product range
• Consensus seems to be
• Product display = Product
• Product entity = Variant
ANOTHER SIMPLE RULE
• Products (variants) are for the back end
• Product displays are for the front end
PUTTING IT ALL TOGETHER
Some scenarios
WAYS TO USE MULTIPLE DISPLAYS
• You can group products together in any way you like
• Different product displays for different contexts
• Promotional landing pages are a good example
LANDING PAGES
• Use an alternative product display for promotional landing pages
• You can change layout in other ways (display suite)
• Best use of alternative product display when you want to group different products
SALES AND PROMOS
• Alternative product display scenario
• Normal display shows all products (variants)
• Sale version shows only a subset
MULTIPLE PRODUCT TYPES
• Products (variants) have different data requirements
• Also different rules
• Eg books - need a way to identify different VAT condition
RULES BASED PRICING
• Sales and promos
• Use alternative product types for promo price rules
SUMMING UP
DRUPAL COMMERCE IS A FRAMEWORK
• Just like Drupal there is a great deal of power under the hood
• Just like Drupal some UX work will help!
QUESTIONS?
Richard Jones, Technical Director, i-KOS
NYC Camp July 2012