Improve the cursor display formatting for imviz

[eteq]

This is a follow-on to #557 / #514. Below is a screenshot of the current look for imviz following those PRs:

DS9 7.4	Imviz

Basically, after several scientists looked at this (@orifox, @camipacifici, @PatrickOgle, and myself), we hit several points of concern. All of these are debatable and somewhat subjective, so this is starting as a space to try to come to consensus. The specific concerns were:

1. instead of sexigesimal for the world coordinates, we may want decimal degrees.
2. The pixels field should not be 0-padded.
3. The value shouldn't be in scientific notation for small numbers
4. The overall look is a bit cramped, particular with the pixel and value on one line. This may call for a 3-row layout
5. (potentially the same as 4) It might make more sense to put value first or last rather than in between pixel and world.

(I'll leave a comment with my opinion on this)

cc @Jenneh @astrofrog @pllim

[eteq]

Now my opinions

1. Astronomer opinions vary on this (@orifox said 50/50, which I think we all agreed is in the right ballpark), so it probably should be an option. But personally I think the default should be decimal degrees because sexigesimal tends to be much harder to use in the wider world - i.e., you usually can't copy-and-paste it as is, you often have to change the h/m/s to colons or whatever, whereas decimal degree, when it works, usually works as-is. So for "quick look" use cases, it makes sense to default to the one that allows the "quickest" workflows, and have an option on the rest. (note not even the 4 people mentioned above agreed on this, so discuss!)
2. In principle agree it should not be zero-padded. But as discussed further in Imviz: Move coordinates overlay to toolbar #557 (comment) this was not just a stylistic choice - it prevents the "jumping around". So I think these issues end up intertwined, because I agree jumping around is worse than 0-padding, but if we can manage a 3-row layout it's better to drop the 0-padding
3. I think this is important for redability and ds9 idiom-compatibility. The biggest question is how to define "small" here - I'd say anything below 65536 or so (or 5 digits before the decimal), since most raw images end up 16-bit. That's pretty arbitrary but 🤷 it feels about right to me.
4. I don't necessarily think 3-row is absolutely necessary, but I think 5 is more important, so if 3-row solves 5 it might be worth it even if the font gets smaller. Another option is to have pixel and world coordinates on a line together, although that comes at the price of a lot of horizontal space or low precision in coordinates
5. I'm strongly in favor of this. I find it very difficult to quickly see the value, and usually in my workflows I either want to see value or the coordinate (possible pixel, possibly world, possibly both), but not both value and coordinate at the same time. So mixing them together is mentally jarring

[hcferguson]

1. I'm agnostic on decimal vs. sexigesimal on the coords, but agree you need to be able to switch. Are you able to copy-paste from the "live" coordinate readout? That's nice functionality; not something you can do on ds9, where you have to hit C. (I'm a fan of keyboard shortcuts in general for interactive tools. It takes time to learn them, but once you memorize your most common ones it speeds workflow by a lot. And in examples like this, you don't have to move the cursor.)
2. Space-padding seems preferable to 0 padding.
3. Once you have keyboard shortcuts, add the option to toggle on and off the display or parts of the display. 3-row is going to start to impact enough of the real-estate that it seems important to be able to turn it off.
4. My own preference would be value col row RA Dec, with no labeling. People would need to read the docs to know which is which. But once they do, the display isn't using real-estate for static text.

[pllim]

Update: I added screenshots from DS9 vs Imviz for two sample images at the same pixels, respectively, above.

My response to the opinions and requests as follow:

1. Personally, I prefer HMS DMS and that is what DS9 and Ginga display also. Degrees are more machine readable, granted, but if our goal is to compare with existing tools, it is HMS DMS. Toggle might be possible, but as Jenn said, having both displayed will eat up the screen real estate.
2. Zero-padding was a design decision made by @astrofrog . The other option was to switch to some fixed width font that is not pretty.
3. I suggested the scientific notation, so the text for the unit won't jump around. That decision was my bad. You could use %g formatting but the text for the unit would then jump around. It was distracting for me but I can be overruled. Other tools do not display unit, so they don't have this problem.
4. We started out with 3 rows but the display looked bad on my end, see Imviz: Move coordinates overlay to toolbar #557 (review)
5. Sure. DS9 shows value, world, pixel, in that order.

[Jenneh]

I have 2 UX concerns. Neither mean this can't be shipped as is, but we may consider turning them into a bug/ticket to address in the future.

1. there is no padding between the bottom of the coordinate and the bottom of the header

• It would be preferred if some padding could be added before we ship because that would improve readability. @kecnry any idea how to do that?
• If padding is not added that should be written up as a UX bug

2. Do any scientists actually want to see both coordinates at the same time? if not, can we add a user preference / settings area where they select which one they want to see?

• This could be a ticket for the future. I know this would require some design and more development work than the current solution.

[pllim]

Reply from @PatrickOgle on Slack:

1. Up to me and @kecnry . (Since my VueJS is weak, if Kyle does not have a quick fix for the padding in Lab, I can open a follow-up bug report after merge.)
2. "Yes, scientists want both."

[kecnry]

@Jenneh @pllim - I'd be happy to work on any UI tweaks. I do see approximately equal padding on the top and bottom (although it is small - but the screenshots might slightly crop out in some cases). The only ways to increase padding would be to decrease font size, increase height of the app toolbar further, or remove the three lines (likely with a switch, but that is in conflict with the "scientists want both".

[pllim]

@kecnry , it looks fine in Notebook but bottom padding gone in Lab. Is Lab using a different CSS or something?