Few questions about catalog

I've just moved all the cloth capes and skirts/etc into the Minifig Body Wear category and asked for that to be renamed as Clothing - these things were previously spread over three different categories (Fabric, Minifig Body Accessory and Minifig Body Wear) so I think it's a good way of tidying things up.

First the request:

1) Is it possible to provide two options for selecting the category? Keep the drop down box as it is now for those rare occasions when needed, but perhaps add a second drop down box that only has the relevant items in it (just the parts categories when editing a part for example, sets when editing a set, etc) - or perhaps a text edit field where we can enter the number of the category we want (with a master list being available on another link like the list of colours). This would save a lot of time and I'm sure server resources also.

A few questions:

1) Seems some parts are listed with both primary and secondary categories, which I think is a great idea, but I can't seem to find a way of editing the secondary category - is this not possible?

2) Where two decorated parts have the same mould, is it worthwhile creating a primary undecorated part to then attach the two decorated variants to, so that measurements only need entering once?

3) Is it possible to select several items and then apply a bulk action - perhaps with the API? This would be a great way of working through the 'uncategorised' category. I've been updating the categories on these parts as I go - always for those I'm selling and sometimes also when I have spare time - but it's a laborious process, if I could select all uncategorised hair-pieces for example, and then bulk change the category, it would be a lot quicker. Would also be a great way of being able to add a parent to things like minifigure heads so that weights, etc. need only be applied once.

4) I noticed the other week that there are many unused categories, for instance 'Food and Drink' being one which might work well if we can add secondary categories to the Minifig food items and some of the decorated bricks that serve as milk and juice cartons, etc. I was wondering if there's a reason why these unused categories exist?

Probably have a few more in time but I think I'm getting more and more familiar with the catalog every day.

Comments

  • 18 Comments sorted by Votes Date Added
  • 1a I've updated the category dropdown so it only shows categories for that item type, and it also only shows categories that have items in them in the moment

    1b could you give an example of items that have both primary and secondary categories?

    2 . It depends, usually this is done when there are several decorated versions, and an actual undecorated version exists

    3 I'm afraid that would be too much work to implement, hopefully the category selection should be much faster now

    4 When items are moved out of a category, the category isn't removed
  • 1a) Great news - one question though, how do we add an item to a newly added category that doesn't appear in the list now? I guess an email request?

    1b) Sure. This item:

    http://www.brickowl.com/catalog/lego-minifigure-figure-sack-92590

    Appears in:
    Catalog > LEGO Parts > Minifig > LEGO Minifig Body Wear
    Catalog > LEGO Parts > Minifig > LEGO Body Accessory Parts

    And when viewing the item it shows its category as:
    Catalog > LEGO Parts > Minifig > Body Wear > Body Accessory >

    Which seems to be a combination of the two of them, I just assumed this was a case of primary/secondary categories. There are a few items like this.

    2), 3), 4) Okay, makes sense.
  • When I changed the edit form yesterday, I did account for this fortunately, any new categories that are created should appear in that list regardless of if they are empty or not.

    So, it's been so long since I made Brick Owl I forget things, technically an item can have multiple categories, but I don't think it's intentional, and it's a bug that happens when a new category is assigned, but the original category isn't removed for the item.
  • The new category selection drop-down works much faster, almost instant, thanks very much. Regards second categories, I think being able to add a secondary category would help standardise item classification sometimes, though I understand not a priority at all.
  • edited December 2015 Vote Up0Vote Down
    I'm often confused about the proper and/or recommended procedure for catalog submissions, especially minifigs.

    1) Generally, should parts that are worn "on the back" of the minfig be included in its inventory? It's really not consistent so far. Personally, I believe everything but hand-held parts should be included, also matching the policy elsewhere.

    2) If a minifig has an inventory that differs from the guideline above or from the other catalog, can we "correct" that minifig's inventory when no store has it listed for sale yet? That implies often correcting the set's inventory as well, separately.

    3) If a minifig has an inventory that differs from the other catalog, can we create a new minifig matching that other inventory? Even if said new minifig wouldn't belong to any set/gear? (here's a precedent: http://www.brickowl.com/catalog/lego-lord-business )

    4) If we create a new minifig to match the other catalog, and that new minifig better matches the not-clearly-defined policy regarding worn-on-the-back parts, can we replace the set's inventory with that new minifig? The previous minifig would be preserved for stores already offering it for sale.

    5) When editing both a minifig and a set's inventory, is there a proper way to specify that the two submissions are linked together? I remember once having one submission accepted and the other rejected, that... didn't improve the situation.

    6) If a minifig's constituent parts still exist in a set's inventory, should we or should we not remove them? I remember conflicting information, about some automated process cleaning these up... but I'm not sure that happens.

    7) Often, we may make a catalog submission, later realize it was incorrect, so we submit a correction. Unfortunately, submissions often appear to be processed latest-first, so the correction is processed first and the bad submission then overrides it. Besides not making errors in the first place (ahah...), what's the correct procedure? Could submissions be processed in the order received instead?
  • @Stragus
    From previous discussion(s) about wrong inventories of minifigs with Admin Lawrence, it is my understanding that minifigs should be inventoried exactly in the same way it is done on other websites, the reason is pretty obvious, there are a whole lot of sellers syncing their inventory, if the composition of a minifig differs, 2 things can happen: either those sellers do not have their minifigs listed on BO (would be bad for both), because we couldn't attach the BLID, either the BLID is attached and the seller doesn't have the right minifig in his/her inventory, which would cause issues with buyers in the long run. I do understand there are sellers working exclusively on BO, so they couldn't care less, but those sellers (and I'm sure Lawrence does) must realise that BO can only grow if it has more sellers, with larger inventories, attracting even more potential customers to the site, and that it shouldn't be the intention that those sellers 'who sync' have non matching minifigs, as it would increase the number of 'issues' in the long while, while the whole setup from the start of BO (auto checkout / instant payment) was to have less issues. Clear catalog entries should contribute to that, and obviously discrepancies in inventories (particulary minifigs) are to be avoided for that same reason IMHO
    So to answer question (personal point of view) #1 yes, minifigs should be like 'elsewhere', Brickset does the same thing if I'm not mistaken.
    #2 minifigs should be corrected, and have been, either by contributors, either by Lawrence. If the correction consists removing something, then it ain't much of a problem, if the correction consists of 'adding' something, then it would be wise to send notifications to the sellers, this could be automated (and should be automated IMHO). Now obviously if contributors follow the guidelines of elsewhere, then not ever this should be an issue ;-)
    #3 Yes IMO, taggings and namings should 'do' for potential buyers to find those, without messing up inventories of sets.
    #4 Certainly, otherwise it would mess up set inventories. But it shouldn't be the intention to create new figs all the times because the initial 'inventorier' didn't follow the same procedure. Obviously Lawrence approves on those, but just like any of us he is a human, so mistakes can happen, clear 'written' guidelines would help, appointing a minifig approver who takes the time to actually match minifigs with other databases might be another option maybe?
    #5 Could be avoided if a minifig was created 'correctly' in the first place. But nevertheless, comments can be made (and should be) during submissions, to point out to it.
    #6 Allthough the process is automated, I don't think it always works correctly, but it is my understanding this might take a day or 2 to adjust. It would be wise to have another check a week later to manually adjust if needed.
    #7 Dunno Admins Lawrence schedule and available time to run BO, besides writing the coding, adjusting it, reading suggestions and adding new features (thank you Lawrence for the 2 most recent ones !!), step in between issues between buyers and sellers when there is a need to, importing and managing new data (new sets, new inventories), approving peoples submissions for new images, submitted sizes and weights, tags, namings, new minfigs, items ID's (BLIDS) etc. I'd simply say kudos to him for the work done so far !! But (and offcourse there is one :-) ), in the long run this is not managable for one person, as some things simply need more time to get sorted and/or approved and needs investigating before approval (I think I have a few submissions pending for well over a year now). The only thing that needs to be done is to accept the help from 'outsiders' and create tools for such, sure this will implicate more coding, but once coded, it would allow for Lawrence to free up a looooot of time, time that could be spended to take care of the less obvious submissions, so in the long run the advantage would be on his side (and therefore BO's side) and they would cause less aggrevation from contributors because now they feel 'it's talking too long' and obviously if submissions are being dealt with 'backwards' in stead of FIFO, then the oldest submissions will never be dealt with (or would take ages to be dealt with). Other things have crossed my mind the past few months, accentuated the past few weeks, but will (at least) try to discuss those privately with Admin Lawrence, most likely during the holiday break.
  • Thanks RobErNat, we really need all that written somewhere.

    In the previous post, I actually left out the point that most bothers me: catalog errors. Unless I'm missing something, the current procedure to correct these is a real mess. It's typically a multi-step process where we must wait for previous steps to be approved. Let's pick a simple and typical example:

    This minifig:
    http://www.brickowl.com/catalog/lego-dareth-minifigure
    is currently part of the inventory of these two sets:
    http://www.brickowl.com/catalog/lego-temple-of-airjitzu-set-70751
    http://www.brickowl.com/catalog/lego-dareth-vs-nindroid-set-5002144

    That's obviously incorrect, these should be two different minifigs. The minifig's inventory belongs to 70751, the photo matches 5002144's.

    The solution? Should I create a new blank minifig, and once it's approved, set that minifig's inventory, fix the existing minifig, and correct the set inventories? That sounds good, right?

    Here's the bad news: I think I have pending "Item Creation" and "Inventory Create/Alter" submissions going back to April 2015. Some of these were preliminary steps to correct catalog errors! I had written down... somewhere... what the following steps were going to be once the previous step was approved. I would have no idea why I was creating a new minifig if it were suddenly approved today.

    The current catalog submission system is all right to submit simple data, but I think we need to figure out something that works better to correct catalog errors.
  • @Stragus.
    You pointed towards the downside of the automated 'search and fill in' system Lawrence created.
    When a fig is created in 1 set, the system search for other sets with the same parts in inventory and also links the fig to that set as well (with bad results obviously), and removes the subparts from that set as well. I've seen it lead to issues with citysets, as sometimes a large set can contain a whole bunch of the same parts from another set, but the composition of the figs is entirely different... In my opinion the 'search and fill in' is a bad move, as it causes indeed incorrect composition of set inventories, and the worst part is that the subparts are gone, so on top the correct figs can no longer be created, and the other figs neither, as some of the subparts are gone. Correction this does involve multiple steps indeed 1. the parts need to be added back to the inventory of the set, such needs approval 2. New figs need to be created, such needs approval 3. the inventory needs to be adjusted, because the wrong fig(s) must be removed, such needs approval.
    So this whole process takes several days, with constant 'keep track on what you where doing' (obviously for contributors 'on paper' as we can't see what we have pending).
    It is my opinion this 'search and fill in' thing is a bad feature, obviously it is a time gainer in many cases, but it is a huge time waister when something goes wrong, not to mention that for people who use the BO catalog to do part out's, they end up with a bunch of loose parts in their inventory because they can no longer be placed together for a fig...
    It's IMHO is the reason why 'minfigs', or the approval of them, and the attachement to sets should be manual *and* supervised and not 'automated' (allthough that sounds pratical).
  • Generally our minifig policy is the same as BL. It can differ with edge cases like Lord business, and we don't include the flowers in the hair of friends minifigures. It would be handy to have all these policies written down, the person who used to do the help pages is no longer in a position to do that, if someone else would like to fill that gap it would of course be much appreciated.

    With the "search and fill in", the process creates the inventory submissions, but it's up to me to approve them, usually by looking at the picture. That reminds me, probably the biggest hindrance to catalog approving stuff is not actually having the set, so if I think a submission could be possibly wrong, it's very difficult to actually work out either way, so then I need to do further research or contact the person.

    You can make up minibuilds for figures that dont match our not even written down policy
  • @lawrence
    As you know I'm pretty activate on minifigs, I actually started a month or 3 ago going over the sets that entered the database *after* the final import from BL in june 2013, and added quite a few to fill gaps. It is still my opinion the process is too slow, and could be enhanced: like when creating a minifig, have tag field to indicate the fig is also in other sets (so once approved they would generate the required inventory request for those sets, without generating requests in sets they don't appear in), adding other information like BLID, sizes/weights, and potentially a picture, would allow to not only speed up the process (without a contributor having to wait for approval, then get back to it to fill details), but would also give you the opportunity to have more details as to where which fig belongs (if in several sets)
    Now if you really wanna have a lower error rate with more instant creation of minifigs who fit the unwritten guidelines and who have been checked with other databases, then the only thing I can suggest is to expect someone to process this right away (and I am willing to do so), soon as you have downloaded the data for the inventory of a set, thing is, none of us knows at what moment you download this data to have it on BO, so why not setup an automated mailing system or an online page to process, towards selected person(s) (who would take the time to create figs) which indicates which new set needs to be dealt with 'minifigs' wise and even potentially provide an online page for that person with all the sets that have been recently downloaded. TLG keeps increasing the variaty of minifigs per year 2006-2009 an average of about 400 per year, 2010-2013 an average of about 560 per year, 2014-2015: an average of 700 new figs per year, and it will most likely keep increasing... So delegating this task to one or two persons (in stead of the whole community of contributors) who can keep control over the matter might be your best option in the long run, and the 'safest' in regards to correctness of them ;-)
  • I've added a new missing data type, for sets that don't have minifigures in the inventory, it will take a day probably for the system to run its processes so I will check to see if that worked tomorrow.
  • A nice step forward :-)
    But I assume it will get falsified soon as 1 fig is created in a set? Can you prevent the indication to dissapear as long as there is still a torso or legs in the inventory (wouldn't base it on heads or other minifig stuff, as sometimes there are extra's, with legs and torso's this is less likely)

    Could you make one as well for minifigs who have not been inventoried? Mainly with the intention to inventory older figs, in the long run, once they are all done this missing data process could be stopped (as current figs are created from the inventories), but there's probably still +4000 that need to be inventoried.


  • Minifig parts are often in sets for other reasons though, let's just see how this goes to start with. There should already be one for items that don't have an inventory, that you should be able to filter on minifigure.
  • @Lawrence
    you mean the missing data overview
    image

    Yes, workable, but it also includes many minifigs that cannot be inventoried (Duplo figs for instance), could you have an additional option to mark something 'cannot be inventoried', that way people can tag them to get them out of the list? This should allow to narrow down, without having hundreds of items in the list that simply cannot be inventoried.
  • @RobErNat No need for email notifications from Lawrence, I can regularly send you a list of all missing data on BrickOwl, especially minifigs. Let's discuss that by email.

    I use such automated lists to submit BLIDs myself, but I'm reluctant to create minifigs when it would be a multi-step process, like Boba Fett from 75060 ( http://www.brickowl.com/catalog/lego-slave-i-set-75060 ), where the set's inventory still has to be modified first.

    My current automated database cross-referencing is way too crude... I'll add some fuzzy matching of minifig inventories, that should get rid of my bad BLID submissions due to some missing flower in the hair or whatever (sorry about these, Lawrence).

    Given how the catalog error mentioned above has already been fixed, is it the recommended procedure to explain the problem in an empty catalog submission note? It never worked well to wait for a first step to be approved before submitting the following steps.
  • @Robernat, it helps if you don't view it like a list where the number needs to go to 0, many of the missing data types cannot go to 0. You can filter by category, so by Star Wars for example, so you can filter out the Duplo figures for example that way.

    @Stragus if a catalogue error is complex and needs communication, then sure, a catalogue note is a good way to do that. It stays in the catalogue submission section until I deal with it. In general, anything that's ever so slightly controversial, I very much appreciate some sort of note, to give me some background and help me make a decision.

  • A nice step forward :-)
    But I assume it will get falsified soon as 1 fig is created in a set? Can you prevent the indication to dissapear as long as there is still a torso or legs in the inventory (wouldn't base it on heads or other minifig stuff, as sometimes there are extra's, with legs and torso's this is less likely)
    Given that some figs have deco slopes instead of legs, probably best to search for torsos floating around. I can't think of any modern sets where there would be an extra torso. Maybe one or two.

    For droids though the legs or head might be more important to look for. Battle droid torsos are occasionally used as something other than the same. I don't recall seeing those legs as anything else though.
Sign In or Register to comment.