Add Exposure number to hover over info

[cracraft]

I would like to request that exposure number be added to the proposal, observation and visit numbers when the user hovers over each individual thumbnail image. This information seems more important to show than the start time, so could maybe replace that?

[rcooper295]

I thought the exposure number might still be nice to have since it's one of the options for sorting the thumbnails so I added it, but there isn't quite enough room for all the text on the thumbnail (see attached screenshots). I also stripped the leading zeros from the exposure num (e.g. 00001 --> 1) and was wondering if I should do that with the proposal, visit, and observation numbers there too or if people are more used to seeing those as as they are, in which case maybe I should leave the exposure numbers alone too?

[bhilbert4]

Showing observation, visit, and exposure, you can still have redundant entires. Is there room to add visit group and activity number as well? Maybe as a combined entry if there isn't room for both?

I'm partial to keeping the leading zeros, just because that's what I'm used to seeing when reading filenames. But that's just me.

Do you think it would make things more readable to right-justify the values?

[bhilbert4]

There was a request by the NIRSpec team today to add exp_type (or actually the instrument mode) to this. This information should be in the django model for each exposure as the exp_type (right @BradleySappington?) In most cases, the exp_type and the instrument mode are synonymous. But for TA observations, there are more steps to retrieve the mode, as it is stored in a header keyword and an extension that is dependent on the type of TA observation. @penaguerrero has the decoder for this. That update probably actually needs to go into the Django model population. I'll create a separate issue for that.

[BradleySappington]

@bhilbert4 and @rcooper295 , only a list of exp_types was saved in the models that I extracted and stored with the thumb_dicts

[bhilbert4]

@BradleySappington so it's a list of exp_types for each observation?

[BradleySappington]

Its a list of the exp_types for each proposal thumbnail. Each individual exp_type is figured out in jwql, not saved in the models, its then stored with the thumbnail data. Once on the observation page, the list only has 1 item in it for each thumbnail. The data is accessible from each html thumbnail using attribute exp_type.

[bhilbert4]

One value for each thumbnail (where we have one thumbnail per exposure) makes sense. I think that's all we would need to display the exp_type when hovering over the thumbnail.

[BradleySappington]

Thats correct, it should be displayed the exact same way as exposure time

[bhilbert4]

If the list of metadata to display is too large, what if we enlarged the area of the hover-over? I don't think we'd want to enlarge it too much (i.e. we shouldn't completely cover the neighboring thumbnails), but if it turns out we need just a bit more area, maybe that's an option?

[rcooper295]

Does this look ok for the updated hover-over display? The size of the thumbnail hover-over is currently limited by the number of items requested for NIRSpec so the other instruments have some empty real estate, but I couldn't see a way of making the display area depend on the instrument or length of the thumbnail info that wasn't overly complicated. The rows seem to get spaced automatically so the hover-over panel doesn't cover adjacent thumbnails.

Also, possibly unrelated, some of the thumbnails look very strange when I run it locally, though they look fine when I display the same page on the normal (prod?) web app. You can see this a bit in the nirspec thumbnail screenshot. I don't think any of the changes I made should have changed the thumbnails though so hopefully it's just a local glitch

[bhilbert4]

Looks good! A couple space-saving suggestions:

1. Combine observation and visit onto one line? Obs/Visit: 002/001
2. Combine filter/grating or filter/pupil onto one line? Optics: CLEAR/PRISM
3. Move the exposure number to be just below Obs/Visit, since they combine to identify the exposure's place in the observation

I didn't realize that the rows would be spaced out more in order to accommodate the hover over. It'd be nice not to space things out too much, which would lead to more scrolling for users.

The library of thumbnails that is used when running locally is different than that when run on the server, so differences there are expected.

[rcooper295]

Those are good suggestions. I do have filter/pupil combined when both those keywords are there, but it doesn't fit on one line that way unfortunately and I didn't know how I felt about abbreviating it (filt/pup??). Do you think "optics" to encompass filter/pupil, filter/grating, and maybe filter/band for relevant MIRI observations is clear enough? I guess users can go into the header if they're not sure which element is in which wheel. That should allow me to decrease the box size a bit.

[bhilbert4]

Yeah, I think Optics is reasonable. The values should make it clear.

[cracraft]

Just to make sure, if we go with Optics, the MIRI combination will come from Channel and Band for the MRS, something like 12, LONG would be the values. For Imager, it would only be Filter. Those are the different options based on which detector is used.

[rcooper295]

Thanks, I will update that -- I had filter/band for MRS (realizing that doesn't make sense) and just filter for imager so I'll change it to channel/band for MRS.