FANDOM


JMRI UI defects and design issues

Functional local defects

Tables

  • Add New Turnout does not validate User Name: when OK is pressed with conflicting user name, JMRI closes the dialog, discards entered data and only then displays error message. No chance to recover the entered values. The object is nevertheless created (!) with an empty user name.
  • Add New Turntable does not have a default button; ENTER does nothing.
  • Add New Turnout does not do system name validation; it's possible to enter a conflicting hardware address, the dialog CLOSES, and object with first available address higher than the entered one will be created. Creates different hardware binding than seen on the screen.
  • Turnout table "automatic retry" checkbox has no visible effect. "Show feedback information", "Show turnout speed details" display columns too short to display the presented values.
  • Doubleclick on the row in Turnout table will not bring up "Edit" dialog.
  • Add New Turnout: System Connection shows just a single item when invoked from a specific connection tab. Either the connection should be disabled, or should contain all choices, with the invoking tab's one pre-selected.
  • Turnout "Mode" property uses all-capitals values. Harder to read, apparently codenames of the underlying enum.
  • Add New Turnout opens with the last-used System Name, although it cannot be used. Should use last-system-name + 1, max(system-name) +1 or some similar suggestion.

PanelPro main

  • Show Panel menu. Menu items are presented as checkboxes, but they cannot be UNchecked. They should appear as normal items.


Layout Editor

  • Grid shrinks with the farthest element placed; does not occupy the entire window.
  • Edit Turnout lists turnout names regardless whether they are system names or user names. Should decorate (i.e. angle brackets, color or font style) to differentiate system names (seldom used).
  • Edit Turnout should support incremental typing and select the matching turnout, or narrow the dropdown choices to ones matching the typed text
  • Rotate dialog should contain the most common choices; e.g. in 45deg steps. Should allow to apply the setting so that the item can be rotated incrementally or repeatedly until the user is satisfied without closing the dialog
  • Rotate should have a hotkey, to rotate in 45 and 90 deg increments directly, without opening a dialog (requires concept of focus or selection, see Workflow errors below)
  • Help displayed in the toolbar *can be edited*
  • When turnout is placed on the layout, with properties set in the toolbar (Name, Rotation), the Name value is retained, will be reset to empty on 1st click on the control. Shoul d be cleared immediately, or some other name selected to indicate the object was placed.
  • Delete / Remove inconsistency. Turnouts are "Deleted", sensors "Removed"
  • No Zoom in / out on CTRL-Mousewheel. Ctrl+ and Ctrl- work as expected, but unlike mouse-driven Zoom in they do not retain focus point in the view.
  • Mouse drag select multiple items, dragging draws selection rectangle. The rectangle's visual appearance is the same as the object selection highlight, and the selection drag rectangle does not disappear after the mouse is released. Confusing what is the selection rectangle and what are the enclosed selected objects. There's no gesture for *single selection*.

Gesture Assignments 

Gesture assignments ignore usual desktop and application conventions: - place (new) item on the surface: Shift-LeftClick vs. LeftClick. LeftClick

Bad Implementation design

Persistence

Implementation class names should be *forbidden* in the XML persistent format. There's a renaming mechanism implemented, which is poorly extensible:

  • a certain Bundle must be written into, or
  • a class must be registered in META-INF/services

The service registration is probably OK for custom / weird / dynamic mappings. However static mapping should not go into one specific bundle:

  • in anticipation to some "modular" packaging, each contributor should be allowed to plug in its own declarations. So some fixed-path resource should be enumerated from the classpath
  • @annotations should be used to generate the resource in a compilaton unit, it's cleaner and more task-focused than centralizing everything into one shared source.

Data holder classes or deserialiers should be registered against namespaceURI:elementName pairs, so for example <signalmasts class="jmri.managers.configurexml.DefaultSignalMastManagerXml" /> which contain implementation class name will become just <signalmasts/> and the binding to the specific class should be distributed with JMRI, not with user data.

Bad UI Design

Layout Editor toolbar

The toolbar (horizontal) occupies around 1/4 of the screen, considering current wide laptop screens. With horizontal layout, individual groups are separated not by graphics, but gaps, which adds to the screen real-estate waste. The "Name", "Rotation" properties are on 2nd line, unaligned - no visual connection to the turnout types in the 1st toolbar row. This is well improved in Toolbar Left position, where groups/frames are used to group items relevant for a item.

The entire toolbar is essentially a "item palette"; just one item type can be active at a time. Supplemental controls for other item categories are unusable - just controls for the currently selected category can be operated and have effect when item is placed on the layout. The supplemental controls occupy a lot of screen real-estate, while are effectively dead most of the time. Representing palette items using radio buttons also wastes screen real-estate, since the labels are long.

Item/tool palettes are commonly communicated as toolbars with icons. Icons for a category (i.e. LH, RH, Wye, ...) can be represented either as an icon group, separated from the other groups visually - e.g. a toolbar with a handle, so the user can re-arrange the categories according to her dominant workflow. To get yet more consistent toolbar is to make variants (category items) as drop-down choices. So there would be just one icon for Turnouts; as a dropdown selection of LH, RH, Wye, ... The toolbar icon would indicate the currently selected tool, down arrow on the side opens a popup selector with variants.

Supplemental controls should be displayed in a separate area context-dependent on the currently selected tool.

The above would reduce the whole large toolbar to about 5 icons with a drop-down selector, and one area (side panel) that follows the current tool and displays the supplemental controls.

Bad Workflow

Saving panels, file management

Save action (CTRL-S) brings up filename dialog as if "Save As" would be performed. If the user does NOT perform a Save however, changes to panels are lost, there's no automatic save. So the action actually means "Save" and "Save As" is missing. Panels should be auto-saved after confirmation on exit from PanelPro, not silently discarded at exit. Autosave of the file should exist. While one can save panels to a new file, a completely EMPTY set of panels can't be really started.

The semantic and interaction between Profile, (set of) Panels, Roster, Throttles is not clearly communicated. Because layout-connected devices (turnouts, sensors, ..) are all stored in the Panels file, it seems as if there could be multiple sets of Panels. For example representing different UI styles of layout control. Or representing different layouts.

Panel -> Store and Panel -> Save affect items in Tools -> Tables menu; yet there's no UI connection between Panels and Tables. Since Panel sets (+ accompanying tables) are the central (and only) document managed by Panel Pro, file management (Save; Store Panels -> Save As; Open panels -> Open; New ...; New panel set) should be in File window.

Tables should get its main menu bar item; Tables are on different 'level' and conceptually + persistence different to other tools (rosters, throttles, ...)

Layout Editor object properties

  • When trying to inspect various objects on the layout, one must always bring up Edit/Properties window to see the object's definition. There should be a "side panel", that displays the most important properties; or all properties organized in tabs. Could be even read - only.

Object selection

  • There's no concept of "current" or "selected" object. If there was then:
  • Edit dialog should have a hotkey, brings up editor for the selected object
  • supplemental window could track selected object's properties
  • more actions could work with the selection: Delete, Rotate.

- should allow **multiple selection** to bulk-delete, bulk-move etc.

Turnout table UI

Workflow in the table is unclear:

  • Line in the table can be selected, even multiple ones, but no operations can be performed on the selection.
  • One can enter new username directly into the cell; but one cannot **change** the username once defined.
  • Delete, Edit, Forget, Query, Edit Auto action buttons are replicated to each row. "Edit" operations inherently operate on one item only. Forget, Query, Delete just occupy screen real estate on each row. If presented as actions *on the table selection*, they would not only free column space, but also allow to perform bulk operations.
  • There's no hotkey to bring up Edit dialog for a current turnout.
  • The column selection checkboxes occupy screen real estate. The table already displays available columns as checkboxes in header context menu; the column groups could be listed there as well, perhaps with some decoration or a separator between groups and individual columns.

Turnout System Name and User Name

The current workflow assumes the user creates an object for a physical device on the layout (identified by system name), then names it (user name). This is not a correct model; actually the physical device on the layout (turnout, sensor, ...) does NOT conceptually change (user name), while its **wiring** (to the decoder, detector, ...) may change as an "implementation detail". For example, when a new turnout is installed, the nearest decoder may be full: it may be appropriate to rearrange other turnout connections. But all those rearranged turnouts remain the same physical devices as before. They have the same style of HW feedback, most possibly the same speed etc.

The current workflow allows to **move user name**, which is a different operation that **rewiring** the device requires. Instead of "Move user name", a "Reassign HW address" is more appropriate. The current workflow requires the user to:

  • create an object with a new system name
  • copy over manually all the custom properties of the former turnout definition
  • move the username to the new definition

"Reassign HW address" action could eliminate the step 2 and 3. In addition, when more turnouts are rearranged, it may be possible that some names are swapped, or shifted, so it's not easy or straightforward to move "user names" around. A dedicated UI would help - if the user just specifies new pairs HW address - User Name, JMRI code can compute the sequence of "user name moves" leading to the desired state.

I see the entire concept of system name (Hardware ID) used as an identity ill-designed, not modelling the layout's reality; each object should have its unique ID (e.g. uuid), used in cross-referencing objects, leaving hardware address and user name just changeable properties. The UUID would then represent the physical device, it's hardware addres its wiring / connection in the physical layout and the user name would act as a label. Nobody reads the XML directly, so it's irrelevant what token will be used to connect objects together.

Access to Tables from Layout

No Table item in the menu. Turnout symbol requires an existing Turnout, but the Turnout properties dialog does not offer a way to invoke Turnout table or pick from the table. One has to switch to the Main Window (Tabbing between various top-levels), then navigate through a different menu (no hotkey). Should be an item in the menu, hotkey AND accessible from within the dialog as a "picker".

Question "Delete or Hide" when closing a panel

When "Hide" is selected, no imformation is lost, the dialog is an extra confirmation getting in the way. There's no "Cancel" to abort the operation -- usual reaction for the user that does not know what's going on and wants to rethink.

Close a window to save real estate is common, deleting one's work is not common; Delete is not on the most common workflow path. Panels deserve their management window / list where they can be deleted or renamed. Closing a Window should be a quick operation. Considering the Panel is the main work item in Panel Editor, list of panels could be available on a hotkey: Hotkey (bring up panel list), down-down-down (or type name prefix should search-select), ENTER (display) or "h" (hide). There should be an explicit "Delete" in the Panel window's menu. There should be a 'management' table-like UI to delete panel(s); currently one has to **open** the panel first, then it can be deleted.

Community content is available under CC-BY-SA unless otherwise noted.