|
 |
| | | Author: | Give.Me.A.Brick  | | Posted: | May 24, 2020 21:23 | | Subject: | Why are these Hinges? | | Viewed: | 293 times | | Topic: | Catalog | | Status: | Open | |
|
| 1.
* | | 37494 Bar 3.6L Double with Angled Ends (Train Pantograph Shoe)
Parts: Bar |
There is no hinge in it.
I understand it is familiar with:
* | | 2922 Hinge Train Pantograph Shoe Locking with 2 Fingers
Parts: Hinge |
and
but there is no hinge.
If they belong together then they should be in Train category?
2.
Again I understand the familiarity with:
and
* | | 44572 Panel 2 x 4 x 3 1/3 with Double Locking 2 Fingers Hinge
Parts: Panel |
But again, there is no hinge. If they really have to belong together, maybe they
should be in Panel category?
Just my opinion, anyway. What do you reckon?
|
|
|
| | | | | |
| | | | | Author: | StormChaser | | Posted: | May 25, 2020 00:00 | | Subject: | Re: Why are these Hinges? | | Viewed: | 91 times | | Topic: | Catalog | |
|
| In Catalog, Give.Me.A.Brick writes:
| | If they belong together then they should be in Train category?
|
| | But again, there is no hinge. If they really have to belong together, maybe they
should be in Panel category?
|
I would say take a look at this proposed page and see if it, in your opinion,
properly addresses this issue. If it does not, then offer suggestions for improving
it:
https://www.bricklink.com/help.asp?helpID=2479
The page is proposed now, but is expected to become official in about a week.
The purpose of the page is to determine the proper category in situations like
the one you mention.
Does it do its job, or does it need work?
|
|
| | | | | | | | | |
| | | | | | | Author: | wildchicken13 | | Posted: | May 25, 2020 00:05 | | Subject: | Re: Why are these Hinges? | | Viewed: | 53 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, Give.Me.A.Brick writes:
| | If they belong together then they should be in Train category?
|
| | But again, there is no hinge. If they really have to belong together, maybe they
should be in Panel category?
|
I would say take a look at this proposed page and see if it, in your opinion,
properly addresses this issue. If it does not, then offer suggestions for improving
it:
https://www.bricklink.com/help.asp?helpID=2479
The page is proposed now, but is expected to become official in about a week.
The purpose of the page is to determine the proper category in situations like
the one you mention.
Does it do its job, or does it need work?
|
Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | StormChaser | | Posted: | May 25, 2020 01:23 | | Subject: | Re: Why are these Hinges? | | Viewed: | 67 times | | Topic: | Catalog | |
|
| In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | wildchicken13 | | Posted: | May 25, 2020 02:39 | | Subject: | Re: Why are these Hinges? | | Viewed: | 49 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
If it were up to me, I would get rid of the hinge category altogether. Most of
the hinge parts look like they would fit better in a different category (brick
modified, plate modified, technic, train, vehicle, etc).
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | connie | | Posted: | May 25, 2020 05:24 | | Subject: | Re: Why are these Hinges? | | Viewed: | 39 times | | Topic: | Catalog | |
|
| The brick modified and plate modified categories are already too big. Have no
idea if they can be made smaller, but for sure lets not add anything to them.
connie
In Catalog, wildchicken13 writes:
| | In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
If it were up to me, I would get rid of the hinge category altogether. Most of
the hinge parts look like they would fit better in a different category (brick
modified, plate modified, technic, train, vehicle, etc).
|
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | StormChaser | | Posted: | May 25, 2020 10:37 | | Subject: | Re: Why are these Hinges? | | Viewed: | 50 times | | Topic: | Catalog | |
|
| In Catalog, wildchicken13 writes:
| | If it were up to me, I would get rid of the hinge category altogether. Most of
the hinge parts look like they would fit better in a different category (brick
modified, plate modified, technic, train, vehicle, etc).
|
The problem with Hinge is that some parts with a hinge were placed there solely
because they had a hinge (like some of the panels). However, other parts
with a hinge were placed into different categories (and this isn't all of
them):
* | | 4318 Boat, Mast 2 x 2 x 9 2/3 Bar with Slot on Top and 2 Finger Hinge on Two Sides
Parts: Boat |
* | | 30637 Container, Box Open Ended 2 x 4 x 4 with 1 Locking Hinge Finger on Each End
Parts: Container |
* | | 51858 Crane Bucket Lift Basket 2 x 3 x 2 with Locking Hinge Fingers
Parts: Crane |
* | | 2650 Hook Slider, Arm Base with Hinge with 3 Fingers
Parts: Hook |
* | | 30394 Vehicle, Digger Bucket 7 Teeth 3 x 6 with Locking 2 Finger Hinge
Parts: Vehicle |
The Hinge category should probably be defined as those parts that had no purpose
other than being a hinge. And even then it's still a problematic category.
I don't know that it would be eliminated completely, but there seems little
need for it when parts with a hinge can be located by typing "hinge" in the search
box.
The one thing I can say for sure is that it could definitely be expanded or pared
down. 
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 25, 2020 11:04 | | Subject: | Re: Why are these Hinges? | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | […]
The Hinge category should probably be defined as those parts that had no purpose
other than being a hinge. And even then it's still a problematic category.
I don't know that it would be eliminated completely, but there seems little
need for it when parts with a hinge can be located by typing "hinge" in the search
box.
|
Exactly.
Because defining a category by “purpose” (or “function”) is The Problem.
First, how can you know what’s the purpose of a piece you’ve never encountered?
Then, as the usual examples show, parts all have multiple functions. What’s
the main one? The first one? The most frequent one?
You need too much previous knowledge to even try to answer that.
If you already need to know which parts are in a category to know what’s in the
category, the category is useless.
Categories should help find the parts, not the other way around.
When you’re looking for a part, say a plate with appendices, you shouldn’t end
up in “Hinges” because you failed to find it in “Plate, Modified.”
Hinges, turntables, small fingers, locking fingers are all features that are
or should be present in the descriptions.
| | The one thing I can say for sure is that it could definitely be expanded or pared
down.
|
Expanding it means removing parts from other categories. But (most of) these
parts are in those categories for a reason, a supposedly good reason.
I say “Off with purpose-defined categories!”
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | StormChaser | | Posted: | May 25, 2020 11:11 | | Subject: | Re: Why are these Hinges? | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | I say “Off with purpose-defined categories!”
|
How would you define those and what categories do you consider to be purpose-defined?
I think these probably are, but beyond that I'm not sure which specific
ones you'd consider purpose-defined.
Bracket
Hinge
Hook
Projectile Launcher
Turntable
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | WhiteHorseMatt | | Posted: | May 25, 2020 11:18 | | Subject: | Re: Why are these Hinges? | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, SylvainLS writes:
| | I say “Off with purpose-defined categories!”
|
How would you define those and what categories do you consider to be purpose-defined?
I think these probably are, but beyond that I'm not sure which specific
ones you'd consider purpose-defined.
Bracket
Hinge
Hook
Projectile Launcher
Turntable
|
Merge Tail and Aircraft maybe?
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 25, 2020 11:32 | | Subject: | Re: Why are these Hinges? | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, SylvainLS writes:
| | I say “Off with purpose-defined categories!”
|
How would you define those and what categories do you consider to be purpose-defined?
I think these probably are, but beyond that I'm not sure which specific
ones you'd consider purpose-defined.
Bracket
|
Bracket is a shape.
Hinge is a function.
Shape.
Function.
Function.
If I encounter a part whose function “obviously” is to launch things (and there’s
no “projectile launcher” category and I know there’s no such category because
that would be a function category), I’ll search in a category matching its shape,
or try to search for the term “launcher” or “cannon” in its description.
It isn’t obvious to me that
is a projectile launcher. It’s a 1 x 4 brick with some sort of slot.
Obviously,
is NOT a projectile launcher. It’s not even obvious it’s a projectile.
But all the shapes aren’t equal. Hook is a shape but when you need to add parts
that are obviously not hook-shaped and barely manage 20 parts, then the category’s
existence is debatable.
(You’re looking for a hook? Search “hook” in the description.)
Isn’t a hook, it’s a slope with struts to attach a hook.
But then, there’s all the minifig utensils, weapons, tools….
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 25, 2020 11:36 | | Subject: | Re: Why are these Hinges? | | Viewed: | 41 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, StormChaser writes:
| | […]
The Hinge category should probably be defined as those parts that had no purpose
other than being a hinge. And even then it's still a problematic category.
I don't know that it would be eliminated completely, but there seems little
need for it when parts with a hinge can be located by typing "hinge" in the search
box.
|
Exactly.
Because defining a category by “purpose” (or “function”) is The Problem.
|
Well yes, I get how the distinction is "problematic"... but I don't think
there's a need to over-problematize this or make it too much of an intellectual
exercise. That is not a popular remark but I'll just be controversial here
and say the sooner we come to terms with this reality, the sooner we'll reach
solutions - which are not perfect, but good enough. If we don't accept it,
one change is going to lead to the next, which leads to uprooting the entire
system that has been laid out, putting it all back into place in a different
configuration, which tomorrow will seem arbitrary to someone else.
I really think that the only 1 solution that is "logically sound" and makes sense
from all angles you can possibly look at it, is putting all parts in 1 category
called "parts". I think even a second category would already raise confusion
or disagreement no matter what is is going to be based on. I'd say that's
just a fact of life.
But it's ok. We don't need to make a catalog that can be understood by
the dumbest robot. We need a catalog that can be understood by humans. And if
humans are naturally capable of picking 10 languages that can have like 3 arbitrary
genders and 20 cases, tenses, and countless exceptions in those systems, I'm
pretty sure people can deal with a part not being in the initial category they
had imagined it to be 
I think the catalog is and always will be a middle way between clinical logic
and common sense decisions. In the case of hinges, I would say: Parts that are
always part of pair, in order to facilitate movement (as I said before, it would
include turntables). Minus the ones that are primarily a different thing such
as a mast. The first part of that definition is clear-cut logic, the second part
is going to be imperfect.
In short, I'd say: Embrace the imperfection, it's gonna be here to stay
When I think about catalog improvement, instead of moving stuff, I'm thinking
about interface improvement, navigability, good search functions (tags), and
something that encourages users to learn. It's a hobby and people are willing
to learn. Whenever people are posting ID topics, their response is usually pretty
positive rather than something like "omg seriously? why on earth is it in that
category?" In my opinion, that is a compliment to the catmins and the community.
Don't wanna kill the discussion (which is always necessary!) but just want
to add that the catalog really is very good
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 25, 2020 12:16 | | Subject: | Re: Why are these Hinges? | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | […]
Well yes, I get how the distinction is "problematic"... but I don't think
there's a need to over-problematize this or make it too much of an intellectual
exercise. That is not a popular remark but I'll just be controversial here
and say the sooner we come to terms with this reality, the sooner we'll reach
solutions - which are not perfect, but good enough. If we don't accept it,
one change is going to lead to the next, which leads to uprooting the entire
system that has been laid out, putting it all back into place in a different
configuration, which tomorrow will seem arbitrary to someone else.
|
The French term is “révolution” and we make one from time to time.
New boss, same as old boss. But it gets the steam out 
| | […]
In short, I'd say: Embrace the imperfection, it's gonna be here to stay
|
But the categories definitions are already changing. So as it’s already changing,
we can discuss where it’s heading.
| | When I think about catalog improvement, instead of moving stuff, I'm thinking
about interface improvement, navigability, good search functions (tags), and
something that encourages users to learn.
|
Yes, but that’s not happening.
| | It's a hobby and people are willing
to learn. Whenever people are posting ID topics, their response is usually pretty
positive rather than something like "omg seriously? why on earth is it in that
category?"
|
Newcomers don’t challenge the established situation.
Older members are used to the categories being weird, they know it’s (was) useless
to discuss it.
| | In my opinion, that is a compliment to the catmins and the community.
Don't wanna kill the discussion (which is always necessary!) but just want
to add that the catalog really is very good
|
I sort my parts by shape, affinity, and size (and room ). It might be said
to somewhat look like the catalogue categories but only if you look at “bricks,
slopes, plates.” As soon as it gets more precise, it’s less and less like the
catalogue.
When I search for a part number, I look in LDraw or LDD. It’s quicker.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | calebfishn | | Posted: | May 25, 2020 13:46 | | Subject: | Re: Why are these Hinges? | | Viewed: | 27 times | | Topic: | Catalog | |
|
| Yes. I agree with this. 99% of parts in the hinge category are not confusing,
whatever the basis for their classification.
The category is not broken, even if it isn't perfect. And it will always
be the case that some parts in a category will need to be re-assessed and moved
from time to time.
I like the idea put forward that we keep the clip and handle/bar systems separate
from hinges.
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Teup | | Posted: | May 25, 2020 03:34 | | Subject: | Re: Why are these Hinges? | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
I agree with the OP these examples are not hinges as they work with the clips
system. Clips and hinges have always been a clear mutual exclusion. I'd keep
the Hinge category for the parts with the hinge systems that we all know and
understand as hinges: The 2/3 finger systems, the swivels, the 1x2 hinge bricks,
pretty much the way it is now, with the examples from this topic removed because
they work with clips and bars.
I think removing the category is thowing away the baby with the bathwater. Sure
you can think up some reasons why some hinge would be hard to find or why something
wouldbe inconsistent if you think about it, but if the conclusion is category
elimination, we will eventually end up with 1 category called "parts"
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | wildchicken13 | | Posted: | May 25, 2020 22:57 | | Subject: | Re: Why are these Hinges? | | Viewed: | 49 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
I agree with the OP these examples are not hinges as they work with the clips
system. Clips and hinges have always been a clear mutual exclusion. I'd keep
the Hinge category for the parts with the hinge systems that we all know and
understand as hinges: The 2/3 finger systems, the swivels, the 1x2 hinge bricks,
pretty much the way it is now, with the examples from this topic removed because
they work with clips and bars.
I think removing the category is thowing away the baby with the bathwater. Sure
you can think up some reasons why some hinge would be hard to find or why something
wouldbe inconsistent if you think about it, but if the conclusion is category
elimination, we will eventually end up with 1 category called "parts"
|
That is actually not a bad idea. It is generally easier to identify an unfamiliar
part by searching for its function and/or physical characteristics than it is
to find it in the catalog, unless you are good at guessing. So as long as part
names are descriptive enough and the catalog is searchable, the only function
of categories is to start arguments over what is a plate modified and what is
a hinge.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | 62Bricks | | Posted: | May 26, 2020 07:55 | | Subject: | Re: Why are these Hinges? | | Viewed: | 52 times | | Topic: | Catalog | |
|
| In Catalog, wildchicken13 writes:
| | In Catalog, Teup writes:
| | In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
I agree with the OP these examples are not hinges as they work with the clips
system. Clips and hinges have always been a clear mutual exclusion. I'd keep
the Hinge category for the parts with the hinge systems that we all know and
understand as hinges: The 2/3 finger systems, the swivels, the 1x2 hinge bricks,
pretty much the way it is now, with the examples from this topic removed because
they work with clips and bars.
I think removing the category is thowing away the baby with the bathwater. Sure
you can think up some reasons why some hinge would be hard to find or why something
wouldbe inconsistent if you think about it, but if the conclusion is category
elimination, we will eventually end up with 1 category called "parts"
|
That is actually not a bad idea. It is generally easier to identify an unfamiliar
part by searching for its function and/or physical characteristics than it is
to find it in the catalog, unless you are good at guessing. So as long as part
names are descriptive enough and the catalog is searchable, the only function
of categories is to start arguments over what is a plate modified and what is
a hinge.
|
No, you would not end up with one single category called parts. You would end
up with categories that describe the parts themselves so that someone not already
familiar with the part's complete usage or who is not current on 20 years
of forum debate can use the categories.
What is happening here is exactly backwards.
The problem is the categories, not the definitions of the categories.
What is happening here is people are imagining what they want the categories
to include, then arguing backward from that to come up with a definition that
will get them as close to that as possible.
That is backwards.
The way forward is to look at the attributes of the parts themselves and decide
how they can be meaningfully grouped. Any attributes that are subjective or
ambiguous - like how a part may sometimes be used - are not suitable for
basing categories on.
The parts should not be defined by the categories. The categories should be defined
by the parts.
This is possible even given the current limitations imposed by Bricklink's
"flat" category structure. But it requires turning the thinking around to be
done effectively.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 26, 2020 09:15 | | Subject: | Re: Why are these Hinges? | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | In Catalog, wildchicken13 writes:
| | In Catalog, Teup writes:
| | In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
I agree with the OP these examples are not hinges as they work with the clips
system. Clips and hinges have always been a clear mutual exclusion. I'd keep
the Hinge category for the parts with the hinge systems that we all know and
understand as hinges: The 2/3 finger systems, the swivels, the 1x2 hinge bricks,
pretty much the way it is now, with the examples from this topic removed because
they work with clips and bars.
I think removing the category is thowing away the baby with the bathwater. Sure
you can think up some reasons why some hinge would be hard to find or why something
wouldbe inconsistent if you think about it, but if the conclusion is category
elimination, we will eventually end up with 1 category called "parts"
|
That is actually not a bad idea. It is generally easier to identify an unfamiliar
part by searching for its function and/or physical characteristics than it is
to find it in the catalog, unless you are good at guessing. So as long as part
names are descriptive enough and the catalog is searchable, the only function
of categories is to start arguments over what is a plate modified and what is
a hinge.
|
No, you would not end up with one single category called parts. You would end
up with categories that describe the parts themselves so that someone not already
familiar with the part's complete usage or who is not current on 20 years
of forum debate can use the categories.
What is happening here is exactly backwards.
The problem is the categories, not the definitions of the categories.
What is happening here is people are imagining what they want the categories
to include, then arguing backward from that to come up with a definition that
will get them as close to that as possible.
That is backwards.
The way forward is to look at the attributes of the parts themselves and decide
how they can be meaningfully grouped. Any attributes that are subjective or
ambiguous - like how a part may sometimes be used - are not suitable for
basing categories on.
The parts should not be defined by the categories. The categories should be defined
by the parts.
This is possible even given the current limitations imposed by Bricklink's
"flat" category structure. But it requires turning the thinking around to be
done effectively.
|
Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.
Until that time, I really feel like the way you prefer it is still.. a preference.
Changing one imperfect system for another will leave us worse off than we were,
because we lost the history. It's kind of like designing a new language from
scratch because English is illogical. Don't forget that people worldwide
are not talking about "Plate modified", "Hinge".. (yes, the English words. Dutch
AFOLs have al learned to adopt the Bricklink terminology) To completely eradicate
the way we have talked about parts for 20 years and replace it with something
else, would really take a perfect system to make that worth it.
But sure, if your system is perfect, then we should do it. I just need to see
it before I will believe it For me the current system makes a lot of sense,
and at first glance a system that would ignore the common sense use of parts
does not sound appealing to me at all. But maybe I will just need to see it to
understand.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | StormChaser | | Posted: | May 26, 2020 10:04 | | Subject: | Re: Why are these Hinges? | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.
|
I would also like to see a reasonably comprehensive organizing of the catalog
using 62Bricks' vision. I'm confident he has good ideas, but I would
like to see an actual category tree with a decent selection of parts assigned
to categories (along with an explanation of how categorizing decisions are made).
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | Author: | 62Bricks | | Posted: | May 26, 2020 14:30 | | Subject: | Re: Why are these Hinges? | | Viewed: | 47 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.
|
I would also like to see a reasonably comprehensive organizing of the catalog
using 62Bricks' vision. I'm confident he has good ideas, but I would
like to see an actual category tree with a decent selection of parts assigned
to categories (along with an explanation of how categorizing decisions are made).
|
You can already see what it looks like, because the catalog already follows it
up to a point. It is where the catalog departs from it that we run into issues.
Categories like Tile, Round, Decorated are based on three independently observable
attributes of a part, placed in a ranked hierarchy from general to specific.
1. Primary shape/type (tile)
2. Secondary shape/attribute (round)
3. Decoration (yes)
using the title and info from inventories, it is possible to add more specific
information like mold variants, descriptions of the decoration, and the color.
General to specific.
None of these key attributes describe the part's usage. Each of them describes
something that can be observed by any user with no special knowledge of the part's
usage. That is how categories should be determined. If part usage is considered
important, it can be added in the title, at the "specific" end of the hierarchy.
Putting usage at the "general" end of the hierarchy means we lose all that general
information that is most useful in finding the part.
Look at the parts. Think about the attributes of the parts themselves that best
distinguish them and that can be determined by someone with no special knowledge,
then rank them in order from the most general to the most specific.
Then run each part down that list of attributes and classify it accordingly.
You don't have to imagine how it would work. It is already working in many
categories. We just need to take those categories that short-circuit this process
by putting the specific information at the wrong end - like "Hinge" - and put
their component parts back through the list of attributes above to see where
they end up. Then, if it appears that there is another level of attributes that
should be added based on the parts, a new category may form based on that.
It works.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 26, 2020 14:40 | | Subject: | Re: Why are these Hinges? | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | […]
You can already see what it looks like, because the catalog already follows it
up to a point. It is where the catalog departs from it that we run into issues. […]
|
You can also look at how LDraw describes the parts, they (try to) follow a shape
approach.
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | Author: | constructibles | | Posted: | May 26, 2020 15:24 | | Subject: | Re: Why are these Hinges? | | Viewed: | 39 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| |
Categories like Tile, Round, Decorated are based on three independently observable
attributes of a part, placed in a ranked hierarchy from general to specific.
1. Primary shape/type (tile)
2. Secondary shape/attribute (round)
3. Decoration (yes)
|
I really like this approach. We would end up with categories like:
Plate, Modified, Hinged
Brick, Modified, Hinged
Panel, Hinged
Makes it very logical and easy. Also it has the added benefit of potentially
reducing the quantity of parts in the 'modified' category by carving
off a couple larger sub-groups.
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 26, 2020 17:47 | | Subject: | Re: Why are these Hinges? | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.
|
I would also like to see a reasonably comprehensive organizing of the catalog
using 62Bricks' vision. I'm confident he has good ideas, but I would
like to see an actual category tree with a decent selection of parts assigned
to categories (along with an explanation of how categorizing decisions are made).
|
You can already see what it looks like, because the catalog already follows it
up to a point. It is where the catalog departs from it that we run into issues.
Categories like Tile, Round, Decorated are based on three independently observable
attributes of a part, placed in a ranked hierarchy from general to specific.
1. Primary shape/type (tile)
2. Secondary shape/attribute (round)
3. Decoration (yes)
using the title and info from inventories, it is possible to add more specific
information like mold variants, descriptions of the decoration, and the color.
General to specific.
None of these key attributes describe the part's usage. Each of them describes
something that can be observed by any user with no special knowledge of the part's
usage. That is how categories should be determined. If part usage is considered
important, it can be added in the title, at the "specific" end of the hierarchy.
Putting usage at the "general" end of the hierarchy means we lose all that general
information that is most useful in finding the part.
Look at the parts. Think about the attributes of the parts themselves that best
distinguish them and that can be determined by someone with no special knowledge,
then rank them in order from the most general to the most specific.
Then run each part down that list of attributes and classify it accordingly.
You don't have to imagine how it would work. It is already working in many
categories. We just need to take those categories that short-circuit this process
by putting the specific information at the wrong end - like "Hinge" - and put
their component parts back through the list of attributes above to see where
they end up. Then, if it appears that there is another level of attributes that
should be added based on the parts, a new category may form based on that.
It works.
|
I'm sorry but it still just looks like a personal preference to me... not
a bad one, but I don't yet see how this elimiates all problems.
The catalog is always a compromise. Findability of parts, usefulness of the categories,
a balanced size of the subcategories, other aspects probably...
It seems from your preference that you've assigned findability utter and
utmost importance and all choices are made based on that aspect. OK, but personally
I think findability is less important than meaningful categories that you can
browse to look for related parts or alternatives. For example, when I was building
and I was looking for some hinges to make a sloping roof, I could look at the
part I had in mind but also browse around other types of hinges that might work.
I think findability is something that is useful but only as long as you don't
yet know the catalog. After that - which is going to be the longest time - other
aspects become more important. Or at least, in my opinion.
I am willing to believe that your catalog would be the champion in findability.
I just don't agree it's the most important thing. I think this will always
be a personal preferences thing..
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | Author: | 62Bricks | | Posted: | May 26, 2020 18:38 | | Subject: | Re: Why are these Hinges? | | Viewed: | 47 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | In Catalog, 62Bricks writes:
| | In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.
|
I would also like to see a reasonably comprehensive organizing of the catalog
using 62Bricks' vision. I'm confident he has good ideas, but I would
like to see an actual category tree with a decent selection of parts assigned
to categories (along with an explanation of how categorizing decisions are made).
|
You can already see what it looks like, because the catalog already follows it
up to a point. It is where the catalog departs from it that we run into issues.
Categories like Tile, Round, Decorated are based on three independently observable
attributes of a part, placed in a ranked hierarchy from general to specific.
1. Primary shape/type (tile)
2. Secondary shape/attribute (round)
3. Decoration (yes)
using the title and info from inventories, it is possible to add more specific
information like mold variants, descriptions of the decoration, and the color.
General to specific.
None of these key attributes describe the part's usage. Each of them describes
something that can be observed by any user with no special knowledge of the part's
usage. That is how categories should be determined. If part usage is considered
important, it can be added in the title, at the "specific" end of the hierarchy.
Putting usage at the "general" end of the hierarchy means we lose all that general
information that is most useful in finding the part.
Look at the parts. Think about the attributes of the parts themselves that best
distinguish them and that can be determined by someone with no special knowledge,
then rank them in order from the most general to the most specific.
Then run each part down that list of attributes and classify it accordingly.
You don't have to imagine how it would work. It is already working in many
categories. We just need to take those categories that short-circuit this process
by putting the specific information at the wrong end - like "Hinge" - and put
their component parts back through the list of attributes above to see where
they end up. Then, if it appears that there is another level of attributes that
should be added based on the parts, a new category may form based on that.
It works.
|
I'm sorry but it still just looks like a personal preference to me... not
a bad one, but I don't yet see how this elimiates all problems.
The catalog is always a compromise. Findability of parts, usefulness of the categories,
a balanced size of the subcategories, other aspects probably...
It seems from your preference that you've assigned findability utter and
utmost importance and all choices are made based on that aspect. OK, but personally
I think findability is less important than meaningful categories that you can
browse to look for related parts or alternatives. For example, when I was building
and I was looking for some hinges to make a sloping roof, I could look at the
part I had in mind but also browse around other types of hinges that might work.
I think findability is something that is useful but only as long as you don't
yet know the catalog. After that - which is going to be the longest time - other
aspects become more important. Or at least, in my opinion.
I am willing to believe that your catalog would be the champion in findability.
I just don't agree it's the most important thing. I think this will always
be a personal preferences thing..
|
It might well be that after setting a hierarchy of attributes, all the hinges
end up in the same category again - but that would be the result of making choices
about what the attributes should be and where to rank them when sorting parts.
It's not an either-or proposition.
I well understand the resistance to thinking about the catalog in a systematic
way. People who have spent years using it do not want anything moved. But there
appears to be general agreement that it is a bad thing that so many similar parts
are scattered around the catalog, and so many apparently dissimilar parts are
grouped together.
My point is not one about personal preference, it is simply to point out that
the cause of that issue is not that the categories are not defined clearly enough,
it is that many of the existing categories were not built from the ground up
based on attributes of the parts. They were imposed from the top down, and redefining
them simply re-imposes them from the top down with a new set of criteria. It
does not fix the root cause.
In fact, creating a system like this would eliminate the "personal preference"
that is built into the current system, and which is a major source of this problem:
The most common usage for this part
is to hold parts that swing back and forth like gates, doors, and shutters. In
other words, as part of a hinge. But you did not see it when you were browsing
the hinge category looking for solutions to your roof build, because it is not
in the hinge category. It's a Brick, Modified.
Why is it there? Because someone made a judgement call about where it should
go. I don't know what criteria they used, but the catalog is full of examples
like this where parts can fit into more than one category and there seems to
be no evident reason for choosing one over the other aside from personal preference
of the submitter, the admins, or both.
An attribute-based system would not necessarily eliminate the issue that a part
might fit in more than one category, but it would rank the attributes so it was
clear and consistent which ones have priority when assigning it to a category.
This is just as it is done currently when we make "brick" more important than
"round" and "decorated," and we make "decorated" less important than "round."
It's not a revolutionary idea. It is already in place. It just needs to be
expanded.
I think the current project to redefine the categories is an acknowledgment that
leaving these kinds of decisions up to personal preference is undesirable. But
the approach to resolving it is from the wrong direction.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 27, 2020 04:40 | | Subject: | Re: Why are these Hinges? | | Viewed: | 52 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | In Catalog, Teup writes:
| | In Catalog, 62Bricks writes:
| | In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | Well, maybe if you would put together a catalog according to your philosophy
and show it and then it'd convince me that it makes sense, then I will agree
with you.
|
I would also like to see a reasonably comprehensive organizing of the catalog
using 62Bricks' vision. I'm confident he has good ideas, but I would
like to see an actual category tree with a decent selection of parts assigned
to categories (along with an explanation of how categorizing decisions are made).
|
You can already see what it looks like, because the catalog already follows it
up to a point. It is where the catalog departs from it that we run into issues.
Categories like Tile, Round, Decorated are based on three independently observable
attributes of a part, placed in a ranked hierarchy from general to specific.
1. Primary shape/type (tile)
2. Secondary shape/attribute (round)
3. Decoration (yes)
using the title and info from inventories, it is possible to add more specific
information like mold variants, descriptions of the decoration, and the color.
General to specific.
None of these key attributes describe the part's usage. Each of them describes
something that can be observed by any user with no special knowledge of the part's
usage. That is how categories should be determined. If part usage is considered
important, it can be added in the title, at the "specific" end of the hierarchy.
Putting usage at the "general" end of the hierarchy means we lose all that general
information that is most useful in finding the part.
Look at the parts. Think about the attributes of the parts themselves that best
distinguish them and that can be determined by someone with no special knowledge,
then rank them in order from the most general to the most specific.
Then run each part down that list of attributes and classify it accordingly.
You don't have to imagine how it would work. It is already working in many
categories. We just need to take those categories that short-circuit this process
by putting the specific information at the wrong end - like "Hinge" - and put
their component parts back through the list of attributes above to see where
they end up. Then, if it appears that there is another level of attributes that
should be added based on the parts, a new category may form based on that.
It works.
|
I'm sorry but it still just looks like a personal preference to me... not
a bad one, but I don't yet see how this elimiates all problems.
The catalog is always a compromise. Findability of parts, usefulness of the categories,
a balanced size of the subcategories, other aspects probably...
It seems from your preference that you've assigned findability utter and
utmost importance and all choices are made based on that aspect. OK, but personally
I think findability is less important than meaningful categories that you can
browse to look for related parts or alternatives. For example, when I was building
and I was looking for some hinges to make a sloping roof, I could look at the
part I had in mind but also browse around other types of hinges that might work.
I think findability is something that is useful but only as long as you don't
yet know the catalog. After that - which is going to be the longest time - other
aspects become more important. Or at least, in my opinion.
I am willing to believe that your catalog would be the champion in findability.
I just don't agree it's the most important thing. I think this will always
be a personal preferences thing..
|
It might well be that after setting a hierarchy of attributes, all the hinges
end up in the same category again - but that would be the result of making choices
about what the attributes should be and where to rank them when sorting parts.
It's not an either-or proposition.
I well understand the resistance to thinking about the catalog in a systematic
way. People who have spent years using it do not want anything moved. But there
appears to be general agreement that it is a bad thing that so many similar parts
are scattered around the catalog, and so many apparently dissimilar parts are
grouped together.
My point is not one about personal preference, it is simply to point out that
the cause of that issue is not that the categories are not defined clearly enough,
it is that many of the existing categories were not built from the ground up
based on attributes of the parts. They were imposed from the top down, and redefining
them simply re-imposes them from the top down with a new set of criteria. It
does not fix the root cause.
In fact, creating a system like this would eliminate the "personal preference"
that is built into the current system, and which is a major source of this problem:
The most common usage for this part
is to hold parts that swing back and forth like gates, doors, and shutters. In
other words, as part of a hinge. But you did not see it when you were browsing
the hinge category looking for solutions to your roof build, because it is not
in the hinge category. It's a Brick, Modified.
Why is it there? Because someone made a judgement call about where it should
go. I don't know what criteria they used, but the catalog is full of examples
like this where parts can fit into more than one category and there seems to
be no evident reason for choosing one over the other aside from personal preference
of the submitter, the admins, or both.
An attribute-based system would not necessarily eliminate the issue that a part
might fit in more than one category, but it would rank the attributes so it was
clear and consistent which ones have priority when assigning it to a category.
This is just as it is done currently when we make "brick" more important than
"round" and "decorated," and we make "decorated" less important than "round."
It's not a revolutionary idea. It is already in place. It just needs to be
expanded.
I think the current project to redefine the categories is an acknowledgment that
leaving these kinds of decisions up to personal preference is undesirable. But
the approach to resolving it is from the wrong direction.
|
Well, true, the catalog mostly just grew this way, which means that it is likely
that there are things to gain by thinking about it more systematically.
I guess I just need to see an example of part of that catalog to really be able
to say something about it. Because right now I'm just imagining it would
be some kind of system where you have a perfect taxonomy to determinate a part
you have in hand, but the categories would not be semantically coherent. Probably
I am imagining something too radical than how you intended it.
Like you could classify animals based on their taxonomy and put them in mammals,
birds, fish, amphibiae etc. Then you can systematically identify them beyond
a doubt, but those groups are not necessarily relevant if you look on a semantic
level of what "type" of animals they are. I can even connect the metaphor literally
to Bricklink: "Animal, Air/Land/Water" are imperfect categories (I believe frogs
are in "land"?). Rearranging them according to "Animal,Vertebrate", "Animal,Anthropod"
etc., would logically solve the problem perfectly and give us 100% consistency
and logic. But those categories would feel less relevant and meaningful when
you're shopping and browsing.
Now I'm just warning in general that a too technical systematic could defeat
the purpose. I cannot say to what extend that applies to what you propose. Just
saying we have to keep in mind the problem we really are trying to solve with
it, which is practical problems in its use - even if that would mean having imperfect
intellectually unsatisfactory categories that leave a bit of gray area.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 26, 2020 18:42 | | Subject: | Re: Why are these Hinges? | | Viewed: | 42 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | The catalog is always a compromise. Findability of parts, usefulness of the categories,
a balanced size of the subcategories, other aspects probably...
|
Define “usefulness of the categories.”
I note that you have dfficulties finding the “other aspects” a categorisation
would have that could serve better (or at all).
| | It seems from your preference that you've assigned findability utter and
utmost importance and all choices are made based on that aspect. OK, but personally
I think findability is less important than meaningful categories that you can
browse to look for related parts or alternatives. For example, when I was building
and I was looking for some hinges to make a sloping roof, I could look at the
part I had in mind but also browse around other types of hinges that might work.
|
Sorry to say, but that “meaningfulness” of categories you describe is actually
also findability.
You want a “Hinges” category so you can find hinges more easily.
You can do that by looking for the term “hinge” in descriptions.
It’s not different from looking for “3 x 3” because you need a “3 x 3” piece
and they are all over the categories.
(And I won’t even go into the problem that the “Hinges” category doesn’t include
many related and alternative pieces, like clips & handles or towballs & their
sockets. So neither looking for “hinge” nor looking into a “hinge” category
gives you all the related parts or alternatives. Indeed, both should give you
the same results.)
| | I think findability is something that is useful but only as long as you don't
yet know the catalog. After that - which is going to be the longest time - other
aspects become more important. Or at least, in my opinion.
|
What other aspects? You still haven’t given examples.
What are categories for if not to ease the process of finding parts by reducing
their number?
Furthermore, you’re saying once one knows the catalogue, they don’t need to find
parts anymore.
Well, first, you still need to find parts, it’s just that you know where many
of them are or should/would be.
Second, even very experienced BLers have problems finding parts (see the forum
requests, they don’t all come from newbies). Even the catmins don’t know all
the parts ( https://www.bricklink.com/message.asp?ID=1199626 ).
Third, the “longest time” is for those who have been here the longest (obviously),
and that’s the very thin tail of the curve. Having no prior knowledge is the
lot of many many more people. And those people are new buyers who should interest
you the most (you seller!). (All the other ones may be return-buyers but they
are very old (having been there the longest) and won’t be there much longer.)
| | I am willing to believe that your catalog would be the champion in findability.
I just don't agree it's the most important thing.
|
But the only usage you gave was another example of findability….
| | I think this will always be a personal preferences thing..
|
Preference in how you find things. On one side, for anyone with no prior knowledge,
on the other side, for you, who have some knowledge and ingrained habits.
So, whom should the catalogue serve? Those who don’t need it or those who do?
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | randyf | | Posted: | May 27, 2020 01:43 | | Subject: | Re: Why are these Hinges? | | Viewed: | 45 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
I'm not a catmin.
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 27, 2020 07:03 | | Subject: | Re: Why are these Hinges? | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | In Catalog, SylvainLS writes:
I'm not a catmin.
|
Not even a cat?
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 27, 2020 04:23 | | Subject: | Re: Why are these Hinges? | | Viewed: | 41 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | The catalog is always a compromise. Findability of parts, usefulness of the categories,
a balanced size of the subcategories, other aspects probably...
|
Define “usefulness of the categories.”
I note that you have dfficulties finding the “other aspects” a categorisation
would have that could serve better (or at all).
|
(...)
| | What other aspects? You still haven’t given examples.
|
Well here's what comes to my mind right now.
Meaningful categories: You could sort a supermarket based on size of the products
of based on alphabet, and it would be extremely easy to find a cauliflower. But
the aisles would not have meaningful categories. The result is that it is easy
to find a single product while at the same time browsing the store is very inconvenient.
Navigability: You can know where a part is, but if it would take many clicks
or staring at the screen, it is still inconvenient to use. For example if the
system would have many subcategories, which we don't at this point, or if
the category would be so large that it has many pages, which we do have.
I don't want to pretend I know what "the" functions of the catalog are, probably
other users have other concerns too, that's why I was vague.
| | Sorry to say, but that “meaningfulness” of categories you describe is actually
also findability.
You want a “Hinges” category so you can find hinges more easily.
You can do that by looking for the term “hinge” in descriptions.
|
(...)
| | Furthermore, you’re saying once one knows the catalogue, they don’t need to find
parts anymore.
Well, first, you still need to find parts, it’s just that you know where many
of them are or should/would be.
|
I understand you can also use "findability" as an umbrella term for all three
aspects that I mention here, but I do think there they can be separated. The
latter is what I call navigability. You are right that they often are in line
with each other, but they can also conflict. Something can be easy to find for
a new user but take time to reach, or something can be reached instantly but
hard to find if you don't yet know where to look. Something can be in a meaningful
category, but based on the one single part you have in your hand, with no prior
knowledge, you could not know what group it's been put into. For example
a product in the supermarket may be hard to find in and of itself, but once you
see it's in the baking aisle you can see how it's useful to have there
for people that are baking things.
So what I'm saying is that these are separate interests, that can sometimes
can conflict. It's about weighing their importance, which by definition means
a catalog is a compromise and does not have a single correct answer that we should
look for. If the catalog had 1 single function and everything could be rearranged
in one mathematically correct solution to cater to that function, I'd say
go for it. But since it is a compromise, it will be replacing one compromise
with another.
That's not to say though that we shouldn't move parts. We definitely
should. It's just that I don't feel that reimagining the catalog would
ever bring us further than where we are now. But maybe I'm imagining 62Bricks
proposed changes as something more dramatic than they really are intended. Right
now I'm just thinking about a system that would have perfect findability
(e.g. categorising all part according to their footprint dimensions or whatever)
but semantically incoherent categories. But I guess it wasn't meant like
that.
By the way, I also think we mustn't forget which problem we are trying to
solve. Is it about solving practical problems with its use, or is it about solving
our feeling of dissatisfaction on some intellectual level? I feel a bit of both
are involved. So how big are the practical problems with the catalog really?
I'm honestly curious. I wonder what info we have that suggests dramatic overhauls
are needed. You'd have to watch people use Bricklink in order to find out
I guess. But if I had to go by the number of ID topics, the people who ask are
vastly outnumbered by the people who answer. But of course, that doesn't
count the times someone had to search for too long.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | 62Bricks | | Posted: | May 27, 2020 08:33 | | Subject: | Re: Why are these Hinges? | | Viewed: | 40 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| |
Well here's what comes to my mind right now.
Meaningful categories: You could sort a supermarket based on size of the products
of based on alphabet, and it would be extremely easy to find a cauliflower. But
the aisles would not have meaningful categories. The result is that it is easy
to find a single product while at the same time browsing the store is very inconvenient.
|
That is an extreme example, but it is a good point. So the conclusion might be
that "First letter of the common English name" is not a suitable attribute for
grouping items. It tells you nothing about the item itself and so leads to categories
that are not meaningful.
And while size is a physical attribute of the item itself, it is not meaningful,
because people do not generally select food by size. It is in the selecting of
the attributes that the final groups are shaped.
What a supermarket actually does is a good real-life example of what a part catalog
could do. It uses meaningful attributes and the end result is meaningful organization.
Usually, the most general attribute is whether the item is fresh or packaged.
Produce, meat, flowers, fresh-baked goods all have their own sections separate
from the packaged goods.
The next level of attribute you find applied in, say, the produce section is
"Fruit or vegetable?" Fruits are grouped with fruits, vegetables with vegetables.
That is based on some foreknowledge on the part of the shopper of the difference
between the two, but it is common knowledge, not specialized knowledge.
Finally, an attribute based on how the item grows is used - roots, bulbs, vines,
leafy plants, trees, etc.
And so running everything through those levels you find the apples, pears and
oranges near each other. You find the turnips and potatoes together. Onions,
garlic and shallots are usually close by. Tomatoes and peppers are together.
You'll find the cauliflower by the broccoli, celery and greens, usually.
By choosing meaningful attributes you get useful and meaningful categories.
But now imagine the supermarket added a category called "Ingredients for pizza."
Now the top-level attribute is no longer a general one like whether it is fresh
or packaged, it is based on a specific usage: whether it can be used to make
pizza. Now the tomato sauce, cheese, flour, yeast and salt are pulled out of
their respective aisles, where they were previously grouped with like items based
on the general-to-specific model, and put together in a separate part of the
store.
Is that a meaningful category? It is for someone who wants to make pizza. Is
it meaningful for someone who wants to make pasta sauce?
That person might reasonably go the aisle that has all the canned tomato products
expecting to find tomato sauce. But it won't be there. To track it down he
has to know two things - this supermarket has a "pizza ingredient" section, and
tomato sauce is a pizza ingredient. That it is also an ingredient in countless
other dishes makes no difference, this supermarket has determined that "pizza"
is its primary purpose and so has stuck it away in a different spot.
He might ask the manager, "Why is your supermarket organized in such a strange
way?"
"Good point," the manager might reply. "Here let's fix that - we've re-written
our definition of 'canned tomato goods' so now it reads 'canned tomato
goods that are not also pizza ingredients.' We'll be posting this on
the bulletin board at the back of the store by the restrooms so everyone will
know where to find the tomato sauce."
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 27, 2020 09:01 | | Subject: | Re: Why are these Hinges? | | Viewed: | 40 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | In Catalog, Teup writes:
| |
Well here's what comes to my mind right now.
Meaningful categories: You could sort a supermarket based on size of the products
of based on alphabet, and it would be extremely easy to find a cauliflower. But
the aisles would not have meaningful categories. The result is that it is easy
to find a single product while at the same time browsing the store is very inconvenient.
|
That is an extreme example, but it is a good point. So the conclusion might be
that "First letter of the common English name" is not a suitable attribute for
grouping items. It tells you nothing about the item itself and so leads to categories
that are not meaningful.
And while size is a physical attribute of the item itself, it is not meaningful,
because people do not generally select food by size. It is in the selecting of
the attributes that the final groups are shaped.
What a supermarket actually does is a good real-life example of what a part catalog
could do. It uses meaningful attributes and the end result is meaningful organization.
Usually, the most general attribute is whether the item is fresh or packaged.
Produce, meat, flowers, fresh-baked goods all have their own sections separate
from the packaged goods.
The next level of attribute you find applied in, say, the produce section is
"Fruit or vegetable?" Fruits are grouped with fruits, vegetables with vegetables.
That is based on some foreknowledge on the part of the shopper of the difference
between the two, but it is common knowledge, not specialized knowledge.
Finally, an attribute based on how the item grows is used - roots, bulbs, vines,
leafy plants, trees, etc.
And so running everything through those levels you find the apples, pears and
oranges near each other. You find the turnips and potatoes together. Onions,
garlic and shallots are usually close by. Tomatoes and peppers are together.
You'll find the cauliflower by the broccoli, celery and greens, usually.
By choosing meaningful attributes you get useful and meaningful categories.
But now imagine the supermarket added a category called "Ingredients for pizza."
Now the top-level attribute is no longer a general one like whether it is fresh
or packaged, it is based on a specific usage: whether it can be used to make
pizza. Now the tomato sauce, cheese, flour, yeast and salt are pulled out of
their respective aisles, where they were previously grouped with like items based
on the general-to-specific model, and put together in a separate part of the
store.
Is that a meaningful category? It is for someone who wants to make pizza. Is
it meaningful for someone who wants to make pasta sauce?
That person might reasonably go the aisle that has all the canned tomato products
expecting to find tomato sauce. But it won't be there. To track it down he
has to know two things - this supermarket has a "pizza ingredient" section, and
tomato sauce is a pizza ingredient. That it is also an ingredient in countless
other dishes makes no difference, this supermarket has determined that "pizza"
is its primary purpose and so has stuck it away in a different spot.
He might ask the manager, "Why is your supermarket organized in such a strange
way?"
"Good point," the manager might reply. "Here let's fix that - we've re-written
our definition of 'canned tomato goods' so now it reads 'canned tomato
goods that are not also pizza ingredients.' We'll be posting this on
the bulletin board at the back of the store by the restrooms so everyone will
know where to find the tomato sauce."
|
True, even though actually they have such things - there is/was an isle for wrap
ingredients here. There's an isle for Mexican dishes, for Asian dishes..
and you're right that's where it gets tricky. Because jalapenos are in
the Mexican section and not in the pepper section with the chilis. Greek peppers
may be somewhere else. Conserved fruit cans are in the section with the conserved
vegetables, but conserved fruit cans that are intended for pies are in the baking
section. So yeah, this is definitely where it gets tricky.
Supermarkets are highly professional and adapted businesses where everything
down to what exact songs are being played is laid out to get the most out of
everything. If even they struggle with these issues, I think we are doing really
well here. Not as an excuse not to do anything, but having some dilemmas doesn't
mean we failed.
I do think some degree of less technical and more thematic categories are good,
even if it causes a bit of gray area. A supermarket couldn't do without a
baking section, or a section for different kinds of lunch snacks, a section for
stuff to put on a sandwich, etc. You're definitely right it shouldn't
go overboard. But I do think it's great we have a "windscreen" and a "panel"
section even if there are some panels that work as windscreens and some opaque
windscreens. The general concepts of windscreens and panels are meaningful when
you're building and shouldn't be tossed away because we can't reach
a 100% logical consistency there.
All in all, I think the important thing is that when a customer goes to some
aisle/category with a certain thought, they should be surrounded by items in
that area that are relevant and that allow them to choose or pick a few more
things. If you're thinking about putting egg salad on a sandwich and you
see there's also hummus and slices of this and that, that is really helpful
and you might also buy more. Whatever catalog system still provides categories
that are helpful for the buyer and give them some overview to brainstorm, is
fine with me.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 27, 2020 09:22 | | Subject: | Re: Why are these Hinges? | | Viewed: | 31 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | […]
Supermarkets are highly professional and adapted businesses where everything
down to what exact songs are being played is laid out to get the most out of
everything. If even they struggle with these issues, […]
|
But do they struggle?
I think they just make choices.
They also sometimes put the products in two places. (They can, we can’t.)
They aren’t struggling to know where the products should be. They choose where
to put them for reasons you don’t necessarily know (but generally do): it’s the
season, it’s for promotions, it’s for novelty / make the store alive, it’s to
cater to some new or newly recognized needs, etc.
Sometimes, the even simply move things around to make you look for them and browse
the shelves and find something else to buy.
Here, they are making attractive stands.
Maybe there’s a lot of people who come in that particular store every day at
lunchtime to get sandwich products. Three blocks away, another store doesn’t
have (or hasn’t yet recognized they have) the same kind of client, so they don’t
have a sandwich stand.
| | , I think we are doing really well here.
|
Analogies are always imperfect and limited. One shouldn’t try to see more into
them than what there is.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 27, 2020 08:39 | | Subject: | Re: Why are these Hinges? | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | […]
| | What other aspects? You still haven’t given examples.
|
Well here's what comes to my mind right now.
Meaningful categories: You could sort a supermarket based on size of the products
of based on alphabet, and it would be extremely easy to find a cauliflower. But
the aisles would not have meaningful categories. The result is that it is easy
to find a single product while at the same time browsing the store is very inconvenient.
|
As you define “meaningful,” shape is meaningful and function isn’t, or is less
meaningful.
Function is like alphabetical order: you need prior knowledge, arbitrary prior
knowledge, prior knowledge that you can’t guess by looking at a part.
| | Navigability: You can know where a part is, but if it would take many clicks
or staring at the screen, it is still inconvenient to use. For example if the
system would have many subcategories, which we don't at this point, or if
the category would be so large that it has many pages, which we do have.
[…]
So what I'm saying is that these are separate interests, that can sometimes
can conflict. […]
|
That’s what the prioritization of the attributes does.
You first find the attributes, then you prioritize them to have categories of
reasonable sizes while keeping simpler, more basic, attributes first (because
they simpler, more direct, to see in a part), and avoid conflicts.
It’s still arbitrary but systematic, needing less arbritrary / specialized prior
knowledge.
The problem with the catalogue now is that it’s inconsistent: there’s no system,
or rather, there are several conflicting systems. Some categories are shape-oriented,
others are function-oriented. Some categories are almost empty, others are full
to the gills.
When a new part arrives or when you’re searching for a part, there often are
several categories in which it can fall, because they are orthogonal categories
(one is shape, one is function) or because there’s no priority (the part mixes
two shapes with the same priority (is 43093 a pin with an axle or an axle with
a pin?)).
What the current project is trying to do is to first refine the categories’ definitions,
but not the categories themselves, hoping it will allow to define clear boundaries.
It might solve the Plate vs. Tile problem but it won’t solve the problem that
a hinged-plate is both a plate and a hinge, it will just put a lot of exceptions
in the definitions and the need of prior knowledge to prevent putting it and
looking for it in the Plate, Modified category.
We already know most of the attributes because they are already used in the category
names: brick, plate, round, hose, decorated, etc. There even is a prioritization
(brick ≫ round ≫ decorated).
What should be done is determine which attributes conflict and need prioritization
or deletion. That means the attributes need to be defined (what’s “hinge”?
it’s a function, it’s orthogonal with primary shape-attributes like brick and
plate, how do we prioritize them?) not the categories (what parts are in “Hinge”?
oh, they could also be elsewhere, let’s massage all the definitions to keep
(most of) them there).
| | By the way, I also think we mustn't forget which problem we are trying to
solve. Is it about solving practical problems with its use, or is it about solving
our feeling of dissatisfaction on some intellectual level? I feel a bit of both
are involved.
|
True.
| | So how big are the practical problems with the catalog really?
I'm honestly curious. I wonder what info we have that suggests dramatic overhauls
are needed. You'd have to watch people use Bricklink in order to find out
I guess. But if I had to go by the number of ID topics, the people who ask are
vastly outnumbered by the people who answer.
|
Not true. It’s always the same people who answer.
(Old timers who know the parts, and how they are arranged in the catalogue, or
have developped tricks to circumvent its inconsistencies, or have simply memorized
those inconsistencies.)
| | But of course, that doesn't count the times someone had to search for too long.
|
Or abandoned and didn’t come to the forum to ask, putting the part in their “what’s
that?” bin for later (a.k.a. never).
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 27, 2020 09:29 | | Subject: | Re: Why are these Hinges? | | Viewed: | 49 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | […]
| | What other aspects? You still haven’t given examples.
|
Well here's what comes to my mind right now.
Meaningful categories: You could sort a supermarket based on size of the products
of based on alphabet, and it would be extremely easy to find a cauliflower. But
the aisles would not have meaningful categories. The result is that it is easy
to find a single product while at the same time browsing the store is very inconvenient.
|
As you define “meaningful,” shape is meaningful and function isn’t, or is less
meaningful.
Function is like alphabetical order: you need prior knowledge, arbitrary prior
knowledge, prior knowledge that you can’t guess by looking at a part.
| | Navigability: You can know where a part is, but if it would take many clicks
or staring at the screen, it is still inconvenient to use. For example if the
system would have many subcategories, which we don't at this point, or if
the category would be so large that it has many pages, which we do have.
[…]
So what I'm saying is that these are separate interests, that can sometimes
can conflict. […]
|
That’s what the prioritization of the attributes does.
You first find the attributes, then you prioritize them to have categories of
reasonable sizes while keeping simpler, more basic, attributes first (because
they simpler, more direct, to see in a part), and avoid conflicts.
It’s still arbitrary but systematic, needing less arbritrary / specialized prior
knowledge.
The problem with the catalogue now is that it’s inconsistent: there’s no system,
or rather, there are several conflicting systems. Some categories are shape-oriented,
others are function-oriented. Some categories are almost empty, others are full
to the gills.
When a new part arrives or when you’re searching for a part, there often are
several categories in which it can fall, because they are orthogonal categories
(one is shape, one is function) or because there’s no priority (the part mixes
two shapes with the same priority (is 43093 a pin with an axle or an axle with
a pin?)).
What the current project is trying to do is to first refine the categories’ definitions,
but not the categories themselves, hoping it will allow to define clear boundaries.
It might solve the Plate vs. Tile problem but it won’t solve the problem that
a hinged-plate is both a plate and a hinge, it will just put a lot of exceptions
in the definitions and the need of prior knowledge to prevent putting it and
looking for it in the Plate, Modified category.
We already know most of the attributes because they are already used in the category
names: brick, plate, round, hose, decorated, etc. There even is a prioritization
(brick ≫ round ≫ decorated).
What should be done is determine which attributes conflict and need prioritization
or deletion. That means the attributes need to be defined (what’s “hinge”?
it’s a function, it’s orthogonal with primary shape-attributes like brick and
plate, how do we prioritize them?) not the categories (what parts are in “Hinge”?
oh, they could also be elsewhere, let’s massage all the definitions to keep
(most of) them there).
| | By the way, I also think we mustn't forget which problem we are trying to
solve. Is it about solving practical problems with its use, or is it about solving
our feeling of dissatisfaction on some intellectual level? I feel a bit of both
are involved.
|
True.
| | So how big are the practical problems with the catalog really?
I'm honestly curious. I wonder what info we have that suggests dramatic overhauls
are needed. You'd have to watch people use Bricklink in order to find out
I guess. But if I had to go by the number of ID topics, the people who ask are
vastly outnumbered by the people who answer.
|
Not true. It’s always the same people who answer.
(Old timers who know the parts, and how they are arranged in the catalogue, or
have developped tricks to circumvent its inconsistencies, or have simply memorized
those inconsistencies.)
| | But of course, that doesn't count the times someone had to search for too long.
|
Or abandoned and didn’t come to the forum to ask, putting the part in their “what’s
that?” bin for later (a.k.a. never).
|
I won't deny there are these problems, but I would really like to have some
kind of data, say a survey, so that we have something to talk about. Saying "the
problem is that categories are inconsistent" to me isn't good enough, because
it is not in and of itself a problem yet. Having multiple options for categories
to put a part in, is not a problem yet. Things like people searching endlessly
or giving yup, yeah, those are problems.
Supermarkets btw have the same inconsistency, the categories are also a hybrid
there. It's not the end of the world (but sure, also not an argument to defend
inconsistencies)
I'm responding based on my buying experience, which was the very first years
of me being a (casual) member (pretty soon I realised it was a too expensive
hobby for me  ). I would look around thinking "so what kind of boat stuff does
this shop have?" and it would not have been convenient for me if that whole category
was broken down into a too technical approach to part attributes - but yeah,
that is going to depend on what precisely the proposed catalog would look like.
As for my selling experience, I don't care either way anymore, because I've
already built my own catalog for my own shop which I can apply to my Bricklink
shop by automatically assigning my categories to the remark fields. I just want
a buyer-friendly catalog that takes into account but not overfocusses on first-time
identification of a part, but also on producing relevant categories that are
pleasant and supporting to browse around. If a more principal system could still
do that, then that's alright.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 27, 2020 10:58 | | Subject: | Re: Why are these Hinges? | | Viewed: | 31 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | […]
I won't deny there are these problems, but I would really like to have some
kind of data, say a survey, so that we have something to talk about. Saying "the
problem is that categories are inconsistent" to me isn't good enough, because
it is not in and of itself a problem yet. Having multiple options for categories
to put a part in, is not a problem yet.
|
“Yet” 
Those are problems now.
People can’t find parts without looking everywhere now.
Parts are put into categories (and sometimes moved from one category to another)
arbitrarily (on whims) now.
| | […]
I'm responding based on my buying experience, which was the very first years
of me being a (casual) member (pretty soon I realised it was a too expensive
hobby for me ). I would look around thinking "so what kind of boat stuff does
this shop have?" and it would not have been convenient for me if that whole category
was broken down into a too technical approach to part attributes - but yeah,
that is going to depend on what precisely the proposed catalog would look like.
|
But LEGO is all about using parts for anything and everything.
“Boat stuff”? Parts for a boat? What’s that? All the parts you can use to
build a boat (bricks, plates, etc.)? They are all in different categories now.
The giant boat hulls? The sails? The oars? The windscreens? The porthole
windows? The hatches? The rigging? They are all in different categories now.
You’ve never been able to find or browse for all the “boat stuff” in one category.
Worse, you have the illusion you can because there’s a “Boat” category (which
is mainly boat hulls, with masts, a couple anchors, a couple wheels, and one
oar (but not the four other oars) sprinkled within), and so you miss on a lot
of parts.
And a more reasoned system won’t be more technical, it’ll be more consistent.
And it won’t necessarily separate the parts that are together now for a wrong
reason, it will give a reason to put them together and it will give consistency
in the choices made to put them together.
E.g, if we remove the functionnal “Boat” category, we can still have a “Boat
Hull” category (that would keep together most of the 230 parts that are now together)
and regroup things that should be together and are now in three categories (like
oars that are now in “Boat”, “Minifigure, Utensil” and “Fabuland”).
(Note that we never talked about the theme-oriented categories, like “Fabuland.”
Yes, Fabuland parts have a style, they are almost like small Duplo, but it’s
not always easy to recognize it. Besides, some of the Fabuland parts have migrated
to other categories, mostly because they have been reused.)
| | I just want
a buyer-friendly catalog that takes into account but not overfocusses on first-time
identification of a part, but also on producing relevant categories that are
pleasant and supporting to browse around. If a more principal system could still
do that, then that's alright.
|
At least, it shouldn’t prevent that anymore than the current unprincipled system
does
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 27, 2020 11:34 | | Subject: | Re: Why are these Hinges? | | Viewed: | 39 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | […]
I won't deny there are these problems, but I would really like to have some
kind of data, say a survey, so that we have something to talk about. Saying "the
problem is that categories are inconsistent" to me isn't good enough, because
it is not in and of itself a problem yet. Having multiple options for categories
to put a part in, is not a problem yet.
|
“Yet”
|
Not in a temporal meaning
This is not a problem,
| | People can’t find parts without looking everywhere now.
|
this is. And I would like to know more about the size and the nature of this
problem. We're now concluding things are problems because it sounds unsatisfactory,
and that's not enough (it always will be).
| | Parts are put into categories (and sometimes moved from one category to another)
arbitrarily (on whims) now.
|
This is not the problem. The problem is the implicitly assumed result: Difficulty
finding things. And that I just want to know more about the problem, not by reasoning
about what logically are problems, but by measuring the actual
problem.
The supermarket example is not just an analogy, it's an example of another
business where categorising is an issue. Is it an issue? Yes, because there too
people are searching, and there too people are asking. It's just within reasonable
limits. Is the BL situation within reasonable limits? We would need to test it.
If first time findability is a huge problem, then yeah, we need to put
all efforts in designing a new catalog and give that 100% importance. If it is
a small problem, then we can afford to balance it with attention to categories
that are nice sets of parts that are relevant to browse.
| | | | […]
I'm responding based on my buying experience, which was the very first years
of me being a (casual) member (pretty soon I realised it was a too expensive
hobby for me ). I would look around thinking "so what kind of boat stuff does
this shop have?" and it would not have been convenient for me if that whole category
was broken down into a too technical approach to part attributes - but yeah,
that is going to depend on what precisely the proposed catalog would look like.
|
But LEGO is all about using parts for anything and everything.
“Boat stuff”? Parts for a boat? What’s that? All the parts you can use to
build a boat (bricks, plates, etc.)? They are all in different categories now.
The giant boat hulls? The sails? The oars? The windscreens? The porthole
windows? The hatches? The rigging? They are all in different categories now.
You’ve never been able to find or browse for all the “boat stuff” in one category.
|
I know, just saying it worked very conveniently for me. Sure, you're right,
a lot of those parts can very well be in other categories. But I had no problems.
If others do, then sure. It's just that in my work I have encountered so
many people saying "well I don't have a problem, but probably other people
do" and then it turned out those people never existed. That is why I am this
kind of skeptical and want to hear it from the people who have the problem. The
signals I'm picking up are limited, but they're more "just take a moment
to learn it" than "omg the BL catalog is so difficult".
And this discussion all started pretty much with everyone in agreement that those
items are not hinges because they have clips. I don't think all is terrible.
| | | | I just want
a buyer-friendly catalog that takes into account but not overfocusses on first-time
identification of a part, but also on producing relevant categories that are
pleasant and supporting to browse around. If a more principal system could still
do that, then that's alright.
|
At least, it shouldn’t prevent that anymore than the current unprincipled system
does
|
It would if it would be something too technical like based on dimensions
only. It is not a guaranteed improvement - there is also a lot to lose here,
and we forget that if we bash everything about the catalog. We just need to be
careful.
Well, let's wrap it up. There are lots of things that could be both better
or worse about the catalog. The reason I'm posting is that all the time I
see it is being talked about from the perspective of the part - where
it is and if it is easy to find. But I never hear about the perspective of the
category - what assortment of parts it contains and if that is a meaningful
set of parts to browse and if it is nicely sized (this is definitely not perfect
now, but it could be worse). The tag system is a good example too: While it is
a good idea, it's exemplary of the 100% focus on that individual part and
how that can be found, but it says nothing about what browsing a store will look
like (you will see the same things many times if they don't have 1 category
location) or what storage is going to look like (both sellers and buyers may
adopt the categories).
As long as whoever fleshes out the improvements says that they keep a balance
of those two perspectives in mind, then I really am fine with any outcome. I
just don't want super-easy-to-identify categories if they are going to be
"everything with 3 studs, everything with 2 clips, .." etc. In that case I prefer
a common-sense hinge category with 3 parts you expected elsewhere that you just
need to memorise. But if it will be better, then go ahead. Maybe we end up in
total agreement once an example is put forth, or when we have data on the problem,
so I'd say let's continue this when it's less hypothetical
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 27, 2020 12:40 | | Subject: | Re: Why are these Hinges? | | Viewed: | 47 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | […]
| | “Yet”
|
Not in a temporal meaning
|
Indeed not. It’s an introductory sentence for the following sentences that explain
the problem. 
| | […]
| | Parts are put into categories (and sometimes moved from one category to another)
arbitrarily (on whims) now.
|
This is not the problem. The problem is the implicitly assumed result: Difficulty
finding things. And that I just want to know more about the problem, not by reasoning
about what logically are problems, but by measuring the actual
problem.
|
No, it’s also a problem on its own. It’s even actually a multi-fold problem.
First, it’s a problem to know where to put a new piece.
Then, it’s a problem because a different catmin could have put the piece in another
category.
Then, as you said, it’s a problem to know where to find a new piece once it has
been added.
And finally, it’s also a problem that the appearance of some new pieces make
us see the need to rethink the categories because of the difficulties of the
first problems.
| | The supermarket example is not just an analogy, it's an example of another
business where categorising is an issue.
|
You have a different definition than mine for analogy, because “an example of
something that is comparable is some ways” is exactly what an anology is.
And all I said was “comparison isn’t reason.” (I don’t if it’s a saying in English
or Dutch but it is in French.)
| | Is it an issue? Yes, because there too
people are searching,
|
Which, as I noted, can be a goal and not an issue.
| | and there too people are asking. It's just within reasonable
limits. Is the BL situation within reasonable limits? We would need to test it.
If first time findability is a huge problem, then yeah, we need to put
all efforts in designing a new catalog and give that 100% importance. If it is
a small problem, then we can afford to balance it with attention to categories
that are nice sets of parts that are relevant to browse.
|
Then there’s no way to measure the extent of the problem to your satisfaction.
We only have anecdotal evidence: each our own experience of using the catalogue
and each our own impression of what transpires on the forum.
How miscontent you are and how miscontent the others are is all feelings.
Even if you do a poll, you’ll only have feelings, and only of those who’d answer
the poll (the vocal ones, the “animated” ones).
So you’ll reject that as being not “huge” enough or too “small.”
| | […]
| | You’ve never been able to find or browse for all the “boat stuff” in one category.
|
I know, just saying it worked very conveniently for me. Sure, you're right,
a lot of those parts can very well be in other categories. But I had no problems.
|
You had and have no problems but you made your own categorization for your shop….
| | If others do, then sure. It's just that in my work I have encountered so
many people saying "well I don't have a problem, but probably other people
do" and then it turned out those people never existed. That is why I am this
kind of skeptical and want to hear it from the people who have the problem. The
signals I'm picking up are limited, but they're more "just take a moment
to learn it" than "omg the BL catalog is so difficult".
|
Except here it’s not “well I don’t have a problem but others may” it’s “I’ve
this problem, and others too.”
And “just a moment to learn it” isn’t a solution, it’s “I’ve a rock in my shoe
but it’s okay, I learned to limp around it.”
| | […]
| | At least, it shouldn’t prevent that anymore than the current unprincipled system
does
|
It would if it would be something too technical like based on dimensions
only.
|
That’s a strawman. We have already given examples of what could be good candidates
for attributes and we have already shown many are already in the current categories
(just not consistently organized yet).
| | […]
As long as whoever fleshes out the improvements says that they keep a balance
of those two perspectives in mind, then I really am fine with any outcome. […]
|
Then you’re fine because we’ve said it from the beginning.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 27, 2020 16:42 | | Subject: | Re: Why are these Hinges? | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | […]
| | “Yet”
|
Not in a temporal meaning
|
|
Come on, adverbs can refer to either time or space, you're a language guy,
you must've figured this "yet" referred to something a bit further on in
the context and not to "now" vs "another time"
| |
Indeed not. It’s an introductory sentence for the following sentences that explain
the problem.
|
No, really. It is too quick to immediately label things as problems without us
knowing anything about the effects. If a part could be two categories and it's
up to randomness in which category it belongs, then that in and of itself is
not the problem. The potential problem is difficulty shopping, but so far we
don't know anything how big that is. The catalog is for humans, not for robots.
You could look at a human language and spot tons of "problems" in it, yet they
don't prove problematic. Inconsistency in and of itself is not a problem,
we're surrounded by it. If the solution is possible and free, then sure.
If the solution is not free, then we need to be able to weigh the problem's
magnitude vs the sacrifice.
| | | | and there too people are asking. It's just within reasonable
limits. Is the BL situation within reasonable limits? We would need to test it.
If first time findability is a huge problem, then yeah, we need to put
all efforts in designing a new catalog and give that 100% importance. If it is
a small problem, then we can afford to balance it with attention to categories
that are nice sets of parts that are relevant to browse.
|
Then there’s no way to measure the extent of the problem to your satisfaction.
|
My satisfaction... wish it was everyone's satisfaction. I would expect
anyone interested in this topic would be interested in finding out if, well,
they're problems. Not liking it from a logical perspective isn't a problem..
unless we were gonna print the catalog and hang it on a wall to enjoy it. I think
we really need to research this. Bricklink could easily create a survey about
this and then we would know a lot more. I don't really care about how many
things we could think of that "don't make sense if you think about it". I
just care about the shopping experience.
| | | | I know, just saying it worked very conveniently for me. Sure, you're right,
a lot of those parts can very well be in other categories. But I had no problems.
|
You had and have no problems but you made your own categorization for your shop….
|
No, I follow Bricklink's. My 2 Boat bins and my 4 Hinge bins are right here
behind me.
| | | | As long as whoever fleshes out the improvements says that they keep a balance
of those two perspectives in mind, then I really am fine with any outcome. […]
|
Then you’re fine because we’ve said it from the beginning.
|
I never heard anyone about creating meaningful categories because there are no
examples. So I have no idea if that example would be a strawman. But sure, in
that case we're cool. I just need to see that either A. the solution comes
at no cost, or B. that its cost weighs up against the magnitude of the problem
- for which we need a survey.
I really hope Bricklink can make this happen. Not because I want to prove any
particular point, I am just genuinely interested in the catalog user experience.
If that would turn up a great degree of dissatisfaction then drastic changes
will probably receive wide support, also from me.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 27, 2020 18:14 | | Subject: | Re: Why are these Hinges? | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | […]
| | “Yet”
|
Not in a temporal meaning
|
|
Come on, adverbs can refer to either time or space, you're a language guy,
you must've figured this "yet" referred to something a bit further on in
the context and not to "now" vs "another time"
|
I still don’t get the original sentence in any other way than temporal. I don’t
see it applying to something placed further (and later) in the message.
| | […]
No, really. It is too quick to immediately label things as problems without us
knowing anything about the effects.
|
Something that upsets people is a problem.
| | If a part could be two categories and it's
up to randomness in which category it belongs, then that in and of itself is
not the problem. The potential problem is difficulty shopping, but so far we
don't know anything how big that is. The catalog is for humans, not for robots.
|
Indeed. Robots can do tedious, repetitive tasks without being bored. Humans
can’t.
Trying all the categories one by one to find parts is a tedious repetitive task
humans prefer not to do.
| | You could look at a human language and spot tons of "problems" in it, yet they
don't prove problematic.
|
Languages do prove problematic. They need further communications to precise,
explain, and clarify.
| | Inconsistency in and of itself is not a problem,
we're surrounded by it. If the solution is possible and free, then sure.
If the solution is not free, then we need to be able to weigh the problem's
magnitude vs the sacrifice.
| | […]
Then there’s no way to measure the extent of the problem to your satisfaction.
|
My satisfaction... wish it was everyone's satisfaction. I would expect
anyone interested in this topic would be interested in finding out if, well,
they're problems. Not liking it from a logical perspective isn't a problem..
unless we were gonna print the catalog and hang it on a wall to enjoy it. I think
we really need to research this. Bricklink could easily create a survey about
this and then we would know a lot more. I don't really care about how many
things we could think of that "don't make sense if you think about it". I
just care about the shopping experience.
|
You always go back to the supposedly unproven existence of a real problem.
Do I have a problem with the categories as they are?
Yes.
Proof: I say so
Do other people have a problem?
Yes.
Proof: they say so in forum posts, either directly saying so or having difficulties
with the categories.
Do admins see a problem with the categories?
Yes.
Proof: https://www.bricklink.com/message.asp?ID=1117709
and in https://www.bricklink.com/message.asp?ID=1190847
“””
Do the definitions do their job?
Imagine a part you'd like to see placed into another category. Do the definitions
of the existing category for the part and the category where you'd like to
see the part moved fully explain the necessity for the move?
”””
Their solution is to make a very, very long dictionary (that no one will ever
read and even less learn but them¹) with lots of convoluted phrasing and exceptions
because they don’t want to touch the categories themselves, yet (in the temporal
sense ).
(¹ It’s okay, it’s their main goal: guidelines for the catalogue to make it less
person-dependant. But it can’t really serve as a guideline for simple users.)
The approach for now has been cautious: move parts on a case by case basis, try
to empty the (Other) category, create a few new categories.
Patches, patches, patches.
Plaster on a wooden leg.
But I get it, that’s not enough people, you want a “survey.”
So, how about the work BL did (and botched) for XP, a work that has partly been
used in Studio?
They tried to make hierarchical categories (“Shapes” in Studio aren’t hierarchical).
They totally missed it for the sets (which should stay theme- and time-oriented),
and there are a inconsistencies and too-big categories for parts, and the way
they are presented isn’t the best.
And, of course, they did it without any user input and without any communication.
But they did it for a reason: they did surveys.
| | […]
| | You had and have no problems but you made your own categorization for your shop….
|
No, I follow Bricklink's. My 2 Boat bins and my 4 Hinge bins are right here
behind me.
|
“I've already built my own catalog for my own shop which I can apply to my
Bricklink
shop by automatically assigning my categories to the remark fields.”
— https://www.bricklink.com/message.asp?ID=1200018
| | […]
I just need to see that either A. the solution comes
at no cost,
|
There’s always a cost.
For the ones who’ll do the job.
For the ones who know the old tricks and will need to learn new ones.
| | or B. that its cost weighs up against the magnitude of the problem
- for which we need a survey.
I really hope Bricklink can make this happen. Not because I want to prove any
particular point, I am just genuinely interested in the catalog user experience.
If that would turn up a great degree of dissatisfaction then drastic changes
will probably receive wide support, also from me.
|
Provided there’s communication about it
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 28, 2020 03:57 | | Subject: | Re: Why are these Hinges? | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | […]
| | “Yet”
|
Not in a temporal meaning
|
|
Come on, adverbs can refer to either time or space, you're a language guy,
you must've figured this "yet" referred to something a bit further on in
the context and not to "now" vs "another time"
|
I still don’t get the original sentence in any other way than temporal. I don’t
see it applying to something placed further (and later) in the message.
|
Aw man really? Here we go:
Saying "the problem is that categories are inconsistent" to me isn't good
enough, because it is not in and of itself a problem yet. Having multiple options
for categories
to put a part in, is not a problem yet. Things like people searching endlessly
or giving yup, yeah, those are problems.
You're a smart guy so you must see the point I keep trying to make..... that
things are not problems just because they violate how we imagine things.. if
I put 10 pens in a cup and one is the other way around from the other 9, you
can perceive it as a problem because it violates some conception of how it "should"
be. But is it a problem in the cup or in the mind? Only if we're talking
about sharp knives, is that really a problem. I'm interested in results
of the way the catalog is, not in intrinsic properties.
| | Something that upsets people is a problem.
|
(...)
| | Do I have a problem with the categories as they are?
Yes.
Proof: I say so
|
Surely we are changing the catalog to improve its practical usefulness, and not
because its intrinsic properties are upsetting? Streetmakers don't lay
a street a certain way to avoid people with OCD being upset with how the bricks
are distributed, they lay it so it's comfortable to walk on.
| | Do other people have a problem?
Yes.
Proof: they say so in forum posts, either directly saying so or having difficulties
with the categories.
|
OK, you're right, here is a problem. If you have difficulties, then
that is certainly important. (I assumed you were one of those veterans who knew
the catalog by heart.)
| | Do admins see a problem with the categories?
Yes.
Proof: https://www.bricklink.com/message.asp?ID=1117709
and in https://www.bricklink.com/message.asp?ID=1190847
“””
Do the definitions do their job?
Imagine a part you'd like to see placed into another category. Do the definitions
of the existing category for the part and the category where you'd like to
see the part moved fully explain the necessity for the move?
”””
Their solution is to make a very, very long dictionary (that no one will ever
read and even less learn but them¹) with lots of convoluted phrasing and exceptions
because they don’t want to touch the categories themselves, yet (in the temporal
sense ).
(¹ It’s okay, it’s their main goal: guidelines for the catalogue to make it less
person-dependant. But it can’t really serve as a guideline for simple users.)
The approach for now has been cautious: move parts on a case by case basis, try
to empty the (Other) category, create a few new categories.
Patches, patches, patches.
Plaster on a wooden leg.
But I get it, that’s not enough people, you want a “survey.”
|
If this plaster on the wooden leg is cause for reduced ease of use (which is
plausible, I just want to know how if it is a small or a big problem), then it
is a problem. If it does the job, then all of what you mention above is fine.
| | | | […]
| | You had and have no problems but you made your own categorization for your shop….
|
No, I follow Bricklink's. My 2 Boat bins and my 4 Hinge bins are right here
behind me.
|
“I've already built my own catalog for my own shop which I can apply to my
Bricklink
shop by automatically assigning my categories to the remark fields.”
— https://www.bricklink.com/message.asp?ID=1200018
|
Exactly. If things change, then I could create a way of keeping it the way it
is for myself, so this is not going to affect me.
| | | | […]
I just need to see that either A. the solution comes
at no cost,
|
There’s always a cost.
For the ones who’ll do the job.
For the ones who know the old tricks and will need to learn new ones.
|
You're a really thoughtful and meticulous guy. But this is almost going over
things quick and carelessly. Seems the story is the catalog is all bad, it
needs to be rewritten because well, using logic you can see it without needing
a survey, and it doesn't really cost anything, just gotta relearn it.
Hey, slow down man! It's great you're contributing to improving things,
but please, please, please let's be a little bit more meticulous in each
of these steps. The catalog is not a brain game. We are talking about things
that affect thousands of people, people for who LEGO is a serious passion and
people who depend on this system for their families livelihoods.
The cost part: Yeah relearning, OK. Now let's think a little bit deeper.
Regardless of what some people say bringing up details, the BL and BO catalogs
are incredibly similar (the hinge and plate modified categories are the same,
so is boat). There is also a third platform that too has the same catalog, and
possibly more (I also see the terminology used outside of it). Changing it means
for example these two things:
- We move further away from a universal or at least mutually intelligible language
for Lego parts. With all platforms having fundamentally their very own way of
classifying things, we're going to have islands rather than 1 strong community.
People will be more focussed on 1 particular platform. That essentially reduces
our power. Also, in the flesh world, people use the English Bricklink category
names in Dutch, and I'm sure that happens all around the world. It's
become jargon.
- Category based sellers are going to be in trouble selling on both platforms
because the picking lists will be inconsistently ordered. I can work around it
because I can do programming, but if I couldn't, I am not sure if I would
want to continue selling on both sites. Most sellers want to start on 1 end of
the stock, and end on the other. Running around in random directions with increased
chance of errors is not appealing.
Now, these things aren't holy - they can be given up. But they surely are
costs. These are my 2 examples, maybe there are more. Let's recognise them.
Putting it polemically: If we're achieving huge usability improvements then
let's do it. If we're achieving the peace of mind of a few people who
just like to see things in logical places when they think about it, at the cost
of sellers making mistakes running around with randomly ordered picking lists,
that is just not worth it. The reality seems to be somewhere in between, but
we don't know where.
IMO We need to know what we gain and what we lose before we would ever make fundamental
changes to the catalog. It takes research that we can't do in an armchair
with just a few people. We need the community.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | StormChaser | | Posted: | May 28, 2020 04:09 | | Subject: | Re: Why are these Hinges? | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
We do. And one of the problems there is that historically much of the work on
BrickLink's catalog, from major decisions to the most minor contributions,
has been done by an incredibly small number of people compared to the overall
membership of BrickLink.
If you have suggestions regarding how to engage a larger portion of the community
in catalog decision-making, we will gladly listen.
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 28, 2020 04:47 | | Subject: | Re: Why are these Hinges? | | Viewed: | 28 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
We do. And one of the problems there is that historically much of the work on
BrickLink's catalog, from major decisions to the most minor contributions,
has been done by an incredibly small number of people compared to the overall
membership of BrickLink.
If you have suggestions regarding how to engage a larger portion of the community
in catalog decision-making, we will gladly listen.
|
Good question. I feel like a survey could be useful. If the Bricklink main page
would display it in that big banner, I would think a lot of people will participate.
(I think it's more likely to attract people who are dissatisfied with the
category than people who are satisfied, so that would be erring on the safe side
for those who want to go and change things.)
If this would happen, I'd be happy to help putting together the questions
- I'm thinking a handful of statements with a 5 or 7 point "strongly agree
- strongly disagree" scale setup, and an open question to gather some input on
possible consequences that weren't thought of yet.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 28, 2020 08:53 | | Subject: | Re: Why are these Hinges? | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | […]
| | I still don’t get the original sentence in any other way than temporal. I don’t
see it applying to something placed further (and later) in the message.
|
Aw man really? Here we go:
Saying "the problem is that categories are inconsistent" to me isn't good
enough, because it is not in and of itself a problem yet. Having multiple options
for categories
to put a part in, is not a problem yet. Things like people searching endlessly
or giving yup, yeah, those are problems.
|
Well, that’s a strange way to use “yet.”
(See, languages do prove problematic….)
| | You're a smart guy so you must see the point I keep trying to make..... that
things are not problems just because they violate how we imagine things..
|
And you keep dismissing and belittling examples that are not imagined.
| | | | Something that upsets people is a problem.
|
[…]
Surely we are changing the catalog to improve its practical usefulness, and not
because its intrinsic properties are upsetting?
|
What is upsetting is all the problems I have explained time and time again.
I won’t explain them again.
| | […]
OK, you're right, here is a problem. If you have difficulties, then
that is certainly important.
|
There you go again, mocking the reality of problems with the categories because
I avoided repeating (again) the list of troubles people have by summing them
up as “difficulties.”
| | (I assumed you were one of those veterans who knew the catalog by heart.)
|
I’m not. I already said I used LDraw or LDD to find part numbers to then look
them up in the catalogue.
The only way I use the categories is to reduce the number of parts I look at
in a store, but I still go over (almost) all of them one by one because there
are always interesting parts hidden there somewhere.
| | […]
If this plaster on the wooden leg is cause for reduced ease of use (which is
plausible, I just want to know how if it is a small or a big problem), then it
is a problem. If it does the job, then all of what you mention above is fine.
|
I (and others) already explained in length which problems it won’t/can’t solve
and why.
| | […]
| | There’s always a cost.
For the ones who’ll do the job.
For the ones who know the old tricks and will need to learn new ones.
|
You're a really thoughtful and meticulous guy. But this is almost going over
things quick and carelessly. Seems the story is the catalog is all bad,
|
I never said that.
I said the catalogue had flaws (again, recognized by many) but I also said most
of it wouldn’t change (therefore it’s good too).
But continue strawmaning it to absolutes.
| | it needs to be rewritten because well, using logic you can see it without needing a survey,
|
I never said that.
I’ve given you real, pratical examples but you always go back to that strawman
“it’s only in your head.”
| | and it doesn't really cost anything,
|
I never said that.
Au contraire, I said (and you didn’t even snip it) it would have costs.
I never said that either.
| | [… blah …]
- We move further away from a universal or at least mutually intelligible language
for Lego parts.
|
No, we do not.
Because, first, which universal language?
LEGO’s is different, LDraw’s is different, Rebrickable’s is different, Studio’s
is different….
None of those use the same categories.
As for “mutually intelligible,” we never proposed to rename “Plates” to “Thin
bricks” or “Baseplates” to “No-bottom very thin bricks.” Au contraire, we propose
to regroup “plates” together IF it’s better (when we prioritize the attributes,
after we have found them).
But no, you are still strawmaning to “everything will totally change and just
because of fake problems that are only in your head!”
| | With all platforms having fundamentally their very own way of
classifying things, we're going to have islands rather than 1 strong community.
|
It’s in your head.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 28, 2020 10:21 | | Subject: | Re: Why are these Hinges? | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | […]
OK, you're right, here is a problem. If you have difficulties, then
that is certainly important.
|
There you go again, mocking the reality of problems with the categories because
I avoided repeating (again) the list of troubles people have by summing them
up as “difficulties.”
|
As far as I can see I have understood everything you said but it seems that you
honestly misunderstand what I try to say. Maybe that's just my fault because
it seems I can't express things well in English, but anyway, you don't
understand what I mean. Wasn't belittling anything, it was the opposite.
I was in fact pointing out that that is the major deal - the difficulties
are THE important thing in all of this (no idea that word was a euphemism, my
bad). It seems to me that you don't see that pointing out an inconsistency
on an intellectual level and figuring out whether or not it is a problem are
two separate steps, it looks like you see it as one automatic, impartible step.
The first can cause the second, but it is not a given - you start with the problem,
then trace its causes.
I think your talents and attention to detail are invaluable for improvements
once those are planned, but I think you seriously miss the point on some things
in the greater picture, and I don't manage to make you see it. Which is OK,
because if there will be changes, it is going to require a combined community
effort anyway.
And it seems the story is inconsistent on categories like hinges and boat will
or will not change - right now it's a bit of eating the cake and having
it too, because on the one hand everything will be logically restrucutured but
on the other hand it will not result in major mismatches in jargon or catalogs
across platforms.
You didn't say it would cost nothing, but still, don't assume you oversee
everything. There are a lot of implications for a lot of people. These need to
be assessed. For me: Rearranging 1 million parts because of a new catalog, sure,
it's a business risk - give me a week and I will happily do it (this is NOT
a strawman - ALL bins will move). Or writing software so that I can keep selling
on both platforms with the same system, sure I will do it. Each time I add parts,
I am going to have to download my inventory, run it through some software to
generate the categories that match BO, then feed it back into BL in XML mass
inventory update chunks (also NOT a strawman, believe me, I know my systems).
Extra work every time, but I will do this. (I have no idea how others will solve
it. tell me if you do)
But I will do it because it improves the user experience for many people in terms
of measurable UX quality. I am not enthusiastic about complicating the tools
I constantly use every day because some users just feel good about logical systems
for their own sake. We need a survey, then I'm going to be impressed.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | May 28, 2020 11:52 | | Subject: | Re: Why are these Hinges? | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | […]
As far as I can see I have understood everything you said but it seems that you
honestly misunderstand what I try to say.
|
What I understand is that you’re sometimes conceding there are problems and then
you go harping on again about how their identified¹ causes are only theoritical,
logical or conceptual considerations that doubtfully cause real problems.
“Oh yes, those are problems. But causes are not problems. And these causes
are only conceptual. So there’s no real problem.”
Guh.
Inconsistency is a no-no in categorization theory. It doesn’t mean the problems
caused by inconsistencies are theoretical.
¹ Yes, the causes are identified:
If the problem is “I can’t identify this part” (which is only one example of
the problems we have), it’s because “I” (the “I” who has the problem, not necessarily
me) looked in categories (plural, “I” is not obtuse and knows they can be wrong
or confused) “I” thought the part would be. And “I” think a part would be in
maybe this or that category because of the names of this and that category and
because the part “I”’m trying to identify looks like the parts that are in this
and that categoriy, or because the part is used like (*brr, shivers*) the parts
that are in this and that category.
So “I” was misguided and confused by the category names and the parts that are
in the categories, by what “I” thought the parts shared.
Same (or worse) with browsing by category: “I” look for parts like such other
parts in the categories these other parts are in, if the parts “I” should see
aren’t in these categories, it’s because “I” didn’t get what the categories “meant”
(what their names meant, what features the parts that are in them share).
Causes: names don’t mean what “I” think they mean, parts don’t share what “I”
think they share.
And what the current project is doing is only addressing the names of the categories,
and then, only by tweaking their definitions, not by changing their names (or
maybe just a little, eventually, if really necessary) and certainly not by regrouping
parts and identifying why people are looking in the wrong categories.
IOW, they are writing down the exceptions to the definitions so that parts will
only be in one category. But if “I” don’t learn these definitions by heart,
“I”’ll still look for them in the wrong places because the names will be the
same and the parts will be in the same place.
Changes to the categories and parts is always on a case by case basis. Sometimes,
one person proposes to split a category or move a couple parts. And then people
discuss this little bit of the catalogue and, maybe, the consequences on another
little bit.
No global view.
“Rearranging chairs” as mfav once put it (well, more than once actually).
| | […]
And it seems the story is inconsistent on categories like hinges and boat will
or will not change - right now it's a bit of eating the cake and having
it too, because on the one hand everything will be logically restrucutured but
on the other hand it will not result in major mismatches in jargon or catalogs
across platforms.
|
It’s simply because we don’t know: we haven’t listed the attributes, we haven’t
prioritized them, we haven’t defined the categories.
| | You didn't say it would cost nothing, but still, don't assume you oversee
everything. There are a lot of implications for a lot of people. These need to
be assessed.
|
But we can’t know. The only question we can ask now is “would you be favourable
to a change in the categories.” But we can’t say how important the change.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 28, 2020 12:57 | | Subject: | Re: Why are these Hinges? | | Viewed: | 29 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, Teup writes:
| | […]
As far as I can see I have understood everything you said but it seems that you
honestly misunderstand what I try to say.
|
What I understand is that you’re sometimes conceding there are problems and then
you go harping on again about how their identified¹ causes are only theoritical,
logical or conceptual considerations that doubtfully cause real problems.
“Oh yes, those are problems. But causes are not problems. And these causes
are only conceptual. So there’s no real problem.”
Guh.
Inconsistency is a no-no in categorization theory. It doesn’t mean the problems
caused by inconsistencies are theoretical.
¹ Yes, the causes are identified:
If the problem is “I can’t identify this part” (which is only one example of
the problems we have), it’s because “I” (the “I” who has the problem, not necessarily
me) looked in categories (plural, “I” is not obtuse and knows they can be wrong
or confused) “I” thought the part would be. And “I” think a part would be in
maybe this or that category because of the names of this and that category and
because the part “I”’m trying to identify looks like the parts that are in this
and that categoriy, or because the part is used like (*brr, shivers*) the parts
that are in this and that category.
So “I” was misguided and confused by the category names and the parts that are
in the categories, by what “I” thought the parts shared.
Same (or worse) with browsing by category: “I” look for parts like such other
parts in the categories these other parts are in, if the parts “I” should see
aren’t in these categories, it’s because “I” didn’t get what the categories “meant”
(what their names meant, what features the parts that are in them share).
Causes: names don’t mean what “I” think they mean, parts don’t share what “I”
think they share.
And what the current project is doing is only addressing the names of the categories,
and then, only by tweaking their definitions, not by changing their names (or
maybe just a little, eventually, if really necessary) and certainly not by regrouping
parts and identifying why people are looking in the wrong categories.
IOW, they are writing down the exceptions to the definitions so that parts will
only be in one category. But if “I” don’t learn these definitions by heart,
“I”’ll still look for them in the wrong places because the names will be the
same and the parts will be in the same place.
Changes to the categories and parts is always on a case by case basis. Sometimes,
one person proposes to split a category or move a couple parts. And then people
discuss this little bit of the catalogue and, maybe, the consequences on another
little bit.
No global view.
“Rearranging chairs” as mfav once put it (well, more than once actually).
| | […]
And it seems the story is inconsistent on categories like hinges and boat will
or will not change - right now it's a bit of eating the cake and having
it too, because on the one hand everything will be logically restrucutured but
on the other hand it will not result in major mismatches in jargon or catalogs
across platforms.
|
It’s simply because we don’t know: we haven’t listed the attributes, we haven’t
prioritized them, we haven’t defined the categories.
| | You didn't say it would cost nothing, but still, don't assume you oversee
everything. There are a lot of implications for a lot of people. These need to
be assessed.
|
But we can’t know. The only question we can ask now is “would you be favourable
to a change in the categories.” But we can’t say how important the change.
|
100% agree that you guys made a very good analysis of what would be the reasons
behind it if there are problems.
Also agree there are these problems.
Not yet sure about the magnitude of the problems, ranging from on the
one hand 'a few guys and gals a day not getting to the part the first try
but reaching it the second time and then memorising it for the next time with
no further difficulty' (the best scenario) to 'lots of people constantly
confused, giving up on placing orders and throwing heaps of parts in the will-do-later-aka-never
bin' (worst scenario)
And yeah, the implications of the solution also depend on how dramatic the rearranging
will be, again ranging from on the one end '99% the same result as we have
now but with perfect definitions' (62Bricks also mentioned this is still
a possibility) to 'forget everything you thought you knew about lego'
on the other end.
That's the prize dimension and the cost dimension.
If changes like this would ever be in the works for real, I guess I would need
to wait with forming an opinion until more would be clear about where we are
on these two scales. I want things to be within reason and proportion (because
there are consequences beyond just getting used to new things), but I would surely
give it an honest chance.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | StormChaser | | Posted: | May 28, 2020 13:05 | | Subject: | Re: Why are these Hinges? | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | And what the current project is doing is only addressing the names of the categories,
and then, only by tweaking their definitions, not by changing their names (or
maybe just a little, eventually, if really necessary) and certainly not by regrouping
parts and identifying why people are looking in the wrong categories.
|
True. As I stated in this message:
https://www.bricklink.com/message.asp?ID=1191211
we're not working with categories right now. We're only trying to
define what existing categories contain or should contain. Ideally we would do
both things at the same time, but I believe that's just too much going on
at once.
Yes, categories need to be updated. That is step two. Creating category definitions,
knowing that a few of them will be changed when we start discussing categories
themselves, was step one.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | Author: | StormChaser | | Posted: | May 26, 2020 23:08 | | Subject: | Re: Why are these Hinges? | | Viewed: | 44 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | The catalog is always a compromise.
|
I'm completely willing to compromise. One of the other commenters in this
thread is advocating for an attribute-based system. Even though there have been
plenty of hours put into defining categories, it sounds like that wouldn't
be necessary with an attribute-based system.
I'd be perfectly happy to consider doing away with the (frankly) lengthy
and cumbersome category definitions page if someone fleshed out some guidelines
for an attribute-based system and presented them.
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | wildchicken13 | | Posted: | May 26, 2020 23:36 | | Subject: | Re: Why are these Hinges? | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | The catalog is always a compromise.
|
I'm completely willing to compromise. One of the other commenters in this
thread is advocating for an attribute-based system. Even though there have been
plenty of hours put into defining categories, it sounds like that wouldn't
be necessary with an attribute-based system.
I'd be perfectly happy to consider doing away with the (frankly) lengthy
and cumbersome category definitions page if someone fleshed out some guidelines
for an attribute-based system and presented them.
|
I like the idea of an actual category tree. Like a decision tree. So when you
click on "plate" you see everything that can be considered a plate and then you
can filter by attributes like the presence or absence of a hinge, the shape (square,
round, or wedge-shaped), the size, etc. Ideally, you would be able to do this
in any order; for example, you could start by clicking on "hinge" and then filter
by hinge bricks, hinge plates, hinge panels, etc. Maybe this is a bit out there,
but it would solve two problems, namely (1) identifying an unfamiliar part, and
(2) trying to find a part with particular characteristics, such as when building
a MOC. LEGO Pick-A-Brick already does this to a small extent.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: | randyf | | Posted: | May 27, 2020 01:49 | | Subject: | Re: Why are these Hinges? | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, wildchicken13 writes:
| | In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | The catalog is always a compromise.
|
I'm completely willing to compromise. One of the other commenters in this
thread is advocating for an attribute-based system. Even though there have been
plenty of hours put into defining categories, it sounds like that wouldn't
be necessary with an attribute-based system.
I'd be perfectly happy to consider doing away with the (frankly) lengthy
and cumbersome category definitions page if someone fleshed out some guidelines
for an attribute-based system and presented them.
|
I like the idea of an actual category tree. Like a decision tree. So when you
click on "plate" you see everything that can be considered a plate and then you
can filter by attributes like the presence or absence of a hinge, the shape (square,
round, or wedge-shaped), the size, etc. Ideally, you would be able to do this
in any order; for example, you could start by clicking on "hinge" and then filter
by hinge bricks, hinge plates, hinge panels, etc. Maybe this is a bit out there,
but it would solve two problems, namely (1) identifying an unfamiliar part, and
(2) trying to find a part with particular characteristics, such as when building
a MOC. LEGO Pick-A-Brick already does this to a small extent.
|
That would be the best way to do it, but BrickLink has a flat catalog that does
not allow for that. In other words, any given part can only be in one category.
So, if something is in the "Plate" category, it cannot also exist in the "Plate,
Round" category. The idea you present would take a lot of programming resources,
and the catalog team does not get the privilege of having access to developers
that listen to our wants and needs. Instead, we get BrickLink XP.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | bje | | Posted: | May 25, 2020 06:25 | | Subject: | Re: Why are these Hinges? | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
Maybe the definition at present is too broad in its scope. Should it not reflect
the specialised nature of the parts to be included in that definition, something
like:
Hinge - For items that facilitate one degree of movement by using a stepped
gear or a pin and knuckle assembly to pivot when connected or .
or
Hinge - For items that facilitate one degree of stepper motion or rotation
using a pintle when connected.
Parts which use handles, clips and bars to perform that movement can then stay
in their respective categories as the hinge parts are specialised for a specific
type of movement or using a specialised method of connecting.
The one degree of movement obviously refers to the plane of movement so that
ball and socket joints are excluded form here, as they should be. Stepper motion
or stepped motion or stepping motion to seperate from brushed motion in the same
plane, which is what would achieved with plates, bricks etc attaching with a
clip or a bar. The pin and knuckle components are specific to hinge design as
far as I know, so again that can exclude pins, bars and clips used for a similar
movement.
I would not like to see clip and bar systems included in the hinge category as
that would mean that some doors and windows also have to move.
I would not like to see the hinge category removed as getting these items under
modified cylinders, bricks, plates, panels, slopes and whatever else is really
not a good idea as it would complicate those sections far too much or worse
still, having categories for modified cylinders and the like.
Also, if you stick with the type of motion or type of connecting parts, you can
make the definition probably easier than having to deal with specific parts designed
to fit together in a specific way to allow for a specific subset of joints to
function in an intended manner
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | Teup | | Posted: | May 25, 2020 09:08 | | Subject: | Re: Why are these Hinges? | | Viewed: | 50 times | | Topic: | Catalog | |
|
| In Catalog, bje writes:
| | In Catalog, StormChaser writes:
| | In Catalog, wildchicken13 writes:
| | Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
It's your catalog. What would you like to see and how would you revise the
category descriptions to make it happen?
|
Maybe the definition at present is too broad in its scope. Should it not reflect
the specialised nature of the parts to be included in that definition, something
like:
Hinge - For items that facilitate one degree of movement by using a stepped
gear or a pin and knuckle assembly to pivot when connected or .
or
Hinge - For items that facilitate one degree of stepper motion or rotation
using a pintle when connected.
Parts which use handles, clips and bars to perform that movement can then stay
in their respective categories as the hinge parts are specialised for a specific
type of movement or using a specialised method of connecting.
The one degree of movement obviously refers to the plane of movement so that
ball and socket joints are excluded form here, as they should be. Stepper motion
or stepped motion or stepping motion to seperate from brushed motion in the same
plane, which is what would achieved with plates, bricks etc attaching with a
clip or a bar. The pin and knuckle components are specific to hinge design as
far as I know, so again that can exclude pins, bars and clips used for a similar
movement.
I would not like to see clip and bar systems included in the hinge category as
that would mean that some doors and windows also have to move.
I would not like to see the hinge category removed as getting these items under
modified cylinders, bricks, plates, panels, slopes and whatever else is really
not a good idea as it would complicate those sections far too much or worse
still, having categories for modified cylinders and the like.
Also, if you stick with the type of motion or type of connecting parts, you can
make the definition probably easier than having to deal with specific parts designed
to fit together in a specific way to allow for a specific subset of joints to
function in an intended manner
|
Agreed, clips and bars are a different system, and in fact they can frequently
be disconnected during play without that constituting "disassembling" the set.
Maybe a good (part of the) definition of hinges is that the parts do not appear
without a counterpart (unless used creatively)? That would include the toothed
hinge plates, swivels, hinge bricks and their top plates, and as far as I can
see pretty much everything else that is in Hinge.
In fact, I would prefer if it would include turntables - the same logic applies
to their bases and top plates (when they're not Plate,Rounds that can be
used in isolation). It's a tiny category that just makes the list of categories
longer. Hinge & Turntable would be pretty neat at least it's how I stored
it as a kid.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | qwertyboy | | Posted: | May 25, 2020 18:13 | | Subject: | Re: Why are these Hinges? | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | Maybe a good (part of the) definition of hinges is that the parts do not appear
without a counterpart (unless used creatively)? That would include the toothed
hinge plates, swivels, hinge bricks and their top plates, and as far as I can
see pretty much everything else that is in Hinge.
In fact, I would prefer if it would include turntables - the same logic applies
to their bases and top plates (when they're not Plate,Rounds that can be
used in isolation).
|
208 turntable bases in these two sets beg to differ...
Niek.
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | May 25, 2020 18:33 | | Subject: | Re: Why are these Hinges? | | Viewed: | 28 times | | Topic: | Catalog | |
|
| In Catalog, qwertyboy writes:
| | In Catalog, Teup writes:
| | Maybe a good (part of the) definition of hinges is that the parts do not appear
without a counterpart (unless used creatively)? That would include the toothed
hinge plates, swivels, hinge bricks and their top plates, and as far as I can
see pretty much everything else that is in Hinge.
In fact, I would prefer if it would include turntables - the same logic applies
to their bases and top plates (when they're not Plate,Rounds that can be
used in isolation).
|
208 turntable bases in these two sets beg to differ...
Niek.
|
True.. that's why I made an exception for "used creatively" It's more
of an AFOL'ish way to use that part than how it was intended.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | BricksThatStick | | Posted: | May 25, 2020 03:17 | | Subject: | Re: Why are these Hinges? | | Viewed: | 39 times | | Topic: | Catalog | |
|
| In Catalog, wildchicken13 writes:
| | In Catalog, StormChaser writes:
| | In Catalog, Give.Me.A.Brick writes:
| | If they belong together then they should be in Train category?
|
| | But again, there is no hinge. If they really have to belong together, maybe they
should be in Panel category?
|
I would say take a look at this proposed page and see if it, in your opinion,
properly addresses this issue. If it does not, then offer suggestions for improving
it:
https://www.bricklink.com/help.asp?helpID=2479
The page is proposed now, but is expected to become official in about a week.
The purpose of the page is to determine the proper category in situations like
the one you mention.
Does it do its job, or does it need work?
|
Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
"When in use a hinge needs to connect to another hinge to make it a hinge"
Does that apply to all hinges in use in sets?
Maybe the hinge category could somehow be defined based on that if so?
Plates with handles are modified plates. A handle doesn't make it a hinge
because it connects to other parts and moves. If that were the case plates with
clips could be included as well.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | 62Bricks | | Posted: | May 25, 2020 09:28 | | Subject: | Re: Why are these Hinges? | | Viewed: | 60 times | | Topic: | Catalog | |
|
| In Catalog, BricksThatStick writes:
| | In Catalog, wildchicken13 writes:
| | In Catalog, StormChaser writes:
| | In Catalog, Give.Me.A.Brick writes:
| | If they belong together then they should be in Train category?
|
| | But again, there is no hinge. If they really have to belong together, maybe they
should be in Panel category?
|
I would say take a look at this proposed page and see if it, in your opinion,
properly addresses this issue. If it does not, then offer suggestions for improving
it:
https://www.bricklink.com/help.asp?helpID=2479
The page is proposed now, but is expected to become official in about a week.
The purpose of the page is to determine the proper category in situations like
the one you mention.
Does it do its job, or does it need work?
|
Under the new definitions,
could fall under either plate modified or hinge. Should we make an exception
for handles? Or should we handle these cases by defaulting to the existing categorization?
|
"When in use a hinge needs to connect to another hinge to make it a hinge"
Does that apply to all hinges in use in sets?
Maybe the hinge category could somehow be defined based on that if so?
Plates with handles are modified plates. A handle doesn't make it a hinge
because it connects to other parts and moves. If that were the case plates with
clips could be included as well.
|
The question is not where to draw the lines, but which lines should be drawn
in the first place.
The categories that are based on one particular type of attachment or usage should
be eliminated and the parts distributed to categories based on general characteristics.
They aren't hinges shaped like plates, they are plates with a hinge attachment.
Likewise, they aren't hinges shaped like bricks, they are bricks with a hinge
attachment. So long as these types of categories exist, their definitions can
be debated forever without improving anything.
The reasons should be clear from this discussion. When you find yourself having
to think up all the exceptions you want to make to a rule so as not to disturb
the other categories, that is a sure sign you are coming at the problem from
the wrong direction.
|
|
|
| | | | | |
| | | | | Author: | wildchicken13 | | Posted: | May 25, 2020 00:02 | | Subject: | Re: Why are these Hinges? | | Viewed: | 41 times | | Topic: | Catalog | |
|
| In Catalog, Give.Me.A.Brick writes:
| | 1.
* | | 37494 Bar 3.6L Double with Angled Ends (Train Pantograph Shoe)
Parts: Bar |
There is no hinge in it.
I understand it is familiar with:
* | | 2922 Hinge Train Pantograph Shoe Locking with 2 Fingers
Parts: Hinge |
and
but there is no hinge.
If they belong together then they should be in Train category?
2.
Again I understand the familiarity with:
and
* | | 44572 Panel 2 x 4 x 3 1/3 with Double Locking 2 Fingers Hinge
Parts: Panel |
But again, there is no hinge. If they really have to belong together, maybe they
should be in Panel category?
Just my opinion, anyway. What do you reckon?
|
has handles on the bottom, so I can understand why it might be considered
a hinge, but then and the like would have to be considered hinges,
so I vote no on that one. Should be a panel instead.
* | | 37494 Bar 3.6L Double with Angled Ends (Train Pantograph Shoe)
Parts: Bar |
should definitely not be a hinge, maybe train or bar instead.
* | | 37494 Bar 3.6L Double with Angled Ends (Train Pantograph Shoe)
Parts: Bar |
* | | 2922 Hinge Train Pantograph Shoe Locking with 2 Fingers
Parts: Hinge |
should all be train if you ask me.
|
|
|
| | | | | |
| | | | | Author: | jennnifer | | Posted: | May 25, 2020 11:17 | | Subject: | Re: Why are these Hinges? | | Viewed: | 39 times | | Topic: | Catalog | |
|
| Here is another Hinge category pickle:
[p=x277]
* | | 47973 Hinge 1 x 3 with Two Pins, Locking 1 Finger - Round Pin Holes
Parts: Hinge |
|
|
| | | | | | | | | |
| | | | | | | Author: | qwertyboy | | Posted: | May 25, 2020 19:02 | | Subject: | Re: Why are these Hinges? | | Viewed: | 42 times | | Topic: | Catalog | |
|
| In Catalog, jennnifer writes:
| | Here is another Hinge category pickle:
[p=x277]
* | | 47973 Hinge 1 x 3 with Two Pins, Locking 1 Finger - Round Pin Holes
Parts: Hinge |
|
I might be (partially) to blame. Items were moved around after a previous discussion:
https://www.bricklink.com/message.asp?ID=1105117
My opinion is that a catalog structure should be there to make it easier to find
parts. If a part looks like "a brick with a thing attached to it", you should
be able to find it in some "brick" category. For the parts in the linked message,
they look very similar, so they should be in the same category (based on how
they look). A categorization stringently based on a functionality might help
put each part in one category, but it will very likely not help a non-expert
to find it.
So (for lack of a tiered category system or some tagged-based solution) it
would make sense to me to try and stick more to categories like "brick-something",
"plate-something" etc. More of "what does it look like", less of "how is it used".
Niek.
|
|
|
| | | | | |
| | | | | Author: | Give.Me.A.Brick | | Posted: | May 25, 2020 15:29 | | Subject: | Re: Why are these Hinges? | | Viewed: | 49 times | | Topic: | Catalog | |
|
| In Catalog, Give.Me.A.Brick writes:
| |
* | | 37494 Bar 3.6L Double with Angled Ends (Train Pantograph Shoe)
Parts: Bar |
|
Thank you everyone, some interesting ideas, and yes, the Hinge category deserves
some attention. (old pet peeve there, Jen? )
My point, and I am not sure if it came across very clear, is that these particular
parts don't have a hinge.
It's like a part being in the Slope category with having any kind of slope
in it.
Or some part being in the Technic Connector category without having an actual
technic connector in it.
Oh wait
(Old pet peeve of mine, change request denied, there is NOT an axle nor a pin
connector in this part. Should be in the Hero Factory for the time being, or
better ye, in the the yet to be created Ball/Joint category)
Also, regarding rules, I don't know, but when I look at this part it sure
looks like a door to me:
And this one like a bucket:
Separated from his twin brother:
And speaking of twins and back on the hinge slippery slope:
Why one is a Slope and the other one Hinge, they are in LEGO's mind the same
part, just an update:
(...)
I mean, the catatlog surely needs rules, and thank you for all the people trying
to make thinks in a logical, standardized and clean way, but do we need rules
such as:
§3.1 A part to qualify to be in the Plate Modified category needs to have a portion
of a plate in it.
§7.1 A part to qualify be in the Hinge category needs to have a hinge in it
Thoughts?
|
|
|
| | | | | | | | | |
| | | | | | | Author: | StormChaser | | Posted: | May 25, 2020 15:34 | | Subject: | Re: Why are these Hinges? | | Viewed: | 56 times | | Topic: | Catalog | |
|
| In Catalog, Give.Me.A.Brick writes:
I would say take a look at this proposed page and see if it, in your opinion,
properly addresses this issue. If it does not, then offer suggestions for improving
it:
https://www.bricklink.com/help.asp?helpID=2479
The page is proposed now, but is expected to become official in about a week.
The purpose of the page is to determine the proper category in situations like
the one you mention.
Does it do its job, or does it need work?
|
|
|
|
|
Portugal
USA, Oklahoma
France, Nouvelle-Aquitaine
United Kingdom, England
Netherlands, Utrecht
Canada, Ontario
South Africa, Western Cape
