Redisplay Messages: Compact | Brief | All | Full Show Messages: All | Without Replies| Author: | mfav  | | Posted: | Feb 27, 2020 15:27 | | Subject: | Re: Dimensions 10507 | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog Requests, StormChaser writes:
| | So stud-size dimensions have a legitimate purpose. If I'm building something,
I don't want to pull out a tape measure and start counting millimeters to
decide if a part I like (but don't own) will fit where I need it to fit.
|
That's true if the stud size dimensions are accurate; but when something
is really 1 x 1.4 but is labeled 1 x 1...not so much.
|
 |
| Author: | mfav | | Posted: | Feb 27, 2020 14:52 | | Subject: | Re: Dimensions 10507 | | Viewed: | 42 times | | Topic: | Catalog | |
|
| In Catalog Requests, StormChaser writes:
| | ... it makes little sense to have stud-size
dimensions for parts like this.
|
It makes no sense to have stud size dimensions for anything in the dimensions
field. Having some dimensions being mm and others being studs makes all of them
useless.
If there are stud size dimensions, relegate them to the description field until
such time as there is a database rethink. Populate the dimensions field...systematically...x,
y, z...in mm...and that ought to go some way towards sorting out the volume calculations
for shipping and whatnot, wouldn't it?
My two cents towards more fully developing roadmap #7.
Also, why are some things 1 x 2 and other things 2 x 1? That's confusing
as all get out.
|
|
| Author: | mfav | | Posted: | Feb 27, 2020 14:29 | | Subject: | Re: Dimensions 10507 | | Viewed: | 52 times | | Topic: | Catalog | |
|
| In Catalog Requests, StormChaser writes:
| | In Catalog Requests, mfav writes:
| | 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?
|
I cannot locate 10507 in the catalog. Please post a link.
|
Sorry, dyslexia kicking in
15070
|
| 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 26, 2020 12:17 | | Subject: | Re: Yo StormBluser, for the roadmap? | | Viewed: | 49 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been thinking about part variants and I'm beginning to be of the
opinion that variants should only be considered for separate catalog entries
when absolutely necessary. There are no guidelines at the moment for part variant
splits, but we need them and we need to rethink part variants and how they're
handled in general.
|
There's a lot to consider.
1. should a piece be restricted to its original part number? If 3713 is superceded
by 6590, which is superceded by 42798, should those subsequent numbers become
official parts, or are you going to continue to collectively house all those
different flavors of the same part under a single number?
Note: http://v4ei.com/brickref/3713-variants.php
I don't know if those are all actually 3713, or by the time you get to the
fifth one if that's actually a 6590 or what, but...one one hand if you're
wanting to research and find the actual part (or as reasonably close to the actual
part) that came with a set, and you have the instructions, and the instructions
say 6590, then you want a 6590. On the other hand, if you're making a thing
with the grandkids, it really doesn't matter. There's a "continuum of
relevance" there that needs to be addressed.
2. http://v4ei.com/brickref/30104v69109.php
Those ought to go on the list to be split if they aren't already. 30104 and
69109 somewhere along the line are decidedly different parts. I don't know
if there's a 136mm 69109 or a 128mm 30104, but having one entry for items
with two different numbers and functional differences ought to be separated.
3. Whatever you decide to do with the variants, it's pretty clear to me that
they need to be investigated in greater detail to have sufficient understanding
of a part before being able to make an informed decision.
4. It would be nice if the points considered in making the decision were noted
on the parts' pages and all relevant parts are cross referenced with links.
|
|
| Author: | mfav | | Posted: | Feb 26, 2020 08:41 | | Subject: | Re: Yo StormBluser, for the roadmap? | | Viewed: | 82 times | | Topic: | Catalog | |
|
| I did note there would be pain associated with the proposal. Thus the question
mark in the title.
We’re finally getting three asp pages rewritten, so maybe the logjam on the dev
side is breaking. Lobby for a better underlying database structure. If you get
that, then cross site labeling issues become moot.
I’d like to see all the nonsense labeling of decorated parts go, too. That should
be an auto increment process handled by the database, not the arcane manual search
process with b p c x and whatever else gets thrown in there with the kitchen
sink.
Real improvement will look like pain for a while. In the end it is probably a
wash. You can have a big knife cut once, or ten paper cuts a day forever.
Certainly agree with the radical rethink. That also becomes a non issue with
a better underlying database.
I’m arguing for consistency in presentation and labeling at the moment, as those
things are achievable within the current structure.
|
|
| 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 24, 2020 22:48 | | Subject: | Re: Inventory Change Request for Set 9610-1 | | Viewed: | 32 times | | Topic: | Inventories Requests | |
|
| | | When I asked for it, my aunt looked down her nose at me and said. It is just
a store-bought print. It isn't valuable. She was hunting out jewelry and
her husband had brought a trailer to haul of power tools. I just said it was
valuable to me.
|
I got grandpa’s desk, because it was magic.
Later I discovered the desk wasn’t magic. The magic was in grandpa.
|
| Author: | mfav | | Posted: | Feb 24, 2020 22:12 | | Subject: | Re: Inventory Change Request for Set 9610-1 | | Viewed: | 31 times | | Topic: | Inventories Requests | |
|
| In Inventories Requests, axaday writes
| | Did you get yours from your grandparents? I hear the story over and over. I
believe every house had one in the 60s.
|
No, sadly my grandparents couldn’t afford such luxuries.
|
| Author: | mfav | | Posted: | Feb 24, 2020 20:34 | | Subject: | Re: Inventory Change Request for Set 9610-1 | | Viewed: | 26 times | | Topic: | Inventories Requests | |
|
| In Inventories Requests, jakemoore writes:
Okay, so my webcam hasn’t been hacked. What a relief.
|
| Author: | mfav | | Posted: | Feb 24, 2020 19:17 | | Subject: | Re: Inventory Change Request for Set 9610-1 | | Viewed: | 45 times | | Topic: | Inventories Requests | |
|
| | Where'd you get this picture? |
|
|
| Author: | mfav | | Posted: | Feb 17, 2020 16:04 | | Subject: | Re: Alternate Images (Rant) | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog Requests, StormChaser writes:
| | I agree with this also, but setting up a notification system is well beyond the
purview of CAs/IAs and requires action from the site's side. I simply don't
have time to individually notify 700,000+ people of changes because to do so
I would have to send exactly that many PMs. There is no system in place for
mass-notification, even though members have asked for it for a long time.
|
For pity's sake. Can't BrickLink afford a ConstantContact or MailChimp
account?
I know, you're not the person to ask.
This is a rhetorical question.
...and I'm a noisy forum user who will therefore be summarily ignored...
|
|
| Author: | mfav | | Posted: | Feb 8, 2020 23:00 | | Subject: | Re: Inventory Change Request for Set 4758-1 | | Viewed: | 39 times | | Topic: | Inventories Requests | |
|
| In Inventories Requests, axaday writes:
| | In Inventories Requests, mfav writes:
| | mfav thinks he'd like to see a wide shot of whateverthehell it is you're
doing for your "studio setup"...background, lights, camera, etc.
|
1 level up from cheapest tent on Amazon, ultra-bright LED bulbs, iPhone XR
| | mfav thinks you've got some awesome light temperature going on there, but
could use a diffuser
|
Isn't the tent a diffuser?
|
I couldn't say without seeing the setup. It could be a diffuser, but it needs
to be positioned correctly. I'm seeing hard white highlights on the tiger
figure which suggests hard direct light. Also seems the light is coming from
the sides, kind of backlit.
Phones are a pain because of the wide angle lens. You end up always having to
be between the light source and the object if you want to get a closeup. There
may be telephoto clip-on lenses that might help. Also a tripod/clamp/mount.
Also look into the Neural Cam app for iPhone.
Are you doing any postproduction with Photoshop or Gimp or something?
By the way, did I mention: The page cannot be displayed because an internal server
error has occurred.
|
|
| Author: | mfav | | Posted: | Feb 8, 2020 22:49 | | Subject: | Re: Description standardization note | | Viewed: | 63 times | | Topic: | Catalog | |
|
| In Catalog, Admin_Russell writes:
| | Unfortunately, single digits are thrown out of many of the search results.
|
Aren't you the fella to talk to to get that changed, Mister Site Manager?
| | But I think in general one would find more numerals in item names than the words
spelled out simply because it makes the name shorter.
|
While that is undoubtedly true, it's not particularly helpful in any way.
If you search, say, legs assemblies...
search for "three" you get two results
search for "3" you get: The following keywords were excluded from your search:
3
...however there are 13 entries containing "3"
Isn't the point of StormBluser's standardization plan to fix this stuff?
To paraphrase the StormBluser: why name something like this when 75% of the search
words are invalid?
Again, I'll make the point you need to distinguish between identification
and discovery. The identification of a thing is irrelevant if it can't be
discovered. People use the search box to find things, they don't browse 180,000
individual items looking for "3". Hope you get my drift.
Aren't you the number one proponent of making the catalog useful? Let's
figure out a way to make it useful.
|
|
| 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 8, 2020 18:18 | | Subject: | Re: Inventory Change Request for Set 4758-1 | | Viewed: | 42 times | | Topic: | Inventories Requests | |
|
| In Inventories Requests, axaday writes:
| | mfav is welcomed to steel these pics.
|
mfav thinks he's not interested in the pics once they've gone through
the bricklink imagemangler
mfav thinks he'd like to see a wide shot of whateverthehell it is you're
doing for your "studio setup"...background, lights, camera, etc.
mfav thinks you've got some awesome light temperature going on there, but
could use a diffuser
mfav also thinks a bunch of other stuff, but is going to stop thinking now
|
|
| Author: | mfav | | Posted: | Feb 7, 2020 21:10 | | Subject: | Re: February Roadmap Project: Old and New | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, dcarmine writes:
| | I have about 98% of the Harry Potter sets if you want to use that for year of
change or verification on that hat. I'm willing to look at them and report
what I find.
|
I'm content to let the mad geniuses of catalog control sort out the catalog.
I'm just documenting the differences I can find in the handful of hats I
have.
Regardless of whatever else, the presence of the prong on some hats and the absence
on others I would think constitutes a different mold, and the supercollectors
may want to note the differences. But, again, I'm content to let the catmins
sort all that out.
If you want to get really crazy, the undersides of the brims also exhibit differences
under the magnifying glass. Some are smooth, some have a pebbled inner and outer
ring, some have an inner ring with parallel striations instead of pebbling, a
couple have a narrow band of striations in an otherwise smooth inner ring. The
subtleties are kind of endless.
For whatever it's worth, though, mine are:
Black 90460: fine pebbling overall
Black: smooth cone, pebbled brim, with prong,
Black: slightly pebbled cone, pebbled brim, with prong,
Blue, Purple, Green: slightly pebbled cone, definitely pebbled brim, with prong
Dark Green, Dark Green with dragon decoration: definitely pebbled cone and brim,
no prong
Tan: slightly pebbled cone, definitely pebbled brim, no prong
Light Purple: cone too beat up to tell if it's smooth or slightly pebbled,
definitely pebbled brim, with prong
The dark green ones and the 90460 are pretty much pristine; the others are old
and worn. Your mileage may vary.
My sample size is small, so additional data is probably warranted if the admins
want to try to make sense of it.
I just updated the hats page with closeups. Don't know if you saw that version
or the earlier no-closeups version.
My opinion otherwise though is that using renders instead of photographs for
the parts is misleading for the collector.
Did I mention: The page cannot be displayed because an internal server error
has occurred.
|
|
| Author: | mfav | | Posted: | Feb 7, 2020 15:45 | | Subject: | Re: February Roadmap Project: Old and New | | Viewed: | 67 times | | Topic: | Catalog | |
|
| In Catalog, jennnifer writes:
| | Sure! I'll play along...
I am not convinced that 90460 is really a new version of 6131.
|
I don't know which number to ascribe to which hat, but there are hat differences.
http://v4ei.com/brickref/wizard-hats.php
|
| Author: | mfav | | Posted: | Feb 7, 2020 12:08 | | Subject: | Re: 30374 Bar 1x4 Frosted Variant | | Viewed: | 39 times | | Topic: | Catalog | |
|
| In Catalog, Hygrotus writes:
| | In Catalog, mfav writes:
I have also third variant 28697 not frosted. It looks like 30374 but has new
number molded on it. Checked under very high magnification.
|
...and an unnumbered version...
pic updated.
|
| Author: | mfav | | Posted: | Feb 5, 2020 13:12 | | Subject: | Re: Identifying minifigures | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Help, Stonemonkey1974 writes:
Note "nougat/flesh" hasn't been updated since the apocalypse, and Anders
is away for a week.
|
| Author: | mfav | | Posted: | Feb 4, 2020 12:19 | | Subject: | Re: Nougats reference | | Viewed: | 72 times | | Topic: | Colors | |
|
| In General, randyf writes:
| | In General, mfav writes:
You forgot Light Nougat. 
|
Yup. Please let me know if this is now corrected to your satisfaction.
http://v4ei.com/brickref/
|
|
| Author: | mfav | | Posted: | Feb 3, 2020 19:29 | | Subject: | Re: 3626cpb1788 Will Still Say Flesh | | Viewed: | 72 times | | Topic: | Colors | |
|
| In Colors, ratas writes:
| | I am a bit on both sides on this idea. In one way, having the variant first is
beneficial, but on the other hand, when the "base" version and variant come one
after other, having the variant later is better (imho). E.g.
Tile 1 x 2
Tile 1 x 2 grooved
To me, it is easier to spot the what is the common stuff and what changes when
they are shown like that.
|
The problem is with cognition:
Is this a Container or a Container Lid?
Container 1 x 2 x 3 Lid
...is it a 1 x 2 x 3 container or is it a 1 x 2 x 3 lid?
The tile example also would argue for a qualifier
Tile Ungrooved
Tile Grooved
Is Grooved the right qualifier? The 2412 Tile is grooved. The title doesn't
reflect that, but I'd suspect that "groove" would be an likely search term
for the uninitiated. So...back up and work on the glossary first?
Attempting this standardization...developing a schema to follow...should probably
take days if not weeks to sort out. If you download the catalog and look just
at the Container section...try to dissect that with a spreadsheet...put like
attributes into columns...you run into the weeds pretty quickly. And that's
an easy category.
And I'll once again emphasize that without substantive changes to the underlying
database structure, this is just rearranging the deck chairs.
If this work being done now is in anticipation of actually getting a better underlying
database sometime down the road, then start planning now and have the StormBluser
Schema anticipate the "to come" schema.
|
|
| Author: | mfav | | Posted: | Feb 3, 2020 19:10 | | Subject: | Re: 3626cpb1788 Will Still Say Flesh | | Viewed: | 55 times | | Topic: | Colors | |
|
| I'd suggest, if you're going to "standardize" the conventions, please
remove all the withs, withouts, ands, ons, throughs and other useless terms.
Stick to nouns wherever possible. The desire to make the titles "human readable"
isn't always in keeping with good discovery practices. As you noted a little
while ago, why name something in such a way that 75% of the terms are useless.
Change sequencing to reflect a variant before the size:
Bad: Container 1 x 2 Lid
Good: Container Lid 1 x 2
Bad: Tile 1 x 2 with Groove
Good: Tile Grooved 1 x 2
Did I mention: The page cannot be displayed because an internal server error
has occurred.
I guess you're not in charge of that one, though.
|
|
| Author: | mfav | | Posted: | Feb 3, 2020 15:28 | | Subject: | Re: We have a new Catalog Associate! | | Viewed: | 84 times | | Topic: | Catalog | |
|
| | Ahh. The two instruments of the Nougat Armageddon are peas in a pod. |
| 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: | Jan 29, 2020 16:01 | | Subject: | Re: goatleg | | Viewed: | 68 times | | Topic: | Catalog | |
|
| In Catalog, Andrsv writes:
| | mfav:
Regarding loading time. There's 2 main reasons for this. Servers are located
in Frankfurt(Germany), Filesize is big because of a library I am using. However,
once loaded everything should run fast. I've looked into it, but didn't
find a quick fix for slow loading time. I know a fix for it but it'll take
some time. It is not currently prioritized. Let me know if it is too annoying
|
Seems fine now. Might have been a first-time thing finding the server or something.
No issues subsequent to that initial load. I'd guess nothing to worry about.
| | FIXED: Search for Black Torso, Blue Arms, no hand color selected. Returns zero
results. (I got 9 results, but it seems to be correct)
|
Confirmed.
| | FIXED: At narrow screen widths the wrap is malformed or something
|
It's better than it was.
| | - Wish the search functionality was available in same window as bricklink (Need
clarification/user story etc)
|
1. I think I know what pitz wants; I'll PM you a demo. But I'm 99.9%
sure the addition of the cookie business on BL's end broke that functionality.
2. I don't know how you'd implement it if you could get it to work, given
your interface uses the entire window. You'd have to make the buttons and
search fields very small to accommodate the iframe to hold the BL window. And
it would be impractical on a mobile device no matter what.
|
|
| Author: | mfav | | Posted: | Jan 25, 2020 20:14 | | Subject: | Re: goatleg | | Viewed: | 62 times | | Topic: | Catalog | |
|
| | | Your first version of goatleg you did, the black torso, blue arms returns 19
results.
|
That is correct. It's a bad result set. It is returning blue arms, sand blue
arms, medium blue arms, etc. Not just blue arms.
|
|
| Author: | mfav | | Posted: | Jan 25, 2020 20:05 | | Subject: | Re: goatleg | | Viewed: | 50 times | | Topic: | Catalog | |
|
| In Catalog, Andrsv writes:
| | I'd love to get some feedback.
- Please let me know if I introduced any bugs, and I'll fix them
- Any suggestions of important changes you want, please let me know and I'll
consider them.
|
My first take.
Took a long time to load for me. I don't necessarily attribute that to whatever
code you have going on, but just saying.
Search for Yellow Head, Any Stud Type, keyword: scar. Returns zero results.
I believe this should return 38 results.
I believe this to be at least in part a flaw in original goatleg code.
Search for Black Torso, Blue Arms, no hand color selected. Returns zero results.
I believe this should return 8 results.
I believe this to be at least in part a flaw in original goatleg code.
With yellow hands also selected, returns 3 results. I believe this to be correct.
It appears that for any search all dropdown options must have an active selection
to function. I would suggest this is not the optimal solution as sometimes arms
or hands may be swapped on a torso. Also if you want to find all heads with glasses
irrespective of what stud type something has...then I don't think three searches
should be required to achieve that.
At narrow screen widths the wrap is malformed or something...button gets cut
off. Screen Grab attached.
Would be nice if the layout better adjusted to a narrow (phone) layout.
Good start, though.
|
|
|
| Author: | mfav | | Posted: | Jan 25, 2020 14:07 | | Subject: | Re: Have A Heart | | Viewed: | 62 times | | Topic: | Catalog | |
|
| In General, BLUSER13161 writes:
| | Forgot to mention: I would like to be identified only by a completely random
number in future comic strips and not by a cleverly brick-built LEGO tornado.
|
Ok. After tomorrow.
|
|
| Author: | mfav | | Posted: | Jan 25, 2020 13:30 | | Subject: | Re: Have A Heart | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In General, BLUSER13161 writes:
| | mfav makes the point that these contributors didn't contribute much and it
was a long time ago. He's saying that it therefore doesn't matter how
we treat them.
|
You know, sometimes you seem to misinterpret the stuff I put in the comics as
a personal point of view. That is not the case. The comics stuff is made to be
funny...well hopefully funny...not to be anything else.
If you want my personal point of view, it is that it is the individual in question
who should decide whether or not their sh*t is public. Not you. Not I.
Bricklink in this instance is presumably attempting to meet compliance with these
new privacy laws. I'm not debating the efficacy of the laws, or the aesthetics,
or morality or anything else, because it's irrelevant. The law is the law
and the affected bodies must be in compliance or in violation.
Given that there are a number of users X whom, presumably Bricklink cannot contact
to affirm their willingness to allow their sh*t to be displayed on the site,
BL likely doesn't have a choice but to anonymize them. Well, they have the
choice to be in violation of the law, but I assume that isn't the choice
that has been made.
Melville and Shakespeare are long dead. You can't cyberpunk them and steal
their identities. The cases with the anonymized users are likely unknown.
I don't necessarily disagree with your general sentiments. But your sentiments
are not the law. BL doesn't have to disagree with your sentiments either,
but not being in compliance with the law is a whole different deal.
Apples and oranges.
Now go ahead and point out where I'm wrong, and I'll make another comic
strip, and tomorrow will be another day.
|
|
| Author: | mfav | | Posted: | Jan 24, 2020 14:19 | | Subject: | Re: Have A Heart | | Viewed: | 59 times | | Topic: | Catalog | |
|
| Maybe familiarizing yourself with this information will clear up many of your
questions about Blusers and cookie screens having priority over things like being
kind and being useful and usable.
Because. Compliance. Governments know what's best for all of us.
https://gdpr.eu
|
| Author: | mfav | | Posted: | Jan 23, 2020 09:03 | | Subject: | Re: goatleg | | Viewed: | 97 times | | Topic: | Catalog | |
|
| In Catalog, Andrsv writes:
| | Why don't you want it out there? What's wrong?
|
PM me.
|
| Author: | mfav | | Posted: | Jan 23, 2020 07:52 | | Subject: | Re: goatleg | | Viewed: | 67 times | | Topic: | Catalog | |
|
| In Catalog, Andrsv writes:
Respectfully, Yeah, no. That happens, I’m going to have issues with two of you.
Andrsv, you want to take the two hours to write yourself your version based on
the instructions I’ve posted, then fine. Don doesn’t want that old version out
there and neither do I.
Also, be aware you may have maintenance issues with the code, and you’re probably
going to need to update regularly for colors.
|
| Author: | mfav | | Posted: | Jan 22, 2020 13:27 | | Subject: | Re: Attack of the Blusers | | Viewed: | 80 times | | Topic: | Suggestions | |
|
| In Suggestions, dcarmine writes:
| | | | I figured it out finally, but it would be helpful to have a brief explanation
of Blusers in the Help Center somewhere.
|
|
| | Can you share what you learned?
|
Blusers = BL Users
|
| Author: | mfav | | Posted: | Jan 22, 2020 13:01 | | Subject: | Re: goatleg | | Viewed: | 77 times | | Topic: | Catalog | |
|
| In Catalog, spattersonlego writes:
| | Who is willing to start a search site to replace goatleg?
I'm sure people would be willing to pay a small fee to use it. I would.
|
What's it worth to you?
|
| Author: | mfav | | Posted: | Jan 6, 2020 20:00 | | Subject: | Re: Remove image | | Viewed: | 51 times | | Topic: | Catalog | |
|
| In Catalog Requests, Admin_Russell writes:
| | Why shouldn't rust be considered a verified color for this part?
|
I know it's daft of me to think this, but can't you just call up the
mothership and get an answer? Then definitively tell us what it is? I mean instead
of questioning us. Like we know.
You know. As in sincerely, can't you do that?
|
| Author: | mfav | | Posted: | Jan 6, 2020 15:58 | | Subject: | Re: Analysts Ruin Everything | | Viewed: | 63 times | | Topic: | Catalog | |
|
| In Problem, calsbricks writes:
| | interesting they are pundits over here.
|
Yep. Equally despised and, you know, exactly the same people. But new and improved
with a fresh name! To make us think they're not pundits. Or analysts. Or
abjectly stoopid.
|
| Author: | mfav | | Posted: | Jan 6, 2020 15:36 | | Subject: | Re: Analysts Ruin Everything | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Problem, calsbricks writes:
| | I'll stick with analyst I cannot, for the life of me, understand why there
is such open hostility towards that.
|
Pretty much every pro football/TV/media talking head "analyst" in the US is an
example of why there's open hostility towards that term. Less accurate than
weathermen and infinitely more obnoxious.
|
|
| Author: | mfav | | Posted: | Jan 6, 2020 14:03 | | Subject: | Re: Analysts Ruin Everything | | Viewed: | 71 times | | Topic: | Catalog | |
|
| In Problem, StormChaser writes:
| | It's difficult to offend me, so do not trouble yourself in that regard.
|
Well, first this: http://v4ei.com/mini-fig-ure-outer/comics/index.php
Second:
Oh, good grief. You can't solve this problem alone, Robert. You can't.
You don't have the requisite tool set.
Bill suggests we get some help from people with the proper tool set to augment
the knowledge you have and you see fit to throw him under the bus.
Tell me the site has worked out all the problems you point out over the past
10 years. Has it? Those problems persist, don't they? Those problems do exist,
continue to not be resolved, and clearly you, we, the community, cannot solve
the problems by ourselves. If they could be resolved by us, then certainly they
would have been over a period of 20 years of community involvement.
Hell, in the thread about what's a tile and what's a plate and so on
you can't come to consensus. So let's have some rules. Because rules
fix everything. F--- all that. Redesign the database properly (this probably
does warrant the involvement of somebody other than you or the community) and
that argument of what something is and what something isn't becomes moot.
Really really wish you'd expend all this good energy you have in investigating
information studies instead of beating the dead horse. Again. Maybe you'd
feel better if Bill stopped using the word "analysts" and started using "information
design specialists".
Anyway, you keep beating your drum, and Bill keep beating his drum, and I'll
keep doing whatever the hell it is that I do.
|
|
| Author: | mfav | | Posted: | Jan 3, 2020 12:53 | | Subject: | Re: Show item quantity on catalog item page! | | Viewed: | 50 times | | Topic: | Suggestions | |
|
| | This isn't it? |
|
|
|
| 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: | mfav | | Posted: | Dec 31, 2019 13:11 | | Subject: | Re: hope for the new year | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In General, calsbricks writes:
| | BYW - why would I want to sign up to the experts ..... system. It is very rare
that BL listen to anyone on the forum me least of all.
|
Well...they don't tell you anything the most often.
|
| Author: | mfav | | Posted: | Dec 24, 2019 17:42 | | Subject: | Re: part number 62696 Dark Tan Bride Hair | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In Problem, Icetrent writes:
| | I received this part today for my Moster Fighter bride, but I can't find
the word lego anywhere on the part.
|
I have at least 10 of this piece, various colors, interior matching what you
show. FWIW. Only the bright light yellow has the "full circle" with LEGO stamped
in it.
|
| Author: | mfav | | Posted: | Dec 21, 2019 17:43 | | Subject: | Re: Guardian News Article | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In General, SylvainLS writes:
| | Okay, I misinterpreted your message as directly and sarcasticly answering
mine 
|
The requested implementation of the font styling in the forum for sarcasm is
still pending.
|
| Author: | mfav | | Posted: | Dec 21, 2019 16:57 | | Subject: | Re: Guardian News Article | | Viewed: | 44 times | | Topic: | Catalog | |
|
| In General, SylvainLS writes:
| | Where’s the spinning in what I said? 
|
Wasn't suggesting that you spun it this way or that. Just that the same data
can be interpreted in various ways.
|
| Author: | mfav | | Posted: | Dec 21, 2019 15:11 | | Subject: | Re: Guardian News Article | | Viewed: | 41 times | | Topic: | Catalog | |
|
| In General, SylvainLS writes:
| | So:
— if considering firmly stated opinions, positive loses.
— if considering all messages, positive is a minority.
Positive lose in more ways than negative.
The crux is that “non-negative” is not ”positive” (and vice versa).
The report can’t be: “mostly it was ‘wait-and-see’ or ‘I don’t know,’” especially
as it’s not true because there was a majority of firmly stated opinions and those
were majorly negative.
|
All hail the spin doctors.
|
|
| Author: | mfav | | Posted: | Dec 21, 2019 14:06 | | Subject: | Re: Guardian News Article | | Viewed: | 39 times | | Topic: | Catalog | |
|
| In General, StormChaser writes:
| | In General, mfav writes:
| | How does (113 not negative) to (47 negative) come up as the majority being negative?
|
A fair question.
First, we must discount the entirety of the no-opinion column. If those people
chose not to express an opinion, then that is not data.
|
I disagree. If you're including them in the sheet, then they're valid
data points.
| | Then the only column in question is the wait-and-see people.
|
That's not in question either. Their position is wait-and-see. If you include
them, they are valid data points.
| | The only real data to compare here are those who definitively expressed a for
or against position. At least that's how I saw it. Correct me where I'm
wrong.
|
Attempting that above.
If you compare just the positives to the negatives, then, agreed, negative has
more numbers.
If you compare the negatives to the cumulative not-negatives, then not-negative
has more numbers.
| | And keep in mind that this is all somewhat open to interpretation anyway. Some
people clearly stated dissatisfaction in no uncertain terms. Others did the
opposite. For those in between, some judgment had to be made.
If you chose to review the comments in the thread, then you might report different
results.
|
Not having an issue with the methodology, just the interpretation of the data.
|
|
| Author: | mfav | | Posted: | Dec 21, 2019 13:45 | | Subject: | Re: Guardian " lego take ovrer BL" | | Viewed: | 43 times | | Topic: | Catalog | |
|
| | How does (113 not negative) to (47 negative) come up as the majority being negative? |
| Author: | mfav | | Posted: | Dec 16, 2019 12:17 | | Subject: | Re: Inventory Change Request for Minifig sw1030 | | Viewed: | 37 times | | Topic: | Inventories Requests | |
|
| In Inventories Requests, StormChaser writes:
| | I've really been listening to mfav and 62Bricks when they talk, although
they might think I don't, and I do think there is some value to looking at
things from the ground up - to consider what root causes might be generating
ongoing problems.
|
Dude, check this out.
http://www.ou.edu/cas/slis
See if you can audit some courses.
|
|
| Author: | mfav | | Posted: | Dec 14, 2019 16:42 | | Subject: | Re: Parts Category Tree | | Viewed: | 52 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I get (for the most part) what mfav and calsbricks are proposing, but it remains
to be seen the level of investment TLG is willing to sink into the catalog (and,
considering their own websites, what the results would be). Provided that the
site chooses to retain the hierarchical system, I think we all agree it can definitely
be improved.
|
Nope. It won't be improved. It will be different. This is just rearranging
the content on shelves in the supermarket.
If the last couple deployments of "site improvements and updates" aren't
enough to dissuade you from tinkering with the site, well...I don't know
what to think. Kind of feels like the wheels are coming off the stagecoach and
the horses are headed for the ravine.
I sincerely appreciate the time, thought, enthusiasm, and commitment you have
for the catalog. Sincerely, I do. That said, I recommend letting stuff settle
down a bit. I'm afraid anything you cook up at this point may be wasted effort.
Stuff that was working two days ago may not be working now.
But it's your effort to waste, so I respect that.
|
|
| Author: | mfav | | Posted: | Dec 13, 2019 15:59 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 50 times | | Topic: | Catalog | |
|
| | | It's not impossible to make educated guesses.
|
...if you're properly educated...
| | Could you provide an example of a large online database that is structured this
way so that I could understand it better?
|
1. Again, seemingly some confusion on your end between the database and how it
is accessed via an html form.
2. No. Database structure isn't generally something that's revealed at
the browser level, nor should it be.
3. Ambiguity at "large" meaning number of records or table/field complexity or
both?
You want a book on relational database design. Avoid the "for dummies" books.
To start, limit yourself to database design. If you get too far off track, you'll
end up with how to install MySQL on Apache, and you're not interested in
the technical aspects of deploying the software on a server.
After that you can move onto web database applications, best practices, and whatnot.
If you want to get your hands a little dirty at no cost, you might try playing
with OpenOffice Base.
|
|
| Author: | mfav | | Posted: | Dec 13, 2019 13:32 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 41 times | | Topic: | Catalog | |
|
| Responses to the two related posts included below.
| | One person said that before making any changes the site should pay a team of
data analysts to examine things.
My response: Maybe so. But I believe, perhaps wrongly, that we could probably
figure many things out for ourselves with some support for catalog improvements
from the new owners.
|
Bill is looking at the bigger picture. You seem to be more concerned about the
catalog specifically. Understand that Bill's view of the "problem" is undoubtedly
significantly more encompassing than anyone else here. Catalog improvements don't
stop at entering info into the database. That single catalog item has to essentially
link all the way from the factory to catalog inclusion here to stock lists and
inventories through sales and delivery...and then possibly to the third party
tools and in-house inventory and sales systems. So, yeah, we could probably figure
out many things. We could also miss just as many or more things because those
things are outside the scope of our particular focus at the moment.
| | One person suggested defining all parts by shape.
My response: Not a bad idea at all. Shape is the true universal. The problem
with that is massive catalog reorganization if nothing else changes. I'm
not against it personally, but it would cause major disruptions.
|
Grok that if not everything changes, then what we have now is the best it'll
ever be. I don't want to say for sure that you're promoting a false narrative
here, but it's impossible to project what disruptions there may or may not
be.
| | I agree that including additional fields for
item attributes would be an excellent solution/improvement to the current practice
of keyword searches by title, even if it does not replace keyword searches.
I tend to disagree that this would be as difficult or as lengthy a process as
you imagine, though you clearly know more about this than I do.
|
There is the time to figure out what needs to be done with the database table
and fields. Then create the database. Then there is creating the admin side forms
for entering, checking, approving, editing, updating, etc. the data. Then there
are the admin search routines for finding a particular record or set of records.
Then all the data needs to be updated, migrated, or otherwise created. But it's
every single record needing to be edited. This doesn't take into account
whether or not the data needs to be spread across multiple tables, which may
be desirable. In which case you're looking at potentially going through each
item multiple times. Then there is the whole customer side interface of being
able to display the data...product detail page, results pages, set inventory
pages, shopping cart and on and on. Then it all needs to be tested. So. Yeah.
A. Long. Time.
| | So let's say your proposed system was fully implemented and I'm doing
some kind of catalog work (like checking titles for consistency) that requires
me to go through lists of parts. How can I avoid having to see the same part
multiple times when it appears in different categories?
|
This is a function of identification, not one of classification. So you should
be able to identify all similar bricks with a specific set of search criteria.
These wedge bricks would likely appear at the intersection of the brick set and
the wedge set.
| | For example, I examine all the parts in the Brick category. Then I examine all
the parts in the Wedge category. How much of this data must I reexamine due
to the fact that individual items appear in multiple categories?
|
You search for brick+wedge and that returns the subset you're looking for.
There is one element record with a lot of attribute checkboxes. Depending on
which attribute checkboxes are checked...that's where the element will appear,
but that's not where the element is located. The element is located at its
unique identifier which is probably the shape+color+decoration attributes "code
number". Here we need the Librarian and the Analyst to come up with the scheme.
The hard-coded category "browse" interface you're used to may or may not
disappear completely and be replaced by a single or multiple different browse
interfaces. Again: analyst.
There is currently "browse by color" and "browse by category" options and you
understand that. Now, for example, take the "browse by category" section and
explode that into multiple checkbox options versus hard links. That scheme immediately
requires less screen space because you now have ( 1 brick, 2 wedge, 3 plate,
4 slope, 5 decorated ) versus ( 1 bricks, 2 bricks decorated, 3 wedge bricks,
4 wedge bricks decorated, 5 plates, 6 plates decorated, 7 wedge plates, 8 wedge
plates decorated, 9 slopes, 10 slopes decorated ) and so on.
| | Or would your system of cataloging eliminate categories as we currently think
of them?
|
Potentially. The analyst should provide a recommendation here. I think the categories
as we now recognize them is a product of old-print-catalog-thinking and not relational-database-thinking.
| | Would there be a category tree in the system you propose? Please elaborate
|
I think this is an interface-side issue, and not a database-side issue. It sounds
like you're not separating the two. Again, if you go through the whole process
there in the custom search builder, it may clarify in your head how these two
"sides" of the process interact.
There could be any number of "trees". Try to move away from the physical-world
perception of a single element with a single label in a single drawer in a single
cabinet on a single wall in a single room. I think you're working in the
world of something is this OR that. You need to work in the world of this AND+/-OR
that.
The analyst should look at this question of category tree and then...uh...analyze...and
come up with proposed solutions. The solution for accessing results from the
database may have different sets of criteria, and accordingly different interfaces,
if you're on the administrative side as opposed to being on the consumer
side.
You need to get comfortable with moving away from this process that's familiar
to you and start from the ground up. You have extensive knowledge of the catalog
and its current limitations. Free yourself from the current set of constraints,
build a list of the administrative functions that you need or want, then present
that to the analyst. That will help to define what fields would be needed in
the database.
The problem is in the current rigid hierarchical system with unconstrained data.
We want a fluid dynamic adaptable system with constrained data.
| | - I find your ideas useful, but this would be an objection I would have.
|
Yes, yes. Many people find my ideas useful while objecting to me having ideas.
|
|
| Author: | mfav | | Posted: | Dec 10, 2019 16:30 | | Subject: | Re: Parts Category Tree | | Viewed: | 54 times | | Topic: | Catalog | |
|
| There seems to be some conflation or confusion regarding the data and the database
structure and how those things relate.
The structure is how it's built and the data is what's within the structure.
Rebuilding the data from the ground up is not necessary. Some of the data is
fine as is and simply would need to be migrated or an existing field related
to a new table and field.
There's no other way to increase functionality or make operations more efficient
without some fundamental change to the underlying structure.
There is no way to create substantive efficiencies within the existing framework.
You have 256 deck chairs and a 900 x 900 foot deck. You can rearrange the chairs
all you want, but it's never going to be more than 256 deck chairs. The arrangement
that makes chair #125 easier to find may make chair #93 harder to find. Everything
is a trade-off.
There is no quick and there is no easy.
If you want to undertake "reorganizing" or "cleaning" the data...for example,
examine all the minifig heads. Rewrite all the descriptions in a uniform manner...start
from top to bottom...hair, eyebrows, eyes, nose, mouth, whiskers, scars, blemishes,
wrinkles, and so on...then that will lead to an incremental improvement in the
data. Functionality isn't going to be improved without a change in the available
tools. I often state that you can cut down a tree with a spoon, but it's
not the best tool for the job. It will get done, but with great effort and it
will take a long time. Invest in an appropriate tool, like a chainsaw, and the
effort decreases, the time decreases, and the satisfaction increases.
Your argument seems to be for changing one spoon for another.
Additional categories won't solve anything. At this point, this is the difference
between sorting mixed pieces of lego in 230 boxes or 240 boxes. You're just
rearranging the deck chairs. Again. When the supermarket redesigns the floor
plan and product location within the store you've been shopping in for 10
years, does that help you find the chicken soup?
Not that I expect you to go through the exercise, but here http://v4ei.com/mini-fig-ure-outer/index.php
is the custom search instruction thing I wrote. It will take about 2 or 3 hours
to complete if you want to do it. Anyway, going through the source information
(skip creating the html if you want) will kind of lay bare the inconsistencies
within the current data. You'll find obvious typos. You'll find similar
items described similarly, but with differing sequences...like items described
dissimilarly...dissimilar items described similarly...nothing you wouldn't
expect when the data is crowd sourced over a long period of time. Some swaths
of data are really good. There has been effort put into the data, but not always
of consistent quality or consistent methodology.
Looking at a dataset as a whole, and not piecemeal, can be quite enlightening.
Do we need any listing that contains the phrase "without such-and-such"? Is it
helpful to list what something doesn't contain? Fish without bicycle spokes.
Butterfly without steel beams.
So, to answer your question, yes and no. I'm making the argument for additional
data. I'm making the argument for additional database structure. I'm
making the argument for thinking things through thoroughly before starting to
build something.
Right now there's no way to add deck chairs to our deck. We need another
deck. And a way to get chairs from one deck to another. And ways to get users
from deck to deck and chair to chair.
If you decide to do the custom search creation, all of it, I think by the end
of that exercise it should provide enlightenment as to the limitations of what
can be done within the current structure and the quality of the current dataset.
Those things should be able to inform your thinking on how to better conceive
a plan for improvement within the current limitations.
Read what Bill says in the light of Bill actually knows what the f--- he's
talking about instead of Bill's a cranky old man. Bill is a cranky old man
because he actually does know what the f--- he's talking about. When
you fully understand what Bill is saying, at that point you'll understand
the complexity of the issue. You seem to think the problem is lack of simple
programming. It's not. It's waaaaaay deeper than that.
Discussion at this point isn't leading to any solutions. I currently find
no value in the obsessive hand-wringing, worry-warting, prognostication of doom,
hopes, wishes, unfulfilled dreams, and ideas of improvement around here. Be patient
and wait for Superplasticorp to take over the Titanic and see where we are in
a month or two.
If you need to do something because you need to do something, I'd suggest
creating a wish list to present to Superplasticorp. They say they want to engage
with the AFOLs. Well, here's your opportunity. What's most important?
Is it more data that's definitive and easily accessible? Is it greater selection
of trans-neon-green elements? History? Factory tours? Let Superplasticorp know
what they can do to facilitate their selling you more stuff...they'll listen
to that.
Improvements of the type often discussed here on the board will take years
to implement, if that's even an option. It could be that Superplasticorp
leaves the current BL management in place and things carry on in the lopsided
manner they have been for the last several years. Or Superplasticorp could actually
value the AFOL community, engage with the community, cooperate with the community,
respect the community, find value in the knowledge the community has to offer,
and not expect those with the knowledge and who actually provide the content
to work for free versus working for mutual benefit. Time will tell. Maybe.
I'm going to shut up now.
|
|
| Author: | mfav | | Posted: | Dec 10, 2019 10:54 | | Subject: | Re: Parts Category Tree | | Viewed: | 46 times | | Topic: | Catalog | |
|
| The category tree is not really the issue.
There needs to be an understanding of the difference between classification and
identification.
Browsing probably takes place against classification.
Identification should not be limited to classification. Identification should
take place against element attributes.
The existing database framework is inadequate to meet what is desired.
The underlying database needs many additional tables and fields to store specific
relevant information.
Classification of any single piece should not be restricted to a single category.
For example
should be categorized as brick and wedge
should be categorized as plate and wedge
should be categorized as panel, window (if transparent), wall element,
windscreen...and perhaps other things.
Identification should be effected against several different and some as-yet-non-existant
fields with specific criteria.
Instead of trying to identify by the contents of the q (title or name) field,
which is the only option at the moment, additional fields should be created that
contain specific attributes of an element: how many studs, how many sides with
studs, how many sides with stud receptors, how many sides without studs, symmetrical
or asymmetrical shape, general shape (rectangular, circular, triangular, rhomboid,
irregular, etc.), protruberances and sockets (axle holders, holes, clips, bars,
pins), and so on.
All this needs to be paired with an illustrated glossary of terms.
After the foundation is laid, then the data needs to be populated in a regular
manner which adheres to strict conditions for consistency. In the instances where
a field can contain discrete "checkboxable" items, that should be simple. Where
a field is "open" criteria should be set in place such that the data is entered
in a logical and repeatable manner.
The much discussed "tag system" is nothing more than an additional name/title
field, perhaps with a character limit in excess of 256 characters, but is susceptible
to the same problems as the current name/title field. It's just more of the
same thing as exists now, so it will fail/succeed/operate in the same manner
as the current name/title field, just in a second field. If the "solution" of
the "tag system" is effected, then you're still going to have data inconsistency...some
items will have value A in field one and some items will have value A in field
two. So that ends up compounding the frustration instead of alleviating it.
Colors should not necessarily be limited to any one institution's nomenclature.
The colors are indexed by an integer value. Any one value can carry multiple
labels. Thus XXX can be both Medium Stone Gray and Light Bluish Gray.
Ultimately this means something like a 10x increase in data (or more), additional
fields, additional forms for both discovery and data entry, and more.
tl;dr
A glossary needs to be in place describing all pertinent aspects and glossary
terms should be used in the datasets.
The underlying database needs to be 1) expanded and 2) available for modification
on a periodic basis as needed.
The data needs to be more, better, and consistent within a field.
It's going to be a lot of work.
|
|
| 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: | Apr 9, 2019 18:57 | | Subject: | Re: inconsistencies | | Viewed: | 43 times | | Topic: | Catalog | |
|
| Yep.
Newbies to this site are told they can find everything here, but the reality
is they're like corpulent bodies with raw meat strapped to them, thrown into
the deep end of the pool where there are sharks with frikkin' lasers!
BrickLink is a very complicated site. Kind of like being strapped into an airplane
cockpit for the first time and, without benefit of any instruction, being told
to fly to a foreign country. There are a lot of things to sort out.
The site needs some genuine marketing savoir faire, plain easy-to-understand
instructions, and a thousand other things. But a good start would be a home page
that says "Welcome to Bricklink" and a big-ass obvious link to "New to Bricklink
Start Here" and a Start Here page with some simple concepts like:
BrickLink is a marketplace where thousands of Lego fans operate independent storefronts.
...and a decent explanation of what that's all about.
BrickLink is a crowdsourced online catalog.
...and a decent explanation of what that's all about.
The Wanted List.
How to buy.
Those four things would go a long way to helping out the newbies. You come here
the first time, it's daunting. Strap tight for your first foray into the
forum.
The other thing, pertinent to the current thread, would be a decent glossary.
That alone ought to help sort out or crystallize concepts relative to language
(plates vs tiles) and other concepts.
|
|
| Author: | mfav | | Posted: | Mar 30, 2019 20:07 | | Subject: | Re: List of known part-color-combinations | | Viewed: | 47 times | | Topic: | Catalog | |
|
| From the color search popup on the search page:
Aqua
Black
Blue
Blue-Violet
Bright Green
Bright Light Blue
Bright Light Orange
Bright Light Yellow
Bright Pink
Brown
Coral
Dark Azure
Dark Blue
Dark Blue-Violet
Dark Bluish Gray
Dark Brown
Dark Flesh
Dark Gray
Dark Green
Dark Orange
Dark Pink
Dark Purple
Dark Red
Dark Tan
Dark Turquoise
Dark Yellow
Earth Orange
Fabuland Brown
Fabuland Orange
Flesh
Green
Lavender
Light Aqua
Light Blue
Light Bluish Gray
Light Flesh
Light Gray
Light Green
Light Lime
Light Orange
Light Pink
Light Purple
Light Salmon
Light Turquoise
Light Violet
Light Yellow
Lime
Maersk Blue
Magenta
Medium Azure
Medium Blue
Medium Dark Flesh
Medium Dark Pink
Medium Green
Medium Lavender
Medium Lime
Medium Orange
Medium Violet
Neon Green
Neon Orange
Olive Green
Orange
Pink
Purple
Red
Reddish Brown
Rust
Salmon
Sand Blue
Sand Green
Sand Purple
Sand Red
Sky Blue
Tan
Very Light Bluish Gray
Very Light Gray
Very Light Orange
Violet
White
Yellow
Yellowish Green
Trans-Black
Trans-Bright Green
Trans-Clear
Trans-Dark Blue
Trans-Dark Pink
Trans-Green
Trans-Light Blue
Trans-Light Orange
Trans-Light Purple
Trans-Medium Blue
Trans-Neon Green
Trans-Neon Orange
Trans-Neon Yellow
Trans-Orange
Trans-Pink
Trans-Purple
Trans-Red
Trans-Very Lt Blue
Trans-Yellow
Chrome Antique Brass
Chrome Black
Chrome Blue
Chrome Gold
Chrome Green
Chrome Pink
Chrome Silver
Copper
Flat Dark Gold
Flat Silver
Metal Blue
Pearl Dark Gray
Pearl Gold
Pearl Light Gold
Pearl Light Gray
Pearl Very Light Gray
Pearl White
Metallic Gold
Metallic Green
Metallic Silver
Glow In Dark Opaque
Glow In Dark Trans
Glow In Dark White
Milky White
Glitter Trans-Clear
Glitter Trans-Dark Pink
Glitter Trans-Light Blue
Glitter Trans-Neon Green
Glitter Trans-Purple
Speckle Black-Copper
Speckle Black-Gold
Speckle Black-Silver
Speckle DBGray-Silver
Mx Aqua Green
Mx Black
Mx Brown
Mx Buff
Mx Charcoal Gray
Mx Clear
Mx Foil Dark Blue
Mx Foil Dark Gray
Mx Foil Dark Green
Mx Foil Light Blue
Mx Foil Light Gray
Mx Foil Light Green
Mx Foil Orange
Mx Foil Red
Mx Foil Violet
Mx Foil Yellow
Mx Lemon
Mx Light Bluish Gray
Mx Light Gray
Mx Light Orange
Mx Light Yellow
Mx Medium Blue
Mx Ochre Yellow
Mx Olive Green
Mx Orange
Mx Pastel Blue
Mx Pastel Green
Mx Pink
Mx Pink Red
Mx Red
Mx Teal Blue
Mx Terracotta
Mx Tile Blue
Mx Tile Brown
Mx Tile Gray
Mx Violet
Mx White
|
|
| Author: | mfav | | Posted: | Mar 10, 2019 23:49 | | Subject: | Re: find nearby stores, based on my ZIP code? | | Viewed: | 33 times | | Topic: | Suggestions | |
|
| Sellers could simply put their coordinates on their splash pages, no programming
needed, if they thought it a good idea. The zip locator is an over complicated
solution to a problem that doesn’t exist.
|
|
| Author: | mfav | | Posted: | Mar 8, 2019 17:58 | | Subject: | Re: find nearby stores, based on my ZIP code? | | Viewed: | 33 times | | Topic: | Suggestions | |
|
| BL has said on more than one occasion they're not going to do it.
So, it isn't going to happen unless, say, you want to build it yourself.
All you need is latitude and longitude information for every postal code in the
world stuck into a database and cross referenced with your list of sellers. That
and a little math. You can find plenty of resources on the web how to program
this thing. Programming is relatively easy compared to managing the underlying
database, though.
For example, the Canadian postal code database will allow for a possible 7.2
million entries. Currently the Canadian database is over 800,000 entries. So
that's one country. Only about 270 more countries to go.
Sure this would be a great feature, but it would cost thousands of dollars to
implement and tens of thousands more to maintain. Some human body will need to
oversee the thing. It would be a full time job to maintain this functionality,
keep the user list policed, keep the postal code data up to date, and so on.
Maybe you'd offer to be the BL zip code database administrator...for no pay?
If you're willing to do that, maybe instead you'd like to be the BL catalog
administrator...for no pay...because there's already an opening there.
I don't mean to throw the snark, but this functionality isn't in any
way going to happen because it won't ever make enough money to be a break-even
proposition from a business standpoint. If it's opt-in and you get 37 sellers
opting in, was it worth the $8000 to build?
I don't think so. But feel free to disagree.
|
|
| 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: | Feb 23, 2019 18:51 | | Subject: | Re: search box repeated problem | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, snapper212 writes:
| | Is it just me, maybe a browser issue? I am using Chrome.
|
Not a browser issue.
The search box which appears at the top of most pages, when set to "All Items",
has a script attached to it.
What follows here is observation, not some intimate knowledge of whateverthehell
the script is.
You enter your query.
Then the script displays up to four "similar" query "returns", then three "product"
"returns" (see attached image).
If your query is "standard"...like a four character part number...then the popdown
displays some variations of that (see first two columns of attached image).
Next it will show the returns. The first return is usually a set, the second
return is usually a part, and the third is usually gear. At least for a four-digit
query. In most cases.
Sometimes, however, your four-digit query has multiple sets associated with that
number. In the case of 4032, there is a great pile of versions of the 4032 set,
and those fill in the returns (see second column of attached image).
Typically there is only one set with a four-digit number. In that case it will
then show the set. Then because there are no more sets it shows the Part query
number. If there are no more parts, it shows the Gear query number.
If you put in a particularly long query, or some non-conforming-to-what-the-script-can-handle
query, then the "similar" returns may vary in number (see third column of attached
image). The "product" returns may also vary or not display depending on the ability
of the script to match the query term with a term in the catalog.
So the search box is working correctly, it's just not working as you'd
expect (yeah, not working as anyone would expect), therefore it appears to be
working incorrectly. This is because the returns are inconsistent...or at least
appear inconsistent.
Because the search dialog is searching the entire catalog, you get returns that
are wildly eccentric based on any particular query string's appearance or
absence in any given part of the catalog. If that string exists either multiple
times across catalog sections or multiple times within a specific
catalog section, that shapes the sequencing in the return.
Hope that makes sense.
If you change the toggle from "All Items" in the search box to one of the other
selections, the auto-popup-whichamajigger doesn't do its thing.
|
|
|
| Author: | mfav | | Posted: | Feb 14, 2019 10:36 | | Subject: | Re: Aren't these differences ridiculous? | | Viewed: | 48 times | | Topic: | Catalog | |
|
| | | | | I have a loop in every room of my house!
|
I don't know what that means.
|
Loupe, not loop.
|
| Author: | mfav | | Posted: | Jan 28, 2019 17:32 | | Subject: | Re: Inventory Change Request for Minifig rsq004 | | Viewed: | 22 times | | Topic: | Inventories Requests | |
|
| In Inventories Requests, randyf writes:
| | In Inventories Requests, mfav writes:
Could you take straight on images instead of isometric views?
|
You know, somebody asks for something, then somebody else takes an hour out of
their day to provide it, then it's unappreciated.
If you don't want to use those, I don't have a problem with it. Somebody
else will step up with the "right kind" of images eventually.
|
| Author: | mfav | | Posted: | Jan 28, 2019 16:31 | | Subject: | Re: Inventory Change Request for Minifig rsq004 | | Viewed: | 25 times | | Topic: | Inventories Requests | |
|
| | 004 and 008 |
|
| Author: | mfav | | Posted: | Jan 15, 2019 08:22 | | Subject: | Re: Search nearby stores by postal or zip code | | Viewed: | 36 times | | Topic: | Suggestions | |
|
| In Suggestions, superchicken77 writes:
| | Privacy issue is solved by it being an opt in feature. I list my postal code
in my terms anyway.
Going back to your suggestion about co-ordinates, maybe that's the easier
way to implement it instead of having to code in zip/postal codes and every other
addressing nomenclature of each country. If you can find your longitude and
latitude on google earth, it should be easy enough to find "near me" stores.
|
https://geocoder.ca
Knock yourself out.
|
|
| Author: | mfav | | Posted: | Jan 14, 2019 16:19 | | Subject: | Re: Search nearby stores by postal or zip code | | Viewed: | 54 times | | Topic: | Suggestions | |
|
| In Suggestions, superchicken77 writes:
| | I'd like to be able to search for stores within a specific range (ie 10km,
20km, 50km) from my postal code. Seeing that a seller is in a given province
(in my case) means they could be around the corner or 12 hours way in Thunder
Bay. Being able to search nearby stores would be a fantastic option. It would
be an option to opt into, whereby a store must enable the feature to show up
in nearby store searches. This would allow stores to disable the feature in
case they are uncomfortable with the feature.
|
Cool idea, but difficult to implement. And there are privacy issues.
The Canadian zip code database runs over 760,000 records; most of them geolocate
to stationary moose, uninhabited parts of the Yukon, and what have you. I don't
recall exactly, but I think their process was to basically put a grid over the
entire land mass of the country, divide it up into little squares, and assign
a code to each square.
The US zip code database, covering a population several times that of Canada
runs only about 42,000 records and the codes cover arbitrary regions roughly
equivalent to towns, and some post offices that don't offer delivery have
their own code.
Typically these zip codes are associated with a longitude and latitude, and these
data files can be acquired from the post office and maybe other sources.
Then there is some math and code to figure out the "as-the-crow-flies" distance
between two zip codes' associated coordinates.
I don't know that the entire globe...or all the areas serviced by BL...have
these databases. Could be. Just never built one of these things other than US/Canada.
Anyway, bottom line is you need the longitude and latitude of every store...or
something reasonably close. The coding is a bit tricky. And it may have to be
broken into hemispheres because of the math for triangulation over a sphere.
If folks want to publish their longitudes and latitudes, then you can find the
distances with Google Earth or something similar. I'd guess most of the mom-and-pop-hobby-shop
operations aren't going to be enthusiastic about posting their residential
coordinates for the world to see, though.
|
|
| Author: | mfav | | Posted: | Jan 9, 2019 09:45 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 52 times | | Topic: | Catalog | |
|
| | | Sometimes the large image space is empty depending on the device you are using.
I notice this when using my phone, and people have reported similar problems
with tablets. That is a bug and I'll write it up if I can reproduce it. I
suspect it is a cache issue.
|
I think some value is not being consistently passed to the javascript controlling
that display, especially when the page loads. The image shows up more consistently
if it HAS been cached.
|
|
| Author: | mfav | | Posted: | Jan 7, 2019 22:08 | | Subject: | Re: Catalog Guidelines: Minifig Heads | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In General, axaday writes:
| | The trophy piece can be a minifig or a untensil depending on its print.
|
One solution: suggest that this piece get its own category where it is neither
minifig nor utensil. 3626 has its own category.
| | Similarly, I don't know why a "head" that is a fishbowl can't be a decorated round brick. Or is that regressive?
|
Minifig, head is a BL designation. As such, it's arbitrary.
Whether splitting the piece across different categories is desirable or not is
debatable. Whether or not that can be implemented within the current database
schema is a question. If the trophy piece already operates this way, then I wouldn't
have an objection. Others might.
I have supported the concept that certain parts be found wherever it makes sense
(multiple categories) and not be restricted to a single category. I believe it
requires changing a field at the db level to accomplish that. Example:
being additionally classified under vehicle, mudguard.
It might also imply some adjustment on the part of sellers to modify their systems
to accommodate.
|
|
| 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 7, 2019 12:24 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 56 times | | Topic: | Catalog | |
|
| Thank you for taking the time to respond.
| | When this copy script was run (this was a one-time function), the credit was NOT transferred.
|
Oi. That makes for some busywork for somebody.
| | The whole rationale behind this image unification is because the management does not like the disconnect between a thumbnail image that shows one thing and a large image that shows another.
|
Woo-hoo management! Good call.
| | So right now, all catalog detail pages of those printed leg parts will show your
username under both small and large credits. But when the large image credit
slot is replaced by the additional credit slot, then the person who submitted
the primary additional image (the "default" additional image, if you will) will
have their username there instead, in cases where there is an additional image.
|
I don't know what the plan for this business is going forward, but it still
sounds problematic to me. I'd think you'd just have a single gallery
per contributor of images submitted, and credit the image in the popup window
alongside the image and eliminate all these other ambiguous and confusing and
possibly wrong attributions elsewhere.
| | It's hard for me to understand why an image of yours would get rejected, but it does appear that in each of these cases, your small image (80 x 60) was approved but your full size one wasn't.
|
No big deal. Can't expect everything to be accepted.
| | The second thing that has changed is that high quality images with a white background are greatly preferred over standard shots.
|
Although I'm not sure of the definition of "standard shot" is quantified
here, I believe this was always the case. The language I believe you should use,
if you want to describe this for future photo takers is: "silhouetted against
white". A piece of paper is white, and lots of objects are shot against that,
but the background in those shots I don't believe is what you're preferring.
| | Nice images were always appreciated, but the emphasis was on correctness, not visual appeal.
|
As we're seeing in some current threads, "correctness" is subject to revision
and whim.
| | So for example, the first minifig on the list currently has a large image showing
the neckpiece removed from the minifigure so as to show the printing on the torso.
In the past it was considered more desirable to be explicit about all details
of the figure,
|
This is not at all defined. What is more explicit: showing a minifig with a decorated
torso covered by a chest piece, or showing the torso? You can't show both
states at once. But explicit detail implies that you do need to know both states.
I'd think the emphasis should be on accurately describing the item in question
without ambiguity and within reason, according to a set of established guidelines.
In the case of minifigs, in the past, I believe that there was a preference for
a full-frontal image, and/or a full-frontal with a head inset if the face was
obscured by a visor or mask or something. In my case, if a figure has a backpack
or air tanks or similar, I try to make a 3/4 view where this element is apparent.
In the case of some divers with flippers, I positioned the figure such that the
flippers were very apparent. I'm sure some of these were not accepted because
they weren't full-frontals, even though they did more accurately completely
describe the figure.
Additional information can be conveyed with additional imagery, presumably accessed
via the image popup. Thumbnail imagery, though, should be simplified to the extent
that it can be while maintaining the most communicative immediacy possible at
a small size. In other words: the busier the thumbnails are, the more difficult
they are to recognize without effort.
| | but now the emphasis is on a presentation of the minifigure that will help sell it to today’s consumer.
|
The problem...don't know that that's the right word...maybe I can rephrase.
The definition of consumer is in question. There are lots of consumers. Some
consumers just want to buy a Darth Vader. Other consumers want to be able to
identify which Darth Vader, with a specific pattern and a specific head which
may be obscured by a helmet and so on. To one consumer the detail is irrelevant,
to another it's absolutely critical.
So, that in mind.
1. I don't believe it's possible, in many many instances, to create a
single image that meets the needs of both ends of the consumer spectrum.
2. Head insets and such do detract aesthetically and potentially introduce some
level of confusion.
3. Multiple-side collage images (front and back shown, also sometimes with an
inset) don't read well at small sizes. Take a look at any of the small black
torso images where there are front and back shown together. Those are dad-gum
near impossible to distinguish from one another. As thumbnails they fail to communicate
adequately.
4. Multiple side images may be misinterpreted as a "pair" of items and not "two
sides of a single item" kind of thing.
Trying to create an acceptable image in the absence of an "image codex"...particularly
in the case of minifigs...is challenging. A definitive set of guidelines would
be appreciated. Also, having the multiple images display in the popup is a step
in the right direction for the for the more hyper-aware customer.
In general, aesthetically, I'd like to see a 3/4 angle on minifigures become
the preferred angle. Here's why:
1. As time goes on, LEGO is incorporating more detail into some figures. Side
details on legs and arms become visible in 3/4 view.
2. Around-the-neck items like backpacks and airtanks can be more clearly shown
in a 3/4 view. Example: with full-frontal shots it's impossible, or nearly
so, to distinguish between an M:Tron fig with tanks and the same fig without.
3. From a technical standpoint, there are a lot of images in the gallery which
are shot either with a flash or the light positioned directly in front and slightly
above the image. This creates a strong white highlight on the top side of the
rounded part of the minifig legs (and sometimes in the middle of the face) and
obscures detail in those parts of the image. A 3/4 position would likely reflect
the light other than directly into the lens of the camera. The instruction to
turn the figure 30 degrees counterclockwise is easier to explain to non-technical
shooters than how to properly position lights, adjust exposure times, turn off
the flash, and the myriad other things one might do to improve the image.
4. Lego, as shiny plastic, can be particularly difficult to photograph well because
the surface is highly reflective. TLG itself tends to "paint out" reflections
in their promotional materials because of this. Any things that can be done to
reduce reflection and glare in the imagery is likely to make the image more communicative.
5. The "emphasis is on a presentation of the minifigure that will help sell it
to today’s consumer" here is being considered without context, and the context
should be an improved user interface sitewide, if greater sales are a goal. A
prettier set of thumbnails alone aren't going to be enough.
| | So in short, we think that your previously rejected images would stand a good
chance of being accepted today. And when in comes to parts, you have many, many
80 x 60 images in the BL system that could easily be upgraded to a larger size.
|
That comment elicits a chuckle from this end. "Easily" meaning I spend hours
combing through the archive to locate, extract, and upload them to BL. I appreciate
what I believe is the intended sentiment here, but, yeah. No. Not the top of
my priority list this week.
| | I understand the concern about mismanagement of images. But the site has actually not lost anything or corrupted it.
|
This is a matter of perspective. Or semantics. From my perspective, having one
contributor's content being credited to another constitutes corruption. When
the script ran that merged the two sets of images and the attribution was not
transferred, that constitutes corruption. The implication that you can correct
the situation eventually may be intended as reassurance, but (I'm going to
use metaphor here) in the immortal words of Cuba Gooding, Jr. "Show me the money."
| | If anything, we need to update the way credits are shown,
|
Yes.
| | and make sure that contributors know exactly why an image is rejected.
|
That would certainly be helpful and much appreciated.
|
|
| Author: | mfav | | Posted: | Jan 4, 2019 15:30 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 44 times | | Topic: | Catalog | |
|
| Thanks for the input.
I don't envy you the task of manually addressing every image in the catalog,
but suspect that's what it's going to take in the long run to remedy
this.
|
|
| Author: | mfav | | Posted: | Jan 4, 2019 15:17 | | Subject: | Re: Admin Russell, WTH images 2 | | Viewed: | 50 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | The attribution at the bottom of the catalog pages is not dynamic. Those attributions
go to whoever supplied the old small image and old large image for the default
image slot in the old system.
In the old system, the old small image slot was able to be chosen among all of
the available colors in all small image slots (one for each color). Whichever
color small image was chosen to be the default one was who the small image got
attributed to on the catalog page.
Also in the old system, only one large image slot was available. The image stored
in this slot was who the large image got attributed to on the catalog page.
These two images could have two different contributors in the old system, which
is why there are two different contributors listed on many catalog pages.
|
Yup. The old system. Which for all its inadequacies functioned consistently and
as expected.
| | With the advent of the new system that was put in place a while ago, these attributions
at the bottom of the catalog pages are kind of meaningless,
|
If they're meaningless, why are they included? I know you don't know,
but rhetorically...?
| | and I would not put any weight in them since large images can be stored in each slot for every color
a part comes in and there is no longer a sole large image slot.
|
Well, I'm not getting bent over the mechanics. Which I sort of understand.
I'm getting bent over the misrepresentation (which in this instance I see
as errors) and inconsistency.
| | The current catalog page needs some reworking, but the only attributions that truly matter now are the ones listed on pages such as the following
|
I think maybe you could choose a...uh...more accurate/less dismissive phrase
than "the only attributions that
truly matter". Perhaps you mean "the only attributions that are truly accurate."
| | As long as you submit your images under the correct color slot, then you will get the correct attribution on those pages.
|
Well, okay, as far as color images go. If you say so. And relative to the catalog
page. Sort of. Sometimes.
1. There's an image of mine sw269 which was submitted properly as far as
I can tell (granted, no color tagged with figs) and it's sitting in your
small images gallery.
I've contributed at least 36 starwars minifigs to the catalog. I'm represented
by 23 currently in the small images gallery, 26 in the large gallery. Where are
the others?
If you search for sw049 in the top search box, my sw049 shows in the auto-search-dropdown
thingy. Click through on that and you get somebody else's sw049.
https://www.bricklink.com/v2/catalog/catalogitem.page?id=8272#T=S&O={"rpp":"500","iconly":0}
Click through from that page to item consists of 3 Parts
http://www.bricklink.com/catalogItemInv.asp?M=sw049
There the sw049 thumbnail is mine. Click the thumbnail, you get the other image.
sw049 isn't in either my small or large gallery. But it's clearly in
the system somewhere. Where'd it go?
2. There's not 1:1 correlation between the set of images shown here
https://www.bricklink.com/catalogColors.asp?itemType=P&itemNo=30358&v=2
and the corresponding (sort of) images shown via the popup here
https://www.bricklink.com/v2/catalog/catalogitem.page?P=30358&idColor=1#T=C&C=2
Check out the tan image. On catalogColors.asp it's my image. On the part
popup on catalogitem.asp it's a render.
Click through the tan from this page
https://www.bricklink.com/catalogColors.asp?itemType=P&itemNo=30358&v=2
( When I click through, half the time the picture block comes up blank, half
the time it comes up with the render. So, YMMV.)
The non-corresponding tan images suggests that images are being called from different
sources. If there are multiple sources it suggests that something on the DB level
is out of sync. Or something feeding data into the db is not quite right. Or
there was some issue somewhere in the past when things got "combined" where things
got a bit out of sorts.
All I'm trying to do is let somebody know that there's something gone
awry. And I appreciate your time and explanation. But I'm not looking for
an explanation of how it's "working" or how it's supposed to work. I'm
looking for an explanation of what's gone wrong. Well. I'm hoping somebody
will look for an explanation of what's gone wrong and remedy it before it's
all FUBAR. Which it will be, if my experience of the last couple weeks is any
indication. Fixing things is more labor intensive than not creating a problem
in the first place, at least in my experience.
And, if it's helpful in any way, feel free to remove any images I've
submitted to the catalog altogether.
|
|
| 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.
|
|
| Author: | mfav | | Posted: | Jan 3, 2019 12:57 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 78 times | | Topic: | Catalog | |
|
| Well, now I can understand why the StormChaser is confused.
If the large image slot is going away, and the large images are going to then
slot into what now is the small slot...
...and I get keeping the small slot because the small slot had ALL colors of
a piece where the large slot typically had one "representative" image per piece
and not per color...
...then I think the solution would be to leave the small images as they were
(as those were the large images slotted down into the small slot) and change
the credit to the appropriate contributor.
If I understand the plan, which I may not, and apparently is also not clear to
more than just me, the plan is to replace all the small images with large images
as they become available. You're keeping the small slot because that slot
is already prepped to contain multiple colors of a piece where the large slot
is not...and you have small images of more pieces than you have large images.
I imagine that you'd lose ~70% of the images if you kept the large set and
abandoned the small set...because you don't have all colors in the large
set.
Right? So I can see the logic of that strategy.
Still.
That leaves me with these questions:
1. Why plug my small images back into the small slot? Why not leave the large-image-put-into-the-small-slot
(as this is the goal) and change the contributor? Seems like you're going
to have to go back and do that at some point.
2. All the legs images in question are recent contributions, and while they may
have slotted into the small slot correctly, that doesn't answer why the large
images are getting mis-attributed. And will the mis-attribution continue?
3. Are there other images in the system that are similarly mis-attributed?
4. I probably do have large images of many pieces for which previously there
were only small slots. However, in the case of the small minifig images in question
here, those large images were uploaded to the system at one time and rejected
in favor of another (usually existing) image for whatever reason. If they were
rejected before, why would I bother to go through the effort of finding all these
things and upload them to have them be rejected a second time?
I hope everyone understands I'm dispassionate about having my images included.
It's not an ego thing. I am concerned that I and other contributors are doing
what amounts to quite a bit of work, and there's a bug or flaw in the system
somewhere...or some bit of information hasn't been communicated appropriately...and
this problem persists, which may result in you having to go back to the contributors
and ask for a re-upload, and so on. And we're all chasing our tails. And
each other's tails.
In any event, I appreciate your efforts here. But you'll understand my reluctance
to comb through the back catalog of images I've created (or create new) and
upload them and so on without some assurance that they're going to be managed
efficiently and appropriately. I just see no sense in adding load to an existing
problem and I'd guess you don't want to be constantly manually fixing
all of it.
Thanks for the "fix" but I'm just not sure that the "why"...the reason for
things being out of whack...have been addressed as you shared no comment on that.
|
|
| Author: | mfav | | Posted: | Jan 2, 2019 17:23 | | Subject: | Re: Admin Russell, what's with the images? | | Viewed: | 70 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | It's all rather confusing, even to me, but I don't believe it is the
result of either human error or database corruption.
|
It has to be one or the other or both. It may occur in the underlying programming
which does whatever it does when an "old" image gets replaced (or bumped, or
set to primary, or whatever you call it) with a "new" image.
If my "new" "large" image replaced otherperson's "large" image...used to
be I'd get credit for "large" image. Now, in some circumstances which I cannot
define, my "new" image ends up being credited to the previous(?) large image
uploader. Or something.
There's not supposed to be either "large" or "small" image any more. Now
there's just "image" and where there used to be "small" and "large" there
is now "multiple"....at least that's how I understood the Great Image Declaration
from Russell some time back.
If my images are showing up in somebody else's register, and somebody else's
images are showing up in someotherbodyelse's register...well...that's
database corruption.
Maybe it's just programming, but something somewhere is awry. Just thinking
it's smarter to fix the problem now before another gazillion images get posted
and end up in the wrong slot and then need to be "fixed".
|
|
| Author: | mfav | | Posted: | Jan 2, 2019 16:33 | | Subject: | Admin Russell, what's with the images? | | Viewed: | 252 times | | Topic: | Catalog | | Status: | Open | |
|
| I'm noticing my "large" images for these items are showing up as being credited
to other contributors.
Kevin1990
- 970c00pb099
- 970c34pb01
swrbricks
- 970c10pb01
- 970c09pb01
- 970c11pb04
jennnifer
- 970c69pb01
- 970c00pb075
- 970c00pb195
Nikilyn
- 970c00pb337
hazelsden
- 970c86pb02
www_mybricks_de
- 970c00 (red)
And I'm credited for these "small" images which aren't mine...and no
idea whose they are.
air023
atl017
gen052
gen053
stu002
cty057
sw016
aqu011
lea005
sw049
twn029
pln100
pln003
pln050
pln057
pln058
pm012
soc034
(I thought the whole "small image" thing was kaput some time last year...no?)
If this is human error, that's one thing. If there are systemic issues or
database corruption or something else going on, then it probably should be looked
into before it gets worse.
|
|
| Author: | mfav | | Posted: | Dec 26, 2018 15:25 | | Subject: | Re: Move header buttons to the left side screen | | Viewed: | 29 times | | Topic: | Suggestions | |
|
| Possible kludge workaround is to go into the browser preferences, find where
you can adjust the fonts and sizes. Increase the font size. Then there should
be an option to override what the browser specifies. Save those changes. Go back
to browser window and use the control/command-minus keyboard shortcut to zoom-down
the screen. It won't be perfect, but may be somewhat more useable.
|
|
| Author: | mfav | | Posted: | Dec 20, 2018 21:25 | | Subject: | Re: Is there actually a 3626bpx28? | | Viewed: | 26 times | | Topic: | Catalog | |
|
| | This do? |
|
| Author: | mfav | | Posted: | Dec 20, 2018 21:01 | | Subject: | Re: Is there actually a 3626bpx28? | | Viewed: | 31 times | | Topic: | Catalog | |
|
| In Catalog, Brickitty writes:
| | In Catalog, baylit writes:
| | Or possible it reflects how long Bandit 1 had gone without shaving for each version
of him.
|
I actually LOLed.
|
Do you need this?
|
|
| Author: | mfav | | Posted: | Dec 20, 2018 20:58 | | Subject: | Re: Is there actually a 3626bpx28? | | Viewed: | 31 times | | Topic: | Catalog | |
|
| | okay, thanks. |
| Author: | mfav | | Posted: | Dec 20, 2018 19:38 | | Subject: | Re: Is there actually a 3626bpx28? | | Viewed: | 27 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | Sorry, didn't realize it was an attempt at humor. I've been getting
some occasionally unfriendly feedback of late and thus I've tended to assume
things are criticism unless stated otherwise.
|
Nope. Not a criticism.
This also not a (negative) criticism. An observation:
I am concerned that you can't maintain the frenzied pace you've set for
yourself these last couple months, though. It's ambitious and admirable.
But, hell, I'm exhausted from just watching you do all this stuff.
|
| Author: | mfav | | Posted: | Dec 20, 2018 19:00 | | Subject: | Re: Is there actually a 3626bpx28? | | Viewed: | 28 times | | Topic: | Catalog | |
|
| | so much for that attempt at humor |
| Author: | mfav | | Posted: | Dec 20, 2018 17:31 | | Subject: | Re: Is there actually a 3626bpx28? | | Viewed: | 40 times | | Topic: | Catalog | |
|
| In Catalog, axaday writes:
Yup. All instructions on Lego's web site show stubble on the figure.
If there was a stubble-less head, then which sets would it belong to?
Oh, well. We can all ignore it and then someone else bring up the question again
in six months.
|
| Author: | mfav | | Posted: | Dec 20, 2018 16:06 | | Subject: | Re: Is there actually a 3626bpx28? | | Viewed: | 32 times | | Topic: | Catalog | |
|
| will follow up off-forum
m
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
USA, Vermont
)
)
)
)
