BrickLink Discussion Forum

In Suggestions, dearlydeparted writes:

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!

Truth be told, 4070 was never "the part without the slot". You should have just
left them unsorted. 4070a was created so that if people wanted to trade the version
with slot, they could do so. But 4070b was never created.

However, that is actually a perfect example of a variant entry that needed to
go away. I agree - a huge waste of time for everyone.

Author:

dearlydeparted

Posted:

Jan 2, 2020 15:37

Subject:

Re: Policy change - Undetermined versus Unknown a

Viewed:

59 times

Topic:

Author:

axaday

Posted:

Jan 2, 2020 13:57

Subject:

Re: Policy change - Undetermined versus Unknown a

Viewed:

67 times

Topic:

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

42876 Turkey Drumstick, 22mm with Oval Opening on Back
Parts: Food & Drink

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:

hpoort

Posted:

Jan 2, 2020 13:43

Subject:

Re: Policy change - Undetermined versus Unknown a

Viewed:

33 times

Topic:

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.

Author:

hpoort

Posted:

Jan 2, 2020 13:20

Subject:

Re: Part Variants

Viewed:

50 times

Topic: