Aligning Categories to user expectations

[Allen Smith]

Someone just posted the following to a local LUG mailing list I'm subscribed to (emphasis added):

Thinking about it, I can remember what derailed my learning LDraw/Mcad/ et al... it was the parts management system… [T]he hundreds of variations with a surface graphic made the whole stack completely unmanageable.

While I don't know the author, I really have to agree with the sentiment. Regular bread-and-butter categories one uses all the time for building are clogged with enormous numbers of decorated parts which are almost never used. Over the years, the single most-requested feature for Bricksmith was to add a "Favorite" category, and I can't help bust suspect this was part of the reason.

A couple years ago when I was adding !CATEGORY support to Bricksmith, I came to the conclusion the situation was actually getting worse. Notably, Duplo elements were being piled into the regular categories like "Brick". The !CATEGORY keyword was also inconsistently applied, so some bricks fell into defined categories, and some fell into implicit categories based on the first word of their description. Some logical first-word categories were being exterminated for inexplicable reasons, but only in a piecemeal fashion. Since it was all inconsistent, it was insanely difficult to find anything. I actually gave up and intentionally ignored !CATEGORY for any single-word category name.

I would like to take a cue from Bricklink here. Separate decorated elements out of the most commonly-used categories of Brick, Tile, and Slope. I think this would be a huge win for regular users.

I would also like to see !CATEGORY be dependable. When I last checked in on the situation (at least a year ago), every Categorization was potentially subject to a review squabble (and endless limbo) on the part tracker. That was the point at which I gave up on implementing the feature and went back to using the description for almost everything.

[Travis Cobbs]

Aside from the whole Duplo issue, what specific problems have you seen with !CATEGORY statements in official files? I did a quick scan, and most of the files that I looked at that used !CATEGORY were good (like 2038 "Signpost Ornamented" with a !CATEGORY of Roadsign). I will admit that I'm unsure why the Belville Bathtub is a "Container".

Note: I agree that Duplo parts shouldn't be lumped with the other parts. My personal opinion there is that they should all have multi-word categories, with "Duplo" being the first word. Having said that, you could hack that in programatically, by looking for "Duplo" in the part description. It's not clean, but it solves the problem, and unless there are a bunch of other hacks needed to make things work, it might not be a bad idea.

I also agree that lumping the patterned parts in makes building more difficult. I could see either creating categories for these (like "Patterned Brick") or doing programatically recognizing "Pattern" in the part description, just like my suggestion for "Duplo". Of course, now I've already suggested this for two separate part description keywords, and there could be others, which would rapidly get messy. On the other hand, if it's just these two, it's still not too bad, and you could even make it user-configurable ("Separate Duplo and patterned elements into their own categories").

[Roland Melkert]

This is why I have the 'sorted' section in the default part bin of my LDCad. It supplies a somewhat friendlier (sub)category based tree. For example I've split bricks into: plain, bricks with stickers, slope 33deg, slope 45def, etc etc

Do note these are just the default bin groups (sorted section), users can add unlimited custom ones or create entire custom bin trees independent of categories etc (using filters or even handpicked part lists).

Recently I wanted to create an upgraded (more user friendly) sorted tree but I'm not familiar enough with all the parts to create a more efficient tree.

Might be bit off topic, but what I'm trying to say is these categories etc are there to be used as a base not 'one on one' imho, the Library is getting to big for that.

[Allen Smith]

Here are the unedited notes I made on 2012-03-20:

Code:

[b]Unofficial categories implicitly defined by the first word in the description (from parts lacking a !CATEGORY)[/b]
Axle // u9132c01 move to Wheel
Brush // 2475, 2578 move to ???
Castle // 4489, 2470 move to Wheel
Cockpit // why is this not an official category?
Duplo // This is a mess. has parts which also have been scattered to all sorts of !CATEGORIES: arch, brick, baseplate, etc
Excavator // 784 move to Vehicle
Fabuland // 4438, 4222a, 4794 move to Figure Accessory; 4796 move to Car
Lamppost // 2039 move to Roadsign
Motor // 4234 move to ???
Pov-RAY // Official category?
Roof // 6121, 44511 move to ???
Round // 6218 move to Panel
Signpost // 764 move to Roadsign
Space // 2516, 2342, 2336, 2336p35, 2336p90, 2336p36, 2336p68, 3940, 4737 move to ???
Stretcher // 4714 move to Minifig Accessory
String // should be official category

[b]Bizarre official categories[/b]
Gate (fence, door)
Jack (Minifig Accessory)

[b]Weirdly filed parts[/b]
87747 "Bar 0.5L" but in Minifig Accessory
4628 Jack Handle in Minifig Accessory not Jack!
87614 "Tail 12x2x5" but in Plane
4876 "Fabuland Slide" in Staircase // why do Belville, Scala, get categories but not Fabuland?

I don't know how many of these have been fixed, or if new problems have developed. I think the weirdly filed parts section is incomplete, but the top two sections were complete. I created this list by doing a programmatic dump of all parts that had a first-word not in the Official List of Categories, and notable mismatches between a description's first word and the !CATEGORY. I definitely remember I looked on the parts tracker and found that some parts with implicit categories migrating inconsistently to Official categories, and in ways I thought were highly illogical.

[Chris Dee]

It's good to have a meaningful discussion about this, and you raise some excellent points. Until I implemented an admin "fast-track" approval in the Parts Tracker I'd been wary of making these kinds of header-only changes for fear that it would just invite people to make other improvements to those, further clogging the Parts Tracker with fixes to parts for which a useable version already exists.

I'll take a look at your list and fix those that are obvious mistakes.

Attached is a count of parts by CATEGORY (implicitly and explicitly defined) to 2013-01, which will no doubt stimulate more debate.

We should do what we can to help users of the library, so I do support the main thrust of this thread regarding patterned parts and duplo and am open to suggestions.

[Allen Smith]

From my (outdated) notes, I would make the minimum following suggestions:

Unofficial categories which should be added to the official list
Cockpit now in the official list
Duplo (personally recommend only one Duplo category)
Fabuland
String

Official categories which should not exist
Gate already gone
Jack already gone

Brand new Categories which are needed
Brick, Decorated
Primo (Currently in Duplo; part descriptions should be updated to remove "Duplo")
Quatro (no bricks exist yet)
Slope, Decorated
Tile, Decorated

As much as possible, part descriptions should align with the categories in which they reside.

An alternative to defining decorated categories is to expect the program to identify patterned parts and auto-generate subcategories for them, either based on the part naming convention (is it 100% consistent?) or a new meta. Generally I favor explicitly-defined data over tricks like this, so I think I favor making decorations real categories.

And of course, any parts currently in de-facto unofficial categories should be moved into real categories as quickly as possible. That's a important for making !CATEGORY ready for production use.

[Roland Melkert]

An alternative to defining decorated categories is to expect the program to identify patterned parts and auto-generate subcategories for them, either based on the part naming convention (is it 100% consistent?) or a new meta.

It is possible it just takes some trial and error to identify all the exclusions etc, for example these are the rules for my 'plain bricks' bin in LDCad

[options]
kind=filter
caption=Plain bricks
description=Basic bricks without stickers etc
mascot=3003.dat
sortOn=description

<rules>
include category brick
exclude description ~*
exclude description _*
exclude description duplo
exclude description pattern
exclude description pat.
exclude description spring
exclude description sticker
exclude description logo
exclude description without corner

----

And these are for 'normal plates'

[options]
kind=filter
caption=Normal plates
description=Normal plates
mascot=3022.dat
sortOn=description

<rules>
include category plate
exclude description ~*
exclude description _*
exclude description duplo
exclude keyword wing
exclude description without corner

----

Personally I think we should do more with keywords and leave the categories 'big' and relative few.

[Steffen]

I had the same problem with properly grouping parts to my needs.

The default parts grouping that comes with MLCad did not at all fit my desires.

Unfortunately, MLCad does not support !CATEGORY yet, but still is one of my main building tools.

So I had to workaround that problem by customizing the parts grouping just by parts title,
and this worked surprisingly well.

Except for some strange parts not falling into any of these groups,
all other parts this way could be grouped as I needed.

You can find my grouping here:

http://forums.ldraw.org/showthread.php?tid=6387,6387

[Steffen]

independent from that, I agree with the above request for official categories. my expectation would be to at least have

• Fabuland
  
• Duplo
  
• Primo
  
• Mursten
  

BTW, could someone post a link here to the list of official categories? I lost track of where to find that.

[Chris Dee]

All fixed and parts fast-track certified, with the exception of the following which need a little more thought:

Code:

[b]Unofficial categories implicitly defined by the first word in the description (from parts lacking a !CATEGORY)[/b]
[s]Axle // u9132c01 move to Wheel[/s] Done
[s]Brush // 2475, 2578 move to ???[/s] Changed to Vehicle
[s]Castle // 4489, 2470 move to Wheel[/s] Had already been done in unofficial updates
[s]Cockpit // why is this not an official category?[/s] Created and parts categorised
Duplo // This is a mess. has parts which also have been scattered to all sorts of !CATEGORIES: arch, brick, baseplate, etc
[s]Excavator // 784 move to Vehicle[/s] Done
[s]Fabuland // 4438, 4222a, 4794 move to Figure Accessory; 4796 move to Car[/s] Done
[s]Lamppost // 2039 move to Roadsign[/s] Done
[s]Motor // 4234 move to ???[/s] Updated to Vehicle, although this is still not perfect
Pov-RAY // Official category?
Roof // 6121, 44511 move to ???
[s]Round // 6218 move to Panel[/s] Already was Cylinder in official library
[s]Signpost // 764 move to Roadsign[/s] Done
[s]Space // 2516, 2342, 2336, 2336p35, 2336p90, 2336p36, 2336p68, 3940, 4737 move to ???[/s] Many had already been fixed, remainder done
[s]Stretcher // 4714 move to Minifig Accessory[/s] Done
String // should be official category

[b]Bizarre official categories[/b]
[s]Gate (fence, door)[/s] Done
[s]Jack (Minifig Accessory)[/s] Done

[b]Weirdly filed parts[/b]
87747 "Bar 0.5L" but in Minifig Accessory
[s]4628 Jack Handle in Minifig Accessory not Jack![/s] All are now Minifig Accessory
[s]87614 "Tail 12x2x5" but in Plane[/s] Done
4876 "Fabuland Slide" in Staircase // why do Belville, Scala, get categories but not Fabuland?

I agree that Duplo is a mess, but I'm not convinced that dumping everything into one Category is good either.
I agree that Belleville, Scala and Fabuland should be treated similarly, but it is hard to define what is and what is not primarily a Fabuland part. The Shovel (556.dat) that has "Fabuland" moulded on was used in two Model Team sets and a Belleville set.

Suggestions for the other unsolved issues are welcome.

[Max Martin Richter]

AFAIK there are two versions of your mentioned shovel. One with an embossed Fabuland Logo and one without.
The newer version (without FL-Logo) is the one, that is used in the Belleville sets. Nevertheless, the "old" Fabuland versions is used in a Model Team set.
And there is another part, (it's not modeled for LDraw yet, but the Fabuland Hook Bricklink Link was used a City set 1993, too)
So this could end in an endless discussion about the category sometimes ;-)

/Max

[Magnus Forsberg]

Do you mean this one?
http://www.ldraw.org/library/tracker/ref/catkeyfaq/

[Steffen]

ah, yes, thank you.

yes, that list IMHO lacks the mentioned categories.

Fabuland:
there are not many Fabuland-specific parts. Mainly the big house building panels, the figures
and some accessories.
Yes, the shovel for example later appeared in another set, but the predominant existence
definetely was Fabuland.

Pov-Ray:
I think we should _not_ add this as official category.
We in the past have removed all POVRay-specific stuff (like inline POVRay code) from our parts.
So I suggest to prepend a ~ to the only file (light.dat) and obsoletize it.
EDIT: I changed my mind, see above

String:
yes, let's have this as new category!
do we also need "Rubberband"?

Duplo:
There do not exist too many Duplo parts.
You usually want to have them all available together.
You'll not want to look in "Train" for the Duplo Train parts.
I clearly favor to have all Duplo stuff in ONE category.

Primo:
the same analogously

[Allen Smith]

Wow, this gives me an incredible warm fuzzy feeling! Thanks!

To the ones with outstanding questions, here are my humble opinions:

Duplo
I suspect most people don't build with Duplo. About the only time I see it in MOCs is to provide filler for mountain interiors. That's why I think one category is sufficient for it. Bricklink has a whole bunch of Duplo categories, and I think they're mostly noise. Note that I don't consider Primo or Quatro to be Duplo; they deserve their own sections.

Pov-RAY
I honestly have no idea what to do with this thing. But the underlying concept of a user-positionable light source is neat.

Roof // 6121, 44511 move to ???
Those look like panels to my mental taxonomy. Bricklink calls them roofs. So maybe that's what they are.

String // should be official category
I said new category because they don't look like anything else to me. That said, the parts are basically useless as is. Flexi parts a whole problem of their own, and that brings up incorporating LSynth segment pieces in the official library. Which is another topic.

Fabuland
I agree this is murky. It doesn't help that Fabuland is obscure. I had no idea how many amazing parts were in Fabuland until after I'd been an AFOL for years. Lego has also repurposed a lot of Fabuland pieces over the years (such as the slide, which was used in Paradisa sets). I guess I figure if it was originally debuted in Fabuland, and was obviously designed for the scale of Fabuland figures, or the Fabuland vibe, it qualifies as a Fabuland part.

In practice, I'd usually just do whatever Bricklink did.

87747 "Bar 0.5L" but in Minifig Accessory
Well, it most closely resembles other things currently in the bar category, such as 88695, 48729, and 64727.

[Ben Supnik]

Hi Allen,

I was going to try to keep my mouth shut because I use BrickSmith as a power user and thus my ideas are probably bad for new users, but...

I think it would be useful from a UI perspective to have a few (or one) broad filter button that virtually cuts the library down to a smaller number of items outside the category system. The idea would be to make the whole library appear smaller temporarily in the UI for the purpose of searching. (If this happens, then the user not knowing the category is unimportant - 'all categories' can be searched without getting 1000 bricks if "1x2" is in the search term.)

In this scheme reasonable filters might be:
- Parts having stickers and/or printing.
- Sub-parts, or anything deprecated or moved - I'm not sure how much of this shows up now.
- Parts belonging to clear building subsets (e.g. duplo).

With a small (or one) filter, the user could toggle between "the kitchen sink" and "normal stuff" pretty easily. I would hope that users have a good intuition as to when what they are looking for is normal or weird.

(When my brother and I were young and had real legos, we specifically put the weird/useful/rare pieces into a separate box - hinges, rare windscreens, tiles with printing, slope bricks with computers, etc. If an eight year old can do it, maybe a new user can too. :-)

cheers
Ben

[Scott Wardlaw]

I couldn't agree more with this. We need to align our categories with one of the two major supliers (Bricklink or LEGO). LEGO's categories are even more worthless than ours (though they are improving).

Because the parts list has grown so much with duplicate parts (with a different graphic) and assemblies of other parts, my last software project was aimed at reducing the parts list to only those parts that I was interested in:



I abandoned it, as only one person was interested:
http://forums.ldraw.org/showthread.php?t...47#pid2747

Scott

[Chris Dee]

87747 "Bar 0.5L" but in Minifig Accessory
Well, it most closely resembles other things currently in the bar category, such as 88695, 48729, and 64727.

It's not just us that have struggled with these, as there is no consistency in the categorisation elsewhere.
87747 (Bar 0.5L with Curved Blade 2L) - BrickLink: Animal, Body Part; LEGO: Animal And Accessories For Animals
88695 (Bar 0.5L with Faceted Spike 1L) - BrickLink: Large Figure Part; LEGO: Figure, Special
48729 (Bar 1.5L with Clip) - BrickLink: Bar; LEGO: Connectors
64727 (Bar 0.5L with Blade 3L) - BrickLink: (Other); LEGO: Animal And Accessories For Animals
Also:
11089 (Claw Flexible 4L with Bar 0.5L) - BrickLink: Animal, Body Part; LEGO: Animal And Accessories For Animals

Apart from 48729, which I think is genuinely a "Bar", maybe all the others are "Figure Accessory" or a new category "Animal Accessory"?

[Chris Dee]

Pov-RAY
I honestly have no idea what to do with this thing. But the underlying concept of a user-positionable light source is neat.

light.dat isn't really a part, it's a "helper" file but has lived in the parts folder since the very beginning of LDraw. I don't think there is anything else like it, so maybe it does need a category of it own - "Helper"?

[Tim Gould]

Handy. I'm more of a command line and scripts man myself. Hence the easily processed .xml output from LDMakeList

Tim

[Orion Pobursky]

Why not allow multiple categorizations rather than try to shoehorn every part into one specific category?

[Steffen]

I've just changed my mind: in a post further below on this page I suggested to
deprecate light.dat because it is POVRay-specific. It is not. It is a generic helper
which by WHATEVER renderer can be used to place light sources.
For example LDView can do that.

So after sleeping this one night over, I changed my mind:

Yes, this is probably the right time to introduce a "Helper" category, but I also think
we should at the same time introduce a "Helper" subfolder in the library
where these parts go, and MOVE-TO light.dat to there.

This overlaps with the discussion of the stud detail files
and the primitives of different resolutions.

In the long run, I would like to see in this helper category files like Willy created (maybe, simply, his? Willy?)
http://www.holly-wood.it/ldraw/helper-en.html
You need these frequently, and not everybody wants to create them again and again.
If you like the ones in the library - use them,
if you better like your own, custom ones, use your own.

I ALSO think that the LSYNTH constraint files belong into that category:

We should not regard them as LSYNTH specific. They are placeholders for ANY generator which
synthesizes flexible parts. They are simply the files which put the CONSTRAINTS for that generator
into a model. This is fully analogous to LIGHT.DAT which simply says where ANY renderer COULD put a lightsource.

[Roland Melkert]

This is also a weird one:

0 Cardboard Trading Card
0 Name: 384.dat

in panel category

[Chris Dee]

Maybe move to CATEGORY Sheet ?

[Willy Tschager]

In the long run, I would like to see in this helper category files like Willy created (maybe, simply, his? Willy?)
http://www.holly-wood.it/ldraw/helper-en.html

If there are more people who think that they should be submitted to the PT I'll do.

I ALSO think that the LSYNTH constraint files belong into that category:

Same here.

w.

[Steffen]

+1!

For example, the Duplo Train parts should be in categories "Duplo" and "Train" IMHO.

However, this will change how the parts lists nowadays usually behave:
each part appears there uniquely currently, just a single time.
Putting a single part into multiple categories will break that principle.
Parts will show in various categories. We should carefully consider if this is
SIMPLER for the users or more CONFUSING.

[Orion Pobursky]

For me it is simpler but that might not be true for everyone. Actually, what I'd like to see in most programs is the ability to have user defined buckets based on rules or simply selection (something like smart playlists and regular playlists in iTunes). MLCad has this for the most part but Bricksmith does not (aside from the favorites list).

It's really a moot point since the number 1 LDraw program (MLCad) doesn't support CATEGORY, isn't being actively developed, and isn't open source.