[12:02pm] rszrama: Anyone around who wanted to throw in some ideas for a default product catalog implementation?
[12:04pm] timmillwood: rszrama: a catalog is based on the product display nodes? and should just be a preset view?
[12:04pm] rszrama: yep, my thoughts exactly - wondering if we should try for nested category support using taxonomy terms / fields... could never exactly reproduce what Ubercart did with its Catalog in Views
[12:08pm] thill: rszrama:  there was a new feature in views that was an arguement for taxonomy parent
[12:08pm] rszrama: oh really?
[12:08pm] thill: rszrama:  that is what we use for drill down views with taxonomy
[12:09pm] thill: so all the children show up when looking at the parent
[12:10pm] thill: rszrama:  not persoanlly in love with the drill down catalog navigation but you have to start somewhere i guess
[12:11pm] thill: rszrama:  do you think the goal is recreating the ubercart catalog in views exactly?
[12:12pm] • thill thinks that there needs to be some basic improvements like exposed sort options
[12:12pm] thill: lowest price first ect
[12:12pm] rszrama: yeah, I'm definitely not sold on the basic Ubercart catalog; if we're implementing this as default Views, there's no reason to stay so limited
[12:14pm] fending: what about two displays for this default product catalog: one with drilldown ("By Category", i guess) that gets you to the filterable/sortable stuff @thill mentioned, and another that does tree structure?
[12:14pm] thill: rszrama:  i think the other must have is an exposed result set limiter show 20 40 or view all
[12:15pm] rszrama: mmm, yeah
[12:15pm] fending: i know it's a layer of complexity, but the hard part here is that shops with 10 items will differ kind of a lot from shops with 1,000.
[12:15pm] rszrama: fending: yeah, I'm thinking there won't be a one size fits all approach here... maybe we should be talking about default "catalog features" that can be enabled
[12:15pm] fending: cool
[12:16pm] thill: fending:  in your opinion what is the difference between "drill down" and "tree"  i think of them as the same
[12:17pm] thill: maybe drill down is more like solr, where you start with the whole set and filter out items ie newegg
[12:18pm] fending: i have some legacy imagery in my head (not of ubercart in particular) with product category tiles. the difference is purely presentation / how much you see at once. we're talking different kinds of drilldown.
[12:18pm] thill: fending:  ok thanks i understand
[12:18pm] fending: parameter filters, tomato, tomahto, etc.
[12:20pm] fending: rszrama: so what's your dump of those default "catalog features" that can be enabled?
[12:21pm] rszrama: fending: I'm open to anything, to be honest... I think you're right that it's size based... smaller sites probably benefit from particular categorization and larger sites would benefit from some sort of faceted browsing (a la NewEgg)
[12:21pm] thill: rszrama:  what about multiple vocabs, that seems to have been a limitation with uc_catalog, but with views you can say any product node and have multiple term agruments that doesnt seem like it will be a limitation other than in the default view
[12:21pm] rszrama: but that depends on a site's products fitting a model of categorization or of defining facets..
[12:23pm] thill: rszrama:  i think we need to keep in mind a module could be created like dc_solr that would add in its own view/pages/catalog right
[12:23pm] rszrama: I think trying to address every situation would just be ridiculous, but perhaps we can have model features for categorization and another for faceting, but faceting really depends on product type setup, not just having taxonomy available
[12:23pm] fending: thill: i think that needs a little discovery re: multiple vocabs. e.g.: the same term occurring in multiple parts of one denormalized hierarchical taxonomy will throw errors. likewise, searching for single term in multiple taxonomies increases likelihood of dupe and watchdog hell
[12:23pm] rszrama: thill: definitely
[12:24pm] fending: just something i've come across w.r.t. views.
[12:24pm] thill: fending:  right, sometimes too much flexibility has problems
[12:25pm] thill: rszrama:  so out of the box we just need a view that displays products that a site owner can change based on the needs of the store
[12:25pm] thill: rszrama:  very similar to the orders view in my opinion
[12:26pm] fending: anyway, for me that base mashery of faceted v. "basic" can have some cool features of value in both. Does everybody agree that a sortable product listing (by name, price, etc) is a base req?
[12:27pm] rszrama: thill: hmm, I wonder how sorting would happen in a grid - it would have to be exposed somehow
[12:28pm] thill: rszrama:  right and in a table in views if there is a pager only the first 10 or whaver get sorted, not the whole view
[12:28pm] dov23: I think we may have a more general question.  Do we want to support primarily catalog based shopping, or some other paradigm OOB
[12:28pm] rszrama: thill: oooh, that's messy
[12:29pm] rszrama: dov23: I think we were conceiving the answer to that question ni terms of the size of the product catalog
[12:29pm] dov23: ok, fair enough
[12:29pm] rszrama: but obviously if a site doesn't need anything special in the catalog, they could just not enable it
[12:30pm] rszrama: I think Tim probably had the solution for them above, a basic View that simply listed out all products without any attempt at categorization or classification
[12:30pm] dov23: ok, so you're proposing a view to sort through the entire catalog and show categories
[12:30pm] dov23: based on taxonomy?
[12:31pm] rszrama: yeah, taxonomy for some sort of categorical catalog - no taxonomy for just a basic product list
[12:31pm] dov23: I could imagine that getting ugly for a larger catalog, no?
[12:32pm] greggles joined the chat room.
[12:32pm] rszrama: it can - I think it depends on the business... but that's where some sort of faceted browsing would probably be preferred...
[12:33pm] rszrama: one example of a large categorical catalog that actually works is http://www.primasupply.com (where I used to work)
[12:33pm] rszrama: but it works b/c people come looking for specific things and it's easy to segment out dishwashers from ovens 
[12:34pm] dov23: ok... but what would the implications be if you wanted to implement a multi-store model?
[12:34pm] thill: For the record exposed sorts made it into drupal 7 views 3
[12:34pm] rszrama: thill: nice
[12:34pm] dov23: Lets say you have a main store
[12:34pm] rszrama: dov23: not sure I follow - what model of multi-store?
[12:34pm] dov23: (with the catalog)
[12:34pm] dov23: and two branded stores
[12:34pm] dov23: lets say a retail and a wholesale
[12:35pm] dov23: they all want to share a common catalog
[12:35pm] thill: rszrama:  http://drupal.org/files/issues/exposed_sorts.png
[12:35pm] dov23: so would the catalog be usable across different stores (read sites in drupal)
[12:36pm] rszrama: dov23: I suppose it depends on what you use to accomplish your multi-site setup
[12:36pm] rszrama: dov23: I imagine it would only be possible if the sites were sharing a single database and using Domain to product visibility based on the domain name
[12:36pm] rszrama: i.e. list this product on domains X and Y and this other one on Y and Z
[12:36pm] thill: rszrama:  do you think overtaking the taxonomy pages for the catalog vocab with a view is over reaching?
[12:37pm] thill: rszrama:  that is the best way to pass those taxonomy aguments
[12:37pm] rszrama: thill: I'd say if we have a three tiered approach where the most basic is a simple View then the next step up should do this
[12:38pm] thill: rszrama:  are you thinking the very basic is a site with 5 products with no taxonomy needs?
[12:38pm] rszrama: yeah, something like that
[12:39pm] thill: rszrama:  so someone is sell 5 books on the site they just need the simple view no taxonomy, that is reasonable
[12:39pm] rszrama: maybe they just sell a handful of membership products or levels of event registration... they don't really need a catalog, but a page listing all their products would be useful
[12:39pm] dov23: hmm... I guess this is a different approach
[12:39pm] dov23: you are going bottom up
[12:40pm] rszrama: dov23: yeah, the problem with the more complex ones is it's hard to craft something very generic
[12:40pm] rszrama: dov23: so, we could plan on a faceted catalog, but it really depends on how someone sets up their product types in the first place
[12:40pm] rszrama: and whether or not the necessary facets are stored on the display node or the product record... that's a tricky question that still hasn't been resolved
[12:41pm] dov23: do we have a firm definition of 'product' yet?
[12:41pm] thill: like we can easily solve easy catalogs out of the box, and expose all the fields to views for people to build complex catalogs
[12:42pm] rszrama: Product = the definition of the thing you're selling, Product display = (presumably) a node you use to present the product for sale through a product reference field
[12:42pm] rszrama: the catalog should link to product displays, but the information we'd use to facet results would most likely reside on the product itself
[12:42pm] dov23: ok, so what about the relation between products and attributes?
[12:43pm] rszrama: well, attributes in the Ubercart sense are gone - an attribute now is represented as a field on the product
[12:44pm] thill: you have a product for every variation of the product and then the display groups the variations on one node right
[12:44pm] rszrama: thill: that's right - so we have this twisted issue where we'll facet / sort based on information in the product but will need to group the results based on what's referenced from a single display
[12:44pm] rszrama: I'm a little worried about how this will turn out 
[12:45pm] dov23: so then I have a question...
[12:45pm] dov23: let's say your product is a cotton tshirt
[12:45pm] dov23: size and color are defining attributes
[12:45pm] dov23: there is no hard concept of a SKU or sellable item?
[12:46pm] rszrama: eh?
[12:46pm] thill: rszrama:  so the basic level catalog needs to be a single node view of product display types
[12:46pm] rszrama: thill: think so
[12:46pm] thill: the advanced next level up are a combination of term views and node views
[12:47pm] rszrama: dov23: the SKU is essential to the product - it represents the particular size / color combination for that style of t-shirt
[12:47pm] dov23: ok, so you are saying we need to make different products for red shirts and blue shirts?
[12:47pm] rszrama: yep
[12:48pm] thill: product = blue small shirt with a sku of 12345 or red large with a sku of 45738
[12:48pm] dov23: so... there is an opportunity for simplifying this:
[12:48pm] thill: the product display groups all the ones you want to group into one node
[12:48pm] dov23: if we let there be two levels:
[12:48pm] dov23: product
[12:48pm] dov23: and item
[12:49pm] dov23: and have a definition that product cross-product defining attributes gives us our items
[12:49pm] dov23: then we can manage the catalog a whole lot better
[12:49pm] dov23: no?
[12:50pm] rszrama: the problem is how to normalize the data behind a product
[12:50pm] dov23: in what sense?
[12:50pm] rszrama: the simplest way right now that we're pursuing is to make everything a field attached to a product
[12:50pm] dov23: but then there's incredible duplication of data, right?
[12:50pm] rszrama: and then to join items together for sale on product displays
[12:51pm] rszrama: nope
[12:51pm] rszrama: none at all
[12:51pm] dov23: so then in my tshirt example
[12:51pm] dov23: you have color(red,blue) size(s,m,l)
[12:51pm] rszrama: dov23: http://www.bywombats.com/blog/11-08-2009/d7uc-future-products (not sure if this will clear anything up, but it's where I first wrote about this)
[12:53pm] dov23: I see... so you're defining skus inside of products
[12:54pm] rszrama: right, a SKU is inherent to a product
[12:55pm] rszrama: (practically speaking, a unique ID is inherent to a product)
[12:55pm] fending: right on.
[12:58pm] dov23: ok, so now that I understand products  ... on the catalog side, you want a default view to show products... and a pagable view for categories as well, right?
[12:58pm] rszrama: something like that
[12:59pm] rszrama: that was the question you came into - what should be "default"
[12:59pm] thill: catalog/shirts whill show product displays with the term of shirt
[1:00pm] thill: while catalog/pants will show product displays with the term of pant
[1:01pm] dov23: what about a category landing page?
[1:01pm] rszrama: the difficult thing is that in Ubercart we could assume there would be a product node type, and we knew exactly which ones they were, so it was easy to add a taxonomy vocabulary to a product node
[1:01pm] fending: but we're not necessarily looking to traverse any further by default. catalog/pants/ground for instance.
[1:01pm] thill: rszrama:  you arent setting up a default vocab with DC?
[1:02pm] rszrama: I suppose w/ a basic Drupal Commerce installation profile we can accomplish the same thing, but having a catalog module that can be dropped into someone's existing site will be tricky
[1:02pm] thill: or should this come with the "catalog" module
[1:02pm] rszrama: thill: it'd be part of a catalog module
[1:02pm] rszrama: oooh, snap - would the taxonomy term be attached to the Product itself or the Product Display?  
[1:02pm] thill: rszrama:  we would need something like taxonomy menu function for a block to get to the catalog pages
[1:03pm] thill: rszrama:  that is what i was thinking
[1:03pm] dov23: the display would be good, because then we could have different displays for diff terms
[1:03pm] rszrama: yeah
[1:05pm] rszrama: brb, getting some lunch real quick
[1:06pm] fending: displays. the closer we can associate to sku level while maintaining function the better. right.
[1:11pm] rszrama: back
[1:11pm] dov23: that gives us more flexibility for landing pages
[1:14pm] thill: rszrama:  you got some good spam going on bywombats 
[1:14pm] rszrama: really?
[1:14pm] thill: rs comment 15 of the link above
[1:14pm] thill: i have seen others
[1:15pm] rszrama: yep, I see 5 comments this month that are spam
[1:16pm] dov23: speaking of catalogs
[1:17pm] dov23:
[1:17pm] dov23: can we have a quick brainstorm about importing catalogs?
[1:17pm] rszrama: what about it?
[1:17pm] thill: "there will be a module for that" 
[1:17pm] dov23: already in the works?
[1:18pm] rszrama: hehe  not really 
[1:18pm] thill: just saying in the drupal world i dont think it wall fall on drupal commerce to import/export data
[1:18pm] rszrama: I'm hoping http://drupal.org/project/node_import gets abstracted into entity_import
[1:19pm] thill: data in drupal commerce will not be any different than other data so stuff like the migrate module should handle that
[1:20pm] rszrama: dov23: did you have any specific thoughts / questions on the topic?
[1:20pm] rszrama: or just wondering if there's been any movement on it yet?
[1:21pm] dov23: well, I would think a standard functionality for XML / JSON feed consumption would be helpful
[1:21pm] dov23: many retailers have their own backend systems
[1:21pm] dov23: and it would allow for easy publishing / control
[1:22pm] rszrama: yeah, this will probably be another one of those areas where a lack of "standard" product display setup might hurt us... but at the very least getting product data into the system / updating it should be simple
[1:22pm] rszrama: (much simpler than with Ubercart)
[1:23pm] dov23: fair enough... but some kind of mass-load functionality would be much better I think, than using the admin
[1:23pm] rszrama: yeah, definitely - actually, we got a Google Summer of Code project through that I'm hoping will address this... looking up the link
[1:23pm] dov23: it's one of those: 'everyone else already does it'
[1:25pm] rszrama: yeah
[1:25pm] rszrama: is http://socghop.appspot.com/gsoc/student_project/show/google/gsoc2010/drupal/t127230758875 publicly viewable?
[1:25pm] rszrama: or http://socghop.appspot.com/gsoc/student_proposal/comment/google/gsoc2010/wildkatana/t127023863644 ?
[1:26pm] thill: first link good, second is bad
[1:26pm] rszrama: ok, bummer - the second one has more info
[1:26pm] rszrama: but... it's all on g.d.o - one sec
[1:27pm] rszrama: eating leftover filet mignon... delicious
[1:27pm] rszrama: here it is: http://groups.drupal.org/node/59113
[1:32pm] dov23: so I think it may be worthwhile to expand on what DC encompasses
[1:32pm] dov23: because it seems that it really focuses on core only
[1:33pm] rszrama: right - there's there's this concept I tried to introduce (that still needs traction) in that the project is at one level the Core code (i.e. what makes it into http://drupal.org/project/commerce) but at a broader level the Core + Essential non-core code (i.e. what we would package up as an installation profile)
[1:33pm] tcindie joined the chat room.
[1:34pm] dov23: ah, I like it
[1:34pm] rszrama: the Core code is narrow intentionally; the packaged profile is what should be known publicly
[1:34pm] rszrama: or rather
[1:34pm] rszrama: companies / individuals should feel free to make their own packaged profiles and market them like Open Atrium
[1:37pm] fending: so a "small biz" profile... a "new egg faceted" (bad name...) profile...
[1:38pm] dov23: and perhaps an enterprise one that allows for multi-store
[1:38pm] fending: the default view just got a lot simpler in my head.
[1:41pm] dov23: rszrama: I am going to sketch out some of my ideas and see where we can go from here
[1:41pm] rszrama: dov23: sure thing - I think a lot of our discussions will tend toward the basic core functionality, but the more complex feature requirements for distributions need to get on paper, too 
[1:41pm] dov23: thanks