Asterism Selection

[swalker2m]

For observations that offer more than one option, we'll need a UI for choosing which particular asterism to use. I think ideally this would be done in the target component editor itself, perhaps in a new row above the target table itself? The thinking here is that the first step in setting up your targets is to decide how you're going to observe. You need to know if you're doing GHOST standard resolution dual target before you start picking targets. The drawback of course is that it takes a lot of precious vertical space for just one setting. It wouldn't need to be visible unless there is more than one option of course, and only GHOST has more than one option. Another idea would be to put it in the table footer (again, only when necessary).

Since some asterisms will come with additional configuration though, perhaps the best idea is to move this all off into a drawer that slides out in the same way that the P2 checking "Problems" drawer opens.

Some implementation ideas:

• We need to be able to represent the choices. Here we just need a simple AsterismType enumeration / ADT with SingleTarget, GhostStandardRes, and GhostHighRes options.
• The Asterism trait could be updated to say which AsterismType it corresponds to.
• The instrument component could provide a List[AsterismType] of available options which could be used by the target component to populate the list of selections and to validate the current asterism with the available options.

A (bonus?) task would be to preserve as much target information as possible when switching between standard and high res asterisms.

[sraaphorst]

I think if we are going to add this information to the target component editor, it should probably be in the header instead of the footer, because, as you say: "the first step in setting up your targets is to decide how you're going to observe." Putting it in the footer will not make it clear that this is the first step.

The drawer idea does concern me because it departs from the uses of the drawer so far, so I think it will be confusing to users. Are the settings you indicate in the above diagram ones we'd need to include for all asterisms? I can see your point, then, that this is a lot of vertical space to give up.

When you say "which particular asterism to use," there is one point I'm not clear on: would the users be able to specify multiple asterisms? My understanding was that there would only be one asterism (based on how you're going to observe). If my understanding is correct, one idea (which may be horrible - I don't know) is to put this information in the instrument editor and then:

1. Either force the user to pick the configuration before even allowing them to modify the target component; or
2. Assume a default mode (which can be changed in the instrument editor) and change the message above the target component table to summarize as a string what mode is currently in use.

I'm not sure any of these options are appealing, but if possible, keeping the target component editor free from more clutter would be desirable, since this is one of the most information-intensive editors we have.

[sraaphorst]

This may be a terrible idea, but I'll still throw it out there: if the combination of options is not huge, and comprises just selecting a bunch of check boxes / radio buttons, this information could be collapsed down into a drop-down menu (with a calibration duration text field). Then the vertical space used would be minimized to just a single row of components.

[swalker2m]

I don't have a strongly held opinion, but I'm partial to the drawer idea because it tucks away nicely and usually won't be modified. Coming in from Phase 1 the asterism should already be set. We also use the drawer idea for

• merge conflict resolution
• showing static sequence information and for
• editing engineering-only parameters (see Flamingos 2)

The last case is similar to this usage. Another bonus is that it doesn't require modifying the existing UI much.

[sraaphorst]

Ahhh, yes. I forgot about those and the fact that this will seldom be changed since it will be coming in through Phase 1. That eliminates my opposition, then.

[sraaphorst]

This seems like mostly UI work, so I'm guessing about 3 days.

[sraaphorst]

It looks like this will be done in 1437, so I'll include estimates there.

[swalker2m]

I believe the UI became just a radio button choice between standard and high resolution mode, placed in the instrument editor as mentioned above. The additional configuration can wait for the future. We should also define what happens to any existing targets when switching between modes. Presumably we try to save at least one valid target.

[sraaphorst]

The resolution and mode have been placed in the instrument component. Other configuration information is something we will have to plan for as the implementation continues.