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