Raw Feedback for Draft 00 of the Visit Planner Detailed Requirements ###################################################################### 00 Visit Planner Tool The Visit Planner (VP) assists the user in making the visits in their proposal schedulable. The VP has the following capabilities: - Determines the times when visits can or cannot schedule - Indicates the reasons that visits are unschedulable at particular times. - Provides access to editors to change visits and relationships between visits to modify schedulability. - Provides general advice on techniques to obtain desired schedulability. - Provides analyses of how particular visits might be modified to improve the schedulability for particular dates. ---------------------------------------------------------------------- Meeting 7/30, 3:00 On the high level requirements under 00, we changed the wording of the second point to be: Identify the observer requirements that cause visits to be unschedulable. It wasn't clear if the original wording was expressing a requirement to provide more information than just identifying the observer requirements. Providing more detailed information will go along with the last of the high level requirements. The high level requirements posted on the VP web page will be change to reflect this change. These high level requirements will also be numbered in future versions of the requirements. ###################################################################### 00.1.1 The CP shall include a Visit Selector (VS) to select which visits from the current APT context to include in subsequent computations of scheduling windows. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.1.1.x ORIG: Do we really want to put visits that are not in the APT context x=1,2, in the VS? The linked visits that are not in the context should be 3,4 included in the calculations, but should not be selectable on their own. NEW: Since we discussed this at the meeting, I think we decided that we would consider making the VS a display mechanism, such that all visits included in the calculations would be included in the list and would be displayed by default, but would able to be hidden by de-selecting them in the VS. The main thing that I was conerned about was ability to display only the visits of interest without having to sift through the visits to which my visit is linked. Now I am concerned about possible confusion in what is in the list. Say that after an initial run, the links were deselected in the SCS for visit 01-- would the visits linked to 01 disappear from VS? If the VS includes only the visits included in the calculations, then those visits not in the APT context and not linked to those APT context visits would not be included, right? Sorry if that's confusing, I just want to make sure I am understanding correctly. ---------------------------------------------------------------------- Jesse 8/3, 3:38 > Say that > after an initial run, the links were deselected in the SCS for visit > 01-- would the visits linked to 01 disappear from VS? Yes, the linked visits would disappear (except, of course, those that are also in the APT context.) ---------------------------------------------------------------------- Jesse 8/3, 3:38 > If the VS > includes only the visits included in the calculations, then those > visits not in the APT context and not linked to those APT context > visits would not be included, right? This is correct ###################################################################### 00.1.1.2 Only those visits explicitly selected in the VS shall be included in subsequent computations of scheduling windows. (A visit not selected will not be included, even if it is linked to a selected visit.) ---------------------------------------------------------------------- Tony 7/23, 10:25 I would have thought the default behavior would be just the opposite. That visits linked to a selected visit would be automatically selected by the VP. The PI would then be able to see a visit's entire scheduability and if they want they could turn off constraints if necessary. I would just be worried that might think things are ok when they really aren't. Not everyone reads all the text on screens, they might just see a schedulable window and think things are ok. Aren't most PIs interested in seeing if their visit is scheduable based on the constraints they have defined? ---------------------------------------------------------------------- Andy 7/30, 11:51 I think we should talk about this. Might be a major pain if observers need painstakingly to activate every visit in a link set in order to get accurate information about any one of them. ---------------------------------------------------------------------- Meeting 7/30, 3:00 We decided that linked visits should always be included in the schedulability computation and that the user should not be able to turn off linked visits by de-selecting the visits. To exclude linked visits, the user will turn off the constraints that specify that the visits are linked. ---------------------------------------------------------------------- Meeting 7/30, 3:00 The original reason for the visit selector in the Control Panel was to enable the user to exclude linked visits. However, since we have decided to force linked visits to be processed unless the links as constraints are turned off, there is no reason for a Visit Selector to select visits for processing. The heirarchical editor will be the visit selector for processing. ---------------------------------------------------------------------- Leslie 8/3, 5:02 00.2.3.5 Chris mentioned in the meeting that this one is inconsistent with 00.1.1.2. ###################################################################### 00.1.2 The Control Panel shall have a Scheduling Constraints Selector (SCS) to select which scheduling constraints to include in subsequent computations of scheduling windows. ---------------------------------------------------------------------- Tony 7/23, 10:25 I assume the PI can only turn off PI specified proposal constraints. That is they can't turn off Sun, Moon, etc. Maybe just a clarification in the requirement. Also I'm assuming that if they toggle off a constraint they are not deleting it from the proposal, but just turning it off to play. Is this true? They then would have to edit their program to delete the constraint if needed. So if I understand this they can relax constraints, see the effects, and then have to delete the constraint from the program. If they want to change/add a constraint (ie., open an orient range), they will have to edit their program also, which is outside the VP control panel's ability. Here is an alternate approach to allowing them to play with their constraints. APT supports the aforementioned funcationality already with no special functionality needed in the VP. A PI could simply make a copy of their visit(s) and delete/add constraints as needed. Basically edit their program with the current APT editting capbilities. Load it into the VP and see what the effects are. If they like the visit, they can make it the real one, if not, delete it. The changes are immediately made in the proposal. ---------------------------------------------------------------------- Rusty 8/2, 9:38 The only other comment I have on the requirements is related to Tony's comment on 00.1.2. In reading this requirement and its children as well as 00.2.3.x I'm worried that the user might be mislead by what they see. This may be an implementation issue but we should also be sure to carefully word the requirements so that its clear that the capability specified is for the user to be able to temporarily disable a specified constraint. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.1.2.2 Would it be only the scheduling constraints that the observer controls that could be removed from the SCS? The line before req. 00.1.4... Is there a case where constraints for a visit could be selected without the visit selected? Can you de-select constraints for a visit not in the APT context, but brought in for computation b/c of links? If so, how will we ensure consistancy when the visit to which it is linked has the link constraint de-selected? Will the visit disappear from the lists and from the calculations? ---------------------------------------------------------------------- Jesse 8/3, 3:38 I would say so, but I don't know of any that are technically out of the observer's control, ie, don't have an observeration requirement which can be changed. Things like the Sun or Moon are physically under the user's control because the coordinates are something under the user's control. It just a matter of the HST observatory policy that the user can't change the target. ---------------------------------------------------------------------- Jesse 8/3, 3:38 I had in mind that the constraint selector sets the constraints to be included for all visits. The schedulability for all visits will be computed using the same set of constraints. If links are turned off in the constraint selector, then all linked visits would disappear from the lists and from the calculations. I think the constraint selector will have to list a constraint for each link set (is it okay to say link set here????). ###################################################################### 00.1.4 If the observer requirement of a scheduling constraint is not specified in a visit, then the scheduling constraint will be treated as if it has no schedulable windows. ---------------------------------------------------------------------- Rusty 7/17, 9:26 I'm not sure what the one above means. Is this saying that the user chose to include a constraint from the SCS for which there is not corresponding constraint in the visit specification? Also the numbering is off, I think this should be 00.1.3. ---------------------------------------------------------------------- Jesse 7/17, 2:35 Thanks for your comments. Your assertion is correct. Then, there would be a statement in the "More Info..." dialog (00.2.3.1). ---------------------------------------------------------------------- Tony 7/23, 10:25 I don't understand this requirement ---------------------------------------------------------------------- Tony 7/23, 10:25 4) There are two 00.1.4 numbered requirements. ---------------------------------------------------------------------- Andy 7/30, 11:51 Naively this strikes me as exactly the opposite of how it should be. Seems to me that if I don't specify a BETWEEN or an ORIENT, the software should assume that any orient or absolute time will satisfy my constraints, not that none would. I'm not sure the subtle distinction between a constraint whose value is defaulted and one which is missing will be appreciated by most users. ---------------------------------------------------------------------- Leslie 8/2, 5:02 There are two 00.1.4's. Should the first 00.1.4 be 00.1.3, then the rest numbered accordingly? ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.1.4 If the total suitability is an intersection of all of the schedulable #1 windows of the constraints, wouldn't we want to consider those constraints not specified to be schedulable everywhere? ---------------------------------------------------------------------- Jesse 8/3, 3:38 This requirement has caused some confusion. Most observation requirements have some default value. So, usually all constraints are specified. This requirement is supposed to handle the case where there is no value given, none specified by the user and no default value. (For example, the default for ORIENT is 0-360. For HST, I don't think there is a good example where there is no default value. If an observatory allows visit planning without coordinates, then that would be a case where Sun and Moon would be unschedulable everywhere. ###################################################################### 00.1.3 The CP shall have a Compute Button to compute and/or update the scheduling windows for the selected visits with the selected scheduling constraints. ---------------------------------------------------------------------- Rusty 7/17, 9:26 Also the numbering is off, I think this should be 00.1.3. ---------------------------------------------------------------------- Tony 7/23, 10:25 4) There are two 00.1.4 numbered requirements. ---------------------------------------------------------------------- Tony 7/23, 10:25 A consistency issue. I believe the orbit planner is calling their button Update. Probably should have the same name for all the buttons that go off and compute something. We might at some point want to follow what most applications do. Apply button possibly. This isn't a big deal, its just a button name. ---------------------------------------------------------------------- Leslie 8/2, 5:02 There are two 00.1.4's. Should the first 00.1.4 be 00.1.3, then the rest numbered accordingly? ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.1.3 Doesn't the Orbit Planner use "Update", rather than "Compute" for its button with similar function? We should try to be consistent. ###################################################################### 00.1.4 The CP shall have a button to invoke a tool for graphically editing links between visits. ---------------------------------------------------------------------- Rusty 7/17, 9:26 Also the numbering is off, I think this should be 00.1.3. ---------------------------------------------------------------------- Tony 7/23, 10:25 4) There are two 00.1.4 numbered requirements. ---------------------------------------------------------------------- Tony 7/23, 10:25 The Phase 2 editor tool will have to have a mechanism to enter special requirements including links for visits. I'd like to see the same editting mechanism used for all of APT (ie, phase 2 editor tool and visit planner tool). I think it will be more clear to user's if we have one mechanism for editting visit's special requirements. Need to coordinate this with Rob and Gary since they will need this capability for the phase 2 editor tool. ---------------------------------------------------------------------- Andy 7/30, 11:51 This will be cute and fun, but does sound more like a nice-to-have than a critical item. ---------------------------------------------------------------------- Leslie 8/2, 5:02 There are two 00.1.4's. Should the first 00.1.4 be 00.1.3, then the rest numbered accordingly? ###################################################################### 00.1.5 The CP shall have a display/controller to set the starting and ending dates for computing scheduling windows. ---------------------------------------------------------------------- Rusty 7/17, 9:26 Also the numbering is off, I think this should be 00.1.3. ---------------------------------------------------------------------- Tony 7/23, 10:25 4) There are two 00.1.4 numbered requirements. ---------------------------------------------------------------------- Tony 7/23, 10:25 Their are some implications that we have to deal with if we let the PI do this. Spike has a orbit model it uses to calculate the location of HST in orbit. The orbital elements are valid for a specific time period (ie., their own start/end times which are independent of the planning start/end). We will have to restrict the PI from setting numbers outside the orbit model range. These values are stored in a file local to Spike, so some communication will need to be implemented to send the numbers to the APT GUI from Spike. Also, Moss files are valid for a specific set of dates. Again these dates will have an impact on whether Moss files are valid or not. ---------------------------------------------------------------------- Andy 7/30, 11:51 I think we need to be careful here. Perhaps the range of the display should be configurable, but for HST use, don't we need to make sure that the suitability is calculated over the cycle in which the visit will be submitted. ---------------------------------------------------------------------- Leslie 8/2, 5:02 There are two 00.1.4's. Should the first 00.1.4 be 00.1.3, then the rest numbered accordingly? ###################################################################### 00.2.1.2 For visit SWCs, if there is at least one schedulable window and all scheduling constraints have been included, then the text area will say "Visit is schedulable." in green text. ---------------------------------------------------------------------- Rusty 7/17, 9:26 1) Rather than saying something should be in red, green or yellow, it would be better to say that some kind of visual cue will be provided. Sometimes putting text in yellow makes it hard to read. A colored icon preceeding black text works justs as well to grab your attention and it maintains the readability of the text. You really only need to get someone's attention when something might be wrong so its not necessary to flag "good" messages in green. You only need to worry about warnings and errors. A different icon could be used for each type of message. For example: (!) Visit 6 is not schedulable. (?) Visit 8 may be schedulable. ---------------------------------------------------------------------- Rusty 7/17, 9:26 3) A general comment about GUI specifics: I usually try to avoid writing requirements that say something has to be a certain color or the user left-clicks to get some information unless there is a reason why it absolutely has to be that way. Its better to keep it generic and say that the system shall provide the capability for the user to obtain the information through a mouse action or the system shall provide the user with a visual cue that something has occured. That gives more leeway at design time to pick the best means of implementing the capability. If you get too specific about the GUI requirements, without needing to, then you wind up having to go back to change requirements when you discover a better way to do something. ---------------------------------------------------------------------- Andy 7/30, 11:51 Red, green and yellow text are hard to read. Also we run into accessability issues. Red/green color blindness strikes about 10% of the male population, so at STScI alone we can expect a couple dozen color blind members of the science staff. Therefore I would hesitate to attach sematics to the color which text appears. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.2 We should consider choosing blue for those that have trouble distinguishing between red and green. Perhaps we should also make some other distiction so that when the output is printed, the user does not need to use a color printer to see the difference. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.x Do we really need to tell them what they can see? I think we should x=1,2, warn them when they have schedulability without using all of the 3,4 constraints. However, they can look at the schedulability display and see if the visit/constraint is schedulable or not. ###################################################################### 00.2.1.3 For visit SWCs, if there are no schedulable windows, then the text area will say "Visit is not schedulable." in red text. ---------------------------------------------------------------------- Rusty 7/17, 9:26 1) Rather than saying something should be in red, green or yellow, it would be better to say that some kind of visual cue will be provided. Sometimes putting text in yellow makes it hard to read. A colored icon preceeding black text works justs as well to grab your attention and it maintains the readability of the text. You really only need to get someone's attention when something might be wrong so its not necessary to flag "good" messages in green. You only need to worry about warnings and errors. A different icon could be used for each type of message. For example: (!) Visit 6 is not schedulable. (?) Visit 8 may be schedulable. ---------------------------------------------------------------------- Rusty 7/17, 9:26 3) A general comment about GUI specifics: I usually try to avoid writing requirements that say something has to be a certain color or the user left-clicks to get some information unless there is a reason why it absolutely has to be that way. Its better to keep it generic and say that the system shall provide the capability for the user to obtain the information through a mouse action or the system shall provide the user with a visual cue that something has occured. That gives more leeway at design time to pick the best means of implementing the capability. If you get too specific about the GUI requirements, without needing to, then you wind up having to go back to change requirements when you discover a better way to do something. ---------------------------------------------------------------------- Andy 7/30, 11:51 Red, green and yellow text are hard to read. Also we run into accessability issues. Red/green color blindness strikes about 10% of the male population, so at STScI alone we can expect a couple dozen color blind members of the science staff. Therefore I would hesitate to attach sematics to the color which text appears. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.2 We should consider choosing blue for those that have trouble distinguishing between red and green. Perhaps we should also make some other distiction so that when the output is printed, the user does not need to use a color printer to see the difference. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.x Do we really need to tell them what they can see? I think we should x=1,2, warn them when they have schedulability without using all of the 3,4 constraints. However, they can look at the schedulability display and see if the visit/constraint is schedulable or not. ###################################################################### 00.2.1.4 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. ---------------------------------------------------------------------- Rusty 7/17, 9:26 1) Rather than saying something should be in red, green or yellow, it would be better to say that some kind of visual cue will be provided. Sometimes putting text in yellow makes it hard to read. A colored icon preceeding black text works justs as well to grab your attention and it maintains the readability of the text. You really only need to get someone's attention when something might be wrong so its not necessary to flag "good" messages in green. You only need to worry about warnings and errors. A different icon could be used for each type of message. For example: (!) Visit 6 is not schedulable. (?) Visit 8 may be schedulable. ---------------------------------------------------------------------- Rusty 7/17, 9:26 3) A general comment about GUI specifics: I usually try to avoid writing requirements that say something has to be a certain color or the user left-clicks to get some information unless there is a reason why it absolutely has to be that way. Its better to keep it generic and say that the system shall provide the capability for the user to obtain the information through a mouse action or the system shall provide the user with a visual cue that something has occured. That gives more leeway at design time to pick the best means of implementing the capability. If you get too specific about the GUI requirements, without needing to, then you wind up having to go back to change requirements when you discover a better way to do something. ---------------------------------------------------------------------- Andy 7/30, 11:51 Red, green and yellow text are hard to read. Also we run into accessability issues. Red/green color blindness strikes about 10% of the male population, so at STScI alone we can expect a couple dozen color blind members of the science staff. Therefore I would hesitate to attach sematics to the color which text appears. ---------------------------------------------------------------------- Chris 7/30, 4:28 Be more specific - "Visit X is schedulable with the selected subset of scheduling constraints." ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.2 We should consider choosing blue for those that have trouble distinguishing between red and green. Perhaps we should also make some other distiction so that when the output is printed, the user does not need to use a color printer to see the difference. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.x Do we really need to tell them what they can see? I think we should x=1,2, warn them when they have schedulability without using all of the 3,4 constraints. However, they can look at the schedulability display and see if the visit/constraint is schedulable or not. ###################################################################### 00.2.1.5 For scheduling constraint SWCs, if there is at least one schedulable window, then the text area will say " has at least one schedulable window." in green text. ---------------------------------------------------------------------- Rusty 7/17, 9:26 1) Rather than saying something should be in red, green or yellow, it would be better to say that some kind of visual cue will be provided. Sometimes putting text in yellow makes it hard to read. A colored icon preceeding black text works justs as well to grab your attention and it maintains the readability of the text. You really only need to get someone's attention when something might be wrong so its not necessary to flag "good" messages in green. You only need to worry about warnings and errors. A different icon could be used for each type of message. For example: (!) Visit 6 is not schedulable. (?) Visit 8 may be schedulable. ---------------------------------------------------------------------- Rusty 7/17, 9:26 3) A general comment about GUI specifics: I usually try to avoid writing requirements that say something has to be a certain color or the user left-clicks to get some information unless there is a reason why it absolutely has to be that way. Its better to keep it generic and say that the system shall provide the capability for the user to obtain the information through a mouse action or the system shall provide the user with a visual cue that something has occured. That gives more leeway at design time to pick the best means of implementing the capability. If you get too specific about the GUI requirements, without needing to, then you wind up having to go back to change requirements when you discover a better way to do something. ---------------------------------------------------------------------- Andy 7/30, 11:51 Red, green and yellow text are hard to read. Also we run into accessability issues. Red/green color blindness strikes about 10% of the male population, so at STScI alone we can expect a couple dozen color blind members of the science staff. Therefore I would hesitate to attach sematics to the color which text appears. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.2 We should consider choosing blue for those that have trouble distinguishing between red and green. Perhaps we should also make some other distiction so that when the output is printed, the user does not need to use a color printer to see the difference. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.x Do we really need to tell them what they can see? I think we should x=1,2, warn them when they have schedulability without using all of the 3,4 constraints. However, they can look at the schedulability display and see if the visit/constraint is schedulable or not. ###################################################################### 00.2.1.6 For scheduling constraint SWCs, if there are no schedulable windows, then the text area will say " has no schedulable windows." in red text. ---------------------------------------------------------------------- Rusty 7/17, 9:26 1) Rather than saying something should be in red, green or yellow, it would be better to say that some kind of visual cue will be provided. Sometimes putting text in yellow makes it hard to read. A colored icon preceeding black text works justs as well to grab your attention and it maintains the readability of the text. You really only need to get someone's attention when something might be wrong so its not necessary to flag "good" messages in green. You only need to worry about warnings and errors. A different icon could be used for each type of message. For example: (!) Visit 6 is not schedulable. (?) Visit 8 may be schedulable. ---------------------------------------------------------------------- Rusty 7/17, 9:26 3) A general comment about GUI specifics: I usually try to avoid writing requirements that say something has to be a certain color or the user left-clicks to get some information unless there is a reason why it absolutely has to be that way. Its better to keep it generic and say that the system shall provide the capability for the user to obtain the information through a mouse action or the system shall provide the user with a visual cue that something has occured. That gives more leeway at design time to pick the best means of implementing the capability. If you get too specific about the GUI requirements, without needing to, then you wind up having to go back to change requirements when you discover a better way to do something. ---------------------------------------------------------------------- Andy 7/30, 11:51 Red, green and yellow text are hard to read. Also we run into accessability issues. Red/green color blindness strikes about 10% of the male population, so at STScI alone we can expect a couple dozen color blind members of the science staff. Therefore I would hesitate to attach sematics to the color which text appears. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.2 We should consider choosing blue for those that have trouble distinguishing between red and green. Perhaps we should also make some other distiction so that when the output is printed, the user does not need to use a color printer to see the difference. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.1.x Do we really need to tell them what they can see? I think we should x=1,2, warn them when they have schedulability without using all of the 3,4 constraints. However, they can look at the schedulability display and see if the visit/constraint is schedulable or not. ###################################################################### 00.2.2 SWCs shall include a linear calender indicating the days that have scheduable windows. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.2 The "days" should be changed to something like "times" since the schedulability may not be in whole days, and perhaps may be less than a day in its totality. ###################################################################### 00.2.2.2.3 The analysis shall display the list of constraints that are "schedulable" at the time of interest. ---------------------------------------------------------------------- Tony 7/23, 10:25 8) Requirements 00.2.2.2.2 and 00.2.2.2.3 are the same. ---------------------------------------------------------------------- Andy 7/30, 11:51 These are identical. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.2.2.2 and 00.2.2.2.3 say exactly the same thing. Should 00.2.2.2.3 perhaps say "...that are _not_ 'schedulable'..."? ###################################################################### 00.2.2.2.4 If the visit is unschedulable at the time of interest , the analysis shall display suggested changes to observer requirements to that would allow the visit to become schedulable. ---------------------------------------------------------------------- Andy 7/30, 11:51 Adding the words "if any" after "suggested changes" would make this requirement closer to being achievable. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.2.2.4 Should we add "if possible" to this since there may be cases where it may not be able to offer suggestions? ###################################################################### 00.2.2.3 For scheduling constraint SWCs, left clicking at a point on the SWC shall display values of the associated observer requirements that allow the constraint to be "schedulable". ---------------------------------------------------------------------- Rusty 7/17, 9:26 3) A general comment about GUI specifics: I usually try to avoid writing requirements that say something has to be a certain color or the user left-clicks to get some information unless there is a reason why it absolutely has to be that way. Its better to keep it generic and say that the system shall provide the capability for the user to obtain the information through a mouse action or the system shall provide the user with a visual cue that something has occured. That gives more leeway at design time to pick the best means of implementing the capability. If you get too specific about the GUI requirements, without needing to, then you wind up having to go back to change requirements when you discover a better way to do something. ---------------------------------------------------------------------- Andy 7/30, 11:51 Like the previous item, I don't think we can guarantee to be able to do this for any constraint. Adding a "wherever possible" somewhere in there might be a good idea. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.2.2.3 I'm not sure I understand this one. ---------------------------------------------------------------------- Jesse 8/3, 3:38 For example, for an orient SWC, left clicking on a point in time would bring up a pop-up box that lists the suitable ranges of ORIENTS for that time. ###################################################################### 00.2.3.2 For a visit, if the scheduling windows do not include all scheduling constraints, then the "More Info..." dialog will state one of the following reasons as appropriate: Not all constraints have been selected to compute the scheduling windows for this visit. Not all constraints have been included to compute the scheduling windows for this visit because the following proposal parameters have not been specified: (). ---------------------------------------------------------------------- Rusty 8/2, 9:38 Also, in the resulting display it should clearly indicate that some constraints were disabled. I think this information should be up front rather than in a pop-up dialog. Perhaps the details of which constraints were disabled could be in the pop-up but the fact that constraints were disabled should be right in the main display as a warning. ###################################################################### 00.2.3.3 If a visit has schedulable windows, but the scheduling windows do not include all scheduling constraints, then the "More Info..." dialog will state: WARNING: This visit may not be schedulable if all constraints are included. ---------------------------------------------------------------------- Chris 7/30, 4:28 Be more specific - This visit is schedulable with the selected subset of scheduling constraints. It is unknown whether this visit is schedulable if all constraints are included. ---------------------------------------------------------------------- Rusty 8/2, 9:38 Also, in the resulting display it should clearly indicate that some constraints were disabled. I think this information should be up front rather than in a pop-up dialog. Perhaps the details of which constraints were disabled could be in the pop-up but the fact that constraints were disabled should be right in the main display as a warning. ###################################################################### 00.2.3.5 If a visit has not been selected, but has been included in the computation of scheduling windows because it has a link to one or more visits that have been selected, then the "More Info..." dialog will state: This visit has been included because it is linked to selected other visits. ---------------------------------------------------------------------- Leslie 8/3, 5:02 00.2.3.5 Chris mentioned in the meeting that this one is inconsistent with 00.1.1.2. ###################################################################### 00.3 The VP shall provide feedback to the APT spreadsheet ---------------------------------------------------------------------- Tony 7/23, 10:25 10) A question for 00.3 section. Are we making things too complicated? Should we just hightlight the visit's spreadsheet row and not worry about cells. The visit row in the spreadsheet isn't going to have much information in it at all and mostly everything that the VP will deal with is the special requirements cell. It just might be easier and as clear to the PI if we just highlight the row. ---------------------------------------------------------------------- Leslie 8/2, 5:02 00.3 Do we want to call it "error" highlighting? Perhaps "unschedulable" highlighting sounds nicer. It's not necessarily an error that the visit/constraint has no schedulability. ###################################################################### 00.3.2 The visit row for any visit selected in the VP for which scheduling windows have not been computed shall be given an error highlighting. ---------------------------------------------------------------------- Tony 7/23, 10:25 9) I don't understand what 00.3.2, 00.3.3, 00.3.4 mean. ---------------------------------------------------------------------- Andy 7/30, 11:51 This would mean initially everything would be an error. Not sure I like this - people would get in the habit of ignoring the error status. A warning might be better, like 00.3.4. ###################################################################### 00.3.3 The visit row for any visit selected in the VP which has no schedulable windows shall be given an error highlighting. ---------------------------------------------------------------------- Tony 7/23, 10:25 9) I don't understand what 00.3.2, 00.3.3, 00.3.4 mean. ###################################################################### 00.3.4 The visit row for any visit selected in the VP whose scheduling windows are out-of-date shall be given a warning highlighting. ---------------------------------------------------------------------- Tony 7/23, 10:25 9) I don't understand what 00.3.2, 00.3.3, 00.3.4 mean. ###################################################################### 00.3.6 The cell for any observer requirement corresponding to a scheduling constraint selected in the VP for which scheduling windows have not been computed shall be given an error highlighting. ---------------------------------------------------------------------- Andy 7/30, 11:51 This would mean initially everything would be an error. Not sure I like this - people would get in the habit of ignoring the error status. A warning might be better, like 00.3.4. ###################################################################### ###################################################################### 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. ###################################################################### 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 another text 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? ###################################################################### 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 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 for the first release and then get user feedback on the issue.