Sellerdeck database

[brucet]

It might be helpful to look at some real-world examples, because I think all of the general possibilities are either currently supported by SellerDeck, or allowed for in the way the new search and filtering is architected (we did put a very great deal of thought and discussion into that).

1) Selecting from products that are all of the same type

Example: Search http://www.johnlewis.com/men/men's-shirts/c600001554
All of the products are of one type, and you can filter by the attributes that apply to this type of product (brand, size, colour etc).

This is similar to your car and inkjet cartridge examples, and is what the filtering function in SellerDeck is designed for.

2) Free text search, different types of product returned

Example: Search www.johnlewis.com for 'james bond'
Products of different types are returned, and the sidebar shows a list of sections containing relevant products.

This is partially achievable in SellerDeck by enabling searching on sections. The selection fields in the search results page can be moved into the sidebar and styled however you want. ATM all sections are shown initially in the results page, but it would not be difficult for us to modify this to show only the relevant ones, and to include other elements found in the filtering, such as result counts.

3) Free text on a list of same-type products

Example: You might want to search http://www.johnlewis.com/men/men's-shirts/c600001554 for a very specific colour, eg 'mulberry'

John Lewis does not allow that on this page, but I have seen it elsewhere. We have allowed for the possibility of adding this option, but we didn't have time to implement it in the first iteration of filtering. It would also be quite straightforward to allow a text search as a preset value in the Section 'Filtering' tab, so it could be used in automatically populating a page.

4) Free text search where all results are the same type of product
Example: Search www.johnlewis.com for 'men's shirts'

The results are all the same type of products, and there is a filter list that allows you to select by the relevant attributes.

This seems like the kind of thing you are asking for. We had planned to offer this by allowing text searches to redirect to a Section or a Product Category, but we did not have time to implement it in the first iteration of filtering. However, a future development along these lines is allowed for in the architecture.


Add the fact that any user-defined variable can be used for both search and filtering, and we are confident that what we have built can ultimately meet the overwhelming majority of requirements. We have also done a lot of performance testing and we're confident of its scaleability.

[I-CC]

Interesting read about how and when its best to use the filtering functions.

No two sites are the same and I had a need where a backend Db was the desirable method for displaying different car radiators, heaters, coolers and air con units, so in this instance I used PHP at publish time to generate a separate flat-file that contains a complete list of all products within the site along with the fields (UDPs) that I deemed important and set the output (file) to be uploaded with each publish.

Then, using PHP on the web server under a cron job, it regularly checks the date time stamp on the file and if changed since it was last checked, conducts a process of updating a mySQL db within the site, which is then used for the actual display of all of the products, filtering and within an additional custom search panel, all of which is pretty instant in in-page display.

Off the top of my head I think there is some 40,000 products in the backend, with a total of 125k plus possible scenarios of when the 40,000 actual products might make a match.

Some bits are still a work in progress buts its at: http://www.kempstonradiators.com/rad...ans-Autos.html

So, my solution was to get a fla file of the data, convert online and push into a mySQL db and then create custom layouts and functions to display it all whilst maintaining the ease of eventual maintenance and order processing.

Just my take on it.

[Mike Hughes]

Bruce,

I'm not really sure what the distinction is between your cases 2-4. For me there are really only 2 scenarios that count.

1. Filtering: to refine down products where they all share a common hierarchy

e.g car parts, printer parts, etc. This works with sellerdeck filtering.

2. free text search, then filter and/or refine search, then sort

Which needs to be seamless and done in whichever order makes sense to the customer at the time.

This Sellerdeck can't do.

I'm not sure I really understand why you several have different variations of search other than to say we can do bits of some of it. Yes, it might help to make sure you have certain bases covered, but from a user / customer perspective it's not hugely relevant.

Are you saying that the current architecture will allow customers to run a free text search, then filter on certain criteria (such as brand, price, colour, size, etc) and then sort by alphabetical, price, popularity, etc?

(I'm happy to ignore the search -> Filter -> refine search scenario as for me this is really a restart of the search and the previous filter set won't necessarily apply. i.e. my thinking here is that any search is really the start of a new attempt to find a suitable results set - which we can then filter/refine and sort)

It seems to me I'm still in the position I was before your reply. In that I haven't yet heard that I'll be able to do what I want: Search for products > refine / filter based on certain criteria and then sort by a variety of methods. To me and the customer it's irrelevant whether the products are in different categories or not and it needs to work for both. And then there's also the issue of what to do with criteria that vary and aren't easily predefined such as 'in stock', 'popularity', etc.

To keep it clear and simple here are the steps I want customers to be able to do:

1. Search using free text
2. based on the displayed results, see a selection of filter variables such as 'section', ' brand', ' colour' etc (with a return count besides each is good) that they can tick to refine their search.
3. based on the new subset of results, sort them by price, brand name, rating, popularity, etc.

I still think using a back end database to return a small set of results quickly and efficiently is the way this should be done. This also would allow the same queries to exclude out of stock items, sort by product reviews, (and actually include product reviews / product questions / feedback and comments which is an area I've been asking for for quite some time), etc.

I'm fairly clear that to move forwards sellerdeck needs to make the move to a back end database to address problems in a number of areas. The ability to quickly and efficiently search > Filter > Sort is just one of them.

Sticking to the area we're discussing though. How far are we from being able to properly Search > Filter > Sort with products across multiple sections / subsections?

Mike