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.
|
Next Page: 5 More | 10 More | 25 More | 50 More | 100 More
|
USA, Vermont
