Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies |
| Author: | mfav  | | Posted: | Mar 18, 2020 20:46 | | Subject: | Clips Ahoy, Part 2! Attention StormChaser | | Viewed: | 136 times | | Topic: | Catalog | | Status: | Open | |
|
| http://v4ei.com/brickref/clips-k-v.php
Some takeaway observations so far.
Catalog is inconsistent in how it treats variants.
- Sometimes there is one ID number for two different designs.
-- Sometimes these design differences are noted, other times not
- Sometimes there is one ID number plus a letter (1234a, 1234b, etc.) indicating
different designs
- Sometimes there is one ID number plus "alternate numbers" for a single design
-- Sometimes these alternate ID numbers are the same design
-- Sometimes these alternate ID numbers are a different design
I would suggest that 48729 and 48729b are functionally different designs.
I would suggest that 48729b is actually 41005, and 41005 is a later variant of
48729b.
21 unique clip shapes to this point.
Some clip shape differences are obvious and others are subtle. Many probably
can't be distinguished by most people, even upon close examination. Through
the process of photographing these elements, and bringing the actual 6mm size
up to somewhere around 180mm these differences become more apparent.
So the differences are now cataloged and you can deal with them or not as you
see fit.
There's probably another page or two to come, but this is pretty slow going.
|
|
|
| Author: | mfav | | Posted: | Mar 11, 2020 20:52 | | Subject: | StormChaser: the tale of two tails | | Viewed: | 230 times | | Topic: | Catalog | | Status: | Open | |
|
| This is sort of akin to Number Six on your roadmap. I think.
Is there a standardization scheme in the works for items like these shown, and
similar items, where the length exceeds the footprint of the attachment plate?
If you're going by the scheme used for 6239, then 2430 ought to be a 1x5.
If you're going by the scheme used for 2430, then 6239 ought to be a 2x3.
I know this is bound to have implications all over the catalog with many modified
bricks and plates and other things, especially when you get into SNOT pieces,
but there's inconsistency within and across categories now.
One would think the overall x-y-z dimensions of the piece would be considered
every time...
I know this is going to require some quiet contemplation followed by noisy debate,
but some semblance of consistency would be really nice to have.
|
|
|
| Author: | mfav | | Posted: | Feb 27, 2020 13:53 | | Subject: | Dimensions 10507 | | Viewed: | 136 times | | Topic: | Catalog | | Status: | Open | |
|
| Why is 10507 listed as 1x1 in studs?
10507 is
x: 7.9mm
y: 11.2mm
z: 11.1mm
making it 1 x 1.4 in studs.
Is this just another one of those places of inconsistency madness?
|
|
| Author: | mfav | | Posted: | Feb 25, 2020 21:45 | | Subject: | Yo StormBluser, for the roadmap? | | Viewed: | 173 times | | Topic: | Catalog | | Status: | Open | |
|
| http://v4ei.com/brickref/4265-variants-proposal.html
I know, there'll be pain with the renaming and whatnot, but it would be nice
if all the axle holes on all the pieces were named consistently and were referred
to in a consistent manner in the item number.
Then there's the issue of sometimes two things that are the similar have
two different catalog numbers and other times two things that are similar have
a single number and a note. So the whole handling of naming and suffixing is
kind of all over the place.
If that page isn't clear, hit me up.
|
|
| Author: | mfav | | Posted: | Feb 8, 2020 21:08 | | Subject: | Description standardization note | | Viewed: | 168 times | | Topic: | Catalog | | Status: | Open | |
|
| It would be good for consistency in the catalog description if all instances
of numbers were either integers or words, not arbitrarily some of each.
So:
Three eyeballs, Three earlobes
or
3 eyeballs, 3 earlobes
not
Three eyeballs, 3 earlobes
...that kind of thing.
There are pros and cons for each option. Please investigate how the search mechanism
works to see which option yields better results.
|
| Author: | mfav | | Posted: | Feb 3, 2020 15:26 | | Subject: | Nougats reference | | Viewed: | 179 times | | Topic: | Colors | | Status: | Open | |
|
| http://v4ei.com/brickref/
And. It's not funny.
|
| Author: | mfav | | Posted: | Aug 28, 2019 15:21 | | Subject: | Inviting trouble | | Viewed: | 222 times | | Topic: | Catalog | | Status: | Open | |
|
| http://v4ei.com/mini-fig-ure-outer/
I promise not to have a conniption if anyone takes the initiative.
|
|
| Author: | mfav | | Posted: | May 5, 2019 14:41 | | Subject: | That Randy Color | | Viewed: | 207 times | | Topic: | Suggestions | | Status: | Open | | Vote: | [Yes|No] | |
|
| I want to further the discussion at https://www.bricklink.com/message.asp?ID=1139677
but under an appropriate thread.
In regards to color.
The comments below go to the use of color labeling in the context of being functional
in regards to search. It is not in regards to color accuracy in terms of cataloging.
There is a schism between the two uses because there is only one available field
in the database to handle what are two distinctly different purposes.
At https://www.bricklink.com/message.asp?ID=1139699 you bring up the color guidelines.
I appreciate as one of the admins, you're attempting to follow the guidelines.
The guidelines however are in conflict with what an average person with no experience
with the guidelines would expect. They're even in conflict with what someone
with greater than average knowledge of the color labeling conventions on BL would
expect. I would reconsider those guidelines.
There are, by my count currently 170 different distinct colors that the system
knows. https://www.bricklink.com/catalogColors.asp
Assuming an ideal world where all of the decorations are accurately color-described
in the database per the guidelines, it's unreasonable to expect any average
person to be able to remember 170 different colors and to accurately identify
every instance of them. Colors shift over time due to aging and formulation.
Color perception changes relative to adjacent colors. Perceived color accuracy
is relative to the available reference photos or renders, the skill of the photographer
to capture the color, the ability of any individual piece of hardware or software
to properly interpret and render the color, lighting conditions, and other factors.
Color is a rainbow hell-hole.
Here is a test situation to illustrate my point. Take the torso in question in
the original thread and show it to 20 random people. Ask them what the colors
are. I'll wager you a cookie that if you ask 20 people who are not jenwick,
that exactly zero describe the blue as "medium azure." I'll wager you another
cookie that less than half describe the purple as "magenta."
With that in mind, somebody comes to the site and attempts to find something.
Somebody will use what they think the color is because that is their perception
of the color, not because they've reviewed the color chart in depth and have
spent time comparing many pieces to one another to grok the nuances and accurately
predict the exact hue necessary to achieve a match in search. What they'll
do is enter the color they think it is (blue) and do a search, and the search
results will be unsatisfactory, and they'll declare they can't find it
and post in the forum "what is this" or they'll search repeatedly and repeatedly
get unsatisfactory results, declare the site too complicated, and go away in
frustration. This frustration ends up being an indelible negative association
with BrickLink in that person's mind.
We've witnessed this scenario time and again here on the forum. We've
witnessed the endless debates over yellowed LBG vs LG, the confusion with pearl
gray and flat silver (two labels for one color), the confusion with pearl gold
(one label for two colors), people can't find pieces they're looking
for when they're looking right at them because the thumbnail color isn't
the same as the color they searched for, and more.
Having people "go away in frustration" is not in the best interest of BL as a
marketplace. Presumably the 10,000 plus shops here have invested some effort
in attempting to sell things. With that in mind, I argue that things which facilitate
sales should have precedent over "historical accuracy" when it comes to searching
the catalog. One needs to be able to find something before one can dig deep into
understanding it and its associated nuances...if one even needs or wants to understand
them.
We know a better solution to the issue would be a more robust database. As we've
been told repeatedly that isn't going to happen, you're left with a choice.
Either you populate the description field with user-friendliness or with historical
accuracy in mind (for user-friendliness, decoration colors in the item/description
would be their most generic counterparts: black, gray, silver, white, gold, red,
orange, yellow, green, blue, purple, brown, tan, chrome, copper, and speckle).
I would suggest the item field be populated with user-friendliness in mind and
that the note/comment field be generously populated with the historical accuracy
and other more esoteric information.
It's not an ideal solution, but it would work within the current operational
parameters of the database and site interface.
On contributions.
I went through a discussion with the Stormchaser about this at length. This isn't
going to improve until all the UI is improved. The forms are too convoluted and
not explained well and the explanations are hidden and it's just too much
work for anybody who isn't more than casually dedicated. All the instructions
for filling a form need to be adjacent to the fields on the form. The instructions
are buried elsewhere. If you start filling a form, then have to leave to find
instructions, the form is then blanked when you return, and that's an issue
and causes frustration. The UI can't improve much without programmer time.
The whole issue gained no traction while I was communicating with the Stormchaser.
I don't expect any improvement any time soon. Refer to second picture attached
after you finish reading this post.
In regards to the Stormchaser.
You'll forgive me if I read your statement about following in his footsteps
probably not the way you intended it. It's pretty clear that being a volunteer
admin at BrickLink is basically like being in the "zone" in Stalker https://www.imdb.com/title/tt0079944/
To really appreciate the statement, you'll have to experience the movie,
if you haven't already.
Stormchaser's footsteps promised much change, then he made like Mrs. Hogwallop.
https://www.youtube.com/watch?v=tsAZ0RweVxk So maybe don't follow those footsteps
too closely.
I had a number of communications with the Stormchaser both on- and off-line.
I'll suggest to you the same thing I did with him: read Steve Krug's
"Don't Make Me Think" https://www.amazon.com/Dont-Make-Think-Revisited-Usability/dp/0321965515/
This book has been revised a few times. I'm familiar with the second version,
but would expect the later versions to be effectively the same content probably
with more recent references. It's a quick read, and appropriate for non-technical
types. He said it helped him with how he thought about things he wanted to do.
So. Food for thought. And in closing, because you asked, a portrait of Randy
after reading this post.
|
|
|
| Author: | mfav | | Posted: | Mar 1, 2019 13:32 | | Subject: | 48729 variations (3 not 2) | | Viewed: | 65 times | | Topic: | Catalog | | Status: | Open | |
|
| | So, this. |
|
|
|
| Author: | mfav | | Posted: | Jan 7, 2019 20:04 | | Subject: | Catalog Guidelines: Minifig Heads | | Viewed: | 96 times | | Topic: | Catalog | | Status: | Open | |
|
| I would like to suggest the following catalog guidelines for minifig head part
3626.
issues
1. Need to distinguish between 1-sided print and 2-sided print
2. Need to distinguish between things with faces and things without faces.
- 2.1 Need to distinguish between things with 1 face and things with 2 faces.
3. Need to distinguish between things that are heads and things that are not
heads.
4. Want to note stud type.
5. Need to note identifying attributes.
methodology
1. Fixed values: 1-sided print, 2-sided print.
- Might consider another value (top-print) for things like Avatar heads which
are printed around the stud. Or maybe not necessary and could be noted in attributes.
Anyway, fixed values here to aid search.
2. Fixed values: single-faced, dual-faced, no-face.
3. Fixed values: head, pattern
- I expect some shrieking about the pattern attribute, but if all decorated pieces
are separated from plain pieces at the category level, the need for "pattern"
as an identifier becomes moot. Thus "pattern" can be used to distinguish between
a "head" and a "not-head".
4. Existing scheme (blocked open, hollow, solid) seems satisfactory
5. Attributes should be considered by their side count and face count and presented
consistently. For any single-sided piece a straight description is fine. For
faces, I'd recommend a top-down scheme for consistency: hair, eyebrows, eyes,
mouth, scars/marks, whiskers. For two-sided, single-faced heads I'd start
with the character name if it exists, followed by Front, followed by Back. For
two-faced heads I'd start with the character name if it exists, followed
by side1 attributes, separate with a slash, side2 attributes. Color values would
precede attributes in "readable English" fashion, thus "brown hair" and not "hair,
brown".
Complete naming convention would be sequenced as follows: Attributes, Sides,
Faces, Type, Stud. This sequencing allows for the unique traits to
appear first, which is likely preferable to having those listed last for a number
of reasons.
2-side, 1-face Example:
Green Goblin. Front: Balaclava, Heavy brown eyebrows, black eyes white highlight,
smirk, dimples, cleft chin. Back: three black scalloped lines blue highlight.
2-sided print, single-faced head, blocked open stud.
2-side, 2-face Example:
Robot. Silver eyebrows, Lime eyes white highlight, clenched teeth, scuffs, rivets
/ Silver eyebrows, lime eyes white highlight, closed mouth, scuffs, rivets. 2-sided
print, dual-faced head, hollow stud.
Note 1: I have a personal prejudice against labelling every head that is not
"human" as "alien". I'd prefer to see additional terms such as "robot" and
perhaps "animal" where appropriate; these terms would also facilitate search.
Note 2: It would facilitate consistent data entry to have a part-specific data
entry form available on the site. The form would include any fixed values as
popup or radio selectors, generous fields for entry of attributes, and an image
or images with callouts to provide visual assistance and reference for the contributor.
Guidelines for data entry should be included on the form itself and not require
leaving the form to locate guideline information elsewhere.
Visualization attached.
|
|
|
| Author: | mfav | | Posted: | Jan 4, 2019 11:26 | | Subject: | Admin Russell, WTH images 2 | | Viewed: | 221 times | | Topic: | Catalog | | Status: | Open | |
|
| Happy New Year.
This image discrepancy thing does appear throughout the catalog.
It looks like any time there was a condition where the large image contributor
and the small image contributor were not the same, the large image contributor's
large image has slotted into the small image contributor's small image gallery.
At least one of mine is in Randy's gallery, a number of other people's
images are in Jen's gallery...it goes on.
I have a suspicion there's some other related gremlin somewhere in the works,
but I can't fathom it other than to note that sometimes the large images
are also somehow awry.
Example:
https://www.bricklink.com/v2/catalog/catalogitem.page?id=66490#T=C&C=10
The dbg image accessed via the popup is mine, and credited to me.
The gray image accessed via the popup is NOT mine, and credited to me...or at
least appears to be...or cannot be determined.
Sometimes
https://www.bricklink.com/v2/catalog/catalogitem.page
(with no color specified for the part) on entering the page, the large image
space is empty, other times it's populated with (I guess) a default image.
https://www.bricklink.com/v2/catalog/catalogitem.page?P=41855#T=C
I see a default (medium blue?) image, and at the bottom of the page I get a credit
for a large image. The red image here is mine, this blue one is not.
https://www.bricklink.com/v2/catalog/catalogitem.page?P=30358#T=C&C=2
This one defaults with a small white straked image (no color selected), I get
credit for the large image.
I thought the attribution dynamically changed on this page when you changed the
selected color of the piece from the popdown, but right now I can't find
where that's happening...but it may be effected with some pieces and not
others. In any event, the behavior on this page is inconsistent and seems to
have something to do with whether or not there's a "default" small image...which
is probably a misnomer. For example, as far as I can tell there are no "small"
images for
* | | 650 Hinge Coupling Nylon - Two Connected 2 x 2 Plates
Parts: Hinge |
Can't figure out how to back-trace any of these pictures to their creators...
...hmm...guessing that the large image attribution is for whatever image occupies
that second vertical thumbnail position there...
Some of this might just be a UI problem where something isn't coded properly,
and with the 53588pb01 I doubt there is a gray version at all, just a dbg (this
was hashed about in the forum not too long ago).
Anyway, I've spent about as much time as I care to looking at this issue.
All I really know is something or things has gone wrong somewhere, and I suggest
you want to sort it out before any more images get put into the system and possibly
mispositioned.
Also, I don't want to be wrongly credited for someone else's contribution.
That's just not right.
You and the StormChaser may want to consider holding off adding any new images
until you can sort out what's going on.
|
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
USA, Vermont
)
)
