|
 |
| | | Author: | FigBits  | | Posted: | Sep 13, 2012 23:39 | | Subject: | BL 2.0 suggestion: Catalog reorganization | | Viewed: | 614 times | | Topic: | Suggestions | | Status: | Open | | Vote: | [Yes|No] | |
|
| Sorry for the length of this post. I know that people don't read enormous blocks
of text like this, but this has been brewing at the back of my mind for many
months now, and I figured it was time to organize my thoughts and put them out
there. I will likely have a couple more "2.0" suggestion posts in the next few
days. This will be the most elaborate one.
Here we go...
We've seen a lot of discussion in the forum over the last few years that I've
been on BrickLink, about variant parts, and their place in the catalog. By interesting
coincidence, the issue of the headlight bricks has come to the forefront today,
with the decision to retire the listing for the slotted version. I'm sure that
we're going to see quite a few threads from people who are confused by the change,
but it was probably the right decision for this particular part.
My suggestion will relate more to parts that have genuine variants. It will have
other applications as well, but it's simplest to describe in terms of variant
parts.
Take minifig heads. Right now, Lego is undergoing a change from the "b" to the
"c" variant of this part -- the stud on top is sometimes open, with a little
triangular webbing in the middle, and is sometimes recessed.
[p=3626b]
[p=3626c]
Many of the minifigs in new sets are available with both variants of the head.
But because minifig assemblies don't allow for alternate parts, the figures inventory
ends up explicitly stating that it's made of the "b" version (or the "c") when
in fact both exist.
This ends up leaving the part listing for the other variant somewhat orphaned
-- it shows that it doesn't appear in any sets, even though it does.
http://www.bricklink.com/catalogItemIn.asp?P=3626cpb560&in=S
http://www.bricklink.com/catalogItemIn.asp?P=3626bpb560&in=S
This means that sellers will sometimes "lie" about which variant they have --
they will put their items in the listing that is most likely to be visited by
buyers.
I do this myself with my unprinted minifig heads. Note the additional comments
on the vast majority of these listings: http://www.bricklink.com/store.asp?p=FigBits&q=3626b
"(may be 3626c with recessed stud)"
Okay, so what is the actual suggestion?
For BrickLink 2.0, we should change the way that the catalog database is set
up, in order to accommodate a new structure, which I'll call a Part Group.
A Part Group isn't really a Part, but a kind of Super-Part. It's a collection
of similar parts which BrickLink would treat as the aggregate of all the sub-parts.
Here's an example:
Those are two different Parts, listed separately in the catalog. But what if
a buyer doesn't care which one they get? How do they search for the listing for
either part? Right now, the way that the catalog is set up, that buyer
is put at a disadvantage -- it's possible that there are sellers who have the
items that they want, in the right quantities, but they will never get Wanted
List notifications for them because those sellers have split their listed quantities
between the two variants.
So, the suggestion would be to have a new Catalog entry, for the aggregate of
those two parts. We'll call the listing Part Group 3794*
When a buyer goes to the listing for 3794, they would see a page that tells them
what parts are members of the part group. If they want to jump to the specific
listing for either one, they can. Or, they can use any of BrickLink's existing
functions for the Part Group instead.
The Price Guide for Part Group 3794* would show every listing for 3794 AND every
listing for 3794b, blended together. Searches would as well. Buyers could add
the Part Group to their Wanted Lists, instead of the individual Parts.
AND! ... Set and minifig inventories would list the Part Group instead of having
alternate inventory parts (where applicable). So, to use the example of the minifig
head I mentioned before, the inventory for
would not have either 3626bpb560 or 3626cpb560 in
its inventory. It would have the Part Group representing both parts (we can call
it 3626*pb560, but the specific nomenclature isn't part of the suggestion).
Sound confusing? It isn't. When you click through on that Part Group in the inventory,
it would show just like a normal Part -- the Catalog Page for the Part Group
would have links to the Items for Sale, In My Inventory, On Wanted Lists, Price
Guide Info, and Known Colors. But all of those links would take you pages that
have aggregate results of all the Parts in the Part Group. The only addition
on the catalog page is that you would see that there are multiple Parts in the
Group, and there would be links to each one in case you didn't want aggregate
results, you wanted one of the specific variants.
It would actually be very straight forward, and it would solve many of the issues
and disagreements we've seen about how to handle part variants. It leave open
the option to be specific for those who want to be specific, and it allows for
buyers and sellers to be generic if they want to be generic.
Now, there's a little wrinkle in there, which actually could cause a bit of confusion.
If you think the suggestion through, you might realize that, for a seller to
actually have a listing that is undifferentiated (that is, they do not want to
specify which variant they have), they could not put their listing as either
of the variants.
This seems to imply that every Catalog Part with variants would need to also
have an "undetermined" type -- additional variant. But no. The Part Group itself
is the undetermined type. Which means that for a seller to list an item in their
store, like my minifig heads that could be either type b or c, they would need
to list the Part Group in their store.
This makes sense when you think about it. If the Part Group is what's in a set
inventory, when you part out that set in BrickLink, by default it would list
the Part Group for you. There would be an option in the part-out process if you
want to replace any of the Part Groups with a member of that Group before uploading
into your store. Or you can leave it as the Group.
If you have a listing for a Part Group, the notifications you send out would
only go to people who have the Part Group in their Wanted List (that is, they
deliberately chose to ignore the variants -- they want whatever). Notices would
not be sent to buyers who have a specific variant in their Wanted List.
So, that's the most significant way in which Part Groups would be different than
"undefined" types. We could actually delete all the undefined listings in the
catalog, like
because they would more thoroughly be represented by Part Group 4085*
If you've made it this far, you're probably insane, so I can tell you about some
of the other implications of the suggestion, without fear that I will scare you
away.
I've been talking about variants "b" and "c" of minifig heads, but there's also
type "a" -- the solid stud heads.
A lot of purists who collect older figures are bothered by the fact that BrickLink's
inventories always list the "b" type. Where are all the minifigs with
in their inventories? They don't exist. Except, of course, they do. it's just
that minifig inventories don't allow for variant parts.
I've mentioned this already, yes? Yes. But, here's the kicker:
If we have a Part Group for 3626*p01, would it include the a, b, and c versions?
It could. The problem is that there is no minifig that has all three of those
variant heads. (Well, maybe there is. But I think you know what I mean.)
What we would actually need is a Part Group for "old minifigs" that would include
the a and b variants, and a Part Group for "modern minifigs" that would include
the b and c variants. At this point the nomenclature gets messy, but I honestly
think that the names of the Part Groups aren't too important. I don't think that
most buyers go specifically looking for "3626cpb560" as though that string of
letters and numbers means anything. So I don't think it matters if we call the
Part Groups 3626old* and 3626new* or whatever. Having those distinct groups would
make the inventories more accurate, it would appease the discriminating buyer,
it would open up additional avenues to the general buyer, and it would allow
sellers to better accommodate their customer's needs, whatever they might be.
That's it. (Mostly)
A new way to address part variants. It doesn't just need to be for the existing
variants, either. Minifig torsos come in variations unrecognized by the catalog,
because including those variations would be a nightmare under the current Catalog
structure. But they would be a breeze to implement in a system that included
Part Groups.
Super-quick:
Set Groups would exist, too. For variant sets. There's also that Star Wars set
that Lego redesigned but released under the same set number.
K. I'm sleepy now.
--
Marc.
|
|
|
| | | | | |
| | | | | Author: | DadsAFOL | | Posted: | Sep 13, 2012 23:52 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 84 times | | Topic: | Suggestions | |
|
| In Suggestions, FigBits writes:
| | For BrickLink 2.0, we should change the way that the catalog database is set
up, in order to accommodate a new structure, which I'll call a Part Group.
A Part Group isn't really a Part, but a kind of Super-Part. It's a collection
of similar parts which BrickLink would treat as the aggregate of all the sub-parts.
|
Yes YES YES!
Thanks for posting Marc. Keeping the variants for the purists and "grouping"
the variants for the 95% of buyers that srive the commerce that keeps the site
running is perfect.
I, like many sellers, already do this within my store, but its a pain to manually
maintain when parting sets.
-Jason
|
|
| | | | | | | | | |
| | | | | | | Author: | Brockmeister | | Posted: | Sep 14, 2012 00:57 | | Subject: | (Cancelled) | | Viewed: | 74 times | | Topic: | Suggestions | |
|
| | (Cancelled) |
|
| | | | | |
| | | | | Author: | lepperk | | Posted: | Sep 14, 2012 00:58 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 66 times | | Topic: | Suggestions | |
|
| In Suggestions, FigBits writes:
| | For BrickLink 2.0, we should change the way that the catalog database is set
up, in order to accommodate a new structure, which I'll call a Part Group.
A Part Group isn't really a Part, but a kind of Super-Part. It's a collection
of similar parts which BrickLink would treat as the aggregate of all the sub-parts.
|
I've been thinking along these lines as well. Imagine the catalog as it looks
now (more or less) but for parts with variants, there is a single catalog entry.
But the catalog entry has the ability to specify variants (from one to several).
Perhaps there would be checkboxes for the variants on the catalog page
So for a part like this:
there would be a single catalog page. There would be check boxes for the variants
(thin 'O' clip, thin 'U' clip, thick 'O' clip, thick 'U' clip).
When looking at the price guide page for the part (for example) you could click
one of the variant checkboxes to see the results for only that part, or leave
them all unchecked to see all variants.
When listing, you could select the variant using the checkbox or not. That way
sellers could decide whether to have their parts be 'undefined' or have the variant
specified.
When searching lots for sale, or making wanted lists, you could select a variant
using the checkbox or not. That way buyers could decide whether to narrow their
search to a specific variant or see all variants.
Sounds quite similar to what you're proposing -- mostly just different terminology.
Karen
|
|
|
| | | | | |
| | | | | Author: | SimplyBricks | | Posted: | Sep 14, 2012 06:57 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 90 times | | Topic: | Suggestions | |
|
| Did I miss the part about where you considered the impact on the inventories?
Your suggestion sounds like it would have the part group in the inventory, but
in reality it would mean that the inventory could be made up with any of the
part variants, regardless of whether that part variant was available at the time
the set was being manufactured.
Does that sum it up, because I would have thought that would not have been acceptable
to the purists anyway!
Emma
Inv. Admin
In Suggestions, FigBits writes:
| | Sorry for the length of this post. I know that people don't read enormous blocks
of text like this, but this has been brewing at the back of my mind for many
months now, and I figured it was time to organize my thoughts and put them out
there. I will likely have a couple more "2.0" suggestion posts in the next few
days. This will be the most elaborate one.
Here we go...
|
|
|
|
| | | | | | | | | |
| | | | | | | Author: | FigBits | | Posted: | Sep 14, 2012 08:12 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 65 times | | Topic: | Suggestions | |
|
| In Suggestions, SimplyBricks writes:
| | Did I miss the part about where you considered the impact on the inventories?
Your suggestion sounds like it would have the part group in the inventory, but
in reality it would mean that the inventory could be made up with any of the
part variants, regardless of whether that part variant was available at the time
the set was being manufactured.
Does that sum it up, because I would have thought that would not have been acceptable
to the purists anyway!
Emma
Inv. Admin
|
The inventory would show the Part Group relevant to that inventory. Near the
end of my post, I describe how parts that have multiple variants would really
need multiple Part Groups to properly capture how they may appear in inventories.
(The example that I used was how the inventories for old minifigs would have
the Part Group representing solid and hollow stud heads, and the inventories
for new minifigs would have the Part Group for hollow and recessed heads. But
the same idea would apply to set inventories.)
Because of the length of the post, I didn't go in to too much additional detail
about how that would actually look. Right now, when creating a new inventory,
users pick the variant that they find in the set, and if they know that another
version also appears, then they list that variant as an alternate. Under the
proposed system, the user would pick the specific variant that appears in the
set, and if they know that another version also appears, then they would pick
the specific Part Group that contains those variants. (In practice, it would
often be that the original inventory submitter would pick a specific variant,
and later on when the variations within the inventory are discovered, someone
would submit an inventory change to switch out the specific part with the relevant
Part Group.) Although it sounds complex, creating, approving, and updating inventories
would not be any more complex than it is now.
The Catalog structure itself would be more complex, though.
Part Groups that are related to each other because they represent different collections
of variants within a larger Part Group would all have relationships built into
the database. When an inventory contains any Part that belongs to a Part Group,
or any Part Group that has a relationship to a parent Part Group, a seller who
parts out that set would be given the option of which Part Group to add to their
store's inventory. The option to choose the highest-level part group would ensure
that the part is described truly as the undefined variant. (Sellers, of course,
could choose an option to always handle those decisions in the same way when
parting out.)
--
Marc.
|
|
|
| | | | | |
| | | | | Author: | jeslego | | Posted: | Sep 14, 2012 09:39 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 54 times | | Topic: | Suggestions | |
|
| Great work. I've got a couple of quibbles, but they should not obscure how well
thought out your suggestion is.
1)Very few new users will be able to wade through a 200 word explanation of a
database design that resolves problems that have existed since before the Internet.
The interface designers will have two choices: Find a better explanation, or
find a way to let new users search without knowing about this level of complexity.
2) I will be very disappointed if it turns out that the database design has not
been finalized for Bricklink 2.0. This may be a better suggestion for v2.1
jes
|
|
| | | | | | | | | |
| | | | | | | Author: | FigBits | | Posted: | Sep 14, 2012 11:44 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 39 times | | Topic: | Suggestions | |
|
| In Suggestions, bljesprop writes:
| | Great work. I've got a couple of quibbles, but they should not obscure how well
thought out your suggestion is.
1)Very few new users will be able to wade through a 200 word explanation of a
database design that resolves problems that have existed since before the Internet.
The interface designers will have two choices: Find a better explanation, or
find a way to let new users search without knowing about this level of complexity.
|
Absolutely. The interface is key. The main reason that I wrote so much is that
I'm trying to sell existing users on the value of this change. Explaining how
to actually interact with the improved catalog would be much easier to describe.
I was thinking about making a few mock-up screenshots of how some frequently
used pages might look if this catalog change was implemented under BL's current
design.
| | 2) I will be very disappointed if it turns out that the database design has not
been finalized for Bricklink 2.0. This may be a better suggestion for v2.1
|
Yeah. I wish we knew more about the progress on the updated site. As far as I
know we have not yet heard even an estimates timeframe. I'm imagining Q2 2013.
--
Marc.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | therobo | | Posted: | Sep 14, 2012 13:39 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 45 times | | Topic: | Suggestions | |
|
| In Suggestions, FigBits writes:
| | In Suggestions, bljesprop writes:
| | Great work. I've got a couple of quibbles, but they should not obscure how well
thought out your suggestion is.
1)Very few new users will be able to wade through a 200 word explanation of a
database design that resolves problems that have existed since before the Internet.
The interface designers will have two choices: Find a better explanation, or
find a way to let new users search without knowing about this level of complexity.
|
Absolutely. The interface is key. The main reason that I wrote so much is that
I'm trying to sell existing users on the value of this change. Explaining how
to actually interact with the improved catalog would be much easier to describe.
I was thinking about making a few mock-up screenshots of how some frequently
used pages might look if this catalog change was implemented under BL's current
design.
| | 2) I will be very disappointed if it turns out that the database design has not
been finalized for Bricklink 2.0. This may be a better suggestion for v2.1
|
Yeah. I wish we knew more about the progress on the updated site. As far as I
know we have not yet heard even an estimates timeframe. I'm imagining Q2 2013.
|
Hi,
up to now Catmins are not involved in ANY possible catalog database design changes.
Ronald
|
|
|
| | | | | |
| | | | | Author: | CPgolfaddict | | Posted: | Sep 14, 2012 12:28 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 33 times | | Topic: | Suggestions | |
|
| I think similar suggestions have been posted in the past. But I'm on board.
There are a bunch of ways to implement this in the BL catalog data model. I
recommend leaving the specific implementation out of the discussion if possible.
Rather, what are the features you want to see as a buyer & seller?
A. Buyer/Seller ability to view, view price guide and list items without specifying
a variant. (The no-variant version) For example, a seller doesn't care or doesn't
want to deal with the variants, but still list and sell the parts accurately
WITHOUT having to put disclaimers in the the item comments or in my store terms
and conditions. Kind of like the undetermined thing.
B. A buyer/seller who so chooses: can view items, view a price guide page and
list items for a specific variant. Those that have a specific need, can get
to that variant and shop by price via the price guide if they choose.
C. A user needs the ability view items and view a price guide page that contains
both the no-variant AND variants. (Average price calculated from both no-variant
part and variants combined). Example: I don't care if the variant is specified
or not, I just wanted to buy the cheapest lot in a particular color. (with
multiple variants there could be some nice-to-have features.... e.g. I want to
see a price guide page that includes the no-variant, variant a, and variant c,
but not variant b. )
|
|
|
| | | | | |
| | | | | Author: | bb200521 | | Posted: | Oct 23, 2012 04:27 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 60 times | | Topic: | Suggestions | |
|
| In a most simple way, I just checked on peeron with the castle serie sets. It
seems that the head with stud hollow appeared only in 1992. (did anyone have
a more reliable information ?)
Though all the castle minifigs coming earlier should have a 3626ap01 head (at
least, a majority of the castle figures listed here, and concerning these sets
don't appear in more recent sets).
I focus on this category of set since the ones from my childhood are essentially
from this theme. Hence I have plenty of solid stud that, for sure, come from
this decade, and no stud hollow.
In another way, from what I read till now on different post, I wonder why, better
than creating an alternate minifig with a type b or c stud, the alternate head
can't appear in the minifig inventory ? Would it be difficult to manage set with
on type of minifig, which on could have an alternate head ?
In Suggestions, FigBits writes:
| |
I've been talking about variants "b" and "c" of minifig heads, but there's also
type "a" -- the solid stud heads.
A lot of purists who collect older figures are bothered by the fact that BrickLink's
inventories always list the "b" type. Where are all the minifigs with
in their inventories? They don't exist. Except, of course, they do. it's just
that minifig inventories don't allow for variant parts.
|
|
|
|
| | | | | |
| | | | | Author: | WoutR | | Posted: | Apr 2, 2013 19:18 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 59 times | | Topic: | Suggestions | |
|
| YES!
But...
In Suggestions, FigBits writes:
| | (...) What we would actually need is a Part Group for "old minifigs" that would include
the a and b variants, and a Part Group for "modern minifigs" that would include
the b and c variants. At this point the nomenclature gets messy, but I honestly
think that the names of the Part Groups aren't too important. (...)
Marc.
|
I don't like this detail.
What would be perfect would be if we can link the year the set was released to
the data available on when part variations appear and disappear. There is a limited
period of time when the part appears in two (or more) versions, and for many
parts we can make a reasonable guess. We already have data on the year released
linked to the part variations.
In the ideal situation we could collect information to show us something like
this:
3626* 1975-present
3626a 1975-2011 (not used in new sets)
3626b 1978-present (fading out)
3626c 2009-present (fading in)
3626d I'm sure there will be more versions in the future 
A set dated 1976 inventoried with 3626* could show that variation 3626a was the
only one available at that time. A set dated 1980 could show that both 3626a
and 3626b would be correct for the time period applicable.
It should be easy to allow a set to be inventoried (and sold) with part 3626*,
while at the same time the catalog can show which part variations would be correct
for the time period so all purists can be happy also.
---
Also, we should never use descriptions like "old" and "new", because new will
be replaced by "newer" and then the naming really gets messy. Just use numbers
or letters to describe variations.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | WoutR | | Posted: | Apr 21, 2014 07:08 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 59 times | | Topic: | Suggestions | |
|
| In Suggestions, WoutR writes:
| | YES!
But...
In Suggestions, FigBits writes:
| | (...) What we would actually need is a Part Group for "old minifigs" that would include
the a and b variants, and a Part Group for "modern minifigs" that would include
the b and c variants. At this point the nomenclature gets messy, but I honestly
think that the names of the Part Groups aren't too important. (...)
Marc.
|
I don't like this detail.
What would be perfect would be if we can link the year the set was released to
the data available on when part variations appear and disappear. There is a limited
period of time when the part appears in two (or more) versions, and for many
parts we can make a reasonable guess. We already have data on the year released
linked to the part variations.
In the ideal situation we could collect information to show us something like
this:
3626* 1975-present
3626a 1975-2011 (not used in new sets)
3626b 1978-present (fading out)
3626c 2009-present (fading in)
3626d I'm sure there will be more versions in the future
A set dated 1976 inventoried with 3626* could show that variation 3626a was the
only one available at that time. A set dated 1980 could show that both 3626a
and 3626b would be correct for the time period applicable.
It should be easy to allow a set to be inventoried (and sold) with part 3626*,
while at the same time the catalog can show which part variations would be correct
for the time period so all purists can be happy also.
---
Also, we should never use descriptions like "old" and "new", because new will
be replaced by "newer" and then the naming really gets messy. Just use numbers
or letters to describe variations.
|
13 months later and an updated opinion. The set inventories should include the
exact part variation used. The historical timeline of the parts and their colors
should be preserved.
I still like the addition of part group & part variant layers to the catalog
for the reasons stated in the initial message, but I think the amount of historical
information preserved is not enough if the suggestion is implemented without
a few modifications.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | FigBits | | Posted: | Aug 2, 2015 17:29 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 45 times | | Topic: | Suggestions | |
|
| In Suggestions, WoutR writes:
| | In Suggestions, WoutR writes:
| | YES!
But...
In Suggestions, FigBits writes:
| | (...) What we would actually need is a Part Group for "old minifigs" that would include
the a and b variants, and a Part Group for "modern minifigs" that would include
the b and c variants. At this point the nomenclature gets messy, but I honestly
think that the names of the Part Groups aren't too important. (...)
Marc.
|
I don't like this detail.
What would be perfect would be if we can link the year the set was released to
the data available on when part variations appear and disappear. There is a limited
period of time when the part appears in two (or more) versions, and for many
parts we can make a reasonable guess. We already have data on the year released
linked to the part variations.
In the ideal situation we could collect information to show us something like
this:
3626* 1975-present
3626a 1975-2011 (not used in new sets)
3626b 1978-present (fading out)
3626c 2009-present (fading in)
3626d I'm sure there will be more versions in the future
A set dated 1976 inventoried with 3626* could show that variation 3626a was the
only one available at that time. A set dated 1980 could show that both 3626a
and 3626b would be correct for the time period applicable.
It should be easy to allow a set to be inventoried (and sold) with part 3626*,
while at the same time the catalog can show which part variations would be correct
for the time period so all purists can be happy also.
---
Also, we should never use descriptions like "old" and "new", because new will
be replaced by "newer" and then the naming really gets messy. Just use numbers
or letters to describe variations.
|
13 months later and an updated opinion. The set inventories should include the
exact part variation used. The historical timeline of the parts and their colors
should be preserved.
I still like the addition of part group & part variant layers to the catalog
for the reasons stated in the initial message, but I think the amount of historical
information preserved is not enough if the suggestion is implemented without
a few modifications.
|
Another 13 months later, and I would agree. I think probably the best solution
for the inventories is to have the specific variant in the inventory, and the
Part Group (I don't like that name anymore) as an alternate.
--
Marc.
|
|
|
| | | | | |
| | | | | Author: | Biodreamer | | Posted: | Jul 10, 2013 03:22 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 62 times | | Topic: | Suggestions | |
|
| I like this suggestion but it's to simplistic to work in all cases.
what you need is the undetermined type in the root of a mold tree.
for example
3062
if you have a set with 3062a it would automatically be acceptable to build with
any piece below in the tree. But pieces above wouldn't work because they
lack a feature, such as the hole in the stud.
This could easily be added in the database by allowing a replaced by mold entry
for each piece and if it's NULL it goes to the undetermined type.
Allowing multiple branches for the more complex none linear mold changes.
|
|
| | | | | |
| | | | | Author: | leggodtshop | | Posted: | Jul 10, 2013 03:59 | | Subject: | Re: BL 2.0 suggestion: Catalog reorganization | | Viewed: | 67 times | | Topic: | Suggestions | |
|
| Too complicated if you ask me.
I think the Catalog will be, or needs to be, generic when it comes
to variants simply because it is sometimes unknown exactly or too much detailed
to add all variants. Much like it is now.
However, the seller has a specific item in hand. Now what does s/he wants
to do?
a) List the generic item as compliant with the Catalog? No problem.
b) List the item as specific? With this specific listing of this item
the seller needs to be able to select specific alternatives from those available
in the Catalog for this item.
The buyer then can check the inventory for this specific listing, and
s/he sees either the generic inventory from the Catalog, or the alternatives
selected by the seller.
This way the Catalog does not need to be changed. It is the listing of the seller
that needs additional functionality.
|
|
|
|
|
|
Canada, Ontario
USA, California
United Kingdom, England
Germany, Berlin
France, Grand Est
Netherlands, Zuid-Holland
Sweden, Stockholm