|
 |
| | | Author: | hpoort  | | Posted: | Jan 2, 2020 03:51 | | Subject: | Policy change - Undetermined versus Unknown a | | Viewed: | 221 times | | Topic: | Suggestions | | Status: | Open | | Vote: | [Yes|No] | |
|
| With the takeover by TLG, it may be time that some fundamental changes to the
site get implemented. Hence the posting of this idea - that has been bothering
me for years.
— requires programming and website extension —
Currently in the Bricklink catalog are parts that signify ‘undetermined variant’,
commonly marked for deletion or already deleted, and corresponding parts that
represent the specific variants of these. The current system requires sellers
to determine the specific variant type – even if they would prefer not to distinguish.
The same system requires buyers to exactly specify which variant they are interested
in buying – even if they don’t actually care which is commonly true. My suggestion
would be to distinguish the two concepts as are the processes: the process of
specifying what is for sale (which may be undetermined) and the process of specifying
what you want to buy (which may be ‘don’t care’). Both processes are already
separate on Bricklink (store inventory and wanted lists), but the concept of
‘undetermined’ is not.
For the catalog policy
• Keep all undetermined variants in the catalog and even add undetermined
variants for those parts that are similar. This information may be extracted
from the relation type ‘part is similar to’.
• Drop the deletion marks for all the undetermined entries and solely use
this marking for wrong or outdated entries.
For sellers
For sellers to don’t want to distinguish between part variants: list these parts
under the undetermined entry only. The BL system should be modified to show these
entries amidst the specific variants for any non specific search as through wanted
lists.
For buyers
For buyers it should be possible to specify an undetermined variety or in
effect a search pattern instead of a single part number. If a buyer does not
care whether a p=4085 is of type a, b, c or d, the buyer should be able to add
p=4085* to his wanted list and the search engine should have no trouble in matching
4085a, 4085b or 4085d with this. Similarly to the 0 color (labeled N/A or Not
Appicable while in this context it actually means Irrelevant).
Buyers should be assisted by the website to specify a specific variant if applicable,
but default to the don’t care form.
For the Bricklink website
• Add a feature to the ‘Add to Wanted List’ and ‘Edit Wanted List’ forms
to allow adding of (a) this specific variant only or (b) include variants. Then
populate the wanted list with the appropriate search pattern instead of the single
part number. This would take the form of either a complete enumeration of all
varieties like ‘4085|4085a|4085b|4085c|4085d’ (plate 1x1 with clip) or the more
general entry of ‘4085*’ or ‘4085@’; I would think the enumeration is more robust,
as it would also allow ‘3794|3794a|3794b|15573’ (jumper 1x2) and would also
allow manual exclusion of one or more variants.
• Adjust the ‘Items for sale’ pages or page fragments that show all matching
parts to include all variants when searching for the don’t care variety.
For the Bricklink database
• Widen the field WantedListItems.ItemNumber to allow for longer patterns.
100 chars would be enough for most enumerations of varieties I can think of.
For the Bricklink search engine
• For matching wanted lists with store items: presume that wanted list entries
may contain a search pattern instead of a single entry. Change the SQL from ‘=’
to ‘LIKE’ wherever necessary or drop the quotes around the field. (But make sure
no malicious code may be entered through this field).
Extra
• A similar feature might be implemented to search for approximate colors
such as ‘any gray’ or ‘any green’, similar to how Studio groups the colors.
Any thoughts of whether this would be helpful for you as a seller or for you
as a buyer?
|
|
|
| | | | | |
| | | | | Author: | SylvainLS | | Posted: | Jan 2, 2020 06:49 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 44 times | | Topic: | Suggestions | |
|
| But but but… The Price Guide!?!!!  |
|
| | | | | | | | | |
| | | | | | | Author: | hpoort | | Posted: | Jan 2, 2020 07:07 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 36 times | | Topic: | Suggestions | |
|
| In Suggestions, SylvainLS writes:
| | But but but… The Price Guide!?!!!
|
Yes maybe that might give some differences between sellers who do and who do
not distinguish. I'd figure the price guide would record the items actually
be sold, whether they be determined or undetermined variants alike.
The actual change would merely be a change to the wanted list feature allowing
for patterned searches instead of exact matches.
Hans-Peter
|
|
| | | | | |
| | | | | Author: | cosmicray | | Posted: | Jan 2, 2020 07:42 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 48 times | | Topic: | Suggestions | |
|
| A long time ago, I made a comment (possibly even a suggestion) that multiple
types of basic parts should be handled by the catalog with a virtual roll-up.
IOW, If you have type-1, type-2, type-3,and undetermined, they should all live
by themselves (in unique catalog entries), but the net effect of all of those
should also be visible under an 'umbrella' catalog entry (for lack of
a better term) that would allow a buyer who does not care about the specific
variant to see all of the specific variants virtually merged into one list. That
would give buyers the Shiite of buying the 'general' part of the 'specific
variant' part as their building needs dictate. Sellers would not be able
to list under the umbrella, but would have to pick one of the participating catalog
entries, know that regardless of which they chose, it would still sow up in the
umbrella listing.
Nita Rae
In Suggestions, hpoort writes:
| | With the takeover by TLG, it may be time that some fundamental changes to the
site get implemented. Hence the posting of this idea - that has been bothering
me for years.
— requires programming and website extension —
Currently in the Bricklink catalog are parts that signify ‘undetermined variant’,
commonly marked for deletion or already deleted, and corresponding parts that
represent the specific variants of these. The current system requires sellers
to determine the specific variant type – even if they would prefer not to distinguish.
The same system requires buyers to exactly specify which variant they are interested
in buying – even if they don’t actually care which is commonly true. My suggestion
would be to distinguish the two concepts as are the processes: the process of
specifying what is for sale (which may be undetermined) and the process of specifying
what you want to buy (which may be ‘don’t care’). Both processes are already
separate on Bricklink (store inventory and wanted lists), but the concept of
‘undetermined’ is not.
For the catalog policy
• Keep all undetermined variants in the catalog and even add undetermined
variants for those parts that are similar. This information may be extracted
from the relation type ‘part is similar to’.
• Drop the deletion marks for all the undetermined entries and solely use
this marking for wrong or outdated entries.
For sellers
For sellers to don’t want to distinguish between part variants: list these parts
under the undetermined entry only. The BL system should be modified to show these
entries amidst the specific variants for any non specific search as through wanted
lists.
For buyers
For buyers it should be possible to specify an undetermined variety or in
effect a search pattern instead of a single part number. If a buyer does not
care whether a p=4085 is of type a, b, c or d, the buyer should be able to add
p=4085* to his wanted list and the search engine should have no trouble in matching
4085a, 4085b or 4085d with this. Similarly to the 0 color (labeled N/A or Not
Appicable while in this context it actually means Irrelevant).
Buyers should be assisted by the website to specify a specific variant if applicable,
but default to the don’t care form.
For the Bricklink website
• Add a feature to the ‘Add to Wanted List’ and ‘Edit Wanted List’ forms
to allow adding of (a) this specific variant only or (b) include variants. Then
populate the wanted list with the appropriate search pattern instead of the single
part number. This would take the form of either a complete enumeration of all
varieties like ‘4085|4085a|4085b|4085c|4085d’ (plate 1x1 with clip) or the more
general entry of ‘4085*’ or ‘4085@’; I would think the enumeration is more robust,
as it would also allow ‘3794|3794a|3794b|15573’ (jumper 1x2) and would also
allow manual exclusion of one or more variants.
• Adjust the ‘Items for sale’ pages or page fragments that show all matching
parts to include all variants when searching for the don’t care variety.
For the Bricklink database
• Widen the field WantedListItems.ItemNumber to allow for longer patterns.
100 chars would be enough for most enumerations of varieties I can think of.
For the Bricklink search engine
• For matching wanted lists with store items: presume that wanted list entries
may contain a search pattern instead of a single entry. Change the SQL from ‘=’
to ‘LIKE’ wherever necessary or drop the quotes around the field. (But make sure
no malicious code may be entered through this field).
Extra
• A similar feature might be implemented to search for approximate colors
such as ‘any gray’ or ‘any green’, similar to how Studio groups the colors.
Any thoughts of whether this would be helpful for you as a seller or for you
as a buyer?
|
|
|
|
| | | | | |
| | | | | Author: | Admin_Russell | | Posted: | Jan 2, 2020 11:02 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 83 times | | Topic: | Suggestions | |
|
|
BrickLink
ID CardAdmin_Russell
|
Location:  USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
 |
Admin |
|
|
| BrickLink Administrator |
|
| My idea is a bit different. I feel that the marketplace needs to be unified,
and that standards should be set to gain maximum listing strength with the fewest
possible entries, while still providing enough entries for important variants.
In order to bring everyone together, we need to do some housecleaning and eliminate
some variants that don't really need to be distinguished by the majority
of buyers and sellers. At the same time, we need to start enforcing listing rules
more stringently, and give a fixed, reasonable length of time for sellers to
deal with undetermined entries in their stores, instead of waiting until all
items have sold out. Keep in mind that not all undetermined entries involve variants.
I do believe there can be a middle ground on some variants, where sellers have
a choice to be general or be specific, but this would be better implemented with
a checkbox system, where sellers would check the variant they have confirmed
(or not check any variant) and then buyers who want a specific variant can easily
search for them. This could replace many of the notes that are currently written
in listings.
But compare these three entries:
For the sake of the marketplace, these entries SHOULD NOT be confused by sellers,
and every seller should sort their parts accordingly. It is a foolish thing to
give an option to uneducated buyers to buy either 3001old or 3001special when
they are looking for the modern 3001.
The issue of variants has been hashed out many times in the Forum, and I would
suggest you go back and read some of those threads, so that you will see that
not all variants are of equal significance. BrickLink's great strength is
selling brand new parts, and it's important that when someone comes here
for replacements, they are directed to the newest, latest mold variant of a given
part.
In Suggestions, hpoort writes:
| | With the takeover by TLG, it may be time that some fundamental changes to the
site get implemented. Hence the posting of this idea - that has been bothering
me for years.
— requires programming and website extension —
Currently in the Bricklink catalog are parts that signify ‘undetermined variant’,
commonly marked for deletion or already deleted, and corresponding parts that
represent the specific variants of these. The current system requires sellers
to determine the specific variant type – even if they would prefer not to distinguish.
The same system requires buyers to exactly specify which variant they are interested
in buying – even if they don’t actually care which is commonly true. My suggestion
would be to distinguish the two concepts as are the processes: the process of
specifying what is for sale (which may be undetermined) and the process of specifying
what you want to buy (which may be ‘don’t care’). Both processes are already
separate on Bricklink (store inventory and wanted lists), but the concept of
‘undetermined’ is not.
For the catalog policy
• Keep all undetermined variants in the catalog and even add undetermined
variants for those parts that are similar. This information may be extracted
from the relation type ‘part is similar to’.
• Drop the deletion marks for all the undetermined entries and solely use
this marking for wrong or outdated entries.
For sellers
For sellers to don’t want to distinguish between part variants: list these parts
under the undetermined entry only. The BL system should be modified to show these
entries amidst the specific variants for any non specific search as through wanted
lists.
For buyers
For buyers it should be possible to specify an undetermined variety or in
effect a search pattern instead of a single part number. If a buyer does not
care whether a p=4085 is of type a, b, c or d, the buyer should be able to add
p=4085* to his wanted list and the search engine should have no trouble in matching
4085a, 4085b or 4085d with this. Similarly to the 0 color (labeled N/A or Not
Appicable while in this context it actually means Irrelevant).
Buyers should be assisted by the website to specify a specific variant if applicable,
but default to the don’t care form.
For the Bricklink website
• Add a feature to the ‘Add to Wanted List’ and ‘Edit Wanted List’ forms
to allow adding of (a) this specific variant only or (b) include variants. Then
populate the wanted list with the appropriate search pattern instead of the single
part number. This would take the form of either a complete enumeration of all
varieties like ‘4085|4085a|4085b|4085c|4085d’ (plate 1x1 with clip) or the more
general entry of ‘4085*’ or ‘4085@’; I would think the enumeration is more robust,
as it would also allow ‘3794|3794a|3794b|15573’ (jumper 1x2) and would also
allow manual exclusion of one or more variants.
• Adjust the ‘Items for sale’ pages or page fragments that show all matching
parts to include all variants when searching for the don’t care variety.
For the Bricklink database
• Widen the field WantedListItems.ItemNumber to allow for longer patterns.
100 chars would be enough for most enumerations of varieties I can think of.
For the Bricklink search engine
• For matching wanted lists with store items: presume that wanted list entries
may contain a search pattern instead of a single entry. Change the SQL from ‘=’
to ‘LIKE’ wherever necessary or drop the quotes around the field. (But make sure
no malicious code may be entered through this field).
Extra
• A similar feature might be implemented to search for approximate colors
such as ‘any gray’ or ‘any green’, similar to how Studio groups the colors.
Any thoughts of whether this would be helpful for you as a seller or for you
as a buyer?
|
|
|
|
| | | | | | | | | |
| | | | | | | Author: | Teup | | Posted: | Jan 2, 2020 11:14 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 42 times | | Topic: | Suggestions | |
|
| In Suggestions, Admin_Russell writes:
| | At the same time, we need to start enforcing listing rules
more stringently, and give a fixed, reasonable length of time for sellers to
deal with undetermined entries in their stores, instead of waiting until all
items have sold out.
|
I think that is only fair if Bricklink also improves the system. Because right
now it has turned a lot of parts that I had in fact determined, into undetermined
parts (thinking of jumper plates now). When a new variant is introduced after
something was listed, then logically the listing is the old variant and does
not need to be undetermined. At the very least I'd like to receive a message
when a new variant is added and a confirmation option to mark my existing stock
as the old variant. Because right now things become undetermined without me know
it, then they are ordered, a random variant gets picked, and the result is inconsistent
inventory that needs to be recounted. That's a bit off putting.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | Admin_Russell | | Posted: | Jan 2, 2020 11:47 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 62 times | | Topic: | Suggestions | |
|
|
BrickLink
ID CardAdmin_Russell
|
| Location: USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
|
Admin |
|
|
| BrickLink Administrator |
|
| In Suggestions, Teup writes:
| | In Suggestions, Admin_Russell writes:
| | At the same time, we need to start enforcing listing rules
more stringently, and give a fixed, reasonable length of time for sellers to
deal with undetermined entries in their stores, instead of waiting until all
items have sold out.
|
I think that is only fair if Bricklink also improves the system. Because right
now it has turned a lot of parts that I had in fact determined, into undetermined
parts (thinking of jumper plates now). When a new variant is introduced after
something was listed, then logically the listing is the old variant and does
not need to be undetermined. At the very least I'd like to receive a message
when a new variant is added and a confirmation option to mark my existing stock
as the old variant. Because right now things become undetermined without me know
it, then they are ordered, a random variant gets picked, and the result is inconsistent
inventory that needs to be recounted. That's a bit off putting.
|
I agree, we need to do a better job of communicating with our sellers. Perhaps
we could have sellers sign up to be notified when a variant relationship is added
to a part they have in stock.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | axaday | | Posted: | Jan 2, 2020 13:57 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 67 times | | Topic: | Suggestions | |
|
| In Suggestions, Teup writes:
| | When a new variant is introduced after
something was listed, then logically the listing is the old variant and does
not need to be undetermined.
|
That's actually not logical. Sometimes it is a while before a variant is
recognized. It is not at all uncommon for it to go unnoticed for 6 months by
which time a lot of people have the new one for sale, listed as the old one.
I added to the catalog when someone on the forum reported that there
was a new variant. I happened to have it and got a quick picture. This happened
Sept 23, 2019. Last year's advent calenders brought the attention to it.
But it has now been found in 7 sets from 2018. You had over a year to part
out one of those sets and have a listing that claimed to be the old variant and
was actually the new variant.
Many more stark examples can be found among the Clikits. Little attention has
usually be given to them. [p=clikits004a] and [p=clikits004b] masqueraded as
the same part for ELEVEN YEARS before Woutr noticed they were distinct and there
are a dozen other Clikits pieces with the same situation. Now the listings are
littered with the undetermined piece and there is no way for the Bricklink computers
to determine which is which. It's pretty easy to do in person once you learn
what you are looking for, but you have to actually have the pieces in your hand.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Teup | | Posted: | Jan 2, 2020 17:14 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 48 times | | Topic: | Suggestions | |
|
| In Suggestions, axaday writes:
| | In Suggestions, Teup writes:
| | When a new variant is introduced after
something was listed, then logically the listing is the old variant and does
not need to be undetermined.
|
That's actually not logical. Sometimes it is a while before a variant is
recognized. It is not at all uncommon for it to go unnoticed for 6 months by
which time a lot of people have the new one for sale, listed as the old one.
I added to the catalog when someone on the forum reported that there
was a new variant. I happened to have it and got a quick picture. This happened
Sept 23, 2019. Last year's advent calenders brought the attention to it.
But it has now been found in 7 sets from 2018. You had over a year to part
out one of those sets and have a listing that claimed to be the old variant and
was actually the new variant.
Many more stark examples can be found among the Clikits. Little attention has
usually be given to them. [p=clikits004a] and [p=clikits004b] masqueraded as
the same part for ELEVEN YEARS before Woutr noticed they were distinct and there
are a dozen other Clikits pieces with the same situation. Now the listings are
littered with the undetermined piece and there is no way for the Bricklink computers
to determine which is which. It's pretty easy to do in person once you learn
what you are looking for, but you have to actually have the pieces in your hand.
|
True, and I wasn't saying that it could account for *all* listings. But it
would already help a great deal if the items that are certainly not of the newer
type, weren't turned into undetermined. Even in your 11 year example, they
could still leave listings that are older than 11 years (and not added to in
the meantime). Maybe not so many listings left that qualify in such an extreme
case, but still, all bits help.
I think for most items we have a pretty good grasp on what year they were released.
If I recall right, several lots in my inventory have turned "undetermined" that
hadn't been created or added to for quite some time, and there was no reason
to make them undetermined because of a much more recent type.
Anyway you're right it's not a *solution*... just something that'd
help. Along with clear communication about new types to sellers that have them
listed when a new one is discovered, and simple interface options to manage types.
I think type listing deserves some attention for improvement, as many problems
buyers run into with sellers have to do with type errors.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | axaday | | Posted: | Jan 2, 2020 20:53 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 44 times | | Topic: | Suggestions | |
|
| It would definitely be nice if the system automatically notified you. But in
trying to clean up the Clikits listings I have often directly asked people to
check their undetermined pieces so the undetermined listings can be deleted.
The result has now and then been that they do it. Mostly it is ignored. Some
people will actually have a back and forth a few messages and then not do it.
One person just told me that I am not an admin and I can't make them. It
is hard for me to understand. It's really easy to fix once someone has pointed
it out.
So I like what Russell said about a time limit and when it is backed by real
authority instead of someone just trying to work things out. When you just get
told that you have this long to fix it or your listing will just evaporate, I
think people will take the couple of minutes to fix it.
In Suggestions, Teup writes:
| | In Suggestions, axaday writes:
| | In Suggestions, Teup writes:
| | When a new variant is introduced after
something was listed, then logically the listing is the old variant and does
not need to be undetermined.
|
That's actually not logical. Sometimes it is a while before a variant is
recognized. It is not at all uncommon for it to go unnoticed for 6 months by
which time a lot of people have the new one for sale, listed as the old one.
I added to the catalog when someone on the forum reported that there
was a new variant. I happened to have it and got a quick picture. This happened
Sept 23, 2019. Last year's advent calenders brought the attention to it.
But it has now been found in 7 sets from 2018. You had over a year to part
out one of those sets and have a listing that claimed to be the old variant and
was actually the new variant.
Many more stark examples can be found among the Clikits. Little attention has
usually be given to them. [p=clikits004a] and [p=clikits004b] masqueraded as
the same part for ELEVEN YEARS before Woutr noticed they were distinct and there
are a dozen other Clikits pieces with the same situation. Now the listings are
littered with the undetermined piece and there is no way for the Bricklink computers
to determine which is which. It's pretty easy to do in person once you learn
what you are looking for, but you have to actually have the pieces in your hand.
|
True, and I wasn't saying that it could account for *all* listings. But it
would already help a great deal if the items that are certainly not of the newer
type, weren't turned into undetermined. Even in your 11 year example, they
could still leave listings that are older than 11 years (and not added to in
the meantime). Maybe not so many listings left that qualify in such an extreme
case, but still, all bits help.
I think for most items we have a pretty good grasp on what year they were released.
If I recall right, several lots in my inventory have turned "undetermined" that
hadn't been created or added to for quite some time, and there was no reason
to make them undetermined because of a much more recent type.
Anyway you're right it's not a *solution*... just something that'd
help. Along with clear communication about new types to sellers that have them
listed when a new one is discovered, and simple interface options to manage types.
I think type listing deserves some attention for improvement, as many problems
buyers run into with sellers have to do with type errors.
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | Teup | | Posted: | Jan 3, 2020 03:43 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 68 times | | Topic: | Suggestions | |
|
| In Suggestions, axaday writes:
| | When you just get
told that you have this long to fix it or your listing will just evaporate, I
|
Listings evaporating would be totally unacceptable though, and would finally
cause the people who are accusing BL of inventory gremlins to be right. If such
a system was implemented it would cause me to write software to evade it. Because
to me, if there is one thing that's unacceptable about selling, it's
parts physically taking up space in my home that are dead weight and I will never
discover it. It's a number that can only grow over time, unless I would count
all of my million parts which - call me lazy - I won't do 
Much better to simply make (older) "undetermined" parts not appear in the list
when browsing a store's items. Or undetermined items forced into stockroom
(with clear notification). The seller's inventory management should always
be 100% accurate and not suffer from a pressure means to improve listings. That's
a very principal thing to me, and for some sellers there's even a tax report
aspect here.
But yes, I understand your sentiment, and it shouldn't be too difficult for
Bricklink to focus the incentive on "buyability" and not on messing up administration.
| |
In Suggestions, Teup writes:
| | In Suggestions, axaday writes:
| | In Suggestions, Teup writes:
| | When a new variant is introduced after
something was listed, then logically the listing is the old variant and does
not need to be undetermined.
|
That's actually not logical. Sometimes it is a while before a variant is
recognized. It is not at all uncommon for it to go unnoticed for 6 months by
which time a lot of people have the new one for sale, listed as the old one.
I added to the catalog when someone on the forum reported that there
was a new variant. I happened to have it and got a quick picture. This happened
Sept 23, 2019. Last year's advent calenders brought the attention to it.
But it has now been found in 7 sets from 2018. You had over a year to part
out one of those sets and have a listing that claimed to be the old variant and
was actually the new variant.
Many more stark examples can be found among the Clikits. Little attention has
usually be given to them. [p=clikits004a] and [p=clikits004b] masqueraded as
the same part for ELEVEN YEARS before Woutr noticed they were distinct and there
are a dozen other Clikits pieces with the same situation. Now the listings are
littered with the undetermined piece and there is no way for the Bricklink computers
to determine which is which. It's pretty easy to do in person once you learn
what you are looking for, but you have to actually have the pieces in your hand.
|
True, and I wasn't saying that it could account for *all* listings. But it
would already help a great deal if the items that are certainly not of the newer
type, weren't turned into undetermined. Even in your 11 year example, they
could still leave listings that are older than 11 years (and not added to in
the meantime). Maybe not so many listings left that qualify in such an extreme
case, but still, all bits help.
I think for most items we have a pretty good grasp on what year they were released.
If I recall right, several lots in my inventory have turned "undetermined" that
hadn't been created or added to for quite some time, and there was no reason
to make them undetermined because of a much more recent type.
Anyway you're right it's not a *solution*... just something that'd
help. Along with clear communication about new types to sellers that have them
listed when a new one is discovered, and simple interface options to manage types.
I think type listing deserves some attention for improvement, as many problems
buyers run into with sellers have to do with type errors.
|
|
|
|
|
| | | | | | | | | |
| | | | | | | Author: | StormChaser | | Posted: | Jan 2, 2020 11:44 | | Subject: | Re: Part Variants | | Viewed: | 43 times | | Topic: | Suggestions | |
|
| In Suggestions, Admin_Russell writes:
Could you explain this term in more detail? I'm genuinely not sure what
it means. I've gone back through and reread all the forum posts where it
is used and I'm still not sure of the definition.
| | the fewest possible entries
|
| | eliminate some variants that don't really need to be distinguished by the majority
of buyers and sellers.
|
Fair enough. I always thought there must be some way to structure the catalog/site
so that all variants could be distinguished without affecting commercial interests.
I still feel like that would be the best possible outcome. It would allow the
site to serve all users equally.
But I understand that some variants really are unimportant and I see the chaos
that variants have on inventories. And I haven't heard anyone propose a
solution that would work well. I'm not sure that one exists.
But if we are going to make a distinction (and the site already does) between
important and unimportant variants, it would probably be helpful to clearly define
that distinction in writing so that everyone knows where the line is drawn.
| | give a fixed, reasonable length of time for sellers to
deal with undetermined entries in their stores, instead of waiting until all
items have sold out.
|
Yeah, maintaining hundreds of Marked for Deletion items for years is not the
best policy.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | Admin_Russell | | Posted: | Jan 2, 2020 12:09 | | Subject: | Re: Part Variants | | Viewed: | 91 times | | Topic: | Suggestions | |
|
|
BrickLink
ID CardAdmin_Russell
|
| Location: USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
|
Admin |
|
|
| BrickLink Administrator |
|
| In Suggestions, StormChaser writes:
| | In Suggestions, Admin_Russell writes:
Could you explain this term in more detail? I'm genuinely not sure what
it means. I've gone back through and reread all the forum posts where it
is used and I'm still not sure of the definition.
|
If an entry with 400 lots is split into two entries, you may see 250 listings
go to one variant and 300 go to another. That would mean that effectively 150
of those lots were also split.
What this means for the buyer is that they now only have 250 or 300 lots to
choose from, not 400. This may not seem like a big deal, but when you narrow
their options down to domestic shipping, and add the complexity of finding a
few dozen other parts from their wanted list in the same store, it becomes a
significant issue, and it could cost them more in shipping charges and higher
part prices.
Looking at it another way, if you have 5000 parts listed in various lots under
an entry, and the entry is split, 2000 may go to one variant and 3000 would then
go to the other.
And in both these examples, if there is an undetermined entry that needs to be
retired, that splits things in three ways instead of two, at least for a year
or so.
Listing strength is one of the advantages that BrickLink has over its competition.
If you look at any given part, there is a greater quantity available from more
sources than on any other site.
Of course, listing strength isn't a big deal if you are only out to buy one
or two parts. But for most of our users, getting the most parts from the fewest
number of sources is likely one of the biggest challenges they face when dealing
with the constraints of thier building budget.
| | | | the fewest possible entries
|
| | eliminate some variants that don't really need to be distinguished by the majority
of buyers and sellers.
|
Fair enough. I always thought there must be some way to structure the catalog/site
so that all variants could be distinguished without affecting commercial interests.
I still feel like that would be the best possible outcome. It would allow the
site to serve all users equally.
But I understand that some variants really are unimportant and I see the chaos
that variants have on inventories. And I haven't heard anyone propose a
solution that would work well. I'm not sure that one exists.
But if we are going to make a distinction (and the site already does) between
important and unimportant variants, it would probably be helpful to clearly define
that distinction in writing so that everyone knows where the line is drawn.
|
Absolutely. Nothing like this will be done behind closed doors.
| | | | give a fixed, reasonable length of time for sellers to
deal with undetermined entries in their stores, instead of waiting until all
items have sold out.
|
Yeah, maintaining hundreds of Marked for Deletion items for years is not the
best policy.
|
Leniency on sellers in this respect was done to appease folks who thought the
catalog was going too far in the direction of the collectors and specialists.
But I really do believe if we can come to a compromise on this issue, sellers
will gladly relinquish their grip on those old entries.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | hpoort | | Posted: | Jan 2, 2020 13:20 | | Subject: | Re: Part Variants | | Viewed: | 50 times | | Topic: | Suggestions | |
|
| In Suggestions, Admin_Russell writes:
| | In Suggestions, StormChaser writes:
| | In Suggestions, Admin_Russell writes:
Could you explain this term in more detail? I'm genuinely not sure what
it means. I've gone back through and reread all the forum posts where it
is used and I'm still not sure of the definition.
|
If an entry with 400 lots is split into two entries, you may see 250 listings
go to one variant and 300 go to another. That would mean that effectively 150
of those lots were also split.
|
Russell,
Since my suggestion was not about splitting, but about unifying the search methods
instead, I am not sure that you have completely understood the implications of
my suggestion. What I am suggesting would allow both sellers not to distinguish
their listings if they don't want to (and some already don't), and buyers
to get what they want without having to distinguish their searches (most new
buyers already don't).
| | [...]
Listing strength is one of the advantages that BrickLink has over its competition.
If you look at any given part, there is a greater quantity available from more
sources than on any other site.
|
With an extended wanted list feature, you would increase the number of lots that
can be found, not decrease.
Hans-Peter
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | 62Bricks | | Posted: | Jan 2, 2020 18:17 | | Subject: | Re: Part Variants | | Viewed: | 47 times | | Topic: | Suggestions | |
|
| In Suggestions, Admin_Russell writes:
| | In Suggestions, StormChaser writes:
| | In Suggestions, Admin_Russell writes:
Could you explain this term in more detail? I'm genuinely not sure what
it means. I've gone back through and reread all the forum posts where it
is used and I'm still not sure of the definition.
|
If an entry with 400 lots is split into two entries, you may see 250 listings
go to one variant and 300 go to another. That would mean that effectively 150
of those lots were also split.
What this means for the buyer is that they now only have 250 or 300 lots to
choose from, not 400. This may not seem like a big deal, but when you narrow
their options down to domestic shipping, and add the complexity of finding a
few dozen other parts from their wanted list in the same store, it becomes a
significant issue, and it could cost them more in shipping charges and higher
part prices.
Looking at it another way, if you have 5000 parts listed in various lots under
an entry, and the entry is split, 2000 may go to one variant and 3000 would then
go to the other.
And in both these examples, if there is an undetermined entry that needs to be
retired, that splits things in three ways instead of two, at least for a year
or so.
Listing strength is one of the advantages that BrickLink has over its competition.
If you look at any given part, there is a greater quantity available from more
sources than on any other site.
Of course, listing strength isn't a big deal if you are only out to buy one
or two parts. But for most of our users, getting the most parts from the fewest
number of sources is likely one of the biggest challenges they face when dealing
with the constraints of thier building budget.
| | | | the fewest possible entries
|
| | eliminate some variants that don't really need to be distinguished by the majority
of buyers and sellers.
|
Fair enough. I always thought there must be some way to structure the catalog/site
so that all variants could be distinguished without affecting commercial interests.
I still feel like that would be the best possible outcome. It would allow the
site to serve all users equally.
But I understand that some variants really are unimportant and I see the chaos
that variants have on inventories. And I haven't heard anyone propose a
solution that would work well. I'm not sure that one exists.
But if we are going to make a distinction (and the site already does) between
important and unimportant variants, it would probably be helpful to clearly define
that distinction in writing so that everyone knows where the line is drawn.
|
Absolutely. Nothing like this will be done behind closed doors.
| | | | give a fixed, reasonable length of time for sellers to
deal with undetermined entries in their stores, instead of waiting until all
items have sold out.
|
Yeah, maintaining hundreds of Marked for Deletion items for years is not the
best policy.
|
Leniency on sellers in this respect was done to appease folks who thought the
catalog was going too far in the direction of the collectors and specialists.
But I really do believe if we can come to a compromise on this issue, sellers
will gladly relinquish their grip on those old entries.
|
For variants that share a part number and are distinguished by a suffix, it would
be possible to add a "pseudo" entry on the parts browsing page that would lead
to search results for all variants. For example, on this page:
https://www.bricklink.com/browseList.asp?itemType=P&catString=27
could be an entry for, say, "Plate, Modified 1 x 1 with Clip Vertical - All variants"
with a list of colors like the other entries. The links would lead to a wildcard
search for that part number in that color, as in:
https://www.bricklink.com/search.asp?viewFrom=sa&itemBrand=1000&colorID=9&q=4085%2A&searchSort=P&sz=25
Additionally, it would be a matter of a few minutes to add a checkbox to the
item search page at https://www.bricklink.com/searchAdvanced.asp?utm_content=subnav
that said "Show all variants" and that would append the * wildcard to the part
number entered.
These are things that could be done now, with no underlying changes to the catalog
or functionality. They would allow buyers to see all the variations in one set
of results.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | bagelboybugle | | Posted: | Jan 2, 2020 12:45 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 37 times | | Topic: | Suggestions | |
|
| In Suggestions, Admin_Russell writes:
| | My idea is a bit different. I feel that the marketplace needs to be unified,
and that standards should be set to gain maximum listing strength with the fewest
possible entries, while still providing enough entries for important variants.
|
Commercially yes, but BL's core appeal is the depth of its catalog.
I have always believed that scrapping undetermined was a bad idea. My argument
links very directly to set inventory - typically, when a part is changed (e.g.
a lip added to reduce the amount of plastic used to make a part) we may be able
to identify through inventory change requests which sets those parts were first
and last seen in, all the sets in between, because of how the parts mix at the
factory or old molds still may be in use, we literally cannot determine which
variant should be in a set. Thus, taking away undetermined made the BL catalog
less accurate.
The insistance by the catalog admins of removing all the undetermined entries,
especially for parts worth only a couple of pence, made it difficult for me as
a seller to offer those parts, it was simply too inefficient to invest the extra
30 minutes on a part out to individually check 1p parts for minor variances.
This played a big factor in my decision to wind up my store as a business and
only sell items that are excess from my own collection.
Perhaps a good way is to use a single entry, which is by default `undetermined`
for buyers and sellers alike who only wish to deal in one entry with variants
identified through a check box or drop down menu (3001old etc), the part out
and wanted screens wouldnt need to look too much different, undetermined options
could select as default, its then easy to select the correct/preferred varient.
It would be valuable if the price guide was also seperatable by the same parameters,
so that those who do choose to sell or buy a specific variant can search appropriately
|
|
|
| | | | | | | | | |
| | | | | | | Author: | dearlydeparted | | Posted: | Jan 2, 2020 15:37 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 59 times | | Topic: | Suggestions | |
|
| Catalogue Variants: One of the most frustrating moments and arguments happened
years ago concerning part 4070 and the addition of 4070a. Many argued it was
the same part but had the slot due to the mold or level of plastic fill - others
said it was a separate mold. I spent days looking through all my 4070's and
separating into 4070a - almost going blind. Then, if I remember correctly, the
4070a was abandoned and all parts had to be compiled again. What a waste in effort
and time - I never separated them out again when the variant reappeared. Does
anyone remember this? Can we avoid such waffling in the future P-L-E-A-S-E!
|
|
| | | | | | |
| | | | | Author: | mfav | | Posted: | Jan 2, 2020 11:47 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 50 times | | Topic: | Suggestions | |
|
| While I champion the desired functionality change, I question the means to get
there.
The underlying catalog database needs to be reenvisioned from the ground up to
effect the type of change you suggest.
You've cherry picked one example out of hundreds where there is some underlying
catalog issue, so this is a piecemeal approach to a problem. The "solution" to
this one particular problem most likely will not be the same "solution" required
for some other element.
The database likely needs to be reconsidered to have these at least fields, probably
more:
- a part number ( e.g., 4085 )
- a mold variant value ( I'd guess three digits would do it...1000 variants
ought to handle it for our lifetime)
- a decoration value ( 7 digits would give 10 million possibilities)
This scheme would allow for
- 4085, 4085.1, 4085.2, etc.
- 973.1.0000001, 973.2.0000001, etc.
You could then WantList 4085 and have stores return 4085, 4085.1, 4085.2, 4085.3,
4085.4
or
Wantlist 4085.2 and have stores return 4085.2
...this is as opposed to...
The idea of a single field with 100 characters. It is too complicated and
too restrictive. This is the same problem we now have with the name/description
field. It is too short and populated too inconsistently for it to be useful.
You fail to present the interface side of the issue. At one extreme you have
grandma who wants to get grandchild a replacement piece to hold an antenna...and
she doesn't understand lego, and she doesn't understand variants, and
she can barely manage to navigate a web site to begin with. On the other extreme
you have the uberAFOLs who want to get extremely granular with the specifics.
The user interface for grandma is going to need to be decidedly different than
the interface for uberAFOLer. Grandma needs a drill-down; UberAFOLer wants a
dense form.
There are already too many "undocumented tricks" required to use the site search
as is. Needing to know to append an asterisk to the end of a search string to
return the variants is number one. Having to put quotes around search strings
is number two.
| | | | For matching wanted lists with store items: presume that wanted
list entries may contain a search pattern instead of a single
entry. Change the SQL from ‘=’ to ‘LIKE’ wherever necessary
or drop the quotes around the field. (But make sure
no malicious code may be entered through this field).
|
|
Statements like this...d'oh! Have a search field that's entirely open
for somebody to put whatever they want into it and at the same time don't
let them put anything bad into it. That's just way too broad an expectation
and impossible to code. With open search fields you have the problems of matching
strings, misspellings, punctuation, the frikkin' ampersand, and on and on.
Open search fields are, generally speaking, just plain bad.
The better solution is to make a search page with a series of checkboxes and/or
popups where you pick what you want from a fixed list. Potentially allow for
an open search box or boxes, but restrict a single search box to a specific
field within the database. Allow the user to also specify the boolean...whether
something equals (LIKE) or contains (LIKE%...%) a value or values.
Then there's the whole issue of having to explain to the user how to use
the search function or make sure it's simple and obvious how to use it...which
the current search function is definitely not.
All the elements of the database structure, data, forms (UI/UX), and programming
need to work in concert. You've addressed parts of some of these and none
of others.
Would your proposed change be helpful? Probably. But it's moot...at least
short term...because it can't be implemented in a useful way without a very
large amount of work. You have something here in embryo that's good/it's
not fully developed yet.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | manganschlamm | | Posted: | Jan 2, 2020 12:25 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 36 times | | Topic: | Suggestions | |
|
| In Suggestions, mfav writes:
| | While I champion the desired functionality change, I question the means to get
there.
The underlying catalog database needs to be reenvisioned from the ground up to
effect the type of change you suggest.
You've cherry picked one example out of hundreds where there is some underlying
catalog issue, so this is a piecemeal approach to a problem. The "solution" to
this one particular problem most likely will not be the same "solution" required
for some other element.
The database likely needs to be reconsidered to have these at least fields, probably
more:
- a part number ( e.g., 4085 )
- a mold variant value ( I'd guess three digits would do it...1000 variants
ought to handle it for our lifetime)
- a decoration value ( 7 digits would give 10 million possibilities)
This scheme would allow for
- 4085, 4085.1, 4085.2, etc.
- 973.1.0000001, 973.2.0000001, etc.
You could then WantList 4085 and have stores return 4085, 4085.1, 4085.2, 4085.3,
4085.4
or
Wantlist 4085.2 and have stores return 4085.2
...this is as opposed to...
The idea of a single field with 100 characters. It is too complicated and
too restrictive. This is the same problem we now have with the name/description
field. It is too short and populated too inconsistently for it to be useful.
You fail to present the interface side of the issue. At one extreme you have
grandma who wants to get grandchild a replacement piece to hold an antenna...and
she doesn't understand lego, and she doesn't understand variants, and
she can barely manage to navigate a web site to begin with. On the other extreme
you have the uberAFOLs who want to get extremely granular with the specifics.
The user interface for grandma is going to need to be decidedly different than
the interface for uberAFOLer. Grandma needs a drill-down; UberAFOLer wants a
dense form.
There are already too many "undocumented tricks" required to use the site search
as is. Needing to know to append an asterisk to the end of a search string to
return the variants is number one. Having to put quotes around search strings
is number two.
| | | | For matching wanted lists with store items: presume that wanted
list entries may contain a search pattern instead of a single
entry. Change the SQL from ‘=’ to ‘LIKE’ wherever necessary
or drop the quotes around the field. (But make sure
no malicious code may be entered through this field).
|
|
Statements like this...d'oh! Have a search field that's entirely open
for somebody to put whatever they want into it and at the same time don't
let them put anything bad into it. That's just way too broad an expectation
and impossible to code. With open search fields you have the problems of matching
strings, misspellings, punctuation, the frikkin' ampersand, and on and on.
Open search fields are, generally speaking, just plain bad.
The better solution is to make a search page with a series of checkboxes and/or
popups where you pick what you want from a fixed list. Potentially allow for
an open search box or boxes, but restrict a single search box to a specific
field within the database. Allow the user to also specify the boolean...whether
something equals (LIKE) or contains (LIKE%...%) a value or values.
Then there's the whole issue of having to explain to the user how to use
the search function or make sure it's simple and obvious how to use it...which
the current search function is definitely not.
All the elements of the database structure, data, forms (UI/UX), and programming
need to work in concert. You've addressed parts of some of these and none
of others.
Would your proposed change be helpful? Probably. But it's moot...at least
short term...because it can't be implemented in a useful way without a very
large amount of work. You have something here in embryo that's good/it's
not fully developed yet.
|
This all boils down to one important question: Will TLG as the new owner put
more resources into this site (i.e. more people)?
|
|
|
| | | | | | | | | |
| | | | | | | Author: | hpoort | | Posted: | Jan 2, 2020 13:43 | | Subject: | Re: Policy change - Undetermined versus Unknown a | | Viewed: | 33 times | | Topic: | Suggestions | |
|
| In Suggestions, mfav writes:
| | [...]
You fail to present the interface side of the issue. At one extreme you have
grandma who wants to get grandchild a replacement piece to hold an antenna...and
she doesn't understand lego, and she doesn't understand variants, and
she can barely manage to navigate a web site to begin with. On the other extreme
you have the uberAFOLs who want to get extremely granular with the specifics.
The user interface for grandma is going to need to be decidedly different than
the interface for uberAFOLer. Grandma needs a drill-down; UberAFOLer wants a
dense form.
|
True, although I envisioned the interface side it in my mind, I did not present
the interface side. My idea is to simplify the interface for the grandma that
does not know nor care about variants, while still allowing the uberAFOLer to
specify a particular variant. This should indeed not be done by a new trick,
simply by the webform having a checkbox and/or dropdown showing the available
variants if any.
| |
| | | | For matching wanted lists with store items: presume that wanted
list entries may contain a search pattern instead of a single
entry. Change the SQL from ‘=’ to ‘LIKE’ wherever necessary
or drop the quotes around the field. (But make sure
no malicious code may be entered through this field).
|
|
Statements like this...d'oh! Have a search field that's entirely open
for somebody to put whatever they want into it and at the same time don't
let them put anything bad into it. That's just way too broad an expectation
and impossible to code. With open search fields you have the problems of matching
strings, misspellings, punctuation, the frikkin' ampersand, and on and on.
Open search fields are, generally speaking, just plain bad.
|
True again. Maybe no user entry then. It is just an implementation suggestion
that would allow the programming to be limited to one line of code.
| |
The better solution is to make a search page with a series of checkboxes and/or
popups where you pick what you want from a fixed list. Potentially allow for
an open search box or boxes, but restrict a single search box to a specific
field within the database. Allow the user to also specify the boolean...whether
something equals (LIKE) or contains (LIKE%...%) a value or values.
Then there's the whole issue of having to explain to the user how to use
the search function or make sure it's simple and obvious how to use it...which
the current search function is definitely not.
|
Agreed; the search function should be more obvious.
| |
All the elements of the database structure, data, forms (UI/UX), and programming
need to work in concert. You've addressed parts of some of these and none
of others.
Would your proposed change be helpful? Probably. But it's moot...at least
short term...because it can't be implemented in a useful way without a very
large amount of work. You have something here in embryo that's good/it's
not fully developed yet.
|
Thanks for your support.
|
|
|
|
|
|
Netherlands, Groningen
France, Nouvelle-Aquitaine
United Kingdom, England
Germany, Nordrhein-Westfalen