Transport Tycoon Forums

newgrf specs wrote: Class labels are unique identifiers composed of the letters A-Z and/or the numbers 0-9, analoguous to station class labels. Their main use is to combine objects into classes and make them available by the top dropdown list in the object construction window.

When coding a lot of objects recently, I got the idea of "hierarchical menues". I.e., a method to allow to classify objects more specifically as it is possible with today´s "flat" menu scheme.

This could be implemented by a new object property "parent class" which would be void for the top layer of object classes, and the feature would only affect the menu display, w/o any other impact on the game.

In addition, another idea would be to introduce a concept of "links" which would make available objects from one class (or sub-class) in other classes (or sub-classes) inside the menu.

regards
Michael

I may have some use for this hierarchy myself, but I'm a bit reserved as it will involve even more clicks to reach a certain object I fear. But an additional sub-level is useful in some cases.

Question: should this be limited to only one additional layer (easier implementation-wise), or should we go the whole nine yards and allow an infinite so to say "folder structure"? If a folder structure, then this probably also requires a different method of browsing these folders (much like the advanced settings tree), rather than the current selection list. For two layers only one could get away with the current GUI, showing the sub-classes of a root element when a root level is clicked, with an added "level up" button to go back to the list of root classes.

What would help on top of this is the GUI remembering the last object used, and showing that when reopening the object window.


As for "links": yes, I have some uses for those too

FooBar wrote:I may have some use for this hierarchy myself, but I'm a bit reserved as it will involve even more clicks to reach a certain object I fear. But an additional sub-level is useful in some cases.

Can clicking become obsolete by making menus fold out when hovering over a menu?

michael blunck wrote:When coding a lot of objects recently, I got the idea of "hierarchical menues". I.e., a method to allow to classify objects more specifically as it is possible with today´s "flat" menu scheme.

I like this suggestion. With two large newobject projects in the works, I can see a definite use for this.

This could be implemented by a new object property "parent class" which would be void for the top layer of object classes, and the feature would only affect the menu display, w/o any other impact on the game.

In addition, another idea would be to introduce a concept of "links" which would make available objects from one class (or sub-class) in other classes (or sub-classes) inside the menu.

I have just one question. I am currently able to code one newobject grf that works seamlessly in both OTTD and TTDP. Without the ability to update TTDP, would this be an "OTTD only" feature that would result in a grf not working under TTDP?

Hyronymus wrote:

FooBar wrote:I may have some use for this hierarchy myself, but I'm a bit reserved as it will involve even more clicks to reach a certain object I fear. But an additional sub-level is useful in some cases.

Can clicking become obsolete by making menus fold out when hovering over a menu?

that would certainly annoy the hell out of me...

wallyweb wrote: I have just one question. I am currently able to code one newobject grf that works seamlessly in both OTTD and TTDP. Without the ability to update TTDP, would this be an "OTTD only" feature that would result in a grf not working under TTDP?

Likely you could still use that NewGRF with TTDPatch as it looks like a feature which means introducing a new property - but of course this feature would be unavailable on TTDP and you'd have to conditionally skip this there.

But personally I'm with Eddi about the annoyance factor of self-unfolding menus via hover. tbh, I'm also skeptical about hirachical object menu with many sub-menus while I like the idea of linking objects also into other categories and remembering the last opened category.

planetmaker wrote: tbh, I'm also skeptical about hirachical object menu with many sub-menus while I like the idea of linking objects also into other categories and remembering the last opened category.

Well, the number of sub-menues would depend on the intelligence of the newGRF coder, it´s not that it´d be enforced on them. Ease of use could be much better with two or three sub-menues, than having all the classes in one long list.

regards
Michael

michael blunck wrote:

planetmaker wrote: tbh, I'm also skeptical about hirachical object menu with many sub-menus while I like the idea of linking objects also into other categories and remembering the last opened category.

Well, the number of sub-menues would depend on the intelligence of the newGRF coder, it´s not that it´d be enforced on them. Ease of use could be much better with two or three sub-menues, than having all the classes in one long list.

regards
Michael

Maybe. Care to sketch a concept how it should look like in the GUI so that things can still be easily accessed and found?

I have one in my head, just no sketching materials available at the moment.

Basic idea (maybe it inspires someone else to do some sketching):
- three vertical columns
- left column: a collapsible/expandable folder structure, like in your average operating system file explorer, similar to the advanced settings hierarchy.
- middle column: shows all objects in this (sub)class. Identical to the right side of the current window.
- right column: object view selection and object information. Identical to the left side of the current window (except the class list).
- with this, object selection works from left to right: class, object, view. And then placing the object on the map of course!

just to make sure we're talking about the same thing (using stations here as example, because i have no experience with objects)

a hierarchy could look like this:

Eddi wrote:just to make sure we're talking about the same thing [...]
a hierarchy could look like this: [...]

Exact.

regards
Michael

Hierarchical menus often have poor usability characteristics.

(This is an assertion, but I could dig up some evidence )

This might be a non-issue, or the least-worst option. Just mentioning it.

Collapsing and expanding a tree is not exactly nice when you want to switch between stuff from different subtrees.
So, just to state an alternative approach which many applications use:
Put everything in one list, but add a filter to quickly create a list of stuff with some common keyword (e.g. like the Content Download window). Then you could filter for stuff like

• station (show station related stuff)
• freight (show freight related stuff)
• brick (show bricky looking stuff)
• plants (show vegatable stuff)
• ...

Obviously this allows selecting the same object using completely different criterions.

While such a filter feels weird for a game GUI, imo the same holds for a tree

(The source of the keywords could be just searching in some "additional purchase list text" provided by some CB)

This is the basic idea I had in mind: Preferably, the tree state should also be remembered on closing and reopening of the window. When opening the window for the first time, the tree can be fully expanded to show the player what's in store.

I don't think it needs further explanation, but just to be sure: when selecting a class in the tree, the bit in the middle will show the objects in that class. Clicking an object will then show the available views at the right, together with name and description.

For station, the left and middle can remain the same. The right part will then be stations-specific, with number of platforms, accepts/supplies, etc.

I could post a mockup based on other contexts, for example, finding a song in an MP3 player with 5,000 songs available. You could have equivalent tree with categories etc, and some MP3 players probably do. A filter does this better.
http://www.interaction-patterns.org/wiki/Live_Filter

I could argue further, but it's already done in the newgrf download and selection guis, which could equivalently have been big trees, but use a text filter.

The 'problem' with doing it for stations and objects is knowing what to type for the text filter....

andythenorth wrote: [...] The 'problem' with doing it for stations and objects is knowing what to type for the text filter....

Exactly that´s why I have reservations w/r to "filters" in this particular context were we won´t have large trees to search, given the limited number of object/station IDs available in-game.

regards
Michael

While continuing work on NewStations, I´d like to re-iterate my proposal of "symbolic links" to station/object types from foreign classes. Especially for stations, their classes might have many features in common, like empty track, buffers, fences, crossings, ..., and with the current "flat" building menu, there´s really too much messing around with switching classes.


This "class label link list" could be defined in the same way as the rail type label lists are, i.e.:

stations: objects: regards
Michael