Internal Technical Memorandum ITM-1998-07
A. Koratkar, D. Soderblom, A. Bosh, G. Bower, S. Casertano, M. Crenshaw,
A. Gerb, K. Noll, A. Roman, Z. Tsvetanov, and J. Valenti
December 23, 1998
BSTRACT
The focus group on program process and scheduling discussed issues concerning documentation, program preparation software tools, Contact Scientist and Program Coordinator support, and program scheduling. Although the main goal of the group was to prepare for lower cost operations, the discussions centered on maintaining and improving user support. We concluded that there were no steps in the process that can lead to an immediate reduction of personnel. The only place for any immediate savings is in the PC/CS program, but such a move was not sought. We provide below a summary of our discussions, including a list of issues that we think will help streamline efforts in two to three years.
Understanding the observational conditions, instrumental capabilities, and scheduling complexities of HST thoroughly, and providing this information to the user community in a concise, timely, effective, and efficient manner is the goal of user support during Phase I and Phase II. To achieve this we depend on:
1. Documentation,
2. Software tools, and
3. Contact Scientists (CSs) and Program Coordinators (PCs).
For the era of lower cost operations we need to use fewer resources, yet without losing the human aspect of support. This implies greater reliance on documentation and software tools. For this changed nature of user support to be acceptable to the user community, both the documentation and software tools have to be user-friendly, up-to-date, and easily accessible to users of varying levels of expertise. We discuss here the present status and possible improvements of these three topics that will allow us to move towards lower-cost operations.
Most respondents to the User Survey considered documentation to be important, and they also appeared satisfied with what is presently available. However, when users commented on this subject, it was to note that certain specific facts are often hard to track down. That is, it is difficult to locate a definitive answer to a specific question unless the document specifically addressed the
1

Internal Technical Memorandum ITM-1998-07
point. The survey also showed that most users (by far) found information through the STScI web site. The users felt that most of the relevant material is available at the web site, but once again they found that the web site is not well interconnected, which makes searching for information difficult. In the focus group we therefore discussed how documentation and the web site could be improved in the context of reducing user support effort for observatory staff.
First, to improve the ability to find information on the STScI web pages, we need better organization of the web pages, and a concise description as to what is on each page. The pages also need to be up-to-date, and information that is not relevant to a given period or Cycle needs to be properly archived. We also agreed on the need for a good search engine or dynamic indexing of both the web pages and the various handbooks. The present search engine is not effective, and the indexing in the various documents is not comprehensive or complete. At present cross-navigation on our web pages is not very effective, which also makes searching for information frustrating. We recommend that cross-navigation be made more efficient and effective and that a comprehensive effort be put into the overall web presence of the Institute.
Second, at present none of our software tools can access the reference documentation in a userfriendly manner (RPS2 can in a limited sense). Also, most of the handbooks and other documents are written as reference material, making them more accessible to the expert user, but not the novice or one-time user. This situation means that either the user spends a lot of time searching for information, or they contact Institute staff and tie up resources. Information needs to be provided to users with varying levels of detail. Also, most users access information for a limited period of time and only when necessary, therefore access to information has to be easy. The present documentation is not dynamic to accommodate users of varying expertise, nor is it written so that it can be accessed by software tools for context-sensitive help.
To reduce the documentation-writing effort, we need to be able to generate a single reference manual that can be dynamically accessed by a reader and provides the reader with the level of detail that reader needs at that time. The present documentation is not dynamic in this sense. A simple way of solving this problem is to have cookbooks for each mode of operation. But, new technologies, like Java, HTML, and XML, can provide information in a dramatically interactive way, and can accommodate users of varying level of expertise. These new technologies therefore have the potential to improve documentation as well as reduce manual user support. These capabilities need to be investigated and exploited.
Electronic documentation with HTML and/or XML tags will allow sections of the document to be accessed in non-sequential order, and they make context-sensitive help possible. The pages and handbooks will be more dynamic, and support provided by the CSs, PCs, and Help Desk can be made more efficient because information can be accessed in a context-sensitive manner. Also, ease-of-use is an added benefit that will pay back in cleaner programs in the long term.
We note that making any dramatic changes to documentation would require some start-up effort.
Therefore we suggest that interactive documentation be implemented for new software packages and instruments (such as ACS). Assessment after a trial period will indicate whether improved quality and/or reduced workload justify a broader use of interactive documents. Backwards compatibility can be achieved as we need it.
Since users are comfortable using electronic documents, we feel that STScI should drop support for hardcopy documentation (which is often distributed only to libraries and departments), and let
2

Internal Technical Memorandum ITM-1998-07
users print what they need at their home institutions. Doing this helps to ensure that users access the most up-to-date version of a document, and saves resources for STScI. Further, in an era of large and complex datasets, users of HST will need to have machines that are reasonably fast and well connected. For those limited number of users with poor internet connectivity, documentation can be printed on an as-needed basis.
Good program preparation software tools are essential not only because they help decrease the amount of human user support, but also because of the complexity of both instruments and observing programs. The tools provide the GO with freedom to explore the observing parameter space. A good software tool has the following properties:
1. It is easy to use for users of many levels of expertise.
2. It reduces manual support from observatory staff. This implies that the tool decreases the complexity of instruments and processes, provides easy-access and up-to-date reference information, and is flexible and helps guide users towards completion of that process.
3. It allows exploration of the observing parameter space.
4. It allows visualization, and is as interactive as possible.
5. It is esthetically pleasing.
6. It is common for both observatory staff and observer.
With this definition in mind, the focus group considered the Exposure-Time Calculators (ETCs),
RPS2, PC tools, etc. Most of our time was devoted to RPS2, as the group felt that this was the tool where most progress could be made. Many of the recommendation for RPS2 are more in line with improvements that would increase user satisfaction and will result in cleaner programs that will require less rework by the PCs. Hardly any time was spent discussing the ETCs.
Perhaps the most common comment from the survey regarding RPS2 was its speed (or lack of it).
We looked at this question and found that lots of people spend lots of time in fine-tuning the details of each orbit of their program. This is a natural tendency because HST time is at a premium and most GOs want to use their orbits optimally. However, GOs do not always realize that the orbits that they are optimizing are just predictions from models and have limited accuracy. Also, although RPS2 has keywords such as MAX DUR, MIN DUR, and EXPAND, users do not tend to use them because these keywords do not expand exposures in a manner that they find scientifically useful. This problem is compounded by the user’s inability to understand the source of overhead times in a given exposure and their effect on expanding or rearranging the exposures in a visit.
Since the GO is iteratively optimizing the observations, the slowness of RPS2 leaves the GO frustrated.
To increase user satisfaction, the group felt that there needs to be a means of user education on how best to use RPS2 and its various capabilities. Easily accessible cookbooks (preferably provided directly in RPS2) that show best practices, many examples (not only simple ones, but also some complex cases), and that deal with the various modes of observing should be readily available. A “Tips” button in RPS2 would also be very useful. This button could explain in a simple
3

Internal Technical Memorandum ITM-1998-07
way the effect of overheads, the use of the various parameters and keywords, etc., thus allowing the GO to determine if it is worthwhile to go through more iterations. A corollary to the “Tips” button is that, to increase the effectiveness of the exposure-optimizing keywords (MAX DUR,
MIN DUR, EXPAND, etc.), RPS2 developers need to revisit these and to determine how to make them more scientifically useful.
Optimization of the exposures in an orbit is important from a GO’s perspective, hence it was also recommended that the Institute investigate the possibility of optimization at the time of the calendar build, i.e., the group was enthusiastic about the idea of “TRANS on demand.” The dynamic capability that this would afford could lead to very high user satisfaction. This capability would also be ideal for routine calibration monitoring programs, which have hundreds of exposures and take a lot of effort on the part of the instrument teams. We also feel that it is important that the LRP remain stable, and would like STScI to considered making scheduling at 70 as the default in RPS2.
We note that implementing “TRANS on demand” would permit an increase in the schedulability criterion to 70% without loss of observing efficiency. The resulting increase in scheduling windows would help stabilize the LRP, thereby reducing demands on the schedulers. This would automatically also mean that the effort spent in optimization by the GO is not lost.
We also discussed the Transverse project and felt that optimization of software speed in this project should be an important high-level goal. We were surprised to find that speed was not a high-level requirement.
Another concern that was clearly seen in the survey regarding RPS2 was that the error messages are not clear. RPS2 developers noted that errors can arise in many ways and that it was a difficult task to go through each one and correct them. An effort within Presto is being made to treat this issue. One way to get useful information is for GOs to send their thoughts to the developers. At present, if users are confused by the behavior of RPS2 they call their PC, learn how to deal with the situation, but then have no incentive or easy mechanism to provide feedback to RPS2 developers. A button on the RPS2 screen that will allow a GO to automatically capture and send the correct information back to the developers at the time a confusing message arises would be very useful, and will help complete the feedback loop.
Another concern is that the internal processes in RPS2 are not robust and depend on many parameters that an average user cannot effectively feedback to the RPS2 developers when the system crashes. The lack of robustness in RPS2 is a major point that lead to user dissatisfaction. We considered the move towards a Java interface and standard communications software as extremely important move for RPS2. But, irrespective of the interface, since user feedback is difficult to obtain the group once again recommends that RPS2 have an improved self-reporting of the process status. A button on the RPS2 screen that will allow a GO to automatically capture and send the correct information back to the developers when a problem arises would be very useful. The developer can then identify and correct problems in an efficient manner.
There was some discussion on the possibility of GOs doing Guide Star availability checking themselves. We were reminded that adding bell and whistles to RPS2 may affect the speed of the tool.
Still, the group felt that the GO should be made responsible for Guide Star availability issues in
Phase II, just as they are responsible for target coordinates. Adding this capability is also favored by PCs and we urge that it be considered.
4

Internal Technical Memorandum ITM-1998-07
Since orientation of the field-of-view and Guide Star availability are closely linked, we discussed the need for an ORIENT tool. We could not agree that a tool that would provide orientation and
Guide Star information in Phase I for exploratory purpose was necessary. It must be noted here that many of the focus group members already use some kind of an orient tool! From the PC perspective, an orient tool and information on guide star availability would reduce PC effort.
There was discussion of the DOC improvements that are now being planned. These improvements will remove much manual effort by PCs. This reduction in effort is considered very important as it allows PCs to concentrate on developing innovative program implementation ideas. We encourage
STScI to complete the process as soon as possible.
There was discussion of all the proposed changes for the Cycle 8 program review process. We consider these as good and useful moves that will streamline the process. It was noted that most CS effort occurs during the data analysis stage, and there needs to be a way to reduce the number of visitors that come to STScI for data analysis. To achieve this goal, we felt that support via documentation has to be improved. The various possibilities are discussed in the documentation section.
There was discussion on removing CS assignments or having fewer CSs. The group acknowledged that this is a place where major cost savings could be achieved, but the focus group did not advocate any such cutbacks.
We discussed how to get fewer proposals, since the staff effort is proportional to the number of programs that the Institute has to implement. Although the TAC process was not for discussion in our group, we agreed there need to be changes in this process. A possible way of achieving fewer programs is to constrain both the number of orbits and number of programs a panel may allocate.
This implies that the panel will have an incentive to give out more medium programs. This strategy was reasonably effective during the FUSE proposal selection process, for example. The results from the Cycle 8 TAC suggest that this issue is already being addressed.
To improve user satisfaction, GOs should be given insight into the process, and STScI must have a good GO “expectation management” policy at all stages of the program preparation process. The group also felt that if STScI could produce good tools that allow GOs more insight into the program preparation process, it would be possible to move some of the tasks onto the GO community.
The availability of guide stars is one example. An important implication of making GOs more responsible is that STScI has to provide GOs with a much more accurate model of the HST scheduling system. A stable LRP is essential, and the proposed policy changes regarding submission deadlines and resubmissions was considered as a good first step in this direction.
6.1 Documentation:
1. Improve organization of the STScI web pages, with concise descriptions as to what is on each page.
2. Clean and update the web site and make sure that all links work.
3. Improve cross-navigation of the web pages to make them more efficient and effective.
5

Internal Technical Memorandum ITM-1998-07
4. Make the documentation more dynamic.
6.2 RPS2:
1. Make speed a high-level goal of RPS2.
2. Make GOs responsible for guide star availability.
3. Make RPS2 error messages clearer and more specific, and indicate how a user can fix a problem.
4. Develop a self-reporting button so that errors are effectively transmitted to the RPS2 developers.
5. Move towards the Java interface.
6. Provide a “Tips” button in RPS2.
7. Aggressively investigate the possibility of TRANS-on-demand (this is especially important for routine calibration programs).
8. Develop an orient tool, either independently, or as part of other user support tools.
6.3 PC/CS Program:
1. Make DOC a high priority.
2. Determine how to reduce doing the same process a number of times, for example calculate schedulability only once and use it for various tools.
3. Streamline the Phase II program review process further.
6