Dashboard TTL Panel Tweaks

[dtcallcock]

We have a few suggestions for improving the TTL panel in the dashboard. I understand that QT bugs that nobody wants to fix may be the reason for some of the things we don't like.

• We would like to be able to append a short comment to the name instead of having it as a tooltip. Lab experience has shown this would be useful, for example to have some information about hardware mapping. Perhaps the current tooltip comments could be left in as a separate comment field so people can use either (or both) as their taste dictates (see #518). For example, something like ttl_bdd: ch7, where ch7 is the comment.

• Instead of 'Override' and 'Level' have 'Override 0' and 'Override 1'. This has the advantage that you only have to click once to set the override level you want instead of potentially twice. A quick straw poll of the lab also suggested this way made more sense. Logic will be needed to uncheck a checked override if the other override box is checked.

• There's a lot of unused space in the boxes. This means the panel either takes up a lot of screen real estate or you have to scroll up and down. This will get worse when we add the planned extra ~50 TTL channels to our QC2 hardware.

• Another way of dealing with the above would be to have a way of moving all the TTL channels we interact with regularly to the top of the panel. This could be achieved by having multiple groupings of TTLs, for example by adding an optional numeric argument sort_group to the device_db entries for TTL channels. The order in the display would be done first in order of sort_group, and then organized by channel number within each sort_group as is done currently (#413). This lets users do arbitrary orderings as they desire, but is straightforward to implement. The same could be done for DDS channels appearing in the DDS panel.

[dnadlinger]

There's a lot of unused space in the boxes. This means the panel either takes up a lot of screen real estate or you have to scroll up and down.

Amen. We are running with quite a few channels now, and the UI is rather painful to use – for the 64 that do work with moninj in the first place, that is.

Another way of dealing with the above would be to have a way of moving all the TTL channels we interact with regularly to the top of the panel. This could be achieved by having multiple groupings of TTLs, for example by adding an optional numeric argument sort_group to the device_db entries for TTL channels.

We were thinking of something similar, although I would have probably gone with a string for the grouping (more flexible, you can still do alphabetical order, and optionally even use it for UI grouping to zoom in on interesting subsystems as required).

We would like to be able to append a short comment to the name instead of having it as a tooltip.

This seems a bit at odds with your point about information density, which I wholeheartedly agree with. Perhaps we could have two different UI modes: firstly, a compact display that is ~6x more dense than the current state by just displaying a (potentially shortened) identifier and the state, probably with some form of colour-coding, and secondly, a mode similar to the current one with the comment strings displayed? I'm a bit hesitant to suggest this – we really want to avoid feature creep at this stage –, but in my experience, having a complete overview of the state of complex real-time systems is immensely helpful as a first step to debugging. For what it's worth, I've come to this conclusion not only as an ion trapper, but also from working in live lighting/audio engineering.

[sbourdeauducq]

Instead of 'Override' and 'Level' have 'Override 0' and 'Override 1'.

We considered this, and the rationale for the current design is you can repeatedly toggle the same TTL by clicking without moving the cursor. Which is more important?

[sbourdeauducq]

adding an optional numeric argument sort_group to the device_db entries for TTL channels.

I'd rather keep GUI stuff out of the device database. What about handling this inside the dashboard alone (and saved in artiq_dashboard.pyon), with a drag-and-drop interface?

[dhslichter]

I think the use case is more likely that one goes from computer-control to manual override with a particular value and back to computer control, less likely to go to override and toggle state back and forth rapidly. You might go to override, set state, do some work on the optical table, set to the other state, and so on....but I can't think of times when I have been clicking on/off/on/off in rapid succession.

[dtcallcock]

We would like to be able to append a short comment to the name instead of having it as a tooltip.

This seems a bit at odds with your point about information density,

The idea is that we would only append very short comments (a couple of numbers/letters) that we want to be easily visible, eg. to denote some temporary change in the device connected to that channel. As suggested, the tooltip comment could be retained as a separate field for longer, more descriptive comments.

What about handling [TTL sorting] inside the dashboard alone (and saved in artiq_dashboard.pyon), with a drag-and-drop interface?

I don't have a problem with this.

[jordens]

I have been toggling the manual value at least as much as I have toggled override. Oven toggling, adjusting overlap between two beams means all mean toggling between force-on and force-off. I would very much advise against mixing the level and the override functionality in that way. To me, this goes against all concepts of UI design.

My recommendation would be to use the "tristate" QCheckBox feature ("no change/partially checked" intuitively and naturally meaning "no override"). That saves a lot of space by getting rid of an entire checkbox. Then toggle tristate with ctrl or shift-LMB.

I would also like to see well chosen keyboard accelerators and usable keyboard navigation for that panel. Well thought-through mouse-accelerated and keyboard-accelerated operation is really helpful once one hase become sufficiently literate with the UI.

Making moninj much more compact is excellent. I tried to push and advocate for that when it was built initially. Checkbox labels like 'override' and 'level' are repetitive and should not take up space at all.

[dtcallcock]

• I haven't read "All concepts of UI design" yet but I just thought I'd mention that we all thought it was a bit odd and preferred the other way. Not a strong preference though. In principle the tri-state sounds like a better way of representing something with three states. The only problem with having to press the keyboard too is that when I'm overriding I'm often leaning across a lab with a powermeter in my hand or something so being able to do it with the mouse only is a plus. Perhaps we'd have to try it to get a good idea of whether it is an improvement.
• Another idea to add to the original list - either override state currently changes the colour of the number displaying the logic level from black to red. Could override 0 make it red and override 1 make it green (or other colours)? This would make it easier to check from across the lab and would make it more obvious if you accidentally clicked the wrong override state.