PDA

View Full Version : RefineBys


authcode
20-08-09, 15:40
I'm delving into refine bys for the first time and getting a problem that could be particular to my implementation (which I think is standard), a bug, or just a "feature".

Basically the list of available refine bys I get back sometimes includes a category that is already in the active refine bys. Obviously this isn't very useful. I could filter it out but I wanted to find out if anyone considers this a bug or if there's a reason you would want this that I'm missing?

GeorgeGaz
20-08-09, 16:58
Hi Steve,

Out of interest, what categories are you seeing come up twice?

Cheers

authcode
20-08-09, 18:54
RefineBy categories
235 DVDs (parent)
and
240 DVDs (child)

240 shows up again in available refine bys for me. Can't check this on ShopWindow.com though.

Just realised I'm refining using multiple category options, prices etc. Is this not the intended use? It's a fairly common approach but I see ShopWindow.com doesn't work like this. That could be the problem.

authcode
20-08-09, 18:58
Another one is
62 Computer Components

Appears again in the list of available rb's, although I've just checked and this isn't the case with SW.com so I'll look back through my code. Probably just a bug my side.

GeorgeGaz
21-08-09, 10:10
Hi authcode,

SW.com is not using v3 of the software.

Keep an eye on it and if you do feel that it is a bug then please do raise it with us and the dev guys can look into it.

If anyone else is getting this problem then please do voice your concern.

Cheers

authcode
21-08-09, 11:32
Ok. I've changed my code to prevent duplicated refine bys in the meantime. Once I've finished development I'll try and see if there's a pattern.

authcode
21-08-09, 15:21
Having thought about this some more I can see what's happening.

As an example you refineby category:
1
and get back refineby categories:
1a
1b
1c

In my implementation I accumulate refinebys instead of replacing them so it's easier to "go back". So I would then refine by:
1 | 1b
and get back:
1a
1b
1c
1bi
1bii
1bii
which are obviously the options for each refineby combined. I would expect this. But even so, I wouldn't expect an active refineby to be included in the list of available refinebys under any circumstance.

I'd consider this a bug, but it's debatable.

GeorgeGaz
24-08-09, 12:16
Hi authcode,

The consensus on this is that the refine by appears in the list because you have requested more than one and may still want to refine by just one or the other.

Basically, if the user requests fashion and electronics then electronics will still come up in the refine by because if they so choose they can click that to refine by just electronics and exclude fashion.

Cheers

authcode
24-08-09, 12:36
Your example doesn't really make sense :o Sorry, at least not in my implementation of refinebys.

If you want to allow refineby multiple categories then your example is wrong for two reasons. First, If you wanted to deactivate fashion from fashion + electronics you would deactivate fashion, not activate electronics again. Second, if you offer mutliple category refineby then choosing a category should add that category to the refine by, not switch to it exclusively, else the functionality to select multiple categories wouldn't work in the first place.

Also, the example you give (and I realise this is just a quick example) wouldn't really occur in practice because you are not really refining your results with that combo, in fact you would be widening your selection.

Multiple category selections should only involve vertically linked categories.

It's no big deal, I can work around it, but I can't think of reason you'd want an active refineby to appear in a list of available refinebys and your example doesn't really apply.

However, it is what it is, and if that's the way it was designed then so be it. I'll move onto something else :)

Ollie
24-08-09, 13:28
Interesting. I'm glad someone has started using this 'feature'. And feedback is good.

To be honest, the way the system should work at the moment is to take all refine bys and params passed and build a result set from that. We then use that result set to build a list of refine bys to return.

If you say you want the parent category X, and want the child of that parent X1 then you will get all category's returned in the entire dataset in your refine by - this may include all children of X or in the smallest case just X and X1.

In its simplest form, your refine bys are built from the data returned from your search and have nothing todo with what is put in.

That said, I think in your example, its not a case of working around but more a case of building an implementation to use the functionality supplied in a way that works for you. So if you want to add to a refine by then you would append this as your end and supply the data to us.

I will make the assumption in your case you are modifying the client software which will probably not do what you want without some serious modification. :eek:

Its worth noting, the client software was built to only work off one refine by within each group at all times rather than on multiple refine bys (we like to leave the odd feature out for people to play around with).

authcode
24-08-09, 13:43
Hi Ollie,

I'm not really using the client at all. I just pinched the api classes and built my own site from scratch. For me, it was more work to figure out smarty than it was to use the PHP I already knew.

Obviously the way I'm using refinebys doesn't quite work with the way the system was designed to be used, but it's close enough. Your explanation of how the available refinebys are gathered makes sense, and in the case of the client implementation makes perfect sense. I realise my approach might be non-standard but I still think my point that active refinebys shouldn't be included in the list of available refinebys is valid. I don't think there's a case when this would be useful, in which case the data is redundant. But I appreciate that it might be more expensive to have the server filter the return list than it is just to send it and let misfits like me deal with it :) As I say, it's not a big deal, but I wanted to check it wasn't a bug.

authcode
24-08-09, 13:49
You're going to hate me for this but I've come across another debatable bug with the refineby system. Again, it's marginal, but I'd like to get your opinions all the same.

In this example I refineby merchant. Fine. Now I want to use a keyword search to search this merchant for "fgfdkgkljkjkl". Obviously, there's no matching results, so the response I get is empty. Fair enough. But the problem is I don't even get back my active refinebys. Now my front end can't show that the user searched for "fgfdkgkljkjkl" + merchant.

Again, it's debatable whether this is a bug, nothing breaks exactly. But I would expect to get back a list of active refinebys even when there are no product results. Any thoughts?

Ollie
24-08-09, 15:33
Ahha.....

But I appreciate that it might be more expensive to have the server filter the return list than it is just to send it and let misfits like me deal with it
I think the system as it stands allows for the greatest level of flexibility so doing the filtering at your end is good.

In this example I refineby merchant. Fine. Now I want to use a keyword search to search this merchant for "fgfdkgkljkjkl". Obviously, there's no matching results, so the response I get is empty. Fair enough. But the problem is I don't even get back my active refinebys. Now my front end can't show that the user searched for "fgfdkgkljkjkl" + merchant.

Looks like this isn't supposed to happen :p You should always get your active refines back.... so something definitely went wrong on that one... I'll raise a ticket to get this sorted.

Cheers