@mouser: This isn't about bugs
per se, but more about SC idiosyncrasies and suggested improvements. If you are tinkering with SC then you might like to consider improving the ergonomics of the SC GUI in the
Options pane - and I was thinking here of the logic for navigation of the LHS
tree in particular.
Where relevant, the notes below are prioritised thus:
Priority rating:- "A" - Mandatory.
- "B" - Highly desirable.
- "C" - Nice-to-have.
Some observations:- Scrolling up/down the tree using the mousewheel, or chiral scrolling on the touchpad is apparently not supported. It would probably be a nice-to-have (Priority C) if this was supported, but may be overdue given the life of the product to date.
- The user is unable to click on and select any of the 4 main headings and have the cursor highlight actually rest on them. This seems counter-intuitive - i.e., the cursor highlight would be expected to rest on the item selected, not somewhere else.
- Instead, clicking on any closed heading expands the group of sub-components nested below that heading, leaving the cursor highlight resting on the first of the subheadings by default. This can be momentarily confusing to the user as it makes an assumption that this is what might be required, whereas the user may in fact typically just want to view the sub-components before selecting any (or none, as required). This seems counter-intuitive.
- The subheading required by the user has to be selected/changed either by direct mouse selection (this seems OK), or by scrolling down (cursor down) from that point, but this latter method is not efficient and the user is obliged to tediously scroll down, as described in the next point below.
- If the user scrolls (cursor down) to the bottom of that group, the next group below is expanded (if it is closed) and by default the cursor selection highlight goes to the first sub-component of that group (cannot be the heading, as noted above). This makes an assumption about what the user might want, again, and seems counter-intuitive - e.g., the user may in fact require to go to a group below that group, but is obliged to have to then either move hand to the mouse to change selection, or to tediously scroll down the whole obligatory opened group - and any subsequent intervening groups below - in linear fashion, to get to the group where they want to go.
- Once the cursor is in that position, the main heading for that subheading cannot be closed/rolled-up until the cursor highlight is resting within another subheading. This seems counter-intuitive.
- The groups under each of the main headings can also all be expanded/closed by clicking on the animated ">" sign on the LHS of the tree - that is all except for one group, which is whichever group the cursor selection highlight happens to be currently situated in. So one of the groups must always remain expanded. This seems counter-intuitive.
- The cursor selection highlight can be moved down the tree (cursor down) - i.e., down a group and into the next group - in the non-intuitive manner as described above, but not up. The cursor selection highlight can only be moved up within the group where it is currently residing, up to the first item in that group, whereupon it hits a ceiling, above which it cannot travel. I think this may be a mistake rather than a bug. It seems counter-intuitive, anyway, and inconsistent.
- Suggestion #1: A more intuitive approach where the cursor selection highlight be allowed to move freely (unrestricted) up and down the entire tree, with cursor left jumping up to the main heading for that group, and if the cursor selection highlight is on a group heading, then cursor left closes the group if it is expanded (or, if closed, then goes to a superior heading if there is one) and cursor right expands it (or, if already expanded, then does nothing), and the highlight rests on the group heading after that.
- Suggestion #2: Ctrl+Home/Ctrl+End moves cursor selection highlight to the top/bottom item heading of the tree, respectively.
- Suggestion #3: Ctrl+PgUp/Ctrl+PgDn moves cursor selection highlight to the next item heading above/below, respectively.
I don't claim this to be an exclusive list, but it might be useful as a starter for thinking, at least.
The above are not so much opinions, but based on learned good/"best" practice in ergonomic design and what I have found to be intuitive/useful, from practical implementation/experience. From a work-study perspective, I am always interested in and consider the ergonomics of tools that are regularly used, though I am aware that many people (including users and programmers) might not give the matter much thought.
It might be worthwhile considering the standardisation of whatever GUI ergonomics you settle for in the SC
Options panel case, for the
Options panels across the mouser range of software (just as you seem to be standardising the DPI settings).
In the case of CHS, there is also the
Tree pane in the GUI to consider, which could benefit from being made consistent with similar standardisation - in fact, the CHS Tree pane
already seems to be part-way there.
My ideal of tree navigation has largely been drawn from specific use-cases - e.g., the particularly thoughtfully-designed navigation of
InfoSelect v8, which navigates the tree intuitively and efficiently using the cursor keys.
I would distinguish between, and suggest that design should cater for, the various HIDs (human inteface devices) that the user might need and have at his/her disposal, and the constraints that the user might be labouring under - e.g., environmental/physical constraints, including ambient light, RSI, handedness, disability, vision impairment.
For HIDs, I especially look for a UI that allows for keyboard use and mouse and touchpad use. This was learned from the experience of having to re-engineer and provide a safe and productive working environment for one of my staff, years ago, who suddenly developed a severe and debilitating form of arthritis at the age of 24. Sometimes, simply moving a finger was a painful challenge. I later myself started to suffer from acute RSI and though it is well under control now (a copper bracelet fixed it and more), I still have to avoid using a mouse for prolonged periods, though a touchpad is fine, but in many applications I find the keyboard to be the optimum - an efficient and ergonomically friendly interface and the one that least aggravates the RSI.
Hope all this can be of help/use.
