Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sensor ordering - UX improvements #2193

Open
porg opened this issue Oct 24, 2024 · 0 comments
Open

Sensor ordering - UX improvements #2193

porg opened this issue Oct 24, 2024 · 0 comments

Comments

@porg
Copy link

porg commented Oct 24, 2024

Genesis of the feature and its current implementation

  • In Customizable sensor order #928 I proposed variants 1ab or 2. You went yet for another variant which I retroactively dubbed variant 3 (added it to the issue description there).

For the chosen implementation I have these usability problems and their solutions:

Stats - Sensor order within Widgets - UX issues as of v2 11 15

1) Technical shortnames barely recognizable

  • Proposed: Use the human readable names as on the tab "Module"

2) Space too limited

Status quo

  • a) Limited in height (to 5 rows).
    • If you need to drag item °8 to position °1 this requires to move with stops inbetween and/or some drag'n'scroll. And all that with the technical shortnames which tell you nothing anyhow.
  • b) Scrollbar within widget

Proposed improvements

  • a) unlimited height
  • b) parent container gets the scrollbar

If you have many sensors you can use all available height for sorting then. Easily reorder far more than 5 sensors then.

3) Reordering is buggy

  • Especially dragging an item to the top and bottom positions never worked as intended. As a workaround I positioned everything relative to position °2 and eventually took the auxiliary element °1 and moved it where it should be. Again not very WYSIWYG if you need to resort to such tricks.
  • In some cases it did not perform the normal reordering behavior as in "insert dropped item at the target position and remove it from the source position" but instead "swapped the element currently at the target position to the destination position" which is a bug not a feature.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant