Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/tof/tof_minutes/04-21-99_andy_list Дата изменения: Fri Jun 11 00:57:52 1999 Дата индексирования: Sat Mar 1 14:35:53 2014 Кодировка: Поисковые слова: http astrokuban.info astrokuban

From owner-tof-limited@stsci.edu Wed Apr 21 14:41 EDT 1999
To: tof-limited@stsci.edu
Subject: My compiled list


I've put together my "comprehensive" list of ideas from all the
written material posted on the web page, including Jeremy's future SEA
ideas which have not been posted yet. I've taken liberties in
combining items that seemed remotely like each other, since a lot of
ideas showed up in many different places. Other team members can work
from my list or compile complete lists of their own. Our hope is that
by the time we hold our user brainstorming session, we'll have a list
of ideas they can start from.

Andy G

----------------------------------------------------------------------

ANDY'S COMPREHENSIVE LIST OF PROPOSAL PREPARATION SYSTEM IDEAS
------ ------------- ---- -- -------- ----------- ------ -----

DOCUMENTATION

o Single source of information completely online in a homogeneous
format.

o Automated user-configurable notification of system changes.

o "Ask Jeeves" style natural language search for information.

o A feedback loop that allows us to upgrade availability when the user
search in vain for information.

o "Proactive help" when the system knows something about the path the
user has chosen, esp. if the user is lost or has made a mistake.

o A human should be readily available at all times for consultation. A
small amount of human assistance early can save the user a lot of
time.

o Dynamically built documentation.

SCIENTIFIC PROPOSAL

o Blur the boundaries between phase 1 and phase 2. Phase 1 tools
should not be separate and distinct from phase 2 tools, though less
detail may be required and less accuracy acceptable.

o Provide a "scientific advisor" similar to the SEA's interview mode

o Provide greater data mining capabilities to search catalogs with
sophisticated queries over any property. Queries should span multiple
catalogs.

o Allow a more open ended proposal structure to facilitate
exploration.

OBSERVATION PREPARATION

o Ability to choose targets from existing catalogs rather than copy
parameters or type them up by scratch.

o Complete elimination of the need for an observer (or operations
specialist) to view proposals in an input format like today's RPS2
proposal file. All proposal data is input and presented graphically.
An implication of this is that all special requirements go away and
are replaced by a graphical representation of themselves.

o Ability to connect to SYNPHOT to provide observatory simulation
during exposure time calculation.

o A visual tool similar the the SEA ETCs to allow selection of an
observation's scientific parameters.

o A visual tool similar to the SEA VTT to allow visualization of
pointing, orientation and guide stars.

o A visualization tool for offset patterns, possibly as part of the
VTT.

o Automated target coordinate measurement, possibly as part of the
VTT.

o Bad pixel information in the VTT

o IRAF functions in the VTT

o Spectral lines, grisms & coronography in the VTT

o Tool which provides availability of shadow and CVZ.

o Bright object check available to observers

o Incorporate duplication checking tool

o An Exposure Planner, which allows the observer to graphically
specify constraints between exposures and visualize how exposures are
organized into orbits.

o A Target Selector, which provides a common Java interface for
searching catalogs for object information. New catalogs can be added
without changing existing code.

o Tag data with a "pedigree" that records its source.

o We may want to preserve some of the data manipulation capabilities
of PED. I.e. cutting, pasting, reordering, copying, etc.

o We may also want a "what-if" capability, where multiple versions of
a proposal are manipulated by a user to determine which are the most
desirable. Something like this exists in today's RPS2. We should
probably retain it.

o Prefabricated scientific and acquisition strategies which users
could import.

o Connection to a central repository which would automatically make
the latest observatory operating parameters and software accessable to
a user.

o Connection to observation status information allows the user to
perform functionality currently required of operations
specialists. E.g. dealing with frozen visits.

o Proposal preparation software gives the observer access to all
publically available archives and target catalogs regardless of their
format. This should support a "do like they did" capability.

o All known causes of requiring manual rework are detected during
observation preparation and explainable to users. Correction advice is
available sufficient to allow the user to solve the problem without
contacting an operations specialist.

o However, operations specialists should be available to users when
they need them with no obstacles. This is a paradox of user
support. The more user support is available, the less it is needed,
because early questions are not deferred and users are sent in the
right direction.

o Instantaneous update of computable information such as overhead
times and creation of support activities.

o All subsystems should be interoperable transparently to the
user. All objects should be observatory specific subclasses of
non-observatory specific objects. Another possibility is to use XML
standards.

o User directable search for optimizable or difficult to satisfy
criteria.

o System develops a model of the user. More knowledgeable users are
give more details of the problem whereas less knowledgeable users are
given more advice.

o System can give you a choice of doing it yourself or providing a
"wizard" to do it for you by handling some of the more commonly
defaulted options.

o System can avoid questions that are not appropriate based on answers
to previous questions.

o Installation should be trivial. Connecting to a web site should be
sufficient to install the software at the user's location and allow
manipulation of local files there.

o Uniform look and feel across all STScI observer interfaces.

o Need an easy way of entering improvement suggestions to the system.

OBSERVATION IMPLEMENTATION

o User accessable tools produce all output needed to feed the
scheduling system. In today's reality these are assignment files, .adf
files and .tic files. Submissions arrive ready for automatic entry
into the scheduling system for LRP or STS. There also will probably a
data file, not intended for direct reading by users, which contains
proposal information.

o A Trans-on-demand style adjustment capability of observation
parameters as more is known about the exact conditions under which
they are scheduled. The observations themselves may need to contain
more information to support this. E.g. allowable ranges instead of
hard and fast values.

o Ability for observers to effect long term or short term scheduling
without intervention by operations specialists. Can this be done? Who
knows. One way might be to allow them to "sign up" for time. This may
be beyond the the scope of our project.

o System accumulates intelligence by experience. It gives better
advice each time a problem is encountered.

o Hard proposals should "announce themselves" when being entered or
when operational changes make reprocessing necessary.

DATA ANALYSIS

o Data simulators for signal-to-noise analysis.

SOFTWARE ARCHITECTURE AND MAINTENANCE

o Use an open-source model to allow other observatories to adopt our
code and customize it.

o Merge human readable and machine readable data.