[Design document] Quick‑Search & Goto Navigation for Nodes and Trainruns

[aiAdrian]

Estimated Size (weeks)

1

Description

Quick‑Search & Filtering Concept

The search bar idea is very good. I would separate the quick‑search functionality from the filtering feature. For the quick search, we should reuse the same behavior we already have in the Pearls View:

• Clicking a node name triggers a goto action and centers the node in the viewport (camera moves).
• Clicking a trainrun section in the Pearls View centers it.
• Clicking a trainrun section in the Netzgrafik scrolls the Pearls View so that the corresponding section is centered.

What I would like to implement

Quick‑Search for a node (Version 1)

• User selects a node
• User presses a Goto button next to it
• View centers on that node

Quick‑Search for a trainrun (Version 2)

• User selects a trainrun
• User presses Goto button
• System jumps to the start top-left node. Second click on the search button the camera moves to the bottom-right end node of the trainrun section.
• If multiple trainruns with given cat + name exists, it cyclic iterates from one to the other element, allways start node - end node, ...

Allowed input:

text	data source	example
Node	node.betriebspunktName	LTH
Node	note.fullName	Paris
Trainrun	trainrun.cat.shortName + + trainrun.name	IC 25

• Autocomplete -> based on node or trainrun name
• If a trainrun name or node name appears multiple times, the name is supplemented with a *. Each click on the search button( ) moves to the next occurrence of that name (cyclic iteration) and calls the goto. This enables a complete search, but also fast duplicate finding for given trainrun name or node name.
• The input field does only allow zero or one element: trainrun or node reference
• Press on the chip element (x) the element gets deleted
• Click into the input field and press back or delete the elements gets deleted
• When the node/trainrun gets deleted, renamed, .. -> no longer exits, the elements gets as well removed from input field or if only one occurance still exits the * gets automatically removed

Input Behavior

Empty input:

• Shows the default placeholder text: enter node / trainrun....
• Goto button is disabled

Value present:

• When a node or trainrun name is present, it remains visible as long as the chip input (single selection) is not deleted or overwritten. The user can click multiple times on the goto button( ).

Go‑to button ( ):

• Enabled when a valid node/trainrun is selected
• Disabled otherwise

Open Question

• Should the entered data be written into the netzgrafik.json for persistence, or should it remain only for the duration of the current session?
• Should the trainrun (goto) be automatically selected just after camera moving, when click goto button?

Mock-ups

Acceptance Criteria

• Menu bar has a new quick search entry point (input field + search button) for navigate to found element { trainrun end or start node | node }
• User can select a trainrun or a node in the quick search input field with the help of autocomplete
• Goto works like described in the description

Implementation Plan

• Add UI element with autocomplete
• Connect the goto function

Tests

UI has to be manually tested

Definition of Ready

• Mock-ups are complete and validated (PO/UX-UI)
• ACs are clear and have been reviewed by another refiner (PO/UX-UI)
• Implementation plan has been written and validated by another maintainer (Technical)
• Validated by Adrian (General)

[aiAdrian]

Design to discuss

Vote

• Variant 1

• Variant 2

@aiAdrian - I prefer (1)

[louisgreiner]

I also prefer the Variant 1: small icon is better.

Very quick review, I'll re-pass on it later

I'm not a huge fan of input. Also, I'm not sure that adding this search bar in the bottom actions bar is a good idea. We have to think if this will be used often or not. Otherwise, it adds "noise" to the editor.

Issue on objects' property unicity

We have an issue on:

• nodes having the same short names (node1.betriebpunktName === node2.betriebpunktName)
• nodes having the same full names (node1.fullName === node2.fullName)
• nodes having mixed short/full names (node1.betriebpunktName === node2.fullName)
• trainrun having same name as a node short name (trainrun.name === node.betriebpunktName)
• trainrun having same name as a node full name (trainrun.name === node.fullName)
• trainruns having the same names (trainrun1.name=== trainrun2.name)

This could be handled if, when typing in the search bar, a list of corresponding objects (listing all their attributes) is shown, and the user can choose one of them.

I'm also a bit worried on search for trainrun category + name: the user might just look for the name of the trainrun, not the category.

[aiAdrian]

Thank you — I mostly agree the input field in the menu bar might not be well suited.

You addressed the right question: how often such a search will be executed is key to understand - this has a impact how/where we have to place the search elements.

We may be better decide to use a sidebar to search the data. Which allows multiple type of search to place more centralised

Any design suggestions are very welcome.

[aiAdrian]

The search integration looks much clearer when placed in the left panel.

The search function must come after the filter; otherwise, users who are familiar with the Netzgrafik-Editor will very likely click the wrong icon because they don’t read or interpret the icons — they rely on the memorized position.

[louisgreiner]

Question about the mock-up: once a node/trainrun is retained in the input, can the user write more text in the input field? The current input makes me think it would be possible (whereas I don't think we want to allow it)

[aiAdrian]

Good point! I agree — we should simply use the search text field, since we can only enter one element anyway. The search field should include all nodes (autocomplete), and it should only allow entering an existing node.name or node.betriebspunktName. The same applies to the train run search.

Element (example)

Source: https://angular.app.sbb.ch/angular/components/search/examples

Coloring - the anguler.app.sbb.ch has red as the button background color, this should be replaced with Netzgrafik-Editor button color.:

Default state:

• Background color matches the mock‑up or uses light gray.

Hover state:

• Background color becomes slightly lighter or darker to provide visual feedback.

Active/Pressed state:

• Background color changes again (lighter or darker), consistent with the behavior of the buttons in the train run dialog.

Consistency:

• The behavior must be implemented uniformly across all relevant buttons.