Distilled Feedback for Draft 00 of the Visit Planner Detailed Requirements 00 Change Indicates the reasons that visits are unschedulable at particular times. to Identify the observer requirements that cause visits to be unschedulable. 00.1.1 The purpose of the Visit Selector will now be to select the visits to include in the Scheduling Display Panel. For now, I would like specify the Visit Selector in the Control Panel to be the mechanism for selecting which visits to display. It is likely that any such mechanism will not be part of the first release and I do not want to get bogged down in its details at this time. A note will be attached to the requirements document explaining this. 00.1.1.2 Remove this requirement since it applies only to processing and not to displaying. 00.1.2 I have similar thoughts as for 00.1.1 that this capability will not be in the first release and I don?t want to be held back by something we don?t need to consider at this time. I think it is clear that we need to consider more carefully exactly what we would want a constraint selector to do and how we would want to present it to the user. 00.1.4 (#1) The observer requirements for a particular scheduling constraint can have one of three states: 1) has a user specified value, 2) uses a default value, 3) has no value associated with it. I think that most observer requirements for HST phase 2 proposals fall into either 1) or 2). For example, by default, orient range is 0-360. The only exceptions I can think of are the target data and instrument configuration. However, if an observatory does have observer requirements which do not have default values, then we must allow for the case when visits with such observer requirements are passed unspecified to the visit planner. 00.1.3 ?Update? it is. 00.1.4 (#2) It?s in the APT requirements to have such a graphical tool. But, that doesn?t mean we have to make it a high priority item. 00.1.5 Maybe we could have a custom dialog for each observatory to choose a date range. For HST, the user could choose the cycle. The behind the scenes data tables would deal with providing the correct model to Spike. 00.2.1.2-00.2.1.6 I think we should dispose of color codes and use a leading icon. I like having words that explicitly describe the state of the visit or scheduling constraint so the user doesn?t have to infer the schedulability from the graphic display. 00.2.1.4 Are there any problems with changing For visit SWCs, if there is at least one schedulable window, but not all scheduling constraints have been included, then the text area will say "Visit may be schedulable." in yellow text. to For visit SWCs, if there is at least one schedulable window, but not all scheduling constraints have been included, then the text area will say "Visit is schedulable with the selected subset of scheduling constraints." 00.2.2 Change to be SWCs shall include a linear calender indicating the periods of time that have scheduable windows. 00.2.2.2.3 Make this the case of indicating the constraints that are not ?schedulable?. 00.2.2.2.4 Change to be 00.2.2.2.4 If the visit is unschedulable at the time of interest, the analysis shall display suggested changes to observer requirements, if any, that would allow the visit to become schedulable. 00.2.2.3 Change to be 00.2.2.3 For scheduling constraint SWCs, left clicking at a point on the SWC shall display values, if any, of the associated observer requirements that allow the constraint to be "schedulable". 00.2.3.2 & 00.2.3.3 Do we want to have a the fact that some constraints are disabled explicit and up front? How do we fit that into the display? 00.2.3.3 Change WARNING: This visit may not be schedulable if all constraints are included. to WARNING: This visit is schedulable with the selected subset of scheduling constraints. It is unknown whether this visit is schedulable if all constraints are included. 00.3 As for what we call the highlighting, I?m not sure what flexibility we have. It depends on what types of highlighting the spreadsheet can support. We should add a requirement that SWC?s are selectable to support visual feed back to corresponding entries in the spreadsheet editor. 00.3.1-00.3.8 There is confusion among these requirements about what is selected. The wording on these requirements should be changed to indicate the spreadsheet feedback occurs when the SWC?s of visits or constraints are selected. 00.3.3 The visit row for any selected visit SWC which has no schedulable windows shall be given an error highlighting. 00.3.4 The visit row for any selected visit SWC whose scheduling windows are out-of-date shall be given a warning highlighting. 00.3.5 Selecting a scheduling constraint SWC shall cause the corresponding observer requirement cells in the APT spreadsheet to be highlighted. 00.3.7 The cell for any observer requirement corresponding to a selected scheduling constraint SWC which has no schedulable windows shall be given an error highlighting. 00.3.8 The cell for any observer requirement corresponding to a selected scheduling constraint SWC whose scheduling windows are out-of-date shall be given a warning highlighting. 00.3.2 and 00.3.6 These requirements made sense when users were allowed to select/deselect visits for schedulability processing. But, since we?re not doing that any more, these requirements will be dropped. Other Issues Prioritizing Requirements Tony 7/23, 10:25 11) Are all of these requirements "must have" requirements to make a VP tool. Are some "would be nice". Meeting 7/30, 3:00 Minimum Requirements The draft requirements will certainly not be implemented for the first release. Jesse will try to come up the subset that would be reasonable. Controlling Displayed Visits Meeting 7/30, 3:00 User's should be able to have control over which visits are included in the Schedulability Display Panel. We don't know yet how to provide this control. This control would be useful if a visit has many linked visits, most of which are not a problem. In general, though, most proposals are not of this nature. Certainly, the default should be to process and display all visits in the current APT context. We might be able to get ideas for selecting visits from how the Spike GUI handles it. Meeting 7/30, 3:00 However, we still need to figure a way for user's to select which visits to display. We could leave the visit selector in the control panel, but use it to control the display, not the processing. We could add a tool bar to the display panel to give some display and visit navigation control. It may be easiest at this time to always display all processed visits Orbit Visibility Tony 7/23, 10:39 Currently CASM reads input from Trans for visibility information. Is this still a requirement for the VP? It imposes a process on APT. Could we do the following? If Trans (orbit planner) info on visibility is available for a visit, the VP uses it. If not, it uses some orbital visibility number and lets the user know about what it has done. Maybe anothertext message on the VP display somewhere. Similiar to the messages they get when they relax a constraint. This will allow the PI to run the VP without the orbit planner being run first. Andy 7/23, 10:48 We disucussed the possibility considering of an "orbit structure", i.e. an arrangement of exposures amongst orbits, as a constraint just like any other. I.e. observers can attach or detach it and the software would function without it being there. Therefore the VP could be run before the OP (in which case no orbit structure would be present) or after (in which case the observer could attach or detach the orbit structure constraint and see its effect on schedulability.) Specifying Constraints Needed for HST Andy 7/30, 11:51 Somewhere in the requirements we should list the types of constraints that the VP needs to support. Otherwise a tool which supports no constraints at all could technically satisfy these requirements. Terms Leslie 8/2, 5:02 00 I think that using the word "calendar" for the individual schedulabilities displayed in the schedulability display could be confusing to those that are used to considering a calendar to mean the flight calendar. We discussed this at the meeting, and I could offer no good alternative that was not "timeline" or "schedulability display". Meeting 7/30, 3:00 Use of the word "Calender" There was some concern that the word "Calender", particularly in the term Schedulability Windows Calender, might be confused with "flight calenders". We decided to just leave it the way it is unless someone later figures out better terminology. Printing Display Leslie 8/2, 5:02 Do we have a requirement that the display output should be able to be printed or saved to a file that could be printed? for the first release and then get user feedback on the issue. Computation Requirements Do we need requirements on what the computations do? This is where we?d specify that linked visits are always included.