|
 |
| | | Author: | StormChaser  | | Posted: | Dec 9, 2019 05:57 | | Subject: | Parts Category Tree | | Viewed: | 236 times | | Topic: | Catalog | | Status: | Open | |
|
| I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
|
|
|
| | | | | |
| | | | | Author: | calsbricks | | Posted: | Dec 9, 2019 06:17 | | Subject: | Re: Parts Category Tree | | Viewed: | 64 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | yorbrick | | Posted: | Dec 9, 2019 06:46 | | Subject: | Re: Parts Category Tree | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, calsbricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
I think it needs a complete rethink and a more modern idea - where something
can be more than one thing. So for example, I'd like to see one category
called "Bricks", and inside this, there can be all the existing types of bricks
categories. This would allow someone to search just through the "Bricks" parent
category but all of them at once. However, there are also technic bricks, which
don't get called "Bricks, technic", rather they are "Technic, bricks". They
are also bricks, so should be searchable under a "Bricks" parent, but also under
a "Technic" parent too.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | calsbricks | | Posted: | Dec 9, 2019 06:55 | | Subject: | Re: Parts Category Tree | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | In Catalog, calsbricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
I think it needs a complete rethink and a more modern idea - where something
can be more than one thing. So for example, I'd like to see one category
called "Bricks", and inside this, there can be all the existing types of bricks
categories. This would allow someone to search just through the "Bricks" parent
category but all of them at once. However, there are also technic bricks, which
don't get called "Bricks, technic", rather they are "Technic, bricks". They
are also bricks, so should be searchable under a "Bricks" parent, but also under
a "Technic" parent too.
|
That is pretty much the way our system works. We decide what the families are
(level above categories) and what goes in them. All of our analysis is done by
family but if we want to take it lower we can. We have bricks, Minifigs, Other,
Plates, Sets (Small polybags), Slopes, Technic and tiles. Other is obviously
the catch all for items that don't fall into any of the others. It does work
and it makes it very easy for us to see what is moving and what isn't
We think the level above categories should be user definable as not everyone
will want to combine the same things. It isn't that complicated to program
and lots of the big high end inventory management systems have it built in, so
there is excellent code examples out there to accommodate.
I think the only real thing we can say is - no harm in dreaming.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | yorbrick | | Posted: | Dec 9, 2019 06:58 | | Subject: | Re: Parts Category Tree | | Viewed: | 40 times | | Topic: | Catalog | |
|
| In Catalog, calsbricks writes:
| | In Catalog, yorbrick writes:
| | In Catalog, calsbricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
I think it needs a complete rethink and a more modern idea - where something
can be more than one thing. So for example, I'd like to see one category
called "Bricks", and inside this, there can be all the existing types of bricks
categories. This would allow someone to search just through the "Bricks" parent
category but all of them at once. However, there are also technic bricks, which
don't get called "Bricks, technic", rather they are "Technic, bricks". They
are also bricks, so should be searchable under a "Bricks" parent, but also under
a "Technic" parent too.
|
That is pretty much the way our system works. We decide what the families are
(level above categories) and what goes in them. All of our analysis is done by
family but if we want to take it lower we can. We have bricks, Minifigs, Other,
Plates, Sets (Small polybags), Slopes, Technic and tiles. Other is obviously
the catch all for items that don't fall into any of the others. It does work
and it makes it very easy for us to see what is moving and what isn't
We think the level above categories should be user definable as not everyone
will want to combine the same things. It isn't that complicated to program
and lots of the big high end inventory management systems have it built in, so
there is excellent code examples out there to accommodate.
I think the only real thing we can say is - no harm in dreaming.
|
It will be interesting to see if LEGO change anything. After all, their online
PAB has very different structure (and often just as confusing as BL's if
you are not used to it).
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | StormChaser | | Posted: | Dec 9, 2019 14:05 | | Subject: | Re: Parts Category Tree | | Viewed: | 44 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | I think it needs a complete rethink and a more modern idea - where something
can be more than one thing. So for example, I'd like to see one category
called "Bricks", and inside this, there can be all the existing types of bricks
categories.
|
That's an interesting idea and I'd like to see how it would work in practice.
Could you lay out a scheme of how the parts categories would be structured?
I used MS Word to create the images shown in my original post if that's
helpful.
I'd like to see how your system would work.
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | mhortar | | Posted: | Dec 10, 2019 01:17 | | Subject: | Re: Parts Category Tree | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, yorbrick writes:
| | I think it needs a complete rethink and a more modern idea - where something
can be more than one thing. So for example, I'd like to see one category
called "Bricks", and inside this, there can be all the existing types of bricks
categories.
|
That's an interesting idea and I'd like to see how it would work in practice.
Could you lay out a scheme of how the parts categories would be structured?
I used MS Word to create the images shown in my original post if that's
helpful.
I'd like to see how your system would work.
|
This is something that I'd been tossing around on my own for years. I was
trying to adapt it to a logical sorting/storage system, but that doesn't
really fit well.
You'd start with the broad, overarching categories:
- Brick (parts that are greater than 1 plate high)
- Plate (parts that are 1 plate high)
- Figure (minifigure body parts, head, torso, etc and accessories)
- Wheel (parts that have/are wheels)
- Duplo
- Other (catch all)
There probably needs to be more major categories, but the idea is to keep it
relatively small at the top level. Each part must contain exactly one top level
category.
Then you have secondary categories. These are in addition to the top level category
and zero or more can be added to any of the existing (although some sub categories
may only apply to certain top level categories). There would be many sub-categories
- Accessory (anything introduced as part of a minfigure that isn't a body
part. Only applies to Figure top level)
- Round (applies to plates, bricks, etc)
- Angled (coould apply to slopes or wedges)
- Curved
- Modified
- Tile
- Decorated
- Cutout
- Technic (anything with pins or pin receptacles)
- Pin
etc
Examples:
would just have the 'Brick' category.
would have the 'Brick' and 'Angled' categories
would have the 'Brick', 'Curved' categories
would have 'Brick', 'Round', 'Curved',
'Decorated'
would have 'Plate', 'Tile', 'Cutout'
would have 'Brick', 'Technic', 'Pin'
would have 'Brick', 'Angled'
would have 'Brick', 'Angled', 'Curved'
New sub categories could be added whenever the need arises and then applied much
easier to existing parts without necessarily having to change the existing categories
or 'move' the part to another part of the catalog
There obviously needs to be way more thought put into this, but I think it would
help immensely for searching plus would still be viable for displaying with the
existing tree structure. It's just that some parts would show up in multiple
places depending on their categories (which I don't really see as an issue,
but a feature).
Josh
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | StormChaser | | Posted: | Dec 10, 2019 04:03 | | Subject: | Re: Parts Category Tree | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, mhortar writes:
| | There obviously needs to be way more thought put into this, but I think it would
help immensely for searching plus would still be viable for displaying with the
existing tree structure. It's just that some parts would show up in multiple
places depending on their categories
|
That seems like a great plan for the tag system when it arrives. If the tag
system is done properly, it can be an entirely new way of seeing/searching the
catalog and will thus be starting from scratch (as I agree with Don and Cory
really should be done).
However, I also agree with Russell and Teup on the value of the current category
system and, after 20 years, I don't think it would be wise to completely
reorganize from the ground up. Maybe I do too much agreeing . . .
I think we could have it both ways, though. I still would like to see the current
category trees reduced by folding some categories into submenus, as stated in
my original post, but the tag system could be used to start from the ground up
and rethink the catalog's organization now that we understand things from
the perspective of 100,000+ catalog entries.
My biggest question on the tag system is if it could be used as a standalone
feature for those wanting to ignore the existing categories altogether when browsing
the catalog and rely solely on tags to find things. This would be perfect -
we could keep the current (dis)organization and add something a little more sensible.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | Admin_Russell | | Posted: | Dec 9, 2019 21:45 | | Subject: | Re: Parts Category Tree | | Viewed: | 91 times | | Topic: | Catalog | |
|
|
BrickLink
ID CardAdmin_Russell
|
Location:  USA, California |
| Member Since |
Contact |
Type |
Status |
| May 9, 2017 |
 |
Admin |
|
|
| BrickLink Administrator |
|
| In Catalog, yorbrick writes:
| | | | This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
I think it needs a complete rethink and a more modern idea - where something
can be more than one thing.
|
That is the flexibility we would get by using a tag system. But the tree still
needs to be there in the background to provide stability. I believe this conversation
is about what that tree should look like.
For a long time we have needed a stepping stone approach to handle the massive
numbers of entries in the catalog. Instead of being presented with 300-some categories,
new users (at least) should start with a few basic choices that lead to other
more detailed choices and perhaps even another level or two to drill down into
what we have come to accept as a "BrickLink category".
During this "drilling" process, they need the option of searching by tag to make
sure they are not missing things due to semantics.
I have often thought that because there are such different types of BrickLink
users, that we should offer several different methods of finding things, perhaps
even including ones developed by certain well known members of the community
(cough, cough) who have already developed third party searching aids.
But these would necessarily be a function of a tag system and not a tree, because
the tree provides its own browsing mechanism, which is of special value to those
maintaining the catalog - who need the ability to work through things section
by section.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | yorbrick | | Posted: | Dec 10, 2019 04:20 | | Subject: | Re: Parts Category Tree | | Viewed: | 27 times | | Topic: | Catalog | |
|
| In Catalog, Admin_Russell writes:
| | In Catalog, yorbrick writes:
| | | | This is a good idea and follows our Family level above categories which we put
into the forum a very long time ago. but whether anything will ever get done
about it remains to be seen. Since your departure and recent return nothing much
has happened on the development side and with the Lego acquisition due shortly
it may be some time before anything actually does. We have done this offline
with our own database system.
It does work and is not clumsy nor long winded - after all unless your are really
into the catalogue you probably don't even know that much about all the sub
menus. A 'soccer mom' might want a star wars set for her son but will
she know which one of the sub menus it is under - not likely - that is for collectors
and enthusiasts.
|
I think it needs a complete rethink and a more modern idea - where something
can be more than one thing.
|
That is the flexibility we would get by using a tag system. But the tree still
needs to be there in the background to provide stability. I believe this conversation
is about what that tree should look like.
For a long time we have needed a stepping stone approach to handle the massive
numbers of entries in the catalog. Instead of being presented with 300-some categories,
new users (at least) should start with a few basic choices that lead to other
more detailed choices and perhaps even another level or two to drill down into
what we have come to accept as a "BrickLink category".
During this "drilling" process, they need the option of searching by tag to make
sure they are not missing things due to semantics.
I have often thought that because there are such different types of BrickLink
users, that we should offer several different methods of finding things, perhaps
even including ones developed by certain well known members of the community
(cough, cough) who have already developed third party searching aids.
But these would necessarily be a function of a tag system and not a tree, because
the tree provides its own browsing mechanism, which is of special value to those
maintaining the catalog - who need the ability to work through things section
by section.
|
Yeah, I don't think that this would need a huge reorganisation. For example,
currently we have:
Brick
Brick, Arch
Brick, Arch, Decorated
:
:
Brick, Round, Decorated
They are all bricks. So why not have a parent "Bricks", then all these as sub-categories
within bricks. "Technic, Bricks" could also be linked into it while also remaining
under the technic parent too.
It would be easier if you just wanted to browse bricks. Similar it would also
work if you wanted to search just within bricks - sometimes you have to run multiple
searches in multiple categories to find what you want.
There are quite a few parent categories that could be chosen - minifigures, slopes,
technic, plates, tiles, vehicles, electric, duplo, etc.
Tags would be preferable, but I guess that is going to need a lot of data added.
|
|
|
| | | | | |
| | | | | Author: | randyf | | Posted: | Dec 9, 2019 09:00 | | Subject: | Re: Parts Category Tree | | Viewed: | 55 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
You know I like this idea. I have been dreaming for something like this ever
since we saw the prototype redesigned catalog menu pages in Chicago 4 1/2 years
ago. This current team that owns BrickLink has been so horrible for the main
BrickLink site. All they did was spend their time on side ventures while ignoring
everything else. I wouldn't hold my breath on getting something like this
accomplished soon, but I am hopeful that LEGO sees a better future for the main
site.
Cheers,
Randy
|
|
|
| | | | | | | | | |
| | | | | | | Author: | StormChaser | | Posted: | Dec 9, 2019 14:01 | | Subject: | Re: Parts Category Tree | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, randyf writes:
| | All they did was spend their time on side ventures while ignoring
everything else. I wouldn't hold my breath on getting something like this
accomplished soon, but I am hopeful that LEGO sees a better future for the main
site.
|
It certainly felt like that. We did see some improvements in functionality for
the catalog and inventories during the 2010s, but nowhere near everything that
was needed.
As for TLG's vision: "We look forward to collaborating further with our adult
fans, while retaining and nurturing the independent spirit of the digital platform.”
If they stick with that position, I take it to mean that the community will still
be mostly responsible for the catalog (as it should be). Therefore, we as a
community should probably have some idea of what we'd collectively like to
see going forward.
The only way to get there is coming up with ideas and discussing them. This
has already happened, of course, with the 1,600 open site suggestions dating
back to 2010. Those really need to be worked through.
This particular idea about the Parts category tree seems like it would be fairly
easy to implement and would improve things in the ways I mentioned, while still
keeping the basic look and feel of the site intact.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | jcvp17 | | Posted: | Dec 9, 2019 14:52 | | Subject: | Re: Parts Category Tree | | Viewed: | 48 times | | Topic: | Catalog | |
|
| Hello!
In Catalog, StormChaser writes:
| | This particular idea about the Parts category tree seems like it would be fairly
easy to implement and would improve things in the ways I mentioned
|
To organize my collection of LEGO, about 15.000 pieces oriented mainly to TECHNIC
constructions, I use a simple EXCEL spreadsheet. To classify the pieces I have
made a simple tree of categories, which I add to this message in case anyone
is interested, I hope the screenshot looks good
I think that everything is easily understood, I just wanted to notice that I
call "pieces" to the pieces with rounded ends, and "bricks" to the pieces with
rectangular ends. I call them thick beam for example "beam 1 x 5" and if they
are thin I distinguish them like this: "beam 1 x 5 x 0.5"
At the moment it works for me and helps me to move between the large number of
different existing pieces.
Best regards.
jcvp17
|
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | jcvp17 | | Posted: | Dec 9, 2019 14:55 | | Subject: | Re: Parts Category Tree | | Viewed: | 28 times | | Topic: | Catalog | |
|
| In Catalog, jcvp17 writes:
| | I think that everything is easily understood, I just wanted to notice that I
call "pieces" to the pieces with rounded ends,
|
Sorry...
I call "beams" to the pieces with rounded ends....
|
|
| | | | | |
| | | | | Author: | 62Bricks | | Posted: | Dec 9, 2019 16:46 | | Subject: | Re: Parts Category Tree | | Viewed: | 52 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
At a certain point - and we may be at that point now - it makes more sense to
start over rather than try to squeeze what has never been a hierarchical system
into a tree. I feel the main issue is the inconsistency in how categories are
defined:
Shape - Brick, Plate, Slope, etc.
Surface appearance - All the decorated categories
Theme - Fabuland, Friends
Material - Cloth, Paper
Usage - Aircraft, Crane, Vehicle
Function - Hinge, Turntable
and so on.
It was never guided by any single, simple, defining characteristic that would
have kept it consistent. Trying to impose order on it now might reduce the "clutter"
but it won't fix the root cause of what has made it so unwieldy in the first
place.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | Teup | | Posted: | Dec 9, 2019 17:28 | | Subject: | Re: Parts Category Tree | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
At a certain point - and we may be at that point now - it makes more sense to
start over rather than try to squeeze what has never been a hierarchical system
into a tree.
|
I think this is part of the cycle of this discussion: we spot imperfections,
changing them have implications, we imagine some deeper more principal changes,
realise we might as well start over, and then realise no system is perfect and
things are not all that bad the way they are..
Not saying it's necessarily a bad idea in every way.... but there's one
major drawback to starting over: By now the catalog transcends Bricklink. Some
form of it has been adopted by other websites for trading as well as for collection
organisation. And I think this is really great. People are talking about wanting
to be "independent" and fear that LEGO buying Bricklink will make them "lose
independence"... but I don't think being owned by a random billionare means
"independence" either. To me, independence means that we've created a universal
Lego vocabulary that we can use anywhere and we don't depend on any one site.
Everyone knows what a Brick,Modified or a Wedge or Slope,Curved is, or what
counts as a Hinge and what as a Plate,Modified. Isn't that great? I think
it's worth preserving and strengthening. Starting over will mean Bricklink's
taxonomy will be unique and not compatible with other sites, and one system is
already more than enough to learn. This means people will get stuck with one
site and the exchange between them will be reduced, which I think would be a
shame. We're stronger when we connect everything.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | 62Bricks | | Posted: | Dec 9, 2019 20:38 | | Subject: | Re: Parts Category Tree | | Viewed: | 42 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | In Catalog, 62Bricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
At a certain point - and we may be at that point now - it makes more sense to
start over rather than try to squeeze what has never been a hierarchical system
into a tree.
|
I think this is part of the cycle of this discussion: we spot imperfections,
changing them have implications, we imagine some deeper more principal changes,
realise we might as well start over, and then realise no system is perfect and
things are not all that bad the way they are..
Not saying it's necessarily a bad idea in every way.... but there's one
major drawback to starting over: By now the catalog transcends Bricklink. Some
form of it has been adopted by other websites for trading as well as for collection
organisation. And I think this is really great. People are talking about wanting
to be "independent" and fear that LEGO buying Bricklink will make them "lose
independence"... but I don't think being owned by a random billionare means
"independence" either. To me, independence means that we've created a universal
Lego vocabulary that we can use anywhere and we don't depend on any one site.
Everyone knows what a Brick,Modified or a Wedge or Slope,Curved is, or what
counts as a Hinge and what as a Plate,Modified. Isn't that great? I think
it's worth preserving and strengthening. Starting over will mean Bricklink's
taxonomy will be unique and not compatible with other sites, and one system is
already more than enough to learn. This means people will get stuck with one
site and the exchange between them will be reduced, which I think would be a
shame. We're stronger when we connect everything.
|
But Bricklink is not really connected to any other major site in that way. What
other catalogs use the category "plate, modified," or anything similar? Brickowl
(38 top-level categories) does not. Rebrickable (65 categories) does not. Brickset
uses tags based on Lego's own category system, which is very broad and has
no such category. LDraw (84 categories) does not have a similar category.
I disagree that Bricklink's category is a standard. In fact the three major
catalog sites that have appeared after Bricklink have much simpler categories.
Even LDraw, which is the Grandaddy from which Bricklink borrowed heavily in early
days, has many fewer categories.
Far from being a standard taxonomy, Bricklink's category system stands like
a clunky behemoth among the rest.
I would also point out that not everyone knows what a "plate, modified" is. Or
even a "hinge." I think regular Bricklink users imagine they know what
makes a hinge a hinge, for example, but maybe they rarely see these three parts
on the same page:
* | | 4626 Vehicle, Digger Bucket 2 x 3 Curved Bottom, Hollow, with 2 Fingers Hinge
Parts: Vehicle |
* | | 51858 Crane Bucket Lift Basket 2 x 3 x 2 with Locking Hinge Fingers
Parts: Crane |
* | | 30394 Vehicle, Digger Bucket 7 Teeth 3 x 6 with Locking 2 Finger Hinge
Parts: Vehicle |
Aside from the dimensions and specific descriptive words, these three parts have
two words in common: "bucket" and "hinge." They should be in the same category.
Why aren't they? Because Bricklink has so many categories that nobody is
clear on what they all mean.
In a better system there would have been a guiding principle that laid what it
is that defines a part. One possibility would be to use the part's shape
as the top defining characteristic, then move on to other characteristics, like
added functional elements. So you would group these items together based on their
shape. And you would include others with a similar shape, like
[p=3493]
Then from there, you could refine the category to define those with hinges. Under
such a system, a part like
* | | 4276 Hinge Plate 1 x 2 with 2 Fingers on End (Undetermined Type)
Parts: Hinge |
would be a "plate, hinge" not a "hinge plate."
Likewise, all the hinge bricks would move to the brick category.
This is just one possibility, but basing categories on shapes (rather than half
a dozen unrelated characteristics) would have one simple advantage - every part
has a shape, and shapes truly are universal.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | SylvainLS | | Posted: | Dec 9, 2019 21:13 | | Subject: | Re: Parts Category Tree | | Viewed: | 28 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | […]
This is just one possibility, but basing categories on shapes (rather than half
a dozen unrelated characteristics) would have one simple advantage - every part
has a shape, and shapes truly are universal.
|
Well said!
(snipped part included)
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Teup | | Posted: | Dec 10, 2019 04:17 | | Subject: | Re: Parts Category Tree | | Viewed: | 35 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | In Catalog, Teup writes:
| | In Catalog, 62Bricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
At a certain point - and we may be at that point now - it makes more sense to
start over rather than try to squeeze what has never been a hierarchical system
into a tree.
|
I think this is part of the cycle of this discussion: we spot imperfections,
changing them have implications, we imagine some deeper more principal changes,
realise we might as well start over, and then realise no system is perfect and
things are not all that bad the way they are..
Not saying it's necessarily a bad idea in every way.... but there's one
major drawback to starting over: By now the catalog transcends Bricklink. Some
form of it has been adopted by other websites for trading as well as for collection
organisation. And I think this is really great. People are talking about wanting
to be "independent" and fear that LEGO buying Bricklink will make them "lose
independence"... but I don't think being owned by a random billionare means
"independence" either. To me, independence means that we've created a universal
Lego vocabulary that we can use anywhere and we don't depend on any one site.
Everyone knows what a Brick,Modified or a Wedge or Slope,Curved is, or what
counts as a Hinge and what as a Plate,Modified. Isn't that great? I think
it's worth preserving and strengthening. Starting over will mean Bricklink's
taxonomy will be unique and not compatible with other sites, and one system is
already more than enough to learn. This means people will get stuck with one
site and the exchange between them will be reduced, which I think would be a
shame. We're stronger when we connect everything.
|
But Bricklink is not really connected to any other major site in that way. What
other catalogs use the category "plate, modified," or anything similar? Brickowl
(38 top-level categories) does not. Rebrickable (65 categories) does not. Brickset
uses tags based on Lego's own category system, which is very broad and has
no such category. LDraw (84 categories) does not have a similar category.
I disagree that Bricklink's category is a standard. In fact the three major
catalog sites that have appeared after Bricklink have much simpler categories.
Even LDraw, which is the Grandaddy from which Bricklink borrowed heavily in early
days, has many fewer categories.
|
I am thinking about BrickOwl, Brickscout and Rebrickable, which people also use
for buying. Are there any trading sides I'm not aware of that use a fundamentally
different catalog?
| | I would also point out that not everyone knows what a "plate, modified" is. Or
even a "hinge." I think regular Bricklink users imagine they know what
makes a hinge a hinge, for example, but maybe they rarely see these three parts
on the same page:
* | | 4626 Vehicle, Digger Bucket 2 x 3 Curved Bottom, Hollow, with 2 Fingers Hinge
Parts: Vehicle |
* | | 51858 Crane Bucket Lift Basket 2 x 3 x 2 with Locking Hinge Fingers
Parts: Crane |
* | | 30394 Vehicle, Digger Bucket 7 Teeth 3 x 6 with Locking 2 Finger Hinge
Parts: Vehicle |
|
Of course, not in detail. But what I mean is that the general conceptual difference
between plate and hinge is understood.
| | (...) Under such a system, a part like
* | | 4276 Hinge Plate 1 x 2 with 2 Fingers on End (Undetermined Type)
Parts: Hinge |
would be a "plate, hinge" not a "hinge plate."
Likewise, all the hinge bricks would move to the brick category.
|
That is exactly what I mean by the general concept, and how it would be lost
in such a system. So in your system, how do category based sellers keep on selling
across platforms? If the catalog similarities with what I am using elsewhere
are lost, I am not sure how I will continue to sell on Bricklink.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | 62Bricks | | Posted: | Dec 10, 2019 10:02 | | Subject: | Re: Parts Category Tree | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | In Catalog, 62Bricks writes:
| | In Catalog, Teup writes:
| | In Catalog, 62Bricks writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
At a certain point - and we may be at that point now - it makes more sense to
start over rather than try to squeeze what has never been a hierarchical system
into a tree.
|
I think this is part of the cycle of this discussion: we spot imperfections,
changing them have implications, we imagine some deeper more principal changes,
realise we might as well start over, and then realise no system is perfect and
things are not all that bad the way they are..
Not saying it's necessarily a bad idea in every way.... but there's one
major drawback to starting over: By now the catalog transcends Bricklink. Some
form of it has been adopted by other websites for trading as well as for collection
organisation. And I think this is really great. People are talking about wanting
to be "independent" and fear that LEGO buying Bricklink will make them "lose
independence"... but I don't think being owned by a random billionare means
"independence" either. To me, independence means that we've created a universal
Lego vocabulary that we can use anywhere and we don't depend on any one site.
Everyone knows what a Brick,Modified or a Wedge or Slope,Curved is, or what
counts as a Hinge and what as a Plate,Modified. Isn't that great? I think
it's worth preserving and strengthening. Starting over will mean Bricklink's
taxonomy will be unique and not compatible with other sites, and one system is
already more than enough to learn. This means people will get stuck with one
site and the exchange between them will be reduced, which I think would be a
shame. We're stronger when we connect everything.
|
But Bricklink is not really connected to any other major site in that way. What
other catalogs use the category "plate, modified," or anything similar? Brickowl
(38 top-level categories) does not. Rebrickable (65 categories) does not. Brickset
uses tags based on Lego's own category system, which is very broad and has
no such category. LDraw (84 categories) does not have a similar category.
I disagree that Bricklink's category is a standard. In fact the three major
catalog sites that have appeared after Bricklink have much simpler categories.
Even LDraw, which is the Grandaddy from which Bricklink borrowed heavily in early
days, has many fewer categories.
|
I am thinking about BrickOwl, Brickscout and Rebrickable, which people also use
for buying. Are there any trading sides I'm not aware of that use a fundamentally
different catalog?
|
Brickscout is the only one that maps the BL categories closely. Rebrickable and
Brickowl do not. There is no top level "crane" category on Brickowl or Rebrickable,
for example. One has the crane bucket piece in a subset of the vehicle category
and one groups it with supports and turntables.
| |
| | I would also point out that not everyone knows what a "plate, modified" is. Or
even a "hinge." I think regular Bricklink users imagine they know what
makes a hinge a hinge, for example, but maybe they rarely see these three parts
on the same page:
* | | 4626 Vehicle, Digger Bucket 2 x 3 Curved Bottom, Hollow, with 2 Fingers Hinge
Parts: Vehicle |
* | | 51858 Crane Bucket Lift Basket 2 x 3 x 2 with Locking Hinge Fingers
Parts: Crane |
* | | 30394 Vehicle, Digger Bucket 7 Teeth 3 x 6 with Locking 2 Finger Hinge
Parts: Vehicle |
|
Of course, not in detail. But what I mean is that the general conceptual difference
between plate and hinge is understood.
| | (...) Under such a system, a part like
* | | 4276 Hinge Plate 1 x 2 with 2 Fingers on End (Undetermined Type)
Parts: Hinge |
would be a "plate, hinge" not a "hinge plate."
Likewise, all the hinge bricks would move to the brick category.
|
That is exactly what I mean by the general concept, and how it would be lost
in such a system. So in your system, how do category based sellers keep on selling
across platforms? If the catalog similarities with what I am using elsewhere
are lost, I am not sure how I will continue to sell on Bricklink.
|
What is the fundamental difference between a 1x2 plate with a hinge attached
and a 1x2 plate with a clip, or a pin hole, or a bar attached? They are all 1x2
plates with an extra type of attachment. But for some reason, the hinge attachment
has been singled out and given its own category. So some are defined by their
shape (plate), some by their type of attachment (hinge), and some by the theme
(Technic). Instead, they should all be placed in a top level category by the
same criteria. That doesn't have to be shape - it could be attachment type
or dimensions or something else, but it should be something common to all parts
and consistently applied.
As for selling across platforms, I don't see how the categories make any
difference to a seller. They don't match as it is, except for brick scout.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | Teup | | Posted: | Dec 10, 2019 10:59 | | Subject: | Re: Parts Category Tree | | Viewed: | 32 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | What is the fundamental difference between a 1x2 plate with a hinge attached
and a 1x2 plate with a clip, or a pin hole, or a bar attached? They are all 1x2
plates with an extra type of attachment. But for some reason, the hinge attachment
has been singled out and given its own category. So some are defined by their
shape (plate), some by their type of attachment (hinge), and some by the theme
(Technic). Instead, they should all be placed in a top level category by the
same criteria. That doesn't have to be shape - it could be attachment type
or dimensions or something else, but it should be something common to all parts
and consistently applied.
|
I understand your reasoning, that's why I brought up the hinge vs plate modified
issue. There is no logic, but it's how we learned it, and I find it convenient
both when selling and buying. My point is that you could reform everything from
the ground up, but it would break with other sites. The question then is: Is
it worth it. In your opinion it is. In my opinion, it's only worth it if
it means we get a principally perfect system. But parts are not numbers that
you can order in one principally correct way. There is no "correct" way. There
will always be opinions and it's always a trade-off: Some want parts categorised
based on shape, others want them more based on thematic scopes, and there's
always a line to draw. It's like the dilemma in spelling reforms: etymology
vs phonology. So to throw away what common language we mananged to build up and
end up with a system that to you and some others will be ideal, and some others
may not be so ideal, to me isn't enough of an improvement to make it worth
it. I may even agree your system would be better and still it wouldn't outweigh
the universality for me. I guess our points are clear, we agree to disagree 
| | As for selling across platforms, I don't see how the categories make any
difference to a seller. They don't match as it is, except for brick scout.
|
Actually that's not right, BrickOwl also uses the same system (as well as
my webshop). Some parts are moved around but these are details. 95% is the same,
for example the hinge vs plate modified logic. I'm sorting orders on a daily
basis on both platforms and my storage is A-Z, and usually there is only like
1 or 2 "jumps" in my BrickOwl orders because of some categories grouped together.
That's acceptable and easy enough to work around. But if it would be all
moved and the order turns into total random with all different categories names...
well you can blame my lack if ingenuity but to be honest I don't know how
I'd pick orders... unless Bricklink would have an option to allow me to view
everything in the classic categories.
If your system could be a parallel system, perhaps a tag based system, then to
me it would be a nice improvement that doesn't come with a sacrifice.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | StormChaser | | Posted: | Dec 14, 2019 15:23 | | Subject: | Re: Parts Category Tree | | Viewed: | 62 times | | Topic: | Catalog | |
|
| In Catalog, 62Bricks writes:
| | So some are defined by their
shape (plate), some by their type of attachment (hinge), and some by the theme
(Technic). Instead, they should all be placed in a top level category by the
same criteria. That doesn't have to be shape - it could be attachment type
or dimensions or something else, but it should be something common to all parts
and consistently applied.
|
Getting away from the discussion of a potential data structure change that may
or may never happen and back to discussing the hierarchical system we have now
. . .
So I've given it more thought and I understand something that should have
been quite obvious before: why certain categories are themed. It's because
they are not compatible, generally speaking, with the standard building system.
Scala is a good example, although even in that category there are some, and
perhaps many, parts that belong elsewhere:
But Friends is an example of a parts category that should not exist. The Friends
line, generally speaking, is fully compatible with the classic building system.
And what you say about shape makes a lot of sense, too. In Technic, for example,
there are standard bricks with holes. Those are clearly just modified bricks.
The outline jcvp17 posted here (although it may need modifications) makes more
sense than what we have now:
https://www.bricklink.com/message.asp?ID=1168937
If we only talk about modifying the system we use now and not about any possible
future systems, it seems like it would be easier to find things with such a category
layout/categorization. You'd see some basic categories first, based as much
as possible on shape. Then one or at the most two levels of submenus would split
things up further.
I get (for the most part) what mfav and calsbricks are proposing, but it remains
to be seen the level of investment TLG is willing to sink into the catalog (and,
considering their own websites, what the results would be). Provided that the
site chooses to retain the hierarchical system, I think we all agree it can definitely
be improved.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | Dec 14, 2019 16:20 | | Subject: | Re: Parts Category Tree | | Viewed: | 49 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | So I've given it more thought and I understand something that should have
been quite obvious before: why certain categories are themed. It's because
they are not compatible, generally speaking, with the standard building system.
Scala is a good example, although even in that category there are some, and
perhaps many, parts that belong elsewhere:
But Friends is an example of a parts category that should not exist. The Friends
line, generally speaking, is fully compatible with the classic building system.
And what you say about shape makes a lot of sense, too.
|
Good thinking. Anyway the category became outdated as it was conceived back when
we thought that minidolls would be Friends-only, but now we know they appear
in different themes. Would that make the accessories Minidoll,Utensil for example
or what do you propose?
| | In Technic, for example,
there are standard bricks with holes. Those are clearly just modified bricks.
|
You want to move technic bricks into Brick Modified?  Bad idea if you ask me.
Brick Modified is already pretty huge, and technic bricks are in my experience
almost always ordered together with other technic parts. This way it is convenient
for buyers to find, and convenient for sellers to pick. I know BrickOwl has Brick,Technic
but I don't like it. Seems strange to have "Technic" subcategories pop up
multiple times under Brick and Plate rather than a main Technic category once.
But Brick,Modified would be even worse - essential technic parts drowning in
a massive category of other parts.
Technic bricks, pins, axes, gears, these are things that belong together.
Besides, it's also conceptually a misinterpretation the way I see it. Technic
Bricks aren't modified; Within the realm of Technic, these are the standard
bricks.
Of all divisions in the catalog, I think Technic vs the rest is actually one
of the clearest most obvious ones... With the hierarchy improvement it would
be even nicer, with Technic Brick being one of the subcategories besides Liftarm
(which is a logical alternative to them), Pins (that fit in them), Axles, and
all those other parts that they are always used with.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | StormChaser | | Posted: | Dec 14, 2019 18:09 | | Subject: | Re: Parts Category Tree | | Viewed: | 59 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | You want to move technic bricks into Brick Modified? Bad idea if you ask me.
Brick Modified is already pretty huge
|
Miscommunication on my part. I think the best thing to do here might be to table
the discussion until such time as it would be possible to have an actual example
category tree page that could be populated (just with categories) and submenus
that could be entered.
Maybe BL will provide that at some point, or perhaps someone could set up such
a page elsewhere.
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | jcvp17 | | Posted: | Dec 14, 2019 16:24 | | Subject: | Re: Parts Category Tree | | Viewed: | 45 times | | Topic: | Catalog | |
|
| Hello!
In Catalog, StormChaser writes:
| | The outline jcvp17 posted here (although it may need modifications) makes more
sense than what we have now:
https://www.bricklink.com/message.asp?ID=1168937
If we only talk about modifying the system we use now and not about any possible
future systems, it seems like it would be easier to find things with such a category
layout/categorization. You'd see some basic categories first, based as much
as possible on shape. Then one or at the most two levels of submenus would split
things up further.
|
I have updated the file whose image I sent, making some modifications to try
to adjust to two parameters that have been commented here:
1) Find a balance between form and function ... A delicate and sometimes difficult
balance ... but other times it is very simple: for example, a brick has - it
can have - so many functions that it is best to classify it by its shape. And
vice versa, a connecting rod has such a specific function that it overshadows
the importance of its shape. Therefore, I have categories that are based on form
and others that are based on function.
2) Do not pass, as cited for example StormChaser, three levels in the classification
tree: the least numerous "main categories" that are possible, the necessary /
essential subcategories (the core of the system, imho) and only some of these,
for its complexity and / or extension, have a third and final subdivision in
sub-subcategories.
I use this tree to classify my small collection of LEGO, about 15,000 pieces
(most of Technic) and it works quite well: when I have a piece in my hand and
look at it well, I almost always know which group to put it in (some are resist,
certainly )
This time I put the file, in case it is in someone's interest, in a more
visible format ...
https://www.jvilchesp.es/imagenes/lego_tree_categories.pdf
And since I don't have any obsession with copyright or intellectual property
or anything really everyone can do whatever they want with the simple ideas
that this work has, if it has any!
I really appreciate the suggestions and help that have been emerging in the forum
and that have helped me a lot to better understand some things.
Best regards
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | mfav | | Posted: | Dec 14, 2019 16:42 | | Subject: | Re: Parts Category Tree | | Viewed: | 52 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I get (for the most part) what mfav and calsbricks are proposing, but it remains
to be seen the level of investment TLG is willing to sink into the catalog (and,
considering their own websites, what the results would be). Provided that the
site chooses to retain the hierarchical system, I think we all agree it can definitely
be improved.
|
Nope. It won't be improved. It will be different. This is just rearranging
the content on shelves in the supermarket.
If the last couple deployments of "site improvements and updates" aren't
enough to dissuade you from tinkering with the site, well...I don't know
what to think. Kind of feels like the wheels are coming off the stagecoach and
the horses are headed for the ravine.
I sincerely appreciate the time, thought, enthusiasm, and commitment you have
for the catalog. Sincerely, I do. That said, I recommend letting stuff settle
down a bit. I'm afraid anything you cook up at this point may be wasted effort.
Stuff that was working two days ago may not be working now.
But it's your effort to waste, so I respect that.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | Teup | | Posted: | Dec 14, 2019 17:00 | | Subject: | Re: Parts Category Tree | | Viewed: | 51 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | In Catalog, StormChaser writes:
| | I get (for the most part) what mfav and calsbricks are proposing, but it remains
to be seen the level of investment TLG is willing to sink into the catalog (and,
considering their own websites, what the results would be). Provided that the
site chooses to retain the hierarchical system, I think we all agree it can definitely
be improved.
|
Nope. It won't be improved. It will be different. This is just rearranging
the content on shelves in the supermarket.
If the last couple deployments of "site improvements and updates" aren't
enough to dissuade you from tinkering with the site, well...I don't know
what to think. Kind of feels like the wheels are coming off the stagecoach and
the horses are headed for the ravine.
I sincerely appreciate the time, thought, enthusiasm, and commitment you have
for the catalog. Sincerely, I do. That said, I recommend letting stuff settle
down a bit. I'm afraid anything you cook up at this point may be wasted effort.
Stuff that was working two days ago may not be working now.
But it's your effort to waste, so I respect that.
|
That is very well put, I second that. I appreciate the effort people are making,
but to be honest I feel like the results would mostly satisfy some people's
personal feeling of how things make the most sense, rather than actually have
basis in UX testing or answers to identified findability problems. I could also
imagine a new catalog that would seem perfect to myself, but probably others
could still struggle with it. Perfect for revamping your own storage, but imposing
it on a global marketplace is something else.
A new catalog would be the most dramatic reorganisation in my 15 year Bricklink
"career" and probably for some other category based sellers as well. While I'm
not asking for sympathy, we better make sure that changes are objective improvements
rather than just new alternative ideas. That way the ton of work that would go
into reorganising a store at least feels like a productive effort. And then there's
also the issue of compatibility with other marketplaces that we lose. So let's
not lose our heads in the enthusiasm...
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | | | Author: | calsbricks | | Posted: | Dec 15, 2019 04:33 | | Subject: | Re: Parts Category Tree | | Viewed: | 55 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | In Catalog, mfav writes:
| | In Catalog, StormChaser writes:
| | I get (for the most part) what mfav and calsbricks are proposing, but it remains
to be seen the level of investment TLG is willing to sink into the catalog (and,
considering their own websites, what the results would be). Provided that the
site chooses to retain the hierarchical system, I think we all agree it can definitely
be improved.
|
Nope. It won't be improved. It will be different. This is just rearranging
the content on shelves in the supermarket.
If the last couple deployments of "site improvements and updates" aren't
enough to dissuade you from tinkering with the site, well...I don't know
what to think. Kind of feels like the wheels are coming off the stagecoach and
the horses are headed for the ravine.
I sincerely appreciate the time, thought, enthusiasm, and commitment you have
for the catalog. Sincerely, I do. That said, I recommend letting stuff settle
down a bit. I'm afraid anything you cook up at this point may be wasted effort.
Stuff that was working two days ago may not be working now.
But it's your effort to waste, so I respect that.
|
That is very well put, I second that. I appreciate the effort people are making,
but to be honest I feel like the results would mostly satisfy some people's
personal feeling of how things make the most sense, rather than actually have
basis in UX testing or answers to identified findability problems. I could also
imagine a new catalog that would seem perfect to myself, but probably others
could still struggle with it. Perfect for revamping your own storage, but imposing
it on a global marketplace is something else.
A new catalog would be the most dramatic reorganisation in my 15 year Bricklink
"career" and probably for some other category based sellers as well. While I'm
not asking for sympathy, we better make sure that changes are objective improvements
rather than just new alternative ideas. That way the ton of work that would go
into reorganising a store at least feels like a productive effort. And then there's
also the issue of compatibility with other marketplaces that we lose. So let's
not lose our heads in the enthusiasm...
|
I believe there are many members who would like to see change but are as wary
as we are about what that change may be. Track record at present is not great
and Lego are not really an IT company - that is pretty much an Achilles heel
for them as well. We, like others, will not give up in trying to bring about
changes that are needed but until the owner (whoever that ends up being) commits
to the investment that is required and puts the correct development team and
processes in place, it is a bit of 'wishful thinking'
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | | | Author: | calsbricks | | Posted: | Dec 15, 2019 04:26 | | Subject: | Re: Parts Category Tree | | Viewed: | 45 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | In Catalog, StormChaser writes:
| | I get (for the most part) what mfav and calsbricks are proposing, but it remains
to be seen the level of investment TLG is willing to sink into the catalog (and,
considering their own websites, what the results would be). Provided that the
site chooses to retain the hierarchical system, I think we all agree it can definitely
be improved.
|
Nope. It won't be improved. It will be different. This is just rearranging
the content on shelves in the supermarket.
If the last couple deployments of "site improvements and updates" aren't
enough to dissuade you from tinkering with the site, well...I don't know
what to think. Kind of feels like the wheels are coming off the stagecoach and
the horses are headed for the ravine.
I sincerely appreciate the time, thought, enthusiasm, and commitment you have
for the catalog. Sincerely, I do. That said, I recommend letting stuff settle
down a bit. I'm afraid anything you cook up at this point may be wasted effort.
Stuff that was working two days ago may not be working now.
But it's your effort to waste, so I respect that.
|
So do I but mfav is 100% correct.
|
|
|
| | | | | |
| | | | | Author: | popsicle | | Posted: | Dec 9, 2019 17:17 | | Subject: | Re: Parts Category Tree | | Viewed: | 51 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been pondering the category trees. When you click on Parts from the
main catalog page you get hit with 230 categories. It's hard to justify
adding further categories, even though needed for some existing categories, because
there are already too many.
I've also been thinking about simple fixes that maintain the BrickLink look
and feel and imagined what it might be like with some submenus (the large image
below with the selections shrunk from 230 to only 85). The little plus signs
might not be the best way to do this - they just indicate for the purposes of
discussion that this category can be expanded or leads to another menu.
I've also imagined a Themed Parts menu and a Minifigure Items menu (those
menus happen when you select those options from the main menu) and added those
images.
Of course, I would always want to be able to see the entire category tree by
default if I chose that option.
Good things: you don't have so much to wade through - allows quicker selection
of exactly what you're looking for. Also, the categories within submenus
could be significantly expanded to make finding items even easier without fear
of adding to the existing mess.
Bad thing: you have to click into more menus to get where you're going.
Thoughts?
|
Sure you want my thoughts?
Although StormChaser's Category Tree idea has merit. 62Bricks's "At a
certain point - and we may be at that point now - it makes more sense to start
over rather than try to squeeze what has never been a hierarchical system into
a tree" statement, goes deeper and to the root of the issue, with potential for
a lasting and fundamental fix.
Two very smart men. Gotta be proud sons of Oklahoma and Missouri 
|
|
|
| | | | | |
| | | | | Author: | StormChaser | | Posted: | Dec 10, 2019 04:48 | | Subject: | Re: Parts Category Tree | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been pondering the category trees.
|
Just as a side note on adding more parts categories, which submenus would allow:
Duplo has been split into 19 existing categories. The first one is titled simply
Duplo and contains 556 items. Those 556 items are essentially uncategorized
and the Duplo category functions at this point like an Other category.
So if there was an overarching Duplo category and clicking it opened a new set
of submenus showing only Duplo items, then those 500+ items could be separated
out into further categories without adding to the huge existing categories list
shown by default.
Some new categories this would allow based on some of the larger sections of
items now categorized only as Duplo:
Duplo, Ball Tube
Duplo, Building
Duplo, Container
Duplo, Door & Window
Duplo, Flag
Duplo, Hose
Duplo, Rattle
Duplo, Technic
Duplo, Tile
Duplo, Winch
Again, I get starting from scratch, but that could be accomplished with a tag
system. I'm mainly talking right now about ways to improve the functionality
and ease of use of the existing categories system.
And if we really wanted to get carried away (frankly, with the system I imagine
I see no reason not to) we could further separate by size. For example, the
Tile, Decorated category which currently contains 4,480 items could be divided
into:
Tile, Decorated 1 X 1
Tile, Decorated 1 X 2
Tile, Decorated 1 X 3
Tile, Decorated 1 X 4
Tile, Decorated 1 X 6
Tile, Decorated 1 X 8
etc.
With the ability to perform a keyword search (existing) and a tag system (hoped-for),
I really think the categories system would benefit from the kind of improvements
I'm proposing.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | Teup | | Posted: | Dec 10, 2019 04:58 | | Subject: | Re: Parts Category Tree | | Viewed: | 38 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, StormChaser writes:
| | I've been pondering the category trees.
|
Just as a side note on adding more parts categories, which submenus would allow:
Duplo has been split into 19 existing categories. The first one is titled simply
Duplo and contains 556 items. Those 556 items are essentially uncategorized
and the Duplo category functions at this point like an Other category.
So if there was an overarching Duplo category and clicking it opened a new set
of submenus showing only Duplo items, then those 500+ items could be separated
out into further categories without adding to the huge existing categories list
shown by default.
Some new categories this would allow based on some of the larger sections of
items now categorized only as Duplo:
Duplo, Ball Tube
Duplo, Building
Duplo, Container
Duplo, Door & Window
Duplo, Flag
Duplo, Hose
Duplo, Rattle
Duplo, Technic
Duplo, Tile
Duplo, Winch
Again, I get starting from scratch, but that could be accomplished with a tag
system. I'm mainly talking right now about ways to improve the functionality
and ease of use of the existing categories system.
And if we really wanted to get carried away (frankly, with the system I imagine
I see no reason not to) we could further separate by size. For example, the
Tile, Decorated category which currently contains 4,480 items could be divided
into:
Tile, Decorated 1 X 1
Tile, Decorated 1 X 2
Tile, Decorated 1 X 3
Tile, Decorated 1 X 4
Tile, Decorated 1 X 6
Tile, Decorated 1 X 8
etc.
With the ability to perform a keyword search (existing) and a tag system (hoped-for),
I really think the categories system would benefit from the kind of improvements
I'm proposing.
|
I like these ideas. It keeps things in tact while making it a lot easier to navigate.
Have you considered this one? (or some variation of the idea)
Vehicle
- Aircraft
- Boat
- Car base
- Car general
- Car mudguard
- Riding cycle
- Train
("Car" is just an idea - or just keep the current vehicle category names and
just move Aircraft, Boat, Riding cycle and Train under the Vehicle umbrella)
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | StormChaser | | Posted: | Dec 10, 2019 05:20 | | Subject: | Re: Parts Category Tree | | Viewed: | 32 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | Have you considered this one? (or some variation of the idea)
|
No, I hadn't. Not at all. But I really like that idea. Some things would
be contentious for moving there, such as Crane, Monorail, Propeller, Tire & Tread,
Wheel, Wing, and Windscreen, but all of them would make sense in a way to find
under a Vehicle umbrella.
I don't know that renaming Vehicle to Car would be a good idea, though.
I think Vehicle is sufficient since some of the items, especially those in Vehicle,
Base, can be used for building different kinds of vehicles.
I think a question that would need to be answered, by the way, is how many submenu
levels would be too many. I wouldn't want to click through ten submenus
to find something - there would have to be a limit imposed from the beginning
on how many levels would exist.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | Teup | | Posted: | Dec 10, 2019 05:38 | | Subject: | Re: Parts Category Tree | | Viewed: | 32 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | Have you considered this one? (or some variation of the idea)
|
No, I hadn't. Not at all. But I really like that idea. Some things would
be contentious for moving there, such as Crane, Monorail, Propeller, Tire & Tread,
Wheel, Wing, and Windscreen, but all of them would make sense in a way to find
under a Vehicle umbrella.
|
Sounds good to me!
| |
I don't know that renaming Vehicle to Car would be a good idea, though.
I think Vehicle is sufficient since some of the items, especially those in Vehicle,
Base, can be used for building different kinds of vehicles.
|
Well, what makes it a little awkward is that vehicle is the term that contains
them all, so to me it feels like we'd need a word that's more specific
for what was previously called vehicle, which is a land vehicle on wheels. While
you could use it for other vehicles, I think what's now in Vehicle Base is
first of all intended for land vehicles on wheels. Bases for other vehicles are
already in cockpit, or aircraft, or train, and perhaps others. (Hmmm.. Maybe
keep it called Vehicle Base and move Cockpit in there, I don't think many
people are too attached to that category..)
| | I think a question that would need to be answered, by the way, is how many submenu
levels would be too many. I wouldn't want to click through ten submenus
to find something - there would have to be a limit imposed from the beginning
on how many levels would exist.
|
I think one level would already be enough. The lists you get when opening a node
will already be many times shorter than the main catalog anyway. So if you can
scan the main catalog, you can also scan a submenu with 10 items. Might be tempting
to group Vehicle Base under the group of Vehicle categories and then together
with Aircraft etc. in a main Vehicle category, but while it's conceptually
elegant I don't think it's practical.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | StormChaser | | Posted: | Dec 10, 2019 05:51 | | Subject: | Re: Parts Category Tree | | Viewed: | 29 times | | Topic: | Catalog | |
|
| In Catalog, Teup writes:
| | I think what's now in Vehicle Base is first of all intended for land vehicles on wheels. Bases for other vehicles are already in cockpit, or aircraft, or train, and perhaps others.
|
Well, but there're these:
* | | 35106 Aircraft Fuselage 4 x 16 x 1 with 2 x 10 Recessed Center and 8 x 4 Wings with Cutaways, 9 Holes
Parts: Aircraft |
* | | 42863 Aircraft Fuselage Forward Bottom Angular 4 x 18 x 1 1/3 with 2 x 14 Recessed Center and 13 Holes
Parts: Aircraft |
And these could be used for a number of different kinds of vehicles:
| | I think one level would already be enough.
|
I wouldn't want more than three levels. So two sublevels of menus seems
perfectly reasonable as an absolute limit, I think - the main category tree and
the possibility of up to two levels makes three total. That's one more than
you propose (the third level would probably only rarely be used).
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | Teup | | Posted: | Dec 10, 2019 07:46 | | Subject: | Re: Parts Category Tree | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, Teup writes:
| | I think what's now in Vehicle Base is first of all intended for land vehicles on wheels. Bases for other vehicles are already in cockpit, or aircraft, or train, and perhaps others.
|
Well, but there're these:
* | | 35106 Aircraft Fuselage 4 x 16 x 1 with 2 x 10 Recessed Center and 8 x 4 Wings with Cutaways, 9 Holes
Parts: Aircraft |
* | | 42863 Aircraft Fuselage Forward Bottom Angular 4 x 18 x 1 1/3 with 2 x 14 Recessed Center and 13 Holes
Parts: Aircraft |
And these could be used for a number of different kinds of vehicles:
|
I still think the latter 3 are ground-vehicle-with-wheels based but ok, Vehicle
Base is a pretty good category. Though it would be better to me if cockpit parts
are also moved in there.
I think all cockpit parts would do well there. Hard to explain the above are
Vehicle Base and this one isn't:
Again, I'm not a fan of reorganising too much, but peripheral categories
such as cockpit are fair game to me - I didn't even know it still existed
at all. Eliminating tiny categories like these is also a way of making the category
list more managable.
| | | | I think one level would already be enough.
|
I wouldn't want more than three levels. So two sublevels of menus seems
perfectly reasonable as an absolute limit, I think - the main category tree and
the possibility of up to two levels makes three total. That's one more than
you propose (the third level would probably only rarely be used).
|
I'll settle for that
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | SylvainLS | | Posted: | Dec 10, 2019 07:50 | | Subject: | Re: Parts Category Tree | | Viewed: | 34 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | […]
I think a question that would need to be answered, by the way, is how many submenu
levels would be too many. I wouldn't want to click through ten submenus
to find something - there would have to be a limit imposed from the beginning
on how many levels would exist.
|
“Three shall be the number of the counting and the number of the counting shall
be three. Four shalt thou not count, neither shalt thou count two, excepting
that thou then proceedeth to three. Five is right out.”
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | yorbrick | | Posted: | Dec 10, 2019 06:32 | | Subject: | Re: Parts Category Tree | | Viewed: | 32 times | | Topic: | Catalog | |
|
|
The name of this one has always struck me as odd. It is a riding cycle as opposed
to some other type of cycle? Like a life cycle or weather cycle?
It is also strange that, for example, three wheelers would go there whereas four
wheels like a quad bike, and it goes into vehicle. After all, a trike has 50%
more wheels than a bicycle but is only lacking 25% of the wheels needed for a
quadbike so is closer to 4 than 2!
|
|
| | | | | |
| | | | | Author: | mfav | | Posted: | Dec 10, 2019 10:54 | | Subject: | Re: Parts Category Tree | | Viewed: | 46 times | | Topic: | Catalog | |
|
| The category tree is not really the issue.
There needs to be an understanding of the difference between classification and
identification.
Browsing probably takes place against classification.
Identification should not be limited to classification. Identification should
take place against element attributes.
The existing database framework is inadequate to meet what is desired.
The underlying database needs many additional tables and fields to store specific
relevant information.
Classification of any single piece should not be restricted to a single category.
For example
should be categorized as brick and wedge
should be categorized as plate and wedge
should be categorized as panel, window (if transparent), wall element,
windscreen...and perhaps other things.
Identification should be effected against several different and some as-yet-non-existant
fields with specific criteria.
Instead of trying to identify by the contents of the q (title or name) field,
which is the only option at the moment, additional fields should be created that
contain specific attributes of an element: how many studs, how many sides with
studs, how many sides with stud receptors, how many sides without studs, symmetrical
or asymmetrical shape, general shape (rectangular, circular, triangular, rhomboid,
irregular, etc.), protruberances and sockets (axle holders, holes, clips, bars,
pins), and so on.
All this needs to be paired with an illustrated glossary of terms.
After the foundation is laid, then the data needs to be populated in a regular
manner which adheres to strict conditions for consistency. In the instances where
a field can contain discrete "checkboxable" items, that should be simple. Where
a field is "open" criteria should be set in place such that the data is entered
in a logical and repeatable manner.
The much discussed "tag system" is nothing more than an additional name/title
field, perhaps with a character limit in excess of 256 characters, but is susceptible
to the same problems as the current name/title field. It's just more of the
same thing as exists now, so it will fail/succeed/operate in the same manner
as the current name/title field, just in a second field. If the "solution" of
the "tag system" is effected, then you're still going to have data inconsistency...some
items will have value A in field one and some items will have value A in field
two. So that ends up compounding the frustration instead of alleviating it.
Colors should not necessarily be limited to any one institution's nomenclature.
The colors are indexed by an integer value. Any one value can carry multiple
labels. Thus XXX can be both Medium Stone Gray and Light Bluish Gray.
Ultimately this means something like a 10x increase in data (or more), additional
fields, additional forms for both discovery and data entry, and more.
tl;dr
A glossary needs to be in place describing all pertinent aspects and glossary
terms should be used in the datasets.
The underlying database needs to be 1) expanded and 2) available for modification
on a periodic basis as needed.
The data needs to be more, better, and consistent within a field.
It's going to be a lot of work.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | calsbricks | | Posted: | Dec 10, 2019 11:48 | | Subject: | Re: Parts Category Tree | | Viewed: | 48 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | The category tree is not really the issue.
There needs to be an understanding of the difference between classification and
identification.
Browsing probably takes place against classification.
Identification should not be limited to classification. Identification should
take place against element attributes.
The existing database framework is inadequate to meet what is desired.
The underlying database needs many additional tables and fields to store specific
relevant information.
Classification of any single piece should not be restricted to a single category.
For example
should be categorized as brick and wedge
should be categorized as plate and wedge
should be categorized as panel, window (if transparent), wall element,
windscreen...and perhaps other things.
Identification should be effected against several different and some as-yet-non-existant
fields with specific criteria.
Instead of trying to identify by the contents of the q (title or name) field,
which is the only option at the moment, additional fields should be created that
contain specific attributes of an element: how many studs, how many sides with
studs, how many sides with stud receptors, how many sides without studs, symmetrical
or asymmetrical shape, general shape (rectangular, circular, triangular, rhomboid,
irregular, etc.), protruberances and sockets (axle holders, holes, clips, bars,
pins), and so on.
All this needs to be paired with an illustrated glossary of terms.
After the foundation is laid, then the data needs to be populated in a regular
manner which adheres to strict conditions for consistency. In the instances where
a field can contain discrete "checkboxable" items, that should be simple. Where
a field is "open" criteria should be set in place such that the data is entered
in a logical and repeatable manner.
The much discussed "tag system" is nothing more than an additional name/title
field, perhaps with a character limit in excess of 256 characters, but is susceptible
to the same problems as the current name/title field. It's just more of the
same thing as exists now, so it will fail/succeed/operate in the same manner
as the current name/title field, just in a second field. If the "solution" of
the "tag system" is effected, then you're still going to have data inconsistency...some
items will have value A in field one and some items will have value A in field
two. So that ends up compounding the frustration instead of alleviating it.
Colors should not necessarily be limited to any one institution's nomenclature.
The colors are indexed by an integer value. Any one value can carry multiple
labels. Thus XXX can be both Medium Stone Gray and Light Bluish Gray.
Ultimately this means something like a 10x increase in data (or more), additional
fields, additional forms for both discovery and data entry, and more.
tl;dr
A glossary needs to be in place describing all pertinent aspects and glossary
terms should be used in the datasets.
The underlying database needs to be 1) expanded and 2) available for modification
on a periodic basis as needed.
The data needs to be more, better, and consistent within a field.
It's going to be a lot of work.
|
Hiya
Nice post and quite accurate. Most modern day research into tagging v hierarchical
systems show that neither are quicker and there are pluses and minuses for both
– so the best recommendation is to incorporate both in your database design.
Lots of articles about best practices for this.
What it needs is a couple of senior analysts to sit down and design this properly
possibly in conjunction with a number of experts that exist within the community.
From there hand it to the programmers and let them write it – test it thoroughly,
correct it – test it again etc. Then release it fully documented. Lots and lots
of the core data that is needed is already in the database – but yes it does
need work eliminating, where possible, inconsistencies.
Analysts can be expensive people but quite honestly they are worth their weight
in gold. Testing is the same – whatever length of time you spend on it up front
is more than compensated for in the less time fixing it when it is supposedly
‘live’. And if it is well documented less time in supporting it.
Modern day software should have lots and lots of parameters built in so that
individuals do not lose features that they utilize. Major accounting software
today – products like Navision, Axapta, Great Plains, SAP + others are heavily
customizable within the organisation that bought the product. Oracle are the
same – that is where they make the majority of their money from consultancy to
set it up the way you wish to use it.
Yes it is lots of work, or at least it can be but if it had been started 6 years
ago maybe we wouldn’t be having this conversation today and time would not have
been spent on tangent developments.
Still lets see what Lego has to say about this as and when they begin exerting
influence/decisions on the site. That isn’t that far away, at least from early
comments about completing by the end of 2019.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | StormChaser | | Posted: | Dec 10, 2019 14:16 | | Subject: | Re: Parts Category Tree | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | The category tree is not really the issue.
|
Fascinating read and I appreciate you taking the time to write it. My only question
is if you're suggesting a rebuild of the data from the ground up (meaning
completely starting over). I don't think you were, but please correct me
if I'm wrong.
If you were suggesting rethinking the data by adding additional site functionality
and modifying existing data to take advantage of that functionality, then I see
no issues except the current lack of catalog programming support from the site.
The original purpose of my post was simply to suggest a quick, easy way to make
the current data organization a little cleaner and easier to use, while at the
same time allowing the expansion of categories. Yet I agree that this is only
a patch for a deeper problem.
Hopefully this discussion amongst all of us will lead to some solutions.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | mfav | | Posted: | Dec 10, 2019 16:30 | | Subject: | Re: Parts Category Tree | | Viewed: | 54 times | | Topic: | Catalog | |
|
| There seems to be some conflation or confusion regarding the data and the database
structure and how those things relate.
The structure is how it's built and the data is what's within the structure.
Rebuilding the data from the ground up is not necessary. Some of the data is
fine as is and simply would need to be migrated or an existing field related
to a new table and field.
There's no other way to increase functionality or make operations more efficient
without some fundamental change to the underlying structure.
There is no way to create substantive efficiencies within the existing framework.
You have 256 deck chairs and a 900 x 900 foot deck. You can rearrange the chairs
all you want, but it's never going to be more than 256 deck chairs. The arrangement
that makes chair #125 easier to find may make chair #93 harder to find. Everything
is a trade-off.
There is no quick and there is no easy.
If you want to undertake "reorganizing" or "cleaning" the data...for example,
examine all the minifig heads. Rewrite all the descriptions in a uniform manner...start
from top to bottom...hair, eyebrows, eyes, nose, mouth, whiskers, scars, blemishes,
wrinkles, and so on...then that will lead to an incremental improvement in the
data. Functionality isn't going to be improved without a change in the available
tools. I often state that you can cut down a tree with a spoon, but it's
not the best tool for the job. It will get done, but with great effort and it
will take a long time. Invest in an appropriate tool, like a chainsaw, and the
effort decreases, the time decreases, and the satisfaction increases.
Your argument seems to be for changing one spoon for another.
Additional categories won't solve anything. At this point, this is the difference
between sorting mixed pieces of lego in 230 boxes or 240 boxes. You're just
rearranging the deck chairs. Again. When the supermarket redesigns the floor
plan and product location within the store you've been shopping in for 10
years, does that help you find the chicken soup?
Not that I expect you to go through the exercise, but here http://v4ei.com/mini-fig-ure-outer/index.php
is the custom search instruction thing I wrote. It will take about 2 or 3 hours
to complete if you want to do it. Anyway, going through the source information
(skip creating the html if you want) will kind of lay bare the inconsistencies
within the current data. You'll find obvious typos. You'll find similar
items described similarly, but with differing sequences...like items described
dissimilarly...dissimilar items described similarly...nothing you wouldn't
expect when the data is crowd sourced over a long period of time. Some swaths
of data are really good. There has been effort put into the data, but not always
of consistent quality or consistent methodology.
Looking at a dataset as a whole, and not piecemeal, can be quite enlightening.
Do we need any listing that contains the phrase "without such-and-such"? Is it
helpful to list what something doesn't contain? Fish without bicycle spokes.
Butterfly without steel beams.
So, to answer your question, yes and no. I'm making the argument for additional
data. I'm making the argument for additional database structure. I'm
making the argument for thinking things through thoroughly before starting to
build something.
Right now there's no way to add deck chairs to our deck. We need another
deck. And a way to get chairs from one deck to another. And ways to get users
from deck to deck and chair to chair.
If you decide to do the custom search creation, all of it, I think by the end
of that exercise it should provide enlightenment as to the limitations of what
can be done within the current structure and the quality of the current dataset.
Those things should be able to inform your thinking on how to better conceive
a plan for improvement within the current limitations.
Read what Bill says in the light of Bill actually knows what the f--- he's
talking about instead of Bill's a cranky old man. Bill is a cranky old man
because he actually does know what the f--- he's talking about. When
you fully understand what Bill is saying, at that point you'll understand
the complexity of the issue. You seem to think the problem is lack of simple
programming. It's not. It's waaaaaay deeper than that.
Discussion at this point isn't leading to any solutions. I currently find
no value in the obsessive hand-wringing, worry-warting, prognostication of doom,
hopes, wishes, unfulfilled dreams, and ideas of improvement around here. Be patient
and wait for Superplasticorp to take over the Titanic and see where we are in
a month or two.
If you need to do something because you need to do something, I'd suggest
creating a wish list to present to Superplasticorp. They say they want to engage
with the AFOLs. Well, here's your opportunity. What's most important?
Is it more data that's definitive and easily accessible? Is it greater selection
of trans-neon-green elements? History? Factory tours? Let Superplasticorp know
what they can do to facilitate their selling you more stuff...they'll listen
to that.
Improvements of the type often discussed here on the board will take years
to implement, if that's even an option. It could be that Superplasticorp
leaves the current BL management in place and things carry on in the lopsided
manner they have been for the last several years. Or Superplasticorp could actually
value the AFOL community, engage with the community, cooperate with the community,
respect the community, find value in the knowledge the community has to offer,
and not expect those with the knowledge and who actually provide the content
to work for free versus working for mutual benefit. Time will tell. Maybe.
I'm going to shut up now.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | calsbricks | | Posted: | Dec 11, 2019 04:00 | | Subject: | Re: Parts Category Tree | | Viewed: | 51 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | There seems to be some conflation or confusion regarding the data and the database
structure and how those things relate.
The structure is how it's built and the data is what's within the structure.
Rebuilding the data from the ground up is not necessary. Some of the data is
fine as is and simply would need to be migrated or an existing field related
to a new table and field.
There's no other way to increase functionality or make operations more efficient
without some fundamental change to the underlying structure.
There is no way to create substantive efficiencies within the existing framework.
You have 256 deck chairs and a 900 x 900 foot deck. You can rearrange the chairs
all you want, but it's never going to be more than 256 deck chairs. The arrangement
that makes chair #125 easier to find may make chair #93 harder to find. Everything
is a trade-off.
There is no quick and there is no easy.
If you want to undertake "reorganizing" or "cleaning" the data...for example,
examine all the minifig heads. Rewrite all the descriptions in a uniform manner...start
from top to bottom...hair, eyebrows, eyes, nose, mouth, whiskers, scars, blemishes,
wrinkles, and so on...then that will lead to an incremental improvement in the
data. Functionality isn't going to be improved without a change in the available
tools. I often state that you can cut down a tree with a spoon, but it's
not the best tool for the job. It will get done, but with great effort and it
will take a long time. Invest in an appropriate tool, like a chainsaw, and the
effort decreases, the time decreases, and the satisfaction increases.
Your argument seems to be for changing one spoon for another.
Additional categories won't solve anything. At this point, this is the difference
between sorting mixed pieces of lego in 230 boxes or 240 boxes. You're just
rearranging the deck chairs. Again. When the supermarket redesigns the floor
plan and product location within the store you've been shopping in for 10
years, does that help you find the chicken soup?
Not that I expect you to go through the exercise, but here http://v4ei.com/mini-fig-ure-outer/index.php
is the custom search instruction thing I wrote. It will take about 2 or 3 hours
to complete if you want to do it. Anyway, going through the source information
(skip creating the html if you want) will kind of lay bare the inconsistencies
within the current data. You'll find obvious typos. You'll find similar
items described similarly, but with differing sequences...like items described
dissimilarly...dissimilar items described similarly...nothing you wouldn't
expect when the data is crowd sourced over a long period of time. Some swaths
of data are really good. There has been effort put into the data, but not always
of consistent quality or consistent methodology.
Looking at a dataset as a whole, and not piecemeal, can be quite enlightening.
Do we need any listing that contains the phrase "without such-and-such"? Is it
helpful to list what something doesn't contain? Fish without bicycle spokes.
Butterfly without steel beams.
So, to answer your question, yes and no. I'm making the argument for additional
data. I'm making the argument for additional database structure. I'm
making the argument for thinking things through thoroughly before starting to
build something.
Right now there's no way to add deck chairs to our deck. We need another
deck. And a way to get chairs from one deck to another. And ways to get users
from deck to deck and chair to chair.
If you decide to do the custom search creation, all of it, I think by the end
of that exercise it should provide enlightenment as to the limitations of what
can be done within the current structure and the quality of the current dataset.
Those things should be able to inform your thinking on how to better conceive
a plan for improvement within the current limitations.
Read what Bill says in the light of Bill actually knows what the f--- he's
talking about instead of Bill's a cranky old man. Bill is a cranky old man
because he actually does know what the f--- he's talking about. When
you fully understand what Bill is saying, at that point you'll understand
the complexity of the issue. You seem to think the problem is lack of simple
programming. It's not. It's waaaaaay deeper than that.
|
Cranky old man ??? Hmm - Just because I want it done correctly? 
| |
Discussion at this point isn't leading to any solutions. I currently find
no value in the obsessive hand-wringing, worry-warting, prognostication of doom,
hopes, wishes, unfulfilled dreams, and ideas of improvement around here. Be patient
and wait for Superplasticorp to take over the Titanic and see where we are in
a month or two.
If you need to do something because you need to do something, I'd suggest
creating a wish list to present to Superplasticorp. They say they want to engage
with the AFOLs. Well, here's your opportunity. What's most important?
Is it more data that's definitive and easily accessible? Is it greater selection
of trans-neon-green elements? History? Factory tours? Let Superplasticorp know
what they can do to facilitate their selling you more stuff...they'll listen
to that.
Improvements of the type often discussed here on the board will take years
to implement, if that's even an option. It could be that Superplasticorp
leaves the current BL management in place and things carry on in the lopsided
manner they have been for the last several years. Or Superplasticorp could actually
value the AFOL community, engage with the community, cooperate with the community,
respect the community, find value in the knowledge the community has to offer,
and not expect those with the knowledge and who actually provide the content
to work for free versus working for mutual benefit. Time will tell. Maybe.
I'm going to shut up now.
|
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | jcvp17 | | Posted: | Dec 11, 2019 04:24 | | Subject: | Re: Parts Category Tree | | Viewed: | 35 times | | Topic: | Catalog | |
|
| Hello!
In Catalog, mfav writes:
Wow, really complex ... I've started doing it following the instructions,
we'll see how it ends ... if it ends
And, in addition, a thousand thanks for your post, very clear, interesting and
revealing.
Best regards
jcvp17
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | bje | | Posted: | Dec 11, 2019 05:10 | | Subject: | Re: Parts Category Tree | | Viewed: | 39 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | There seems to be some conflation or confusion regarding the data and the database
structure and how those things relate.
The structure is how it's built and the data is what's within the structure.
Rebuilding the data from the ground up is not necessary. Some of the data is
fine as is and simply would need to be migrated or an existing field related
to a new table and field.
There's no other way to increase functionality or make operations more efficient
without some fundamental change to the underlying structure.
There is no way to create substantive efficiencies within the existing framework.
You have 256 deck chairs and a 900 x 900 foot deck. You can rearrange the chairs
all you want, but it's never going to be more than 256 deck chairs. The arrangement
that makes chair #125 easier to find may make chair #93 harder to find. Everything
is a trade-off.
There is no quick and there is no easy.
If you want to undertake "reorganizing" or "cleaning" the data...for example,
examine all the minifig heads. Rewrite all the descriptions in a uniform manner...start
from top to bottom...hair, eyebrows, eyes, nose, mouth, whiskers, scars, blemishes,
wrinkles, and so on...then that will lead to an incremental improvement in the
data. Functionality isn't going to be improved without a change in the available
tools. I often state that you can cut down a tree with a spoon, but it's
not the best tool for the job. It will get done, but with great effort and it
will take a long time. Invest in an appropriate tool, like a chainsaw, and the
effort decreases, the time decreases, and the satisfaction increases.
Your argument seems to be for changing one spoon for another.
Additional categories won't solve anything. At this point, this is the difference
between sorting mixed pieces of lego in 230 boxes or 240 boxes. You're just
rearranging the deck chairs. Again. When the supermarket redesigns the floor
plan and product location within the store you've been shopping in for 10
years, does that help you find the chicken soup?
Not that I expect you to go through the exercise, but here http://v4ei.com/mini-fig-ure-outer/index.php
is the custom search instruction thing I wrote. It will take about 2 or 3 hours
to complete if you want to do it. Anyway, going through the source information
(skip creating the html if you want) will kind of lay bare the inconsistencies
within the current data. You'll find obvious typos. You'll find similar
items described similarly, but with differing sequences...like items described
dissimilarly...dissimilar items described similarly...nothing you wouldn't
expect when the data is crowd sourced over a long period of time. Some swaths
of data are really good. There has been effort put into the data, but not always
of consistent quality or consistent methodology.
Looking at a dataset as a whole, and not piecemeal, can be quite enlightening.
Do we need any listing that contains the phrase "without such-and-such"? Is it
helpful to list what something doesn't contain? Fish without bicycle spokes.
Butterfly without steel beams.
So, to answer your question, yes and no. I'm making the argument for additional
data. I'm making the argument for additional database structure. I'm
making the argument for thinking things through thoroughly before starting to
build something.
Right now there's no way to add deck chairs to our deck. We need another
deck. And a way to get chairs from one deck to another. And ways to get users
from deck to deck and chair to chair.
If you decide to do the custom search creation, all of it, I think by the end
of that exercise it should provide enlightenment as to the limitations of what
can be done within the current structure and the quality of the current dataset.
Those things should be able to inform your thinking on how to better conceive
a plan for improvement within the current limitations.
Read what Bill says in the light of Bill actually knows what the f--- he's
talking about instead of Bill's a cranky old man. Bill is a cranky old man
because he actually does know what the f--- he's talking about. When
you fully understand what Bill is saying, at that point you'll understand
the complexity of the issue. You seem to think the problem is lack of simple
programming. It's not. It's waaaaaay deeper than that.
Discussion at this point isn't leading to any solutions. I currently find
no value in the obsessive hand-wringing, worry-warting, prognostication of doom,
hopes, wishes, unfulfilled dreams, and ideas of improvement around here. Be patient
and wait for Superplasticorp to take over the Titanic and see where we are in
a month or two.
If you need to do something because you need to do something, I'd suggest
creating a wish list to present to Superplasticorp. They say they want to engage
with the AFOLs. Well, here's your opportunity. What's most important?
Is it more data that's definitive and easily accessible? Is it greater selection
of trans-neon-green elements? History? Factory tours? Let Superplasticorp know
what they can do to facilitate their selling you more stuff...they'll listen
to that.
Improvements of the type often discussed here on the board will take years
to implement, if that's even an option. It could be that Superplasticorp
leaves the current BL management in place and things carry on in the lopsided
manner they have been for the last several years. Or Superplasticorp could actually
value the AFOL community, engage with the community, cooperate with the community,
respect the community, find value in the knowledge the community has to offer,
and not expect those with the knowledge and who actually provide the content
to work for free versus working for mutual benefit. Time will tell. Maybe.
I'm going to shut up now.
|
No need to shut up. This goes the way it always goes as we are always trying
to find WHAT must be done with the data, as opposed to WHERE the data must be.
As someone who has worked in an actual library and made a top to bottom study
of the Dewey, AL and Coleridge's systems, I can only say +1 000 to everything
both you and Bill wrote. And I'll add a tail piece - if you do not document
a la Dewey how you are supposed to classify, then nothing will come of it. You
can tag, describe, redesign all you want but if there is no consistent documented
method of adding a minifigure head with its correct description, then mistakes
will appear again, meaning all of the work preceding that single mistake is factually
useless.
There is a reason some very clever people spent many years designing library
catalogue systems such as Dewey. There is also a reason the best accounting systems,
whether an open source ERP or a shelf package, all start with the design of the
chart of accounts - it is the basic start as to WHERE the data must go, not what
must be done with it. I have consistently designed charts of accounts to be useful
across the board - whether it is a micro business or a group of companies, the
basic chart design comes down to knowing upfront where that data must go. Even
in the old days of HAPAS, it only took for 1 first year clerk with an allocation
error as a result of bad documentation to screw up an entire chart in use for
3 years and from there the P&L and the Balance sheet. All of the discussions
on here, including Bill's discussion some time ago about the catalogue, end
up with what must be done with the data. In a well designed system, the data
is available anywhere for anything because it is known how it is classified.
Thus, a user can extract his sales data for individual colours of individual
parts only when the data is consistently available across the entire platform.
At present you have to search for cushions in order to find the chairs and do
not ask for different colours of chairs
The catalogue does not IMO need another band aid over the festering and pus filled
wound of its poorly designed descriptors and poorly documented and inconsistent
application of catalogue entries. It needs corrective surgery, much like everything
else. Time will tell if the investment required will be made. At present though,
there is still not enough information to make that call. All I see is that searching
the catalogue, even with the best of tools, remains for many users a difficulty.
IF the present systems is deemed to be the way forward, then by all means bring
in the tags (which was supposed to have been done sometime this year if I remember
correctly) and resort categories. It will be fun, but not productive. TLG might
want suggestions and make improvements, then again they might look at the scope
of what needs to be done and decide that plasters is maybe a bit cheaper and
more readily available. After all - adding tags and reclassifying will be done
with volunteers, redesign has to be done with (paid) employees. Some things require
money and that is the measure of the commitment. TLG's commitment remains
to be measured - we know the level of commitment of volunteers already.
|
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | calsbricks | | Posted: | Dec 11, 2019 06:49 | | Subject: | Re: Parts Category Tree | | Viewed: | 43 times | | Topic: | Catalog | |
|
| In Catalog, bje writes:
| | In Catalog, mfav writes:
| | There seems to be some conflation or confusion regarding the data and the database
structure and how those things relate.
The structure is how it's built and the data is what's within the structure.
Rebuilding the data from the ground up is not necessary. Some of the data is
fine as is and simply would need to be migrated or an existing field related
to a new table and field.
There's no other way to increase functionality or make operations more efficient
without some fundamental change to the underlying structure.
There is no way to create substantive efficiencies within the existing framework.
You have 256 deck chairs and a 900 x 900 foot deck. You can rearrange the chairs
all you want, but it's never going to be more than 256 deck chairs. The arrangement
that makes chair #125 easier to find may make chair #93 harder to find. Everything
is a trade-off.
There is no quick and there is no easy.
If you want to undertake "reorganizing" or "cleaning" the data...for example,
examine all the minifig heads. Rewrite all the descriptions in a uniform manner...start
from top to bottom...hair, eyebrows, eyes, nose, mouth, whiskers, scars, blemishes,
wrinkles, and so on...then that will lead to an incremental improvement in the
data. Functionality isn't going to be improved without a change in the available
tools. I often state that you can cut down a tree with a spoon, but it's
not the best tool for the job. It will get done, but with great effort and it
will take a long time. Invest in an appropriate tool, like a chainsaw, and the
effort decreases, the time decreases, and the satisfaction increases.
Your argument seems to be for changing one spoon for another.
Additional categories won't solve anything. At this point, this is the difference
between sorting mixed pieces of lego in 230 boxes or 240 boxes. You're just
rearranging the deck chairs. Again. When the supermarket redesigns the floor
plan and product location within the store you've been shopping in for 10
years, does that help you find the chicken soup?
Not that I expect you to go through the exercise, but here http://v4ei.com/mini-fig-ure-outer/index.php
is the custom search instruction thing I wrote. It will take about 2 or 3 hours
to complete if you want to do it. Anyway, going through the source information
(skip creating the html if you want) will kind of lay bare the inconsistencies
within the current data. You'll find obvious typos. You'll find similar
items described similarly, but with differing sequences...like items described
dissimilarly...dissimilar items described similarly...nothing you wouldn't
expect when the data is crowd sourced over a long period of time. Some swaths
of data are really good. There has been effort put into the data, but not always
of consistent quality or consistent methodology.
Looking at a dataset as a whole, and not piecemeal, can be quite enlightening.
Do we need any listing that contains the phrase "without such-and-such"? Is it
helpful to list what something doesn't contain? Fish without bicycle spokes.
Butterfly without steel beams.
So, to answer your question, yes and no. I'm making the argument for additional
data. I'm making the argument for additional database structure. I'm
making the argument for thinking things through thoroughly before starting to
build something.
Right now there's no way to add deck chairs to our deck. We need another
deck. And a way to get chairs from one deck to another. And ways to get users
from deck to deck and chair to chair.
If you decide to do the custom search creation, all of it, I think by the end
of that exercise it should provide enlightenment as to the limitations of what
can be done within the current structure and the quality of the current dataset.
Those things should be able to inform your thinking on how to better conceive
a plan for improvement within the current limitations.
Read what Bill says in the light of Bill actually knows what the f--- he's
talking about instead of Bill's a cranky old man. Bill is a cranky old man
because he actually does know what the f--- he's talking about. When
you fully understand what Bill is saying, at that point you'll understand
the complexity of the issue. You seem to think the problem is lack of simple
programming. It's not. It's waaaaaay deeper than that.
Discussion at this point isn't leading to any solutions. I currently find
no value in the obsessive hand-wringing, worry-warting, prognostication of doom,
hopes, wishes, unfulfilled dreams, and ideas of improvement around here. Be patient
and wait for Superplasticorp to take over the Titanic and see where we are in
a month or two.
If you need to do something because you need to do something, I'd suggest
creating a wish list to present to Superplasticorp. They say they want to engage
with the AFOLs. Well, here's your opportunity. What's most important?
Is it more data that's definitive and easily accessible? Is it greater selection
of trans-neon-green elements? History? Factory tours? Let Superplasticorp know
what they can do to facilitate their selling you more stuff...they'll listen
to that.
Improvements of the type often discussed here on the board will take years
to implement, if that's even an option. It could be that Superplasticorp
leaves the current BL management in place and things carry on in the lopsided
manner they have been for the last several years. Or Superplasticorp could actually
value the AFOL community, engage with the community, cooperate with the community,
respect the community, find value in the knowledge the community has to offer,
and not expect those with the knowledge and who actually provide the content
to work for free versus working for mutual benefit. Time will tell. Maybe.
I'm going to shut up now.
|
No need to shut up. This goes the way it always goes as we are always trying
to find WHAT must be done with the data, as opposed to WHERE the data must be.
As someone who has worked in an actual library and made a top to bottom study
of the Dewey, AL and Coleridge's systems, I can only say +1 000 to everything
both you and Bill wrote. And I'll add a tail piece - if you do not document
a la Dewey how you are supposed to classify, then nothing will come of it. You
can tag, describe, redesign all you want but if there is no consistent documented
method of adding a minifigure head with its correct description, then mistakes
will appear again, meaning all of the work preceding that single mistake is factually
useless.
There is a reason some very clever people spent many years designing library
catalogue systems such as Dewey. There is also a reason the best accounting systems,
whether an open source ERP or a shelf package, all start with the design of the
chart of accounts - it is the basic start as to WHERE the data must go, not what
must be done with it. I have consistently designed charts of accounts to be useful
across the board - whether it is a micro business or a group of companies, the
basic chart design comes down to knowing upfront where that data must go. Even
in the old days of HAPAS, it only took for 1 first year clerk with an allocation
error as a result of bad documentation to screw up an entire chart in use for
3 years and from there the P&L and the Balance sheet. All of the discussions
on here, including Bill's discussion some time ago about the catalogue, end
up with what must be done with the data. In a well designed system, the data
is available anywhere for anything because it is known how it is classified.
Thus, a user can extract his sales data for individual colours of individual
parts only when the data is consistently available across the entire platform.
At present you have to search for cushions in order to find the chairs and do
not ask for different colours of chairs
The catalogue does not IMO need another band aid over the festering and pus filled
wound of its poorly designed descriptors and poorly documented and inconsistent
application of catalogue entries. It needs corrective surgery, much like everything
else. Time will tell if the investment required will be made. At present though,
there is still not enough information to make that call. All I see is that searching
the catalogue, even with the best of tools, remains for many users a difficulty.
IF the present systems is deemed to be the way forward, then by all means bring
in the tags (which was supposed to have been done sometime this year if I remember
correctly) and resort categories. It will be fun, but not productive. TLG might
want suggestions and make improvements, then again they might look at the scope
of what needs to be done and decide that plasters is maybe a bit cheaper and
more readily available. After all - adding tags and reclassifying will be done
with volunteers, redesign has to be done with (paid) employees. Some things require
money and that is the measure of the commitment. TLG's commitment remains
to be measured - we know the level of commitment of volunteers already.
|
Hi Jean
I have spent the better part of my life designing and implementing charts of
accounts - some for the UK's largest organisations both commercial and charitable.
It is a complex job and needs a level of understanding which Dan and Eric will
have had but as there wasn't the quality documentation that was needed the
current development team will have found difficult - hence their reluctance to
delve into the 'Spaghetti code' they were left.
You need to understand what is required at the end of it as well as how to use
it for the purposes of data collection
Hence my earlier comments about system analysts doing a system design job before
code gets written.
Time will tell what Lego are prepared to put into the site as well as where the
resources for this need to come from. There is a tremendous amount of knowledge
and talent in the membership and this time it needs to be used as opposed to
being overridden or ignored. .
It is almost like waiting with baited breath.
Roll on New Years.
|
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | Author: | SylvainLS | | Posted: | Dec 11, 2019 07:49 | | Subject: | Re: Parts Category Tree | | Viewed: | 42 times | | Topic: | Catalog | |
|
| In Catalog, calsbricks writes:
| | […]
It is almost like waiting with baited breath.
Roll on New Years.
|
2020: SuperPlasticCorp contracts Accidenture to audit BL’s systems and databases.
2023: Accidenture’s multi-million-euros 632-PowerBullet-slides report finally
delivered.
It boils down to: “Oh my god! It’s full of noddles!”
2025: SuperPlasticCorp contracts Debacle to modernize BL’s database.
2038: Another year, another billion sunk into the still not delivered Debacle
system.
Old BL is still running, somewhat, for people who kept their 2010 PCs and
like 500 errors.
(Names have been changed to protect the victims’ families.)
|
|
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | | | | | Author: | calsbricks | | Posted: | Dec 11, 2019 08:23 | | Subject: | Re: Parts Category Tree | | Viewed: | 40 times | | Topic: | Catalog | |
|
| In Catalog, SylvainLS writes:
| | In Catalog, calsbricks writes:
| | […]
It is almost like waiting with baited breath.
Roll on New Years.
|
2020: SuperPlasticCorp contracts Accidenture to audit BL’s systems and databases.
2023: Accidenture’s multi-million-euros 632-PowerBullet-slides report finally
delivered.
It boils down to: “Oh my god! It’s full of noddles!”
2025: SuperPlasticCorp contracts Debacle to modernize BL’s database.
2038: Another year, another billion sunk into the still not delivered Debacle
system.
Old BL is still running, somewhat, for people who kept their 2010 PCs and
like 500 errors.
(Names have been changed to protect the victims’ families.)
|
Good grief - I might not make it then
Roll on the fountain of youth - or something similar. 
|
|
|
| | | | | | | | | |
| | | | | | | Author: | yorbrick | | Posted: | Dec 11, 2019 04:51 | | Subject: | Re: Parts Category Tree | | Viewed: | 40 times | | Topic: | Catalog | |
|
| | | Colors should not necessarily be limited to any one institution's nomenclature.
The colors are indexed by an integer value. Any one value can carry multiple
labels. Thus XXX can be both Medium Stone Gray and Light Bluish Gray.
|
Without meaning to be pedantic, LEGO calls that colour "medium stone grey" not
"medium stone gray". So if BL are using LEGO's colour names, shouldn't
they use the correct LEGO spelling too, based here on British and not American
spelling?
Of course, they could also add both. And the same could happen with longer titles,
LEGO's official names could be used now they are known for new items - and
again there are many things such as tires that are not actually tires, they are
tyres. Of course, some LEGO names are a bit bizarre - for example steering wheels
are not steering wheels, they are consoles. The names of hinges varies wildly
depending on what they are and the names for torsos are often useless.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | paulvdb | | Posted: | Dec 11, 2019 05:05 | | Subject: | Re: Parts Category Tree | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | the names for torsos are often useless.
|
So you don't know what I'm talking about when I say Mini Upper Part,
No. 4420? It's obviously the one that comes after Mini Upper Part, No. 4419
and before Mini Upper Part, No. 4421.
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | yorbrick | | Posted: | Dec 11, 2019 05:30 | | Subject: | Re: Parts Category Tree | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, paulvdb writes:
| | In Catalog, yorbrick writes:
| | the names for torsos are often useless.
|
So you don't know what I'm talking about when I say Mini Upper Part,
No. 4420? It's obviously the one that comes after Mini Upper Part, No. 4419
and before Mini Upper Part, No. 4421.
|
Yep, torsos are fairly useless. However, some of the other parts have fairly
algorithmic names, if only LEGO was consistent (just like BL or any other site
trying to catalogue parts). Plus some of LEGO's names are quite funny.
|
|
| | | | | | | | | | | | | | | | | | | | | |
| | | | | | | | | | | | | Author: | paulvdb | | Posted: | Dec 11, 2019 07:47 | | Subject: | Re: Parts Category Tree | | Viewed: | 37 times | | Topic: | Catalog | |
|
| In Catalog, yorbrick writes:
| | In Catalog, paulvdb writes:
| | In Catalog, yorbrick writes:
| | the names for torsos are often useless.
|
So you don't know what I'm talking about when I say Mini Upper Part,
No. 4420? It's obviously the one that comes after Mini Upper Part, No. 4419
and before Mini Upper Part, No. 4421.
|
Yep, torsos are fairly useless. However, some of the other parts have fairly
algorithmic names, if only LEGO was consistent (just like BL or any other site
trying to catalogue parts). Plus some of LEGO's names are quite funny.
|
Many of their names make it clear what a part is, especially once you become
a bit more familiar with their naming system. But for printed parts you get names
like those torsos I mentioned in my earlier post. Those are basically useless
if you're looking for a part with a specific print.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | StormChaser | | Posted: | Dec 13, 2019 02:49 | | Subject: | Re: Parts Category Tree | | Viewed: | 33 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | The category tree is not really the issue.
|
I thought I was done, but I have more to discuss. Okay, I've read through
this yet again and think I finally understand it. I'm completely on board
with the system you propose, but I have one question as regards this statement:
| | Classification of any single piece should not be restricted to a single category.
For example
should be categorized as brick and wedge
|
So let's say your proposed system was fully implemented and I'm doing
some kind of catalog work (like checking titles for consistency) that requires
me to go through lists of parts. How can I avoid having to see the same part
multiple times when it appears in different categories?
For example, I examine all the parts in the Brick category. Then I examine all
the parts in the Wedge category. How much of this data must I reexamine due
to the fact that individual items appear in multiple categories?
Or would your system of cataloging eliminate categories as we currently think
of them? Would there be a category tree in the system you propose? Please elaborate
- I find your ideas useful, but this would be an objection I would have.
| | Instead of trying to identify by the contents of the q (title or name) field,
which is the only option at the moment, additional fields should be created that
contain specific attributes of an element
|
Yep, I get that now. Again, very useful idea.
| | All this needs to be paired with an illustrated glossary of terms.
|
Absolutely agree. This has been needed for a long time.
| | After the foundation is laid, then the data needs to be populated in a regular
manner which adheres to strict conditions for consistency. In the instances where
a field can contain discrete "checkboxable" items, that should be simple. Where
a field is "open" criteria should be set in place such that the data is entered
in a logical and repeatable manner.
|
Agree on this also.
| | The much discussed "tag system" is nothing more than an additional name/title
field, perhaps with a character limit in excess of 256 characters, but is susceptible
to the same problems as the current name/title field.
|
Yes, I see that now. The solution lies deeper.
| | Ultimately this means something like a 10x increase in data (or more), additional
fields, additional forms for both discovery and data entry, and more.
|
| | It's going to be a lot of work.
|
You know what's a lot of work? Arranging and rearranging things repeatedly
because of poorly thought-out and poorly documented systems of cataloging and
inventorying combined with inconsistent application of those systems. We really
have to do better and I, for one, appreciate the time you've contributed
to steering us in that direction.
Because a little flattery never hurts.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | StormChaser | | Posted: | Dec 13, 2019 02:58 | | Subject: | Re: Parts Category Tree | | Viewed: | 36 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | We really have to do better and I, for one, appreciate the time you've contributed
to steering us in that direction.
|
We as a community, I mean. Obviously I'm not in volunteer administration
anymore. But I am back to making catalog/inventory submissions regularly and
I still think about the bigger picture when it comes to the catalog.
I feel like if we want to have some input on the direction things go, we should
probably make it known that we do have input to share. Hopefully they'll
listen.
|
|
| | | | | |
| | | | | Author: | StormChaser | | Posted: | Dec 13, 2019 02:16 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 44 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | I've been pondering the category trees.
|
So . . . 13 people shared their thoughts. Thanks to everyone for the input!
Here's what I took from the discussion on my idea for making the parts category
tree more navigable:
Three people felt like this was a good idea.
My response: so did I!
Six other people felt like the catalog needed deeper improvements and this idea
was doing nothing to genuinely improve things.
My response: The first part is true. I will discuss the second part in more
depth below.
One person said that before making any changes the site should pay a team of
data analysts to examine things.
My response: Maybe so. But I believe, perhaps wrongly, that we could probably
figure many things out for ourselves with some support for catalog improvements
from the new owners.
One person suggested defining all parts by shape.
My response: Not a bad idea at all. Shape is the true universal. The problem
with that is massive catalog reorganization if nothing else changes. I'm
not against it personally, but it would cause major disruptions.
Two people said the tag system would help, but let's keep the category tree.
My response: I have mixed feelings about how helpful tags will be. I think mfav
is right: a lasting fix would be deeper than tags. But I do like the category
tree and I don't imagine it will go away.
Two people said we need documentation of how data should be entered.
My response: I wholeheartedly agree.
Finally, to mfav: I read through your instructions and understand much better
what you're saying now. I don't claim to completely understand you,
so correct me where I go wrong. I agree that including additional fields for
item attributes would be an excellent solution/improvement to the current practice
of keyword searches by title, even if it does not replace keyword searches.
I tend to disagree that this would be as difficult or as lengthy a process as
you imagine, though you clearly know more about this than I do.
As for title consistency, I've argued long and hard for consistency for the
last decade. Rewriting the entire catalog guidelines was a step I took in the
direction of across-the-board data consistency, although more work needs to be
done on those guidelines as regards title standardization. And, of course, 11
months later they're still only proposed guidelines that were never fully
completed or implemented. For titles: yes, we need a standard way of writing
titles that everyone can understand and all existing data needs to be updated
to follow those standards. No question about that.
As for my original idea (which has probably been discussed many times before):
No one strongly opposed trimming the category tree by hiding some categories
in submenus and a few would find it helpful. We all agreed that it didn't
fix underlying issues related to searching for and finding things.
|
|
|
| | | | | | | | | |
| | | | | | | Author: | mfav | | Posted: | Dec 13, 2019 13:32 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 41 times | | Topic: | Catalog | |
|
| Responses to the two related posts included below.
| | One person said that before making any changes the site should pay a team of
data analysts to examine things.
My response: Maybe so. But I believe, perhaps wrongly, that we could probably
figure many things out for ourselves with some support for catalog improvements
from the new owners.
|
Bill is looking at the bigger picture. You seem to be more concerned about the
catalog specifically. Understand that Bill's view of the "problem" is undoubtedly
significantly more encompassing than anyone else here. Catalog improvements don't
stop at entering info into the database. That single catalog item has to essentially
link all the way from the factory to catalog inclusion here to stock lists and
inventories through sales and delivery...and then possibly to the third party
tools and in-house inventory and sales systems. So, yeah, we could probably figure
out many things. We could also miss just as many or more things because those
things are outside the scope of our particular focus at the moment.
| | One person suggested defining all parts by shape.
My response: Not a bad idea at all. Shape is the true universal. The problem
with that is massive catalog reorganization if nothing else changes. I'm
not against it personally, but it would cause major disruptions.
|
Grok that if not everything changes, then what we have now is the best it'll
ever be. I don't want to say for sure that you're promoting a false narrative
here, but it's impossible to project what disruptions there may or may not
be.
| | I agree that including additional fields for
item attributes would be an excellent solution/improvement to the current practice
of keyword searches by title, even if it does not replace keyword searches.
I tend to disagree that this would be as difficult or as lengthy a process as
you imagine, though you clearly know more about this than I do.
|
There is the time to figure out what needs to be done with the database table
and fields. Then create the database. Then there is creating the admin side forms
for entering, checking, approving, editing, updating, etc. the data. Then there
are the admin search routines for finding a particular record or set of records.
Then all the data needs to be updated, migrated, or otherwise created. But it's
every single record needing to be edited. This doesn't take into account
whether or not the data needs to be spread across multiple tables, which may
be desirable. In which case you're looking at potentially going through each
item multiple times. Then there is the whole customer side interface of being
able to display the data...product detail page, results pages, set inventory
pages, shopping cart and on and on. Then it all needs to be tested. So. Yeah.
A. Long. Time.
| | So let's say your proposed system was fully implemented and I'm doing
some kind of catalog work (like checking titles for consistency) that requires
me to go through lists of parts. How can I avoid having to see the same part
multiple times when it appears in different categories?
|
This is a function of identification, not one of classification. So you should
be able to identify all similar bricks with a specific set of search criteria.
These wedge bricks would likely appear at the intersection of the brick set and
the wedge set.
| | For example, I examine all the parts in the Brick category. Then I examine all
the parts in the Wedge category. How much of this data must I reexamine due
to the fact that individual items appear in multiple categories?
|
You search for brick+wedge and that returns the subset you're looking for.
There is one element record with a lot of attribute checkboxes. Depending on
which attribute checkboxes are checked...that's where the element will appear,
but that's not where the element is located. The element is located at its
unique identifier which is probably the shape+color+decoration attributes "code
number". Here we need the Librarian and the Analyst to come up with the scheme.
The hard-coded category "browse" interface you're used to may or may not
disappear completely and be replaced by a single or multiple different browse
interfaces. Again: analyst.
There is currently "browse by color" and "browse by category" options and you
understand that. Now, for example, take the "browse by category" section and
explode that into multiple checkbox options versus hard links. That scheme immediately
requires less screen space because you now have ( 1 brick, 2 wedge, 3 plate,
4 slope, 5 decorated ) versus ( 1 bricks, 2 bricks decorated, 3 wedge bricks,
4 wedge bricks decorated, 5 plates, 6 plates decorated, 7 wedge plates, 8 wedge
plates decorated, 9 slopes, 10 slopes decorated ) and so on.
| | Or would your system of cataloging eliminate categories as we currently think
of them?
|
Potentially. The analyst should provide a recommendation here. I think the categories
as we now recognize them is a product of old-print-catalog-thinking and not relational-database-thinking.
| | Would there be a category tree in the system you propose? Please elaborate
|
I think this is an interface-side issue, and not a database-side issue. It sounds
like you're not separating the two. Again, if you go through the whole process
there in the custom search builder, it may clarify in your head how these two
"sides" of the process interact.
There could be any number of "trees". Try to move away from the physical-world
perception of a single element with a single label in a single drawer in a single
cabinet on a single wall in a single room. I think you're working in the
world of something is this OR that. You need to work in the world of this AND+/-OR
that.
The analyst should look at this question of category tree and then...uh...analyze...and
come up with proposed solutions. The solution for accessing results from the
database may have different sets of criteria, and accordingly different interfaces,
if you're on the administrative side as opposed to being on the consumer
side.
You need to get comfortable with moving away from this process that's familiar
to you and start from the ground up. You have extensive knowledge of the catalog
and its current limitations. Free yourself from the current set of constraints,
build a list of the administrative functions that you need or want, then present
that to the analyst. That will help to define what fields would be needed in
the database.
The problem is in the current rigid hierarchical system with unconstrained data.
We want a fluid dynamic adaptable system with constrained data.
| | - I find your ideas useful, but this would be an objection I would have.
|
Yes, yes. Many people find my ideas useful while objecting to me having ideas.
|
|
|
| | | | | | | | | | | | | |
| | | | | | | | | Author: | StormChaser | | Posted: | Dec 13, 2019 15:17 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, mfav writes:
| | it's impossible to project what disruptions there may or may not be.
|
It's not impossible to make educated guesses.
| | categories as we now recognize them is . . . not relational-database-thinking.
|
Could you provide an example of a large online database that is structured this
way so that I could understand it better?
| | Yes, yes. Many people find my ideas useful while objecting to me having ideas.
|
There seems to have been a miscommunication. I was saying I would object to
a system that required more effort and offered less certainty when performing
catalog/inventory work. That's probably not the system you were describing,
though - just how I imagined it would work. Again, I'd like to see an example
of the relational database you're proposing so that I could more fully understand
it.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | mfav | | Posted: | Dec 13, 2019 15:59 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 50 times | | Topic: | Catalog | |
|
| | | It's not impossible to make educated guesses.
|
...if you're properly educated...
| | Could you provide an example of a large online database that is structured this
way so that I could understand it better?
|
1. Again, seemingly some confusion on your end between the database and how it
is accessed via an html form.
2. No. Database structure isn't generally something that's revealed at
the browser level, nor should it be.
3. Ambiguity at "large" meaning number of records or table/field complexity or
both?
You want a book on relational database design. Avoid the "for dummies" books.
To start, limit yourself to database design. If you get too far off track, you'll
end up with how to install MySQL on Apache, and you're not interested in
the technical aspects of deploying the software on a server.
After that you can move onto web database applications, best practices, and whatnot.
If you want to get your hands a little dirty at no cost, you might try playing
with OpenOffice Base.
|
|
|
| | | | | | | | | | | | | | | | | |
| | | | | | | | | | | Author: | calsbricks | | Posted: | Dec 14, 2019 04:55 | | Subject: | Re: Parts Category Tree - Update | | Viewed: | 46 times | | Topic: | Catalog | |
|
| In Catalog, StormChaser writes:
| | In Catalog, mfav writes:
| | it's impossible to project what disruptions there may or may not be.
|
It's not impossible to make educated guesses.
| | categories as we now recognize them is . . . not relational-database-thinking.
|
Could you provide an example of a large online database that is structured this
way so that I could understand it better?
| | Yes, yes. Many people find my ideas useful while objecting to me having ideas.
|
There seems to have been a miscommunication. I was saying I would object to
a system that required more effort and offered less certainty when performing
catalog/inventory work. That's probably not the system you were describing,
though - just how I imagined it would work. Again, I'd like to see an example
of the relational database you're proposing so that I could more fully understand
it.
|
To help you get a better idea of the desing and development of a relational database
you might want to look here.
https://www.opengatesw.net/
There is a free 30 day trial and it deals with the issue in simple and straightforward
terms for non-programmers. In fact with the free trial you can design a catalogue
and see how it breaks it up and relates.
|
|
|
|
|
|
)
)
)
United Kingdom, England
Spain, Catalonia
Netherlands, Utrecht
France, Nouvelle-Aquitaine
South Africa, Western Cape
