LDraw.org Discussion Forums
Aligning Categories to user expectations - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Aligning Categories to user expectations (/thread-9783.html)

Pages: 1 2 3


Aligning Categories to user expectations - Allen Smith - 2013-08-28

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

Quote: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.


Re: Aligning Categories to user expectations - Travis Cobbs - 2013-08-28

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").


Re: Aligning Categories to user expectations - Roland Melkert - 2013-08-28

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.


Re: Aligning Categories to user expectations - Allen Smith - 2013-08-28

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.


Re: Aligning Categories to user expectations - Chris Dee - 2013-08-29

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.


Re: Aligning Categories to user expectations - Allen Smith - 2013-08-29

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.


Re: Aligning Categories to user expectations - Roland Melkert - 2013-08-29

Allen Smith Wrote: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.


Re: Aligning Categories to user expectations - Steffen - 2013-08-29

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


Re: Aligning Categories to user expectations - Steffen - 2013-08-29

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.


Re: Aligning Categories to user expectations - Chris Dee - 2013-08-29

All fixed and parts fast-track certified, with the exception of the following which need a little more thought:
Allen Smith Wrote:
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.