anecdote 0.2.3 → 0.2.4

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA1:
-  metadata.gz: '0158e4492bd9ad413a58911904c409a9cb433d69'
-  data.tar.gz: 1d0941278b89f8b11ce704cc2b302eeca1d510a2
+  metadata.gz: e4b091ee11a7c20ea441716daf4484d830e66491
+  data.tar.gz: b8d639d1c828d888ca1e98c8844c1def2b9ac5e5
 SHA512:
-  metadata.gz: 4ac63c12f71780268d52b0de5b083c5202d4d65cbb95eac7c2321623f155703e5b24a07cfbb3818b7835fdaa326a453230547d4e455383c96a3d009131d81cf1
-  data.tar.gz: e112b6867ebf609c7418f55dbcb8ed0a1e95d81a251d5f2e1a432c162d035f43624f572a3832eb98f243e5f09292c66549bd7c26bb2decea980024c979b29a84
+  metadata.gz: 35b16a6db55309e747cb1c587a264a4b8c4756a09c6efb58561f5f6b32ecc4cb044c94985c6dc8e24e33e0e84822fd51fc8259703e1f8cb32e18615b0bfa01aa
+  data.tar.gz: d9d6f5eb15a9426846757f667b926320cae31b1ac712da2218a5b268e58f3e7638949681f6080f2a7222facdb6701e73ed222df5dd9e0821ae2cefafa09f397f

data/lib/anecdote.rb

@@ -5,12 +5,12 @@ require "anecdote/engine"
 
 module Anecdote
 
-  def self.markdown_and_parse(content="")
-    markdown_only( raconteur.parse(content) )
+  def self.markdown_and_parse(content="", options={})
+    markdown_only( raconteur.parse(content, options[:raconteur_options] || {}), options[:kramdown_options] )
   end
 
-  def self.markdown_only(content)
-    ::Kramdown::Document.new( content.presence || "", { input: :GFM } ).to_html.html_safe
+  def self.markdown_only(content="", options={})
+    ::Kramdown::Document.new( content.presence, { input: :GFM }.merge(options || {}) ).to_html.html_safe
   end
 
   def self.raconteur
@@ -47,7 +47,7 @@ module Anecdote
             dimensions = settings[:dimensions].split('x').map(&:to_f)
             geo = { width: dimensions.first, height: dimensions.last }
           end
-          if settings[:_scope_].present? && settings[:_scope_][:processor].tag == 'gallery'
+          if settings[:_scope_].present? && settings[:_scope_].key?(:processor) && settings[:_scope_][:processor].tag == 'gallery'
             settings[:_scope_][:settings][:_graphics_] ||= []
             settings[:_scope_][:settings][:_graphics_] << geo
           end
@@ -203,6 +203,39 @@ module Anecdote
         view_context.content_tag(tag, markdown_and_parse_without_wrapping_tags(settings[:text] || settings[:_yield_]), module_wrapper_options(settings).merge(id: settings[:anchor], class: klasses.flatten.join(' ')))
       end
       })
+
+
+    raconteur.processors.register!('display-if', {
+      handler: lambda do |settings|
+        response = ''
+        # grab the 'format' provided to Anecdote for this particular call, or the default setting (if neither has been provdided, nothing is rendered)
+        if ( settings.key?([:_scope_]) && settings[:_scope_].key?(:format) ) || ( raconteur.settings.key?(:render_options) && raconteur.settings[:render_options].key?(:default_format) )
+          current_format = ( settings[:_scope_][:format] || raconteur.settings[:render_options][:default_format] ).to_s
+          sanctioned_formats = settings[:formats].split(',').map(&:to_s).select(&:present?)
+          # if the current format matches one of the formats "sanctioned" by the tag, render the content (otherwise, nothing is rendered)
+          if sanctioned_formats.include?(current_format)
+            response = settings[:_yield_]
+          end
+        end
+        response
+      end
+      })
+    raconteur.processors.register!('display-unless', {
+      handler: lambda do |settings|
+        response = settings[:_yield_]
+        # grab the 'format' provided to Anecdote for this particular call, or the default setting (if neither has been provided, the content is rendered)
+        if ( settings.key?([:_scope_]) && settings[:_scope_].key?(:format) ) || ( raconteur.settings.key?(:render_options) && raconteur.settings[:render_options].key?(:default_format) )
+          current_format = ( settings[:_scope_][:format] || raconteur.settings[:render_options][:default_format] ).to_s
+          unsanctioned_formats = settings[:formats].split(',').map(&:to_s).select(&:present?)
+          # if the current format matches one of the formats "unsanctioned" by the tag, nothing is rendered (otherwise, the content is rendered)
+          if unsanctioned_formats.include?(current_format)
+            response = ''
+          end
+        end
+        response
+      end
+      })
+
   end
 
 
@@ -390,3 +423,4 @@ module Anecdote
 end
 
 Anecdote.init_raconteur
+Anecdote.raconteur.settings[:render_options] = { default_format: :web }

data/lib/anecdote/version.rb

@@ -1,3 +1,3 @@
 module Anecdote
-  VERSION = "0.2.3"
+  VERSION = "0.2.4"
 end

data/test/dummy/app/controllers/pages_controller.rb

@@ -2,6 +2,6 @@ class PagesController < ApplicationController
   def show
     page = params[:id] || 'article'
     file = File.read Rails.root.join('app', 'views', 'pages', "#{page}.markdown")
-    render text: Anecdote.markdown_and_parse(file), layout: 'application'
+    render html: Anecdote.markdown_and_parse(file), layout: 'application'
   end
 end

data/test/dummy/app/views/pages/article.markdown

@@ -2,7 +2,9 @@
 
 {{ graphic: href=//baymard.com + href-title=$Clicking this image will take you to Baymard.com!$ + assets-path=category-specific-sorting-01-rei-mock-up.jpg + size=full-width + caption=$This is the 3rd in a series of 9 articles based on research findings from our e-commerce [product list usability](http://baymard.com/research/ecommerce-product-lists study).$ }}
 
+{{% display-if: formats=print,web %}}
 We considered naming this article "the sort type all users want but zero sites offer" because category-specific sorting really is one of those rare instances where an obvious feature has somehow been **completely overlooked** by the e-commerce community.
+{{% end %}}
 
 {{ graphic: size=big + dimensions=1280x720 + embed-code=$<iframe src="https://www.youtube.com/embed/ZCBE8ocOkAQ" frameborder="0" allowfullscreen></iframe>$ + mood=positive + sidebar-caption=true + caption=$A mockup we've created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.$ }}
 

data/test/dummy/config/application.rb

@@ -11,7 +11,7 @@ module Dummy
     # Application configuration should go into files in config/initializers
     # -- all .rb files in that directory are automatically loaded.
     config.middleware.insert_after ActionDispatch::Static, Rack::LiveReload
-    
+
     # Set Time.zone default to the specified zone and make Active Record auto-convert to this zone.
     # Run "rake -D time" for a list of tasks for finding time zone names. Default is UTC.
     # config.time_zone = 'Central Time (US & Canada)'
@@ -21,6 +21,6 @@ module Dummy
     # config.i18n.default_locale = :de
 
     # Do not swallow errors in after_commit/after_rollback callbacks.
-    config.active_record.raise_in_transactional_callbacks = true
+    # config.active_record.raise_in_transactional_callbacks = true
   end
 end

data/test/dummy/log/development.log

@@ -46685,3 +46685,667 @@ DEPRECATION WARNING: `render :text` is deprecated because it does not actually r
 Completed 200 OK in 472ms (Views: 8.4ms | ActiveRecord: 0.0ms)
 
 
+Started GET "/" for ::1 at 2017-12-14 11:32:12 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 1874ms
+
+
+  
+NoMethodError (undefined method `raise_in_transactional_callbacks=' for ActiveRecord::Base:Class):
+  
+activerecord (5.1.4) lib/active_record/dynamic_matchers.rb:22:in `method_missing'
+activerecord (5.1.4) lib/active_record/railtie.rb:112:in `block (3 levels) in <class:Railtie>'
+activerecord (5.1.4) lib/active_record/railtie.rb:111:in `each'
+activerecord (5.1.4) lib/active_record/railtie.rb:111:in `block (2 levels) in <class:Railtie>'
+activesupport (5.1.4) lib/active_support/lazy_load_hooks.rb:69:in `instance_eval'
+activesupport (5.1.4) lib/active_support/lazy_load_hooks.rb:69:in `block in execute_hook'
+activesupport (5.1.4) lib/active_support/lazy_load_hooks.rb:60:in `with_execution_control'
+activesupport (5.1.4) lib/active_support/lazy_load_hooks.rb:65:in `execute_hook'
+activesupport (5.1.4) lib/active_support/lazy_load_hooks.rb:50:in `block in run_load_hooks'
+activesupport (5.1.4) lib/active_support/lazy_load_hooks.rb:49:in `each'
+activesupport (5.1.4) lib/active_support/lazy_load_hooks.rb:49:in `run_load_hooks'
+activerecord (5.1.4) lib/active_record/base.rb:326:in `<module:ActiveRecord>'
+activerecord (5.1.4) lib/active_record/base.rb:25:in `<top (required)>'
+activesupport (5.1.4) lib/active_support/dependencies.rb:292:in `require'
+activesupport (5.1.4) lib/active_support/dependencies.rb:292:in `block in require'
+activesupport (5.1.4) lib/active_support/dependencies.rb:258:in `load_dependency'
+activesupport (5.1.4) lib/active_support/dependencies.rb:292:in `require'
+activerecord (5.1.4) lib/active_record/railties/controller_runtime.rb:40:in `append_info_to_payload'
+actionpack (5.1.4) lib/action_controller/metal/instrumentation.rb:36:in `ensure in block in process_action'
+actionpack (5.1.4) lib/action_controller/metal/instrumentation.rb:36:in `block in process_action'
+activesupport (5.1.4) lib/active_support/notifications.rb:166:in `block in instrument'
+activesupport (5.1.4) lib/active_support/notifications/instrumenter.rb:21:in `instrument'
+activesupport (5.1.4) lib/active_support/notifications.rb:166:in `instrument'
+actionpack (5.1.4) lib/action_controller/metal/instrumentation.rb:30:in `process_action'
+actionpack (5.1.4) lib/action_controller/metal/params_wrapper.rb:252:in `process_action'
+activerecord (5.1.4) lib/active_record/railties/controller_runtime.rb:22:in `process_action'
+actionpack (5.1.4) lib/abstract_controller/base.rb:124:in `process'
+actionview (5.1.4) lib/action_view/rendering.rb:30:in `process'
+actionpack (5.1.4) lib/action_controller/metal.rb:189:in `dispatch'
+actionpack (5.1.4) lib/action_controller/metal.rb:253:in `dispatch'
+actionpack (5.1.4) lib/action_dispatch/routing/route_set.rb:49:in `dispatch'
+actionpack (5.1.4) lib/action_dispatch/routing/route_set.rb:31:in `serve'
+actionpack (5.1.4) lib/action_dispatch/journey/router.rb:50:in `block in serve'
+actionpack (5.1.4) lib/action_dispatch/journey/router.rb:33:in `each'
+actionpack (5.1.4) lib/action_dispatch/journey/router.rb:33:in `serve'
+actionpack (5.1.4) lib/action_dispatch/routing/route_set.rb:834:in `call'
+rack (2.0.3) lib/rack/etag.rb:25:in `call'
+rack (2.0.3) lib/rack/conditional_get.rb:25:in `call'
+rack (2.0.3) lib/rack/head.rb:12:in `call'
+rack (2.0.3) lib/rack/session/abstract/id.rb:232:in `context'
+rack (2.0.3) lib/rack/session/abstract/id.rb:226:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/cookies.rb:613:in `call'
+activerecord (5.1.4) lib/active_record/migration.rb:556:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/callbacks.rb:26:in `block in call'
+activesupport (5.1.4) lib/active_support/callbacks.rb:97:in `run_callbacks'
+actionpack (5.1.4) lib/action_dispatch/middleware/callbacks.rb:24:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/executor.rb:12:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/debug_exceptions.rb:59:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/show_exceptions.rb:31:in `call'
+railties (5.1.4) lib/rails/rack/logger.rb:36:in `call_app'
+railties (5.1.4) lib/rails/rack/logger.rb:24:in `block in call'
+activesupport (5.1.4) lib/active_support/tagged_logging.rb:69:in `block in tagged'
+activesupport (5.1.4) lib/active_support/tagged_logging.rb:26:in `tagged'
+activesupport (5.1.4) lib/active_support/tagged_logging.rb:69:in `tagged'
+railties (5.1.4) lib/rails/rack/logger.rb:24:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/remote_ip.rb:79:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/request_id.rb:25:in `call'
+rack (2.0.3) lib/rack/method_override.rb:22:in `call'
+rack (2.0.3) lib/rack/runtime.rb:22:in `call'
+activesupport (5.1.4) lib/active_support/cache/strategy/local_cache_middleware.rb:27:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/executor.rb:12:in `call'
+rack-livereload (0.3.16) lib/rack/livereload.rb:23:in `_call'
+rack-livereload (0.3.16) lib/rack/livereload.rb:14:in `call'
+actionpack (5.1.4) lib/action_dispatch/middleware/static.rb:125:in `call'
+rack (2.0.3) lib/rack/sendfile.rb:111:in `call'
+railties (5.1.4) lib/rails/engine.rb:522:in `call'
+rack (2.0.3) lib/rack/handler/webrick.rb:86:in `service'
+/Users/jamieappleseed/.rbenv/versions/2.4.2/lib/ruby/2.4.0/webrick/httpserver.rb:140:in `service'
+/Users/jamieappleseed/.rbenv/versions/2.4.2/lib/ruby/2.4.0/webrick/httpserver.rb:96:in `run'
+/Users/jamieappleseed/.rbenv/versions/2.4.2/lib/ruby/2.4.0/webrick/server.rb:290:in `block in start_thread'
+Started GET "/" for ::1 at 2017-12-14 11:32:37 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 98ms
+
+
+  
+TypeError (no implicit conversion of nil into Hash):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:32:40 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 54ms
+
+
+  
+TypeError (no implicit conversion of nil into Hash):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:33:28 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 111ms
+
+
+  
+TypeError (no implicit conversion of nil into Hash):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:33:43 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 1617ms
+
+
+  
+NoMethodError (undefined method `raise_in_transactional_callbacks=' for ActiveRecord::Base:Class):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:33:54 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 587ms
+
+
+  
+ActionView::MissingTemplate (Missing template pages/show, application/show with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby]}. Searched in:
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/test/dummy/app/views"
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/app/views"
+):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:34:46 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 628ms
+
+
+  
+ActionView::MissingTemplate (Missing template pages/show, application/show with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby]}. Searched in:
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/test/dummy/app/views"
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/app/views"
+):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:35:03 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 622ms
+
+
+  
+ActionView::MissingTemplate (Missing template pages/show, application/show with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby]}. Searched in:
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/test/dummy/app/views"
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/app/views"
+):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:35:12 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 733ms
+
+
+  
+ActionView::MissingTemplate (Missing template pages/show, application/show with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby]}. Searched in:
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/test/dummy/app/views"
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/app/views"
+):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:35:27 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 601ms
+
+
+  
+RuntimeError (<h1 id="category-specific-sorting-a-new-way-to-sort-products">Category-Specific Sorting: A New Way to Sort Products</h1>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-full-width"><div class="inner"><a href="//baymard.com" title="Clicking this image will take you to Baymard.com!" class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 64.92248062015504%;"><img alt="" src="/assets/category-specific-sorting-01-rei-mock-up-4b493aff69299ddd35d3cfe999080636a6a958570f7100fd4cc1d4b78a959ed8.jpg" /></div></a>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>This is the 3rd in a series of 9 articles based on research findings from our e-commerce <a href="http://baymard.com/research/ecommerce-product-lists study">product list usability</a>.</p>
+</div></div></div></div>
+
+<p>We considered naming this article “the sort type all users want but zero sites offer” because category-specific sorting really is one of those rare instances where an obvious feature has somehow been <strong>completely overlooked</strong> by the e-commerce community.</p>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-big v-mood-positive v-sidebar-caption"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 56.25%;"><iframe src="https://www.youtube.com/embed/ZCBE8ocOkAQ" frameborder="0" allowfullscreen=""></iframe></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>
+</div></div></div></div>
+
+<p>After all, it really shouldn’t come as a surprise that users would like to sort a list of TVs by “Screen size” or a collection of hard drives by “Storage capacity”.</p>
+
+<div class="anecdote-pull-quote-sba2ha anecdote-module-3ba83n v-size-big"><div class="inner"><p>By “category-specific sort types” we mean any sorting options that are only available in one or a few select categories</p>
+</div></div>
+
+<p>During our research study on product list usability the test subjects repeatedly sought out these kinds of category-specific sort types – however, to no avail since seemingly <strong>zero sites</strong> offer them. Even after <a href="http://baymard.com/ecommerce-product-lists/benchmark/site-reviews">benchmarking</a> the product lists of 50 major e-commerce sites we have yet to find a site that truly offer category-specific sorting.</p>
+
+<div class="anecdote-gallery-dn2bak anecdote-module-3ba83n v-size-big"><div class="inner"><div class="content anecdote-flex-module-a4j2aj v-gutter-spacing-small v-flow-from-tablet">
+  <div class="anecdote-graphic-dn32ja anecdote-module-3ba83n v-mood-positive" style="width:75.21865889212827%;flex-basis:75.21865889212827%"><div class="inner">
+<div class="anecdote-flex-offset-a4j2aj" style="padding-top: 0.0%;"></div>
+<div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 66.66666666666666%;"><img alt="" src="/assets/category-specific-sorting-02-bestbuy-f14fff79d781e96075b7d85c778786cc0cf003610cd26e6128d3a8a00f045b8e.jpg" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab">
+<p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>
+</div></div>
+</div></div>
+  <div class="anecdote-graphic-dn32ja anecdote-module-3ba83n v-mood-negative" style="width:24.78134110787172%;flex-basis:24.78134110787172%"><div class="inner">
+<div class="anecdote-flex-offset-a4j2aj" style="padding-top: 72.94117647058822%;"></div>
+<div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 129.41176470588235%;"><img alt="" src="/assets/category-specific-sorting-08-faceted-sorting-952f653066737f1a75aaf01a867ba4ca4e072b2a76cd38d68d8c5515e9820baf.jpg" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab">
+<p>An example of how things can go really wrong.</p>
+</div></div>
+</div></div>
+</div></div></div>
+
+<p>In this article we’ll outline our research findings on why <strong>category-specific sorting</strong> is so important to the user’s product finding abilities, and how it can be implemented.</p>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-small v-float-left v-float-from-large-handheld"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 66.66666666666666%;"><img alt="" src="http://assets.baymard.com/blog/category-specific-sorting-02-bestbuy-d0496405ef767b1f469cc0e71cc4f84d.jpg" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>
+</div></div></div></div>
+
+<p>Given that category-specific sorting is such an uncommon features, let’s quickly <strong>define</strong> the term. By “category-specific sort types” we mean any sorting options that are only available in one or a few select categories (because they wouldn’t make sense as site-wide sorting options – they only make sense for the products within those particular categories). Examples include being able to sort suitcases by volume, fishing rods by length, pens by point size, hard drives by storage capacity and spindle speed, road bikes by weight, etc. It’s this category specificity that makes them different from common site-wide sort types such as ‘Best Selling’, ‘Relevance’, ‘User Ratings’, and ‘Price’, which are typically available for all products and categories throughout a site.</p>
+
+<h2 id="soft-boundary-sorting-vs-hard-boundary-filtering">‘Soft’ Boundary Sorting vs ‘Hard’ Boundary Filtering</h2>
+
+<p>The differences between filtering and sorting may on the surface appear subtle. Indeed, many users <strong>mix up</strong> the terminology or use the terms interchangeably. However, the differences are in fact quite significant: <em>Filters</em> set the criteria for whether a given product is in- or excluded from the product list (i.e. what is displayed) whereas <em>Sorting</em> determines the sequence of those products (i.e. how it is displayed).</p>
+
+<p>This makes <em>Filters</em> great for setting “hard” boundaries while <em>Sorting</em> is optimal for applying “soft” boundaries:</p>
+
+<ul>
+  <li><strong>Filters</strong> – Sets a “hard” boundary. Any product that doesn’t strictly fall within the selected value(s) will be cut off. It is a great way for users to exclude any products that don’t match specific criteria.</li>
+  <li><strong>Sorting</strong> – Applies a “soft” boundary. The products are ordered by the chosen sort type (in the case of category-specific sort types that typically means a product attribute). It changes the sequence of the products but doesn’t exclude any items, enabling users to still see items that fall outside their initial boundary.</li>
+</ul>
+
+<p>Our <a href="http://baymard.com/research/ecommerce-product-lists">product list</a> usability testing showed that <strong>users need both</strong> hard boundaries (i.e. filters) and soft boundaries (i.e. sorting) for optimal control over the product list. Depending on the user’s knowledge of the product domain and their own needs and restrictions they may have very strict and 100% clear criteria the product must fall within, in which case “hard” boundary filters are appropriate.</p>
+
+<p>However, in many cases users don’t have that strict criteria and sometimes they don’t even know what an appropriate filtering range would be, in which case “soft” boundary sorting is more suitable. For instance, the user might <strong>care about</strong> a product attribute without having a specific criteria for it, or they may not have the necessary domain knowledge to set meaningful cut-off points.</p>
+
+<h2 id="case-the-2000-lightweight-road-bike">Case: The $2,000 Lightweight Road Bike</h2>
+
+<p>Let’s take an example of a user with a simple purchase preference: <em>“I would like a lightweight road bike and my budget is $2,000.”</em> Now, that wouldn’t be an unusual or odd request in a road bike store, but it would be a <strong>very difficult</strong> product-finding task at the 98% of e-commerce sites that don’t offer category-specific sort types, because the “lightweight” preference isn’t suited for a “hard” boundary filter (but instead needs the soft boundary of a sort type).</p>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 64.92248062015504%;"><img alt="" src="/assets/category-specific-sorting-03-rei-original-5ec1970395515322e74260bc6227f3168c3bc233199bc26589043cc62bafca62.jpg" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>While there are plenty of sorting options available none of them are category-specific and none of them will help the user with their “lightweight” preference – even though the site clearly has weight information on their bikes (to support the “Weight (lbs)” filter).</p>
+</div></div></div></div>
+
+<p>Let’s play out the scenario to illustrate the issue. Note in the following how you can replace “bike” with your main product category and “weight” with any one of the primary numeric product attributes for that product category (e.g., capacity, power, speed, size, duration):</p>
+
+<ol>
+  <li>The user starts out by finding the “Bikes” category and applies a “Bike type” filter of “Road bike”. The user now has a list of road bikes.</li>
+  <li>Then, the user applies a “Price” filter defining an upper limit of $2,000. That’s easily done at most sites, and the specificity is well-suited for the hard boundary of a filter. The user now has a list of road bikes at $2,000 and below.</li>
+  <li>Finally the user cares about the bike weight, and this is where problems arise. If a “Weight” filter at the lowest end of the range is applied, the user ends up with a very small selection of road bikes, and will still have to open all their respective product pages to figure out which one is the lightest. If a broader “Weight” range is applied (or no “Weight” filter is applied at all), the user ends up with road bikes that aren’t necessarily lightweight, forcing the user to open every product page and mentally keep track of which bikes are lightweight and which aren’t. Clearly neither of these approaches are ideal as the user must either apply overly restrictive filters (meaning they might miss out on relevant items), or make do with an excessively permissive “Weight” filter or no filtering at all (introducing a high degree of noise in the product list leading to needless friction in the user’s product exploration).</li>
+</ol>
+
+<p>Now imagine in step #3, if the user had a <strong>category-specific sort type</strong> for “Weight”. If instead of applying “Weight” as a filter the user sorted the product list by weight (while keeping the $2,000 price filter in place), they would end up with a list of road bikes priced $2,000 or less sorted by lowest weight. The user would effectively have indicated their “lightweight” preference without having had to define highly precise cut-off points. Finally, the user would have a list of road bikes from lightest to heaviest costing $2,000 or below.</p>
+
+<p>The “soft” boundaries of sorting essentially enable users to apply a preference to the product list without having to worry about striking some perfect <strong>magical sweet spot</strong> between an overly restrictive and excessively lax filter range. Yet filters remain relevant for things like the user’s specific budget limitation of $2,000 – this isn’t a mere preference. It’s by applying a combination of both “soft” (sorting) and “hard” (filtering) boundaries that the user is ultimately able to get what they are seeking: a list matching both the specific budget limitations of $2,000 while also having the “lightweight” preference applied.</p>
+
+<h2 id="why-users-often-prefer-soft-boundaries">Why Users Often Prefer “Soft” Boundaries</h2>
+
+<p>During usability testing the subjects often preferred the “soft” boundaries of sorting over the “hard” boundaries of filters. The road bike example illustrates why users in some cases prefer “soft” boundaries over “hard” ones – it alleviates them from defining cut-off points. Further investigation reveals <strong>3 reasons</strong> users prefer the “soft” boundaries of sorting:</p>
+
+<ol>
+  <li><strong>Fear of missing out</strong> – The user may not want to set a hard boundary in fear of missing out on relevant products that fall just outside their defined range, hence many users prefer the soft boundaries of sorting.</li>
+  <li><strong>Lacks domain knowledge</strong> – The user may not know or feel like they have sufficient knowledge about the product domain (the natural spec jumps within the vertical, the implications of different product attributes, etc) to set appropriate cut-off criteria. In these instances the user will naturally find it more desirable to indicate their preference without having to define it through criteria they don’t fully understand.</li>
+  <li><strong>Unclear about own preferences</strong> – The user may not be entirely clear on their own preferences and restrictions (budgetary limitations, compatibility requirements, usage conditions, etc). Oftentimes users purchasing for themselves are willing to flex their criteria significantly once they start seeing what’s available and begin to understand the product domain better.</li>
+</ol>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 48.740310077519375%;"><img alt="" src="/assets/category-specific-sorting-04-soft-boundary-preference-5cb14a2121d7f15c53bd1ab82551c3e293e624a5b63edc7924253cfa8212a149.png" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>Setting specific criteria requires knowledge about the product domain (reason #2) – the natural spec jumps within the vertical, the implications of different attribute values, etc. – as well as knowledge about your own preferences and restrictions (reason #3) – budgetary limitations, compatibility requirements, usage conditions, etc. Both of these feed into reason #1, the fear of missing out on relevant items. If the user either lacks domain knowledge or is unclear about their own preferences (or both), they will tend to prefer “soft” boundaries because they would fear excluding potentially relevant products if they were to apply restrictive filtering criteria.</p>
+</div></div></div></div>
+
+<p>All of this is typically provoked by an <strong>information dilemma</strong>: the user has to set the “hard” boundary criteria before seeing the available products. So unless the user already has very good information about the product domain and their own preferences (prior to visiting the site) they often feel unconfident in applying such strict criteria. Few users want to fine-tune a product list if they don’t feel confident in accurately predicting the consequences of this fine-tuning.</p>
+
+<h2 id="sorting-prevents-accidental-product-elimination">Sorting Prevents Accidental Product Elimination</h2>
+
+<p>Sorting provide users a way to <strong>fine-tune</strong> the product list to their preferences without running the risk of accidentally eliminating relevant items. It thus helps solve one of the fundamental challenges users have when browsing an e-commerce site: somehow finding all the products that are relevant to their specific needs and preferences out of the site’s typically enormous product catalog.</p>
+
+<p>In order to attain this highly curated list the user must narrow the product list down to a <strong>manageable size</strong> without discarding any relevant products in the process – they must at once be sufficiently aggressive in their filtering to reach a manageable product list without being so aggressive that they filter out relevant items in the process.</p>
+
+<p>When the user can only filter and not sort by category-specific attributes they are limited to setting “hard” boundaries only. This leaves the user with two <strong>less-than-ideal options</strong>: either 1) apply the preferred range as filters and run the risk of accidental product elimination, or 2) loosen the preferred range to be more inclusive to avoid this elimination at the cost of ending up with a much poorer signal-to-noise ratio (due to numerous less relevant items suddenly being included).</p>
+
+<p>Soft boundaries are very helpful in this regard because they allow the user to mainly browse a certain range without excluding (any potentially relevant) items outside it – enabling users to <strong>discriminate</strong> rather than eliminate.</p>
+
+<h2 id="sorting-increase-domain-and-site-insight">Sorting Increase Domain and Site Insight</h2>
+
+<p>“Soft boundary” sorting can provide users with a better understanding of the product vertical and site catalog by revealing different “spec jumps” and “product gaps”. For instance, in the road bike example, it might be that the first three bikes in the sorted list cost $1,800 and weigh in at ~17 pounds (~7.5kg), and then there’s a jump in the list where bikes four through ten are 6 to 8 pounds heavier but also cost significantly less (e.g., weigh 22 pounds but only cost $900). This would help the user better <strong>understand the relationship</strong> between price and weight within the road bikes domain.</p>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 64.92248062015504%;"><img alt="" src="/assets/category-specific-sorting-01-rei-mock-up-4b493aff69299ddd35d3cfe999080636a6a958570f7100fd4cc1d4b78a959ed8.jpg" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>A mock-up we’ve created of what the earlier road bike example could look like with category-specific sorting for “Weight” and “Gears”. Sort types like these can help both novice and expert users gain better insight into the site as well as the domain they are currently browsing.</p>
+</div></div></div></div>
+
+<p>This is obviously very helpful to <strong>novice users</strong> because their lack of domain knowledge means they don’t instinctively know the natural “spec jumps” in the product vertical and might therefore inadvertently eliminate large clusters of perfectly relevant products. These users will therefore tend to prefer “soft” boundary sorting over “hard” boundary filters in fear of missing out due to a lack of domain knowledge, as explored earlier.</p>
+
+<p>However, category-specific sorting can also help <strong>expert users</strong> despite them being intimately familiar with the “spec jumps” in a product vertical because it provides insight into the site’s catalog and any “product gaps” there might be in it. After all, just because the user knows a certain range of products exist they don’t necessarily know which of those products the site carries. By sorting instead of filtering, expert users get insight into which product groups the site carries within the vertical (and which they don’t carry).</p>
+
+<p>Category-specific sort types can thus help increase novice users’ understanding of the product category (and any “spec jumps” within it) while simultaneously providing expert users insight into the breadth of the site’s product range (and any “gaps” within it).</p>
+
+<h2 id="numerical-category-specific-product-attributes">Numerical Category-Specific Product Attributes</h2>
+
+<p>Category-specific sort types are appropriate in product categories where the products <strong>share</strong> one or more numeric attributes that users may have an interest in or preference for – such as the “Display size” of TVs or “Storage capacity” of hard drives. This is particularly true if the attribute is something where users don’t want to apply strict criteria or are unfit at doing so due to a lack of domain knowledge.</p>
+
+<p>The numericality of the product attribute is important because it makes it <strong>well-disposed to sorting</strong> as the products can be ordered based on the natural progression of the attribute. Compare this to a non-numeric product attribute like ‘Color’ which can’t really be sorted in a sequence logical to most users. It simply doesn’t make sense to sort by discrete product features even if it is technically possible because there isn’t a natural progression or hierarchy for such attributes. For example, DSLR camera lenses can’t meaningfully be sorted by “Lens type” or “Camera mount” (as they have no natural progression or hierarchy), but it could make sense to sort the category by “Focal length” or “Angle of View”.</p>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 62.967032967032964%;"><img alt="" src="/assets/category-specific-sorting-06-amazon-ad5690ce6efef0afa70989eb7fa5df86cc7b847c16f0f2d735f04088419c4068.jpg" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>The closest we came to a meaningful category-specific sort type during testing was at Amazon which have a special “Release date” sorting option within their “Movies &amp; TV” scope. The attribute is unique to the category and dates obviously have a natural progression. Unfortunately it is a rather ambiguous product attribute since it isn’t clear if it is the premiere date of the movie or the day the DVD version was released – something that tripped up numerous subjects during the usability tests.</p>
+</div></div></div></div>
+
+<p>Many product verticals do, however, have such numeric attributes and category-specific sort types are therefore relevant to a <strong>wide range</strong> of domains such as consumer electronics, kitchen utilities, office supplies, sports and hobby equipment, hardware, and similar industries. There are some exceptions of course – in particular verticals that are driven mainly by aesthetics, such as home decor and apparel. These verticals generally have only a few or no important numeric product attributes and it therefore won’t necessarily be meaningful to implement category-specific sort types in them (although even in these domains, attributes such as weight and size may be important depending on the exact product type).</p>
+
+<h2 id="curating-the-category-specific-sort-types">Curating the Category-Specific Sort Types</h2>
+
+<p>Determining which product attributes should be implemented as category-specific sort types is a fairly straight-forward matter: simply take the 3-5 most important numeric category-specific filters available in each category on your site and turn them into sorting options too. Let’s tackle some common questions that typically arise as a result of that statement:</p>
+
+<ul>
+  <li><em>Why 3-5 attributes?</em> To avoid overly long sorting drop-downs that induce choice paralysis. Although don’t get too stuck on the specific numbers, just make sure the number of sorting options don’t get completely out of hand.</li>
+  <li><em>How do I identify which filters are the “most important”?</em> Well, these filters should already be identified as the order of the filtering options should be determined on their relative importance. This importance may be arrived at through expert (human) judgement or programmatically through various proxies (filter popularity, number of products, feature impact on price, etc) – or a combination of the two. An example of a very important product trait would of course be ‘<a href="http://baymard.com/blog/price-per-unit">price per unit</a>’ in categories where this attribute is relevant (i.e. where multi-quantity products are common, such as golf balls, copy paper, liquids, etc).</li>
+  <li><em>Why numeric attributes?</em> Because they have a natural progression that makes them suitable for sorting. (See the above section.)</li>
+  <li><em>Why category-specific filters?</em> The category-specific sort types should be provided in addition to the regular site-wide sort types such as “Price”. We assume you already have these in place and are here dealing with dynamically created sorting options that won’t be available site-wide. (Note: If category-specific filters aren’t already implemented, stop reading this article and implement them right now! Our usability testing revealed this to be one of the most fundamental features to the user’s browsing experience.)</li>
+  <li><em>How do I turn the filters into sorting options as well?</em> Well, with category-specific filters already in place, this is a simple matter of reusing the data powering those filters. After all, in order to be filterable the product data will already be fully structured and can therefore simply be reused for sorting purposes as well.</li>
+</ul>
+
+<p>So in summary: We limit the number of category-specific filters to double as sort types to <em>3-5 attributes</em> to avoid unruly and intimidating sorting drop-downs. Because of this restraint we obviously want to pick the <em>most important</em> product attributes to cater for the most likely use cases on our site. And we implement all of this by tapping into the data structures already in place for category-specific filters.</p>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 66.66666666666666%;"><img alt="" src="/assets/category-specific-sorting-02-bestbuy-f14fff79d781e96075b7d85c778786cc0cf003610cd26e6128d3a8a00f045b8e.jpg" /></div></div>
+<div class="anecdote-caption-ajkd3b"><div class="inner anecdote-wysicontent-ndj4ab"><p>If familiar with the <a href="http://baymard.com/blog/kano-model">Kano model</a>, the attributes to use as category-specific sort types will often be the “Performance” attributes within each product vertical.</p>
+</div></div></div></div>
+
+<p>The beauty of category-specific sort types is that they tap into <strong>investments already made</strong> in filters, effectively increasing the return on those investments. Because it’s a technical feature, it doesn’t require continuous data collection or curation (beyond what is already being done for the filters), and it’s therefore a one-time investment that permanently increases the value of the continuous investments made in collecting, curating and maintaining structured product attributes.</p>
+
+<p>The most important filters within each unique product category can thus <em>also</em> be utilized as sort types in that category. (It should of course still be a filter as well – this is about giving users the ability to apply both “hard” and “soft” boundaries to product attributes of interest to them.)</p>
+
+<h2 id="empowering-users-with-category-specific-sort-types">Empowering Users with Category-Specific Sort Types</h2>
+
+<p>The user needs both hard boundaries (i.e. filters) and soft boundaries (i.e. sorting) for optimal control over the product list. When the user has good domain knowledge and a clear understanding of their own needs, “hard boundary” filters are appropriate. However, as we’ve seen throughout this article there are other times where the user doesn’t have this level of domain knowledge or strict criteria for their product needs, in which case “soft boundary” sorting will often be more suitable. Both “hard” and “soft” boundaries thus have <strong>valid usage scenarios</strong> and this alone justifies their implementation.</p>
+
+<p>A major bonus of implementing both “hard” and “soft” boundary controls (i.e. filtering and sorting) is that users can then <strong>combine them</strong>. This affords the user a new level of control over the product list, enabling them to wield both “hard” restrictions and “softer” preferences onto the site’s product lists. Suddenly a rather complex statement like “I would like a lightweight road bike and my budget is $2,000” can successfully be applied, with both “hard” restrictions (i.e. “road bike” and “$2,000 budget”) <em>and</em> “softer” preferences (i.e. “lightweight”).</p>
+
+<p>If you have category-specific filters, the data is already there (and if you don’t, you really should implement them!), ready to be reused for category-specific <em>sort types</em> as well. Category-specific sort types are thus a great opportunity to gain even more from the structured data you’ve invested so dearly in collecting, curating and maintaining.</p>
+
+<div class="anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-small v-float-right v-float-from-large-handheld"><div class="inner"><div class="anecdote-intrinsic-embed-n42ha1"><div class="inner" style="padding-bottom: 129.41176470588235%;"><img alt="" src="/assets/category-specific-sorting-08-faceted-sorting-952f653066737f1a75aaf01a867ba4ca4e072b2a76cd38d68d8c5515e9820baf.jpg" /></div></div></div></div>
+
+<p>Indeed, this may even be taken to the next level by combining category-specific sort types with scope selection in higher-level categories and on <a href="http://baymard.com/blog/ecommerce-sub-category-pages">sub-category pages</a>. This combines category-specific sort types with <a href="http://baymard.com/blog/faceted-sorting">faceted sorting</a>, allowing highly relevant and popular category-specific sort types to be displayed at (higher) category levels where all products don’t actually share the attribute to be sorted by. This would furthermore make category-specific sort types possible in search results despite some of the results not having the sorting attribute.</p>
+
+<p>Sadly, category-specific sort types are a good example of just how <strong>neglected sorting</strong> is on e-commerce sites – numerous users want these sort types yet no sites offer them! It’s a rare example of an obvious innovation that e-commerce sites have yet to make. (Tip: you can see <a href="http://baymard.com/ecommerce-product-lists/benchmark/page-types/sorting-tool">46 different sorting interfaces</a> from the top US e-commerce sites we benchmarked for this study.)</p>
+
+<p>Category-specific sort types are ultimately about <strong>empowering users</strong> with the tools they need to reach the product selection they want and have it presented in a way that suits their unique interests. It’s an obvious opportunity to increase the return on existing product data investments, empower your users and get ahead of the competition.</p>
+):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/assets/category-specific-sorting-01-rei-mock-up-4b493aff69299ddd35d3cfe999080636a6a958570f7100fd4cc1d4b78a959ed8.jpg" for ::1 at 2017-12-14 11:35:30 +0100
+Started GET "/assets/category-specific-sorting-02-bestbuy-f14fff79d781e96075b7d85c778786cc0cf003610cd26e6128d3a8a00f045b8e.jpg" for ::1 at 2017-12-14 11:35:30 +0100
+Started GET "/assets/category-specific-sorting-03-rei-original-5ec1970395515322e74260bc6227f3168c3bc233199bc26589043cc62bafca62.jpg" for ::1 at 2017-12-14 11:35:30 +0100
+Started GET "/assets/category-specific-sorting-08-faceted-sorting-952f653066737f1a75aaf01a867ba4ca4e072b2a76cd38d68d8c5515e9820baf.jpg" for ::1 at 2017-12-14 11:35:30 +0100
+Started GET "/assets/category-specific-sorting-06-amazon-ad5690ce6efef0afa70989eb7fa5df86cc7b847c16f0f2d735f04088419c4068.jpg" for ::1 at 2017-12-14 11:35:30 +0100
+Started GET "/assets/category-specific-sorting-04-soft-boundary-preference-5cb14a2121d7f15c53bd1ab82551c3e293e624a5b63edc7924253cfa8212a149.png" for ::1 at 2017-12-14 11:35:30 +0100
+Started GET "/" for ::1 at 2017-12-14 11:35:35 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 623ms
+
+
+  
+RuntimeError ("<h1 id=\"category-specific-sorting-a-new-way-to-sort-products\">Category-Specific Sorting: A New Way to Sort Products</h1>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-full-width\"><div class=\"inner\"><a href=\"//baymard.com\" title=\"Clicking this image will take you to Baymard.com!\" class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 64.92248062015504%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-01-rei-mock-up-4b493aff69299ddd35d3cfe999080636a6a958570f7100fd4cc1d4b78a959ed8.jpg\" /></div></a>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>This is the 3rd in a series of 9 articles based on research findings from our e-commerce <a href=\"http://baymard.com/research/ecommerce-product-lists study\">product list usability</a>.</p>\n</div></div></div></div>\n\n<p>We considered naming this article “the sort type all users want but zero sites offer” because category-specific sorting really is one of those rare instances where an obvious feature has somehow been <strong>completely overlooked</strong> by the e-commerce community.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-big v-mood-positive v-sidebar-caption\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 56.25%;\"><iframe src=\"https://www.youtube.com/embed/ZCBE8ocOkAQ\" frameborder=\"0\" allowfullscreen=\"\"></iframe></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>\n</div></div></div></div>\n\n<p>After all, it really shouldn’t come as a surprise that users would like to sort a list of TVs by “Screen size” or a collection of hard drives by “Storage capacity”.</p>\n\n<div class=\"anecdote-pull-quote-sba2ha anecdote-module-3ba83n v-size-big\"><div class=\"inner\"><p>By “category-specific sort types” we mean any sorting options that are only available in one or a few select categories</p>\n</div></div>\n\n<p>During our research study on product list usability the test subjects repeatedly sought out these kinds of category-specific sort types – however, to no avail since seemingly <strong>zero sites</strong> offer them. Even after <a href=\"http://baymard.com/ecommerce-product-lists/benchmark/site-reviews\">benchmarking</a> the product lists of 50 major e-commerce sites we have yet to find a site that truly offer category-specific sorting.</p>\n\n<div class=\"anecdote-gallery-dn2bak anecdote-module-3ba83n v-size-big\"><div class=\"inner\"><div class=\"content anecdote-flex-module-a4j2aj v-gutter-spacing-small v-flow-from-tablet\">\n  <div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-mood-positive\" style=\"width:75.21865889212827%;flex-basis:75.21865889212827%\"><div class=\"inner\">\n<div class=\"anecdote-flex-offset-a4j2aj\" style=\"padding-top: 0.0%;\"></div>\n<div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 66.66666666666666%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-02-bestbuy-f14fff79d781e96075b7d85c778786cc0cf003610cd26e6128d3a8a00f045b8e.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\">\n<p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>\n</div></div>\n</div></div>\n  <div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-mood-negative\" style=\"width:24.78134110787172%;flex-basis:24.78134110787172%\"><div class=\"inner\">\n<div class=\"anecdote-flex-offset-a4j2aj\" style=\"padding-top: 72.94117647058822%;\"></div>\n<div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 129.41176470588235%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-08-faceted-sorting-952f653066737f1a75aaf01a867ba4ca4e072b2a76cd38d68d8c5515e9820baf.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\">\n<p>An example of how things can go really wrong.</p>\n</div></div>\n</div></div>\n</div></div></div>\n\n<p>In this article we’ll outline our research findings on why <strong>category-specific sorting</strong> is so important to the user’s product finding abilities, and how it can be implemented.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-small v-float-left v-float-from-large-handheld\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 66.66666666666666%;\"><img alt=\"\" src=\"http://assets.baymard.com/blog/category-specific-sorting-02-bestbuy-d0496405ef767b1f469cc0e71cc4f84d.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>\n</div></div></div></div>\n\n<p>Given that category-specific sorting is such an uncommon features, let’s quickly <strong>define</strong> the term. By “category-specific sort types” we mean any sorting options that are only available in one or a few select categories (because they wouldn’t make sense as site-wide sorting options – they only make sense for the products within those particular categories). Examples include being able to sort suitcases by volume, fishing rods by length, pens by point size, hard drives by storage capacity and spindle speed, road bikes by weight, etc. It’s this category specificity that makes them different from common site-wide sort types such as ‘Best Selling’, ‘Relevance’, ‘User Ratings’, and ‘Price’, which are typically available for all products and categories throughout a site.</p>\n\n<h2 id=\"soft-boundary-sorting-vs-hard-boundary-filtering\">‘Soft’ Boundary Sorting vs ‘Hard’ Boundary Filtering</h2>\n\n<p>The differences between filtering and sorting may on the surface appear subtle. Indeed, many users <strong>mix up</strong> the terminology or use the terms interchangeably. However, the differences are in fact quite significant: <em>Filters</em> set the criteria for whether a given product is in- or excluded from the product list (i.e. what is displayed) whereas <em>Sorting</em> determines the sequence of those products (i.e. how it is displayed).</p>\n\n<p>This makes <em>Filters</em> great for setting “hard” boundaries while <em>Sorting</em> is optimal for applying “soft” boundaries:</p>\n\n<ul>\n  <li><strong>Filters</strong> – Sets a “hard” boundary. Any product that doesn’t strictly fall within the selected value(s) will be cut off. It is a great way for users to exclude any products that don’t match specific criteria.</li>\n  <li><strong>Sorting</strong> – Applies a “soft” boundary. The products are ordered by the chosen sort type (in the case of category-specific sort types that typically means a product attribute). It changes the sequence of the products but doesn’t exclude any items, enabling users to still see items that fall outside their initial boundary.</li>\n</ul>\n\n<p>Our <a href=\"http://baymard.com/research/ecommerce-product-lists\">product list</a> usability testing showed that <strong>users need both</strong> hard boundaries (i.e. filters) and soft boundaries (i.e. sorting) for optimal control over the product list. Depending on the user’s knowledge of the product domain and their own needs and restrictions they may have very strict and 100% clear criteria the product must fall within, in which case “hard” boundary filters are appropriate.</p>\n\n<p>However, in many cases users don’t have that strict criteria and sometimes they don’t even know what an appropriate filtering range would be, in which case “soft” boundary sorting is more suitable. For instance, the user might <strong>care about</strong> a product attribute without having a specific criteria for it, or they may not have the necessary domain knowledge to set meaningful cut-off points.</p>\n\n<h2 id=\"case-the-2000-lightweight-road-bike\">Case: The $2,000 Lightweight Road Bike</h2>\n\n<p>Let’s take an example of a user with a simple purchase preference: <em>“I would like a lightweight road bike and my budget is $2,000.”</em> Now, that wouldn’t be an unusual or odd request in a road bike store, but it would be a <strong>very difficult</strong> product-finding task at the 98% of e-commerce sites that don’t offer category-specific sort types, because the “lightweight” preference isn’t suited for a “hard” boundary filter (but instead needs the soft boundary of a sort type).</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 64.92248062015504%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-03-rei-original-5ec1970395515322e74260bc6227f3168c3bc233199bc26589043cc62bafca62.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>While there are plenty of sorting options available none of them are category-specific and none of them will help the user with their “lightweight” preference – even though the site clearly has weight information on their bikes (to support the “Weight (lbs)” filter).</p>\n</div></div></div></div>\n\n<p>Let’s play out the scenario to illustrate the issue. Note in the following how you can replace “bike” with your main product category and “weight” with any one of the primary numeric product attributes for that product category (e.g., capacity, power, speed, size, duration):</p>\n\n<ol>\n  <li>The user starts out by finding the “Bikes” category and applies a “Bike type” filter of “Road bike”. The user now has a list of road bikes.</li>\n  <li>Then, the user applies a “Price” filter defining an upper limit of $2,000. That’s easily done at most sites, and the specificity is well-suited for the hard boundary of a filter. The user now has a list of road bikes at $2,000 and below.</li>\n  <li>Finally the user cares about the bike weight, and this is where problems arise. If a “Weight” filter at the lowest end of the range is applied, the user ends up with a very small selection of road bikes, and will still have to open all their respective product pages to figure out which one is the lightest. If a broader “Weight” range is applied (or no “Weight” filter is applied at all), the user ends up with road bikes that aren’t necessarily lightweight, forcing the user to open every product page and mentally keep track of which bikes are lightweight and which aren’t. Clearly neither of these approaches are ideal as the user must either apply overly restrictive filters (meaning they might miss out on relevant items), or make do with an excessively permissive “Weight” filter or no filtering at all (introducing a high degree of noise in the product list leading to needless friction in the user’s product exploration).</li>\n</ol>\n\n<p>Now imagine in step #3, if the user had a <strong>category-specific sort type</strong> for “Weight”. If instead of applying “Weight” as a filter the user sorted the product list by weight (while keeping the $2,000 price filter in place), they would end up with a list of road bikes priced $2,000 or less sorted by lowest weight. The user would effectively have indicated their “lightweight” preference without having had to define highly precise cut-off points. Finally, the user would have a list of road bikes from lightest to heaviest costing $2,000 or below.</p>\n\n<p>The “soft” boundaries of sorting essentially enable users to apply a preference to the product list without having to worry about striking some perfect <strong>magical sweet spot</strong> between an overly restrictive and excessively lax filter range. Yet filters remain relevant for things like the user’s specific budget limitation of $2,000 – this isn’t a mere preference. It’s by applying a combination of both “soft” (sorting) and “hard” (filtering) boundaries that the user is ultimately able to get what they are seeking: a list matching both the specific budget limitations of $2,000 while also having the “lightweight” preference applied.</p>\n\n<h2 id=\"why-users-often-prefer-soft-boundaries\">Why Users Often Prefer “Soft” Boundaries</h2>\n\n<p>During usability testing the subjects often preferred the “soft” boundaries of sorting over the “hard” boundaries of filters. The road bike example illustrates why users in some cases prefer “soft” boundaries over “hard” ones – it alleviates them from defining cut-off points. Further investigation reveals <strong>3 reasons</strong> users prefer the “soft” boundaries of sorting:</p>\n\n<ol>\n  <li><strong>Fear of missing out</strong> – The user may not want to set a hard boundary in fear of missing out on relevant products that fall just outside their defined range, hence many users prefer the soft boundaries of sorting.</li>\n  <li><strong>Lacks domain knowledge</strong> – The user may not know or feel like they have sufficient knowledge about the product domain (the natural spec jumps within the vertical, the implications of different product attributes, etc) to set appropriate cut-off criteria. In these instances the user will naturally find it more desirable to indicate their preference without having to define it through criteria they don’t fully understand.</li>\n  <li><strong>Unclear about own preferences</strong> – The user may not be entirely clear on their own preferences and restrictions (budgetary limitations, compatibility requirements, usage conditions, etc). Oftentimes users purchasing for themselves are willing to flex their criteria significantly once they start seeing what’s available and begin to understand the product domain better.</li>\n</ol>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 48.740310077519375%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-04-soft-boundary-preference-5cb14a2121d7f15c53bd1ab82551c3e293e624a5b63edc7924253cfa8212a149.png\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>Setting specific criteria requires knowledge about the product domain (reason #2) – the natural spec jumps within the vertical, the implications of different attribute values, etc. – as well as knowledge about your own preferences and restrictions (reason #3) – budgetary limitations, compatibility requirements, usage conditions, etc. Both of these feed into reason #1, the fear of missing out on relevant items. If the user either lacks domain knowledge or is unclear about their own preferences (or both), they will tend to prefer “soft” boundaries because they would fear excluding potentially relevant products if they were to apply restrictive filtering criteria.</p>\n</div></div></div></div>\n\n<p>All of this is typically provoked by an <strong>information dilemma</strong>: the user has to set the “hard” boundary criteria before seeing the available products. So unless the user already has very good information about the product domain and their own preferences (prior to visiting the site) they often feel unconfident in applying such strict criteria. Few users want to fine-tune a product list if they don’t feel confident in accurately predicting the consequences of this fine-tuning.</p>\n\n<h2 id=\"sorting-prevents-accidental-product-elimination\">Sorting Prevents Accidental Product Elimination</h2>\n\n<p>Sorting provide users a way to <strong>fine-tune</strong> the product list to their preferences without running the risk of accidentally eliminating relevant items. It thus helps solve one of the fundamental challenges users have when browsing an e-commerce site: somehow finding all the products that are relevant to their specific needs and preferences out of the site’s typically enormous product catalog.</p>\n\n<p>In order to attain this highly curated list the user must narrow the product list down to a <strong>manageable size</strong> without discarding any relevant products in the process – they must at once be sufficiently aggressive in their filtering to reach a manageable product list without being so aggressive that they filter out relevant items in the process.</p>\n\n<p>When the user can only filter and not sort by category-specific attributes they are limited to setting “hard” boundaries only. This leaves the user with two <strong>less-than-ideal options</strong>: either 1) apply the preferred range as filters and run the risk of accidental product elimination, or 2) loosen the preferred range to be more inclusive to avoid this elimination at the cost of ending up with a much poorer signal-to-noise ratio (due to numerous less relevant items suddenly being included).</p>\n\n<p>Soft boundaries are very helpful in this regard because they allow the user to mainly browse a certain range without excluding (any potentially relevant) items outside it – enabling users to <strong>discriminate</strong> rather than eliminate.</p>\n\n<h2 id=\"sorting-increase-domain-and-site-insight\">Sorting Increase Domain and Site Insight</h2>\n\n<p>“Soft boundary” sorting can provide users with a better understanding of the product vertical and site catalog by revealing different “spec jumps” and “product gaps”. For instance, in the road bike example, it might be that the first three bikes in the sorted list cost $1,800 and weigh in at ~17 pounds (~7.5kg), and then there’s a jump in the list where bikes four through ten are 6 to 8 pounds heavier but also cost significantly less (e.g., weigh 22 pounds but only cost $900). This would help the user better <strong>understand the relationship</strong> between price and weight within the road bikes domain.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 64.92248062015504%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-01-rei-mock-up-4b493aff69299ddd35d3cfe999080636a6a958570f7100fd4cc1d4b78a959ed8.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>A mock-up we’ve created of what the earlier road bike example could look like with category-specific sorting for “Weight” and “Gears”. Sort types like these can help both novice and expert users gain better insight into the site as well as the domain they are currently browsing.</p>\n</div></div></div></div>\n\n<p>This is obviously very helpful to <strong>novice users</strong> because their lack of domain knowledge means they don’t instinctively know the natural “spec jumps” in the product vertical and might therefore inadvertently eliminate large clusters of perfectly relevant products. These users will therefore tend to prefer “soft” boundary sorting over “hard” boundary filters in fear of missing out due to a lack of domain knowledge, as explored earlier.</p>\n\n<p>However, category-specific sorting can also help <strong>expert users</strong> despite them being intimately familiar with the “spec jumps” in a product vertical because it provides insight into the site’s catalog and any “product gaps” there might be in it. After all, just because the user knows a certain range of products exist they don’t necessarily know which of those products the site carries. By sorting instead of filtering, expert users get insight into which product groups the site carries within the vertical (and which they don’t carry).</p>\n\n<p>Category-specific sort types can thus help increase novice users’ understanding of the product category (and any “spec jumps” within it) while simultaneously providing expert users insight into the breadth of the site’s product range (and any “gaps” within it).</p>\n\n<h2 id=\"numerical-category-specific-product-attributes\">Numerical Category-Specific Product Attributes</h2>\n\n<p>Category-specific sort types are appropriate in product categories where the products <strong>share</strong> one or more numeric attributes that users may have an interest in or preference for – such as the “Display size” of TVs or “Storage capacity” of hard drives. This is particularly true if the attribute is something where users don’t want to apply strict criteria or are unfit at doing so due to a lack of domain knowledge.</p>\n\n<p>The numericality of the product attribute is important because it makes it <strong>well-disposed to sorting</strong> as the products can be ordered based on the natural progression of the attribute. Compare this to a non-numeric product attribute like ‘Color’ which can’t really be sorted in a sequence logical to most users. It simply doesn’t make sense to sort by discrete product features even if it is technically possible because there isn’t a natural progression or hierarchy for such attributes. For example, DSLR camera lenses can’t meaningfully be sorted by “Lens type” or “Camera mount” (as they have no natural progression or hierarchy), but it could make sense to sort the category by “Focal length” or “Angle of View”.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 62.967032967032964%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-06-amazon-ad5690ce6efef0afa70989eb7fa5df86cc7b847c16f0f2d735f04088419c4068.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>The closest we came to a meaningful category-specific sort type during testing was at Amazon which have a special “Release date” sorting option within their “Movies &amp; TV” scope. The attribute is unique to the category and dates obviously have a natural progression. Unfortunately it is a rather ambiguous product attribute since it isn’t clear if it is the premiere date of the movie or the day the DVD version was released – something that tripped up numerous subjects during the usability tests.</p>\n</div></div></div></div>\n\n<p>Many product verticals do, however, have such numeric attributes and category-specific sort types are therefore relevant to a <strong>wide range</strong> of domains such as consumer electronics, kitchen utilities, office supplies, sports and hobby equipment, hardware, and similar industries. There are some exceptions of course – in particular verticals that are driven mainly by aesthetics, such as home decor and apparel. These verticals generally have only a few or no important numeric product attributes and it therefore won’t necessarily be meaningful to implement category-specific sort types in them (although even in these domains, attributes such as weight and size may be important depending on the exact product type).</p>\n\n<h2 id=\"curating-the-category-specific-sort-types\">Curating the Category-Specific Sort Types</h2>\n\n<p>Determining which product attributes should be implemented as category-specific sort types is a fairly straight-forward matter: simply take the 3-5 most important numeric category-specific filters available in each category on your site and turn them into sorting options too. Let’s tackle some common questions that typically arise as a result of that statement:</p>\n\n<ul>\n  <li><em>Why 3-5 attributes?</em> To avoid overly long sorting drop-downs that induce choice paralysis. Although don’t get too stuck on the specific numbers, just make sure the number of sorting options don’t get completely out of hand.</li>\n  <li><em>How do I identify which filters are the “most important”?</em> Well, these filters should already be identified as the order of the filtering options should be determined on their relative importance. This importance may be arrived at through expert (human) judgement or programmatically through various proxies (filter popularity, number of products, feature impact on price, etc) – or a combination of the two. An example of a very important product trait would of course be ‘<a href=\"http://baymard.com/blog/price-per-unit\">price per unit</a>’ in categories where this attribute is relevant (i.e. where multi-quantity products are common, such as golf balls, copy paper, liquids, etc).</li>\n  <li><em>Why numeric attributes?</em> Because they have a natural progression that makes them suitable for sorting. (See the above section.)</li>\n  <li><em>Why category-specific filters?</em> The category-specific sort types should be provided in addition to the regular site-wide sort types such as “Price”. We assume you already have these in place and are here dealing with dynamically created sorting options that won’t be available site-wide. (Note: If category-specific filters aren’t already implemented, stop reading this article and implement them right now! Our usability testing revealed this to be one of the most fundamental features to the user’s browsing experience.)</li>\n  <li><em>How do I turn the filters into sorting options as well?</em> Well, with category-specific filters already in place, this is a simple matter of reusing the data powering those filters. After all, in order to be filterable the product data will already be fully structured and can therefore simply be reused for sorting purposes as well.</li>\n</ul>\n\n<p>So in summary: We limit the number of category-specific filters to double as sort types to <em>3-5 attributes</em> to avoid unruly and intimidating sorting drop-downs. Because of this restraint we obviously want to pick the <em>most important</em> product attributes to cater for the most likely use cases on our site. And we implement all of this by tapping into the data structures already in place for category-specific filters.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 66.66666666666666%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-02-bestbuy-f14fff79d781e96075b7d85c778786cc0cf003610cd26e6128d3a8a00f045b8e.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>If familiar with the <a href=\"http://baymard.com/blog/kano-model\">Kano model</a>, the attributes to use as category-specific sort types will often be the “Performance” attributes within each product vertical.</p>\n</div></div></div></div>\n\n<p>The beauty of category-specific sort types is that they tap into <strong>investments already made</strong> in filters, effectively increasing the return on those investments. Because it’s a technical feature, it doesn’t require continuous data collection or curation (beyond what is already being done for the filters), and it’s therefore a one-time investment that permanently increases the value of the continuous investments made in collecting, curating and maintaining structured product attributes.</p>\n\n<p>The most important filters within each unique product category can thus <em>also</em> be utilized as sort types in that category. (It should of course still be a filter as well – this is about giving users the ability to apply both “hard” and “soft” boundaries to product attributes of interest to them.)</p>\n\n<h2 id=\"empowering-users-with-category-specific-sort-types\">Empowering Users with Category-Specific Sort Types</h2>\n\n<p>The user needs both hard boundaries (i.e. filters) and soft boundaries (i.e. sorting) for optimal control over the product list. When the user has good domain knowledge and a clear understanding of their own needs, “hard boundary” filters are appropriate. However, as we’ve seen throughout this article there are other times where the user doesn’t have this level of domain knowledge or strict criteria for their product needs, in which case “soft boundary” sorting will often be more suitable. Both “hard” and “soft” boundaries thus have <strong>valid usage scenarios</strong> and this alone justifies their implementation.</p>\n\n<p>A major bonus of implementing both “hard” and “soft” boundary controls (i.e. filtering and sorting) is that users can then <strong>combine them</strong>. This affords the user a new level of control over the product list, enabling them to wield both “hard” restrictions and “softer” preferences onto the site’s product lists. Suddenly a rather complex statement like “I would like a lightweight road bike and my budget is $2,000” can successfully be applied, with both “hard” restrictions (i.e. “road bike” and “$2,000 budget”) <em>and</em> “softer” preferences (i.e. “lightweight”).</p>\n\n<p>If you have category-specific filters, the data is already there (and if you don’t, you really should implement them!), ready to be reused for category-specific <em>sort types</em> as well. Category-specific sort types are thus a great opportunity to gain even more from the structured data you’ve invested so dearly in collecting, curating and maintaining.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-small v-float-right v-float-from-large-handheld\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 129.41176470588235%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-08-faceted-sorting-952f653066737f1a75aaf01a867ba4ca4e072b2a76cd38d68d8c5515e9820baf.jpg\" /></div></div></div></div>\n\n<p>Indeed, this may even be taken to the next level by combining category-specific sort types with scope selection in higher-level categories and on <a href=\"http://baymard.com/blog/ecommerce-sub-category-pages\">sub-category pages</a>. This combines category-specific sort types with <a href=\"http://baymard.com/blog/faceted-sorting\">faceted sorting</a>, allowing highly relevant and popular category-specific sort types to be displayed at (higher) category levels where all products don’t actually share the attribute to be sorted by. This would furthermore make category-specific sort types possible in search results despite some of the results not having the sorting attribute.</p>\n\n<p>Sadly, category-specific sort types are a good example of just how <strong>neglected sorting</strong> is on e-commerce sites – numerous users want these sort types yet no sites offer them! It’s a rare example of an obvious innovation that e-commerce sites have yet to make. (Tip: you can see <a href=\"http://baymard.com/ecommerce-product-lists/benchmark/page-types/sorting-tool\">46 different sorting interfaces</a> from the top US e-commerce sites we benchmarked for this study.)</p>\n\n<p>Category-specific sort types are ultimately about <strong>empowering users</strong> with the tools they need to reach the product selection they want and have it presented in a way that suits their unique interests. It’s an obvious opportunity to increase the return on existing product data investments, empower your users and get ahead of the competition.</p>\n"):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:36:06 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 590ms
+
+
+  
+RuntimeError ("<h1 id=\"category-specific-sorting-a-new-way-to-sort-products\">Category-Specific Sorting: A New Way to Sort Products</h1>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-full-width\"><div class=\"inner\"><a href=\"//baymard.com\" title=\"Clicking this image will take you to Baymard.com!\" class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 64.92248062015504%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-01-rei-mock-up-4b493aff69299ddd35d3cfe999080636a6a958570f7100fd4cc1d4b78a959ed8.jpg\" /></div></a>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>This is the 3rd in a series of 9 articles based on research findings from our e-commerce <a href=\"http://baymard.com/research/ecommerce-product-lists study\">product list usability</a>.</p>\n</div></div></div></div>\n\n<p>We considered naming this article “the sort type all users want but zero sites offer” because category-specific sorting really is one of those rare instances where an obvious feature has somehow been <strong>completely overlooked</strong> by the e-commerce community.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-big v-mood-positive v-sidebar-caption\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 56.25%;\"><iframe src=\"https://www.youtube.com/embed/ZCBE8ocOkAQ\" frameborder=\"0\" allowfullscreen=\"\"></iframe></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>\n</div></div></div></div>\n\n<p>After all, it really shouldn’t come as a surprise that users would like to sort a list of TVs by “Screen size” or a collection of hard drives by “Storage capacity”.</p>\n\n<div class=\"anecdote-pull-quote-sba2ha anecdote-module-3ba83n v-size-big\"><div class=\"inner\"><p>By “category-specific sort types” we mean any sorting options that are only available in one or a few select categories</p>\n</div></div>\n\n<p>During our research study on product list usability the test subjects repeatedly sought out these kinds of category-specific sort types – however, to no avail since seemingly <strong>zero sites</strong> offer them. Even after <a href=\"http://baymard.com/ecommerce-product-lists/benchmark/site-reviews\">benchmarking</a> the product lists of 50 major e-commerce sites we have yet to find a site that truly offer category-specific sorting.</p>\n\n<div class=\"anecdote-gallery-dn2bak anecdote-module-3ba83n v-size-big\"><div class=\"inner\"><div class=\"content anecdote-flex-module-a4j2aj v-gutter-spacing-small v-flow-from-tablet\">\n  <div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-mood-positive\" style=\"width:75.21865889212827%;flex-basis:75.21865889212827%\"><div class=\"inner\">\n<div class=\"anecdote-flex-offset-a4j2aj\" style=\"padding-top: 0.0%;\"></div>\n<div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 66.66666666666666%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-02-bestbuy-f14fff79d781e96075b7d85c778786cc0cf003610cd26e6128d3a8a00f045b8e.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\">\n<p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>\n</div></div>\n</div></div>\n  <div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-mood-negative\" style=\"width:24.78134110787172%;flex-basis:24.78134110787172%\"><div class=\"inner\">\n<div class=\"anecdote-flex-offset-a4j2aj\" style=\"padding-top: 72.94117647058822%;\"></div>\n<div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 129.41176470588235%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-08-faceted-sorting-952f653066737f1a75aaf01a867ba4ca4e072b2a76cd38d68d8c5515e9820baf.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\">\n<p>An example of how things can go really wrong.</p>\n</div></div>\n</div></div>\n</div></div></div>\n\n<p>In this article we’ll outline our research findings on why <strong>category-specific sorting</strong> is so important to the user’s product finding abilities, and how it can be implemented.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-small v-float-left v-float-from-large-handheld\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 66.66666666666666%;\"><img alt=\"\" src=\"http://assets.baymard.com/blog/category-specific-sorting-02-bestbuy-d0496405ef767b1f469cc0e71cc4f84d.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>A mockup we’ve created of what category-specific sort types could look like at BestBuy. Here the three last sorting options – for TV screen size, refresh rate, and display depth – are available exclusively within the TV category while the other sort types are available site-wide.</p>\n</div></div></div></div>\n\n<p>Given that category-specific sorting is such an uncommon features, let’s quickly <strong>define</strong> the term. By “category-specific sort types” we mean any sorting options that are only available in one or a few select categories (because they wouldn’t make sense as site-wide sorting options – they only make sense for the products within those particular categories). Examples include being able to sort suitcases by volume, fishing rods by length, pens by point size, hard drives by storage capacity and spindle speed, road bikes by weight, etc. It’s this category specificity that makes them different from common site-wide sort types such as ‘Best Selling’, ‘Relevance’, ‘User Ratings’, and ‘Price’, which are typically available for all products and categories throughout a site.</p>\n\n<h2 id=\"soft-boundary-sorting-vs-hard-boundary-filtering\">‘Soft’ Boundary Sorting vs ‘Hard’ Boundary Filtering</h2>\n\n<p>The differences between filtering and sorting may on the surface appear subtle. Indeed, many users <strong>mix up</strong> the terminology or use the terms interchangeably. However, the differences are in fact quite significant: <em>Filters</em> set the criteria for whether a given product is in- or excluded from the product list (i.e. what is displayed) whereas <em>Sorting</em> determines the sequence of those products (i.e. how it is displayed).</p>\n\n<p>This makes <em>Filters</em> great for setting “hard” boundaries while <em>Sorting</em> is optimal for applying “soft” boundaries:</p>\n\n<ul>\n  <li><strong>Filters</strong> – Sets a “hard” boundary. Any product that doesn’t strictly fall within the selected value(s) will be cut off. It is a great way for users to exclude any products that don’t match specific criteria.</li>\n  <li><strong>Sorting</strong> – Applies a “soft” boundary. The products are ordered by the chosen sort type (in the case of category-specific sort types that typically means a product attribute). It changes the sequence of the products but doesn’t exclude any items, enabling users to still see items that fall outside their initial boundary.</li>\n</ul>\n\n<p>Our <a href=\"http://baymard.com/research/ecommerce-product-lists\">product list</a> usability testing showed that <strong>users need both</strong> hard boundaries (i.e. filters) and soft boundaries (i.e. sorting) for optimal control over the product list. Depending on the user’s knowledge of the product domain and their own needs and restrictions they may have very strict and 100% clear criteria the product must fall within, in which case “hard” boundary filters are appropriate.</p>\n\n<p>However, in many cases users don’t have that strict criteria and sometimes they don’t even know what an appropriate filtering range would be, in which case “soft” boundary sorting is more suitable. For instance, the user might <strong>care about</strong> a product attribute without having a specific criteria for it, or they may not have the necessary domain knowledge to set meaningful cut-off points.</p>\n\n<h2 id=\"case-the-2000-lightweight-road-bike\">Case: The $2,000 Lightweight Road Bike</h2>\n\n<p>Let’s take an example of a user with a simple purchase preference: <em>“I would like a lightweight road bike and my budget is $2,000.”</em> Now, that wouldn’t be an unusual or odd request in a road bike store, but it would be a <strong>very difficult</strong> product-finding task at the 98% of e-commerce sites that don’t offer category-specific sort types, because the “lightweight” preference isn’t suited for a “hard” boundary filter (but instead needs the soft boundary of a sort type).</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 64.92248062015504%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-03-rei-original-5ec1970395515322e74260bc6227f3168c3bc233199bc26589043cc62bafca62.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>While there are plenty of sorting options available none of them are category-specific and none of them will help the user with their “lightweight” preference – even though the site clearly has weight information on their bikes (to support the “Weight (lbs)” filter).</p>\n</div></div></div></div>\n\n<p>Let’s play out the scenario to illustrate the issue. Note in the following how you can replace “bike” with your main product category and “weight” with any one of the primary numeric product attributes for that product category (e.g., capacity, power, speed, size, duration):</p>\n\n<ol>\n  <li>The user starts out by finding the “Bikes” category and applies a “Bike type” filter of “Road bike”. The user now has a list of road bikes.</li>\n  <li>Then, the user applies a “Price” filter defining an upper limit of $2,000. That’s easily done at most sites, and the specificity is well-suited for the hard boundary of a filter. The user now has a list of road bikes at $2,000 and below.</li>\n  <li>Finally the user cares about the bike weight, and this is where problems arise. If a “Weight” filter at the lowest end of the range is applied, the user ends up with a very small selection of road bikes, and will still have to open all their respective product pages to figure out which one is the lightest. If a broader “Weight” range is applied (or no “Weight” filter is applied at all), the user ends up with road bikes that aren’t necessarily lightweight, forcing the user to open every product page and mentally keep track of which bikes are lightweight and which aren’t. Clearly neither of these approaches are ideal as the user must either apply overly restrictive filters (meaning they might miss out on relevant items), or make do with an excessively permissive “Weight” filter or no filtering at all (introducing a high degree of noise in the product list leading to needless friction in the user’s product exploration).</li>\n</ol>\n\n<p>Now imagine in step #3, if the user had a <strong>category-specific sort type</strong> for “Weight”. If instead of applying “Weight” as a filter the user sorted the product list by weight (while keeping the $2,000 price filter in place), they would end up with a list of road bikes priced $2,000 or less sorted by lowest weight. The user would effectively have indicated their “lightweight” preference without having had to define highly precise cut-off points. Finally, the user would have a list of road bikes from lightest to heaviest costing $2,000 or below.</p>\n\n<p>The “soft” boundaries of sorting essentially enable users to apply a preference to the product list without having to worry about striking some perfect <strong>magical sweet spot</strong> between an overly restrictive and excessively lax filter range. Yet filters remain relevant for things like the user’s specific budget limitation of $2,000 – this isn’t a mere preference. It’s by applying a combination of both “soft” (sorting) and “hard” (filtering) boundaries that the user is ultimately able to get what they are seeking: a list matching both the specific budget limitations of $2,000 while also having the “lightweight” preference applied.</p>\n\n<h2 id=\"why-users-often-prefer-soft-boundaries\">Why Users Often Prefer “Soft” Boundaries</h2>\n\n<p>During usability testing the subjects often preferred the “soft” boundaries of sorting over the “hard” boundaries of filters. The road bike example illustrates why users in some cases prefer “soft” boundaries over “hard” ones – it alleviates them from defining cut-off points. Further investigation reveals <strong>3 reasons</strong> users prefer the “soft” boundaries of sorting:</p>\n\n<ol>\n  <li><strong>Fear of missing out</strong> – The user may not want to set a hard boundary in fear of missing out on relevant products that fall just outside their defined range, hence many users prefer the soft boundaries of sorting.</li>\n  <li><strong>Lacks domain knowledge</strong> – The user may not know or feel like they have sufficient knowledge about the product domain (the natural spec jumps within the vertical, the implications of different product attributes, etc) to set appropriate cut-off criteria. In these instances the user will naturally find it more desirable to indicate their preference without having to define it through criteria they don’t fully understand.</li>\n  <li><strong>Unclear about own preferences</strong> – The user may not be entirely clear on their own preferences and restrictions (budgetary limitations, compatibility requirements, usage conditions, etc). Oftentimes users purchasing for themselves are willing to flex their criteria significantly once they start seeing what’s available and begin to understand the product domain better.</li>\n</ol>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 48.740310077519375%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-04-soft-boundary-preference-5cb14a2121d7f15c53bd1ab82551c3e293e624a5b63edc7924253cfa8212a149.png\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>Setting specific criteria requires knowledge about the product domain (reason #2) – the natural spec jumps within the vertical, the implications of different attribute values, etc. – as well as knowledge about your own preferences and restrictions (reason #3) – budgetary limitations, compatibility requirements, usage conditions, etc. Both of these feed into reason #1, the fear of missing out on relevant items. If the user either lacks domain knowledge or is unclear about their own preferences (or both), they will tend to prefer “soft” boundaries because they would fear excluding potentially relevant products if they were to apply restrictive filtering criteria.</p>\n</div></div></div></div>\n\n<p>All of this is typically provoked by an <strong>information dilemma</strong>: the user has to set the “hard” boundary criteria before seeing the available products. So unless the user already has very good information about the product domain and their own preferences (prior to visiting the site) they often feel unconfident in applying such strict criteria. Few users want to fine-tune a product list if they don’t feel confident in accurately predicting the consequences of this fine-tuning.</p>\n\n<h2 id=\"sorting-prevents-accidental-product-elimination\">Sorting Prevents Accidental Product Elimination</h2>\n\n<p>Sorting provide users a way to <strong>fine-tune</strong> the product list to their preferences without running the risk of accidentally eliminating relevant items. It thus helps solve one of the fundamental challenges users have when browsing an e-commerce site: somehow finding all the products that are relevant to their specific needs and preferences out of the site’s typically enormous product catalog.</p>\n\n<p>In order to attain this highly curated list the user must narrow the product list down to a <strong>manageable size</strong> without discarding any relevant products in the process – they must at once be sufficiently aggressive in their filtering to reach a manageable product list without being so aggressive that they filter out relevant items in the process.</p>\n\n<p>When the user can only filter and not sort by category-specific attributes they are limited to setting “hard” boundaries only. This leaves the user with two <strong>less-than-ideal options</strong>: either 1) apply the preferred range as filters and run the risk of accidental product elimination, or 2) loosen the preferred range to be more inclusive to avoid this elimination at the cost of ending up with a much poorer signal-to-noise ratio (due to numerous less relevant items suddenly being included).</p>\n\n<p>Soft boundaries are very helpful in this regard because they allow the user to mainly browse a certain range without excluding (any potentially relevant) items outside it – enabling users to <strong>discriminate</strong> rather than eliminate.</p>\n\n<h2 id=\"sorting-increase-domain-and-site-insight\">Sorting Increase Domain and Site Insight</h2>\n\n<p>“Soft boundary” sorting can provide users with a better understanding of the product vertical and site catalog by revealing different “spec jumps” and “product gaps”. For instance, in the road bike example, it might be that the first three bikes in the sorted list cost $1,800 and weigh in at ~17 pounds (~7.5kg), and then there’s a jump in the list where bikes four through ten are 6 to 8 pounds heavier but also cost significantly less (e.g., weigh 22 pounds but only cost $900). This would help the user better <strong>understand the relationship</strong> between price and weight within the road bikes domain.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 64.92248062015504%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-01-rei-mock-up-4b493aff69299ddd35d3cfe999080636a6a958570f7100fd4cc1d4b78a959ed8.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>A mock-up we’ve created of what the earlier road bike example could look like with category-specific sorting for “Weight” and “Gears”. Sort types like these can help both novice and expert users gain better insight into the site as well as the domain they are currently browsing.</p>\n</div></div></div></div>\n\n<p>This is obviously very helpful to <strong>novice users</strong> because their lack of domain knowledge means they don’t instinctively know the natural “spec jumps” in the product vertical and might therefore inadvertently eliminate large clusters of perfectly relevant products. These users will therefore tend to prefer “soft” boundary sorting over “hard” boundary filters in fear of missing out due to a lack of domain knowledge, as explored earlier.</p>\n\n<p>However, category-specific sorting can also help <strong>expert users</strong> despite them being intimately familiar with the “spec jumps” in a product vertical because it provides insight into the site’s catalog and any “product gaps” there might be in it. After all, just because the user knows a certain range of products exist they don’t necessarily know which of those products the site carries. By sorting instead of filtering, expert users get insight into which product groups the site carries within the vertical (and which they don’t carry).</p>\n\n<p>Category-specific sort types can thus help increase novice users’ understanding of the product category (and any “spec jumps” within it) while simultaneously providing expert users insight into the breadth of the site’s product range (and any “gaps” within it).</p>\n\n<h2 id=\"numerical-category-specific-product-attributes\">Numerical Category-Specific Product Attributes</h2>\n\n<p>Category-specific sort types are appropriate in product categories where the products <strong>share</strong> one or more numeric attributes that users may have an interest in or preference for – such as the “Display size” of TVs or “Storage capacity” of hard drives. This is particularly true if the attribute is something where users don’t want to apply strict criteria or are unfit at doing so due to a lack of domain knowledge.</p>\n\n<p>The numericality of the product attribute is important because it makes it <strong>well-disposed to sorting</strong> as the products can be ordered based on the natural progression of the attribute. Compare this to a non-numeric product attribute like ‘Color’ which can’t really be sorted in a sequence logical to most users. It simply doesn’t make sense to sort by discrete product features even if it is technically possible because there isn’t a natural progression or hierarchy for such attributes. For example, DSLR camera lenses can’t meaningfully be sorted by “Lens type” or “Camera mount” (as they have no natural progression or hierarchy), but it could make sense to sort the category by “Focal length” or “Angle of View”.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 62.967032967032964%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-06-amazon-ad5690ce6efef0afa70989eb7fa5df86cc7b847c16f0f2d735f04088419c4068.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>The closest we came to a meaningful category-specific sort type during testing was at Amazon which have a special “Release date” sorting option within their “Movies &amp; TV” scope. The attribute is unique to the category and dates obviously have a natural progression. Unfortunately it is a rather ambiguous product attribute since it isn’t clear if it is the premiere date of the movie or the day the DVD version was released – something that tripped up numerous subjects during the usability tests.</p>\n</div></div></div></div>\n\n<p>Many product verticals do, however, have such numeric attributes and category-specific sort types are therefore relevant to a <strong>wide range</strong> of domains such as consumer electronics, kitchen utilities, office supplies, sports and hobby equipment, hardware, and similar industries. There are some exceptions of course – in particular verticals that are driven mainly by aesthetics, such as home decor and apparel. These verticals generally have only a few or no important numeric product attributes and it therefore won’t necessarily be meaningful to implement category-specific sort types in them (although even in these domains, attributes such as weight and size may be important depending on the exact product type).</p>\n\n<h2 id=\"curating-the-category-specific-sort-types\">Curating the Category-Specific Sort Types</h2>\n\n<p>Determining which product attributes should be implemented as category-specific sort types is a fairly straight-forward matter: simply take the 3-5 most important numeric category-specific filters available in each category on your site and turn them into sorting options too. Let’s tackle some common questions that typically arise as a result of that statement:</p>\n\n<ul>\n  <li><em>Why 3-5 attributes?</em> To avoid overly long sorting drop-downs that induce choice paralysis. Although don’t get too stuck on the specific numbers, just make sure the number of sorting options don’t get completely out of hand.</li>\n  <li><em>How do I identify which filters are the “most important”?</em> Well, these filters should already be identified as the order of the filtering options should be determined on their relative importance. This importance may be arrived at through expert (human) judgement or programmatically through various proxies (filter popularity, number of products, feature impact on price, etc) – or a combination of the two. An example of a very important product trait would of course be ‘<a href=\"http://baymard.com/blog/price-per-unit\">price per unit</a>’ in categories where this attribute is relevant (i.e. where multi-quantity products are common, such as golf balls, copy paper, liquids, etc).</li>\n  <li><em>Why numeric attributes?</em> Because they have a natural progression that makes them suitable for sorting. (See the above section.)</li>\n  <li><em>Why category-specific filters?</em> The category-specific sort types should be provided in addition to the regular site-wide sort types such as “Price”. We assume you already have these in place and are here dealing with dynamically created sorting options that won’t be available site-wide. (Note: If category-specific filters aren’t already implemented, stop reading this article and implement them right now! Our usability testing revealed this to be one of the most fundamental features to the user’s browsing experience.)</li>\n  <li><em>How do I turn the filters into sorting options as well?</em> Well, with category-specific filters already in place, this is a simple matter of reusing the data powering those filters. After all, in order to be filterable the product data will already be fully structured and can therefore simply be reused for sorting purposes as well.</li>\n</ul>\n\n<p>So in summary: We limit the number of category-specific filters to double as sort types to <em>3-5 attributes</em> to avoid unruly and intimidating sorting drop-downs. Because of this restraint we obviously want to pick the <em>most important</em> product attributes to cater for the most likely use cases on our site. And we implement all of this by tapping into the data structures already in place for category-specific filters.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 66.66666666666666%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-02-bestbuy-f14fff79d781e96075b7d85c778786cc0cf003610cd26e6128d3a8a00f045b8e.jpg\" /></div></div>\n<div class=\"anecdote-caption-ajkd3b\"><div class=\"inner anecdote-wysicontent-ndj4ab\"><p>If familiar with the <a href=\"http://baymard.com/blog/kano-model\">Kano model</a>, the attributes to use as category-specific sort types will often be the “Performance” attributes within each product vertical.</p>\n</div></div></div></div>\n\n<p>The beauty of category-specific sort types is that they tap into <strong>investments already made</strong> in filters, effectively increasing the return on those investments. Because it’s a technical feature, it doesn’t require continuous data collection or curation (beyond what is already being done for the filters), and it’s therefore a one-time investment that permanently increases the value of the continuous investments made in collecting, curating and maintaining structured product attributes.</p>\n\n<p>The most important filters within each unique product category can thus <em>also</em> be utilized as sort types in that category. (It should of course still be a filter as well – this is about giving users the ability to apply both “hard” and “soft” boundaries to product attributes of interest to them.)</p>\n\n<h2 id=\"empowering-users-with-category-specific-sort-types\">Empowering Users with Category-Specific Sort Types</h2>\n\n<p>The user needs both hard boundaries (i.e. filters) and soft boundaries (i.e. sorting) for optimal control over the product list. When the user has good domain knowledge and a clear understanding of their own needs, “hard boundary” filters are appropriate. However, as we’ve seen throughout this article there are other times where the user doesn’t have this level of domain knowledge or strict criteria for their product needs, in which case “soft boundary” sorting will often be more suitable. Both “hard” and “soft” boundaries thus have <strong>valid usage scenarios</strong> and this alone justifies their implementation.</p>\n\n<p>A major bonus of implementing both “hard” and “soft” boundary controls (i.e. filtering and sorting) is that users can then <strong>combine them</strong>. This affords the user a new level of control over the product list, enabling them to wield both “hard” restrictions and “softer” preferences onto the site’s product lists. Suddenly a rather complex statement like “I would like a lightweight road bike and my budget is $2,000” can successfully be applied, with both “hard” restrictions (i.e. “road bike” and “$2,000 budget”) <em>and</em> “softer” preferences (i.e. “lightweight”).</p>\n\n<p>If you have category-specific filters, the data is already there (and if you don’t, you really should implement them!), ready to be reused for category-specific <em>sort types</em> as well. Category-specific sort types are thus a great opportunity to gain even more from the structured data you’ve invested so dearly in collecting, curating and maintaining.</p>\n\n<div class=\"anecdote-graphic-dn32ja anecdote-module-3ba83n v-size-small v-float-right v-float-from-large-handheld\"><div class=\"inner\"><div class=\"anecdote-intrinsic-embed-n42ha1\"><div class=\"inner\" style=\"padding-bottom: 129.41176470588235%;\"><img alt=\"\" src=\"/assets/category-specific-sorting-08-faceted-sorting-952f653066737f1a75aaf01a867ba4ca4e072b2a76cd38d68d8c5515e9820baf.jpg\" /></div></div></div></div>\n\n<p>Indeed, this may even be taken to the next level by combining category-specific sort types with scope selection in higher-level categories and on <a href=\"http://baymard.com/blog/ecommerce-sub-category-pages\">sub-category pages</a>. This combines category-specific sort types with <a href=\"http://baymard.com/blog/faceted-sorting\">faceted sorting</a>, allowing highly relevant and popular category-specific sort types to be displayed at (higher) category levels where all products don’t actually share the attribute to be sorted by. This would furthermore make category-specific sort types possible in search results despite some of the results not having the sorting attribute.</p>\n\n<p>Sadly, category-specific sort types are a good example of just how <strong>neglected sorting</strong> is on e-commerce sites – numerous users want these sort types yet no sites offer them! It’s a rare example of an obvious innovation that e-commerce sites have yet to make. (Tip: you can see <a href=\"http://baymard.com/ecommerce-product-lists/benchmark/page-types/sorting-tool\">46 different sorting interfaces</a> from the top US e-commerce sites we benchmarked for this study.)</p>\n\n<p>Category-specific sort types are ultimately about <strong>empowering users</strong> with the tools they need to reach the product selection they want and have it presented in a way that suits their unique interests. It’s an obvious opportunity to increase the return on existing product data investments, empower your users and get ahead of the competition.</p>\n"):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:36:15 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 570ms
+
+
+  
+ActionView::MissingTemplate (Missing template pages/show, application/show with {:locale=>[:en], :formats=>[:html], :variants=>[], :handlers=>[:raw, :erb, :html, :builder, :ruby]}. Searched in:
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/test/dummy/app/views"
+  * "/Users/jamieappleseed/Sites/baymard/plugins-and-scripts/anecdote/app/views"
+):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:36:56 +0100
+Processing by PagesController#show as HTML
+  Rendering text template
+  Rendered text template (0.0ms)
+Completed 200 OK in 698ms (Views: 46.1ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 11:37:59 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 797ms (Views: 174.6ms)
+
+
+Started GET "/assets/application.self-498cef3368860b1704871d187f16c8fffaa3430695c6575010040d0a2b38aa49.css?body=1" for ::1 at 2017-12-14 11:38:01 +0100
+Started GET "/" for ::1 at 2017-12-14 11:55:31 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 908ms
+
+
+  
+TypeError (no implicit conversion of nil into String):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:56:03 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 1185ms (Views: 23.8ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 11:56:41 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 543ms (Views: 13.2ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 11:57:07 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 1248ms (Views: 24.6ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 11:57:16 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 625ms (Views: 9.6ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 11:57:22 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 636ms (Views: 11.0ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 11:57:28 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 751ms
+
+
+  
+RuntimeError (grrr):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:58:21 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 719ms
+
+
+  
+RuntimeError ({:formats=>"web", :_yield_=>"\nWe considered naming this article \"the sort type all users want but zero sites offer\" because category-specific sorting really is one of those rare instances where an obvious feature has somehow been **completely overlooked** by the e-commerce community.\n"}):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:59:03 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 100ms
+
+
+  
+RuntimeError ({:formats=>"web", :_scope_=>{:format=>:web}, :_yield_=>"\nWe considered naming this article \"the sort type all users want but zero sites offer\" because category-specific sorting really is one of those rare instances where an obvious feature has somehow been **completely overlooked** by the e-commerce community.\n"}):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 11:59:34 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 978ms
+
+
+  
+NoMethodError (undefined method `tag' for nil:NilClass):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 12:02:54 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 208ms
+
+
+  
+NoMethodError (undefined method `tag' for nil:NilClass):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 12:03:33 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 910ms
+
+
+  
+NoMethodError (undefined method `tag' for nil:NilClass):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 12:03:49 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.2ms)
+Completed 200 OK in 582ms (Views: 18.3ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:04:35 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.0ms)
+Completed 200 OK in 575ms (Views: 8.2ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:04:45 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 848ms
+
+
+  
+NoMethodError (undefined method `[]' for nil:NilClass):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 12:07:58 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.2ms)
+Completed 200 OK in 93251ms (Views: 24.2ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:09:37 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 74805ms
+
+
+  
+NoMethodError (undefined method `tag' for nil:NilClass):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 12:11:57 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 1391ms (Views: 22.8ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:12:14 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 657ms (Views: 51.6ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:12:24 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 611ms (Views: 7.8ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:12:28 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 581ms (Views: 11.4ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:12:39 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 111ms
+
+
+  
+NoMethodError (undefined method `[]' for nil:NilClass):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 12:13:39 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 1356ms (Views: 22.3ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:14:03 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 537ms (Views: 8.7ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:14:08 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.0ms)
+Completed 200 OK in 593ms (Views: 10.3ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:14:21 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 1333ms (Views: 21.5ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:14:35 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 552ms (Views: 9.2ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:14:42 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.0ms)
+Completed 200 OK in 636ms (Views: 8.7ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:14:54 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.3ms)
+Completed 200 OK in 580ms (Views: 12.5ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:15:00 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 566ms (Views: 9.0ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:24:48 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 1364ms (Views: 21.3ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:25:05 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 545ms (Views: 9.1ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:25:15 +0100
+Processing by PagesController#show as HTML
+Completed 500 Internal Server Error in 98ms
+
+
+  
+NoMethodError (undefined method `split' for nil:NilClass):
+  
+app/controllers/pages_controller.rb:5:in `show'
+Started GET "/" for ::1 at 2017-12-14 12:25:19 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.0ms)
+Completed 200 OK in 555ms (Views: 10.2ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:25:28 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.0ms)
+Completed 200 OK in 561ms (Views: 7.1ms)
+
+
+Started GET "/" for ::1 at 2017-12-14 12:25:34 +0100
+Processing by PagesController#show as HTML
+  Rendering html template within layouts/application
+  Rendered html template within layouts/application (0.1ms)
+Completed 200 OK in 647ms (Views: 9.4ms)
+
+