Home› Brick Owl› Site Issues

Unexpected wishlist behaviour

HoddieHoddie
in Site Issues Vote Up0Vote Down
I made a wish-list for the new Bat-Pod set and once in the buy wizard I clicked the checkbox to select all stores (in the EU). I then removed ticks from all stores which were "Quote only" and the wizard reported all parts except the wheels were available for a total of EUR 213.36 (107.76 plus 105.60 shipping).

The wizard selected 29 stores with 12 of them having just 1 lot each. After looking at the carts, some of these lots were for very common parts (4 x 4 black plate for example).

On removing the tick from one of those 1 lot stores, the total cost went down to 208.23. The part in that one lot was obviously added to one of the other carts with a resulting saving of over 5.00. Removing a few more ticks and the wizard was reporting I could still grab all the parts from the remaining stores for less than 180.00 - a saving of over 30.00 compared to the initial spread of carts.

It seems to me that the wizard is only looking at the item price and ignoring shipping costs except for display purposes. Is this expected? I noticed there'd been some work done to the wishlist feature recently so I'm reporting this behaviour in case it's a bug. Expecting the wizard to select the absolute optimal result is asking for a lot, but 30.00 across 109 lots is quite a difference.

While I'm here, would it be possible to offer an option to exclude stores if the shipping would be "Quote only".

Comments

  • 7 Comments sorted by Votes Date Added
  • LawrenceLawrence
    Vote Up0Vote Down
    The calculations don't include shipping cost, the ideal way is to select stores manually and then the shipping will be more efficient
  • OvertheBrickOvertheBrick
    Vote Up0Vote Down
    Would be a nice optimization problem to solve.
  • LawrenceLawrence
    Vote Up0Vote Down
    It can of course be done, but it's a trade off made between the speed expected from a website and finding an optimal solution. It would likely take several minutes and be very resource intensive, so we prefer to give the customer choice over the stores and inform them of the availability in those stores.
  • StragusStragus
    Vote Up0Vote Down
    @Lawrence Just wondering, if BrickOwl won't do it, do you think that's something that could be solved off the website? Would it be viable if all the necessary data were to be queried? Would you agree with that kind of bandwidth use? (assuming some caching of data)

    I'm just brainstorming erratically here, but this gives me ideas about a "BrickOwl optimizer" website/service/program of some sort, taking wish lists and producing an optimal lists of stores... It doesn't look hard, I believe a single GTX 690 and its 3072 cores could solve dozens of wish lists per second (huge wish lists would converge by heuristics rather than solving the true absolute solution).

    Obviously, that's somewhat redundant and it would be far preferable if the feature were part of BrickOwl directly.
  • LawrenceLawrence
    Vote Up0Vote Down
    Doing it offsite isn't really practical, the data is too much to download, will quickly go stale, and shipping "can't" be calculated offsite. Even if the system did give you an "optimal" solution, there's still other factors like location of store, customs, handling time, personal preference etc. Maybe I'm just being stubborn though.
  • HoddieHoddie
    Vote Up0Vote Down
    Thanks for the responses Lawrence. I wonder if adding a 'second pass' as it were every time a store is added (/checked) or removed (/unchecked) would help refine it, with this second pass taking into account shipping costs. It should certainly help remove the one-lot carts even though it won't necessarily be the absolute optimal solution (which I agree would require a lot of resources for perhaps just a few cents optimisation).

    As it is I think the 'select all' checkbox gives misleading results. Users would expect the wizard to find the optimal cost. Perhaps this checkbox should be disabled, or alternatively, have it select a maximum of 10 stores - those with the most parts from the wishlist - and display a message that more can be added manually if all the parts haven't been found.
  • StragusStragus
    edited September 2015 Vote Up0Vote Down
    @Lawrence I know you are stubborn!! :)) But you are also right, it would be impractical due to the amount of data required and the shipping calculations that would have to be absolutely identical.

    And yet I can't shake the feeling that a true wishlist optimizer would be one "killer feature" for BrickOwl. No doubt about it, BrickOwl needs that. And it wouldn't have to resolve the true absolute minimum, people won't mind if the solution found costs 1-2% more.

    If it's an issue due to web languages being 200 times slower than real code, give me a shout! Writing highly optimized C code (SSE/AVX/CUDA/etc.) is what I'm doing all day since ten years. I have seen jaws drop when legacy Fortran code was rewritten to be 3800 times faster... :)

    Think about it, that would be pretty neat.
Sign In or Register to comment.