Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/tof/tof_minutes/04-21-99_karla_list Дата изменения: Fri Jun 11 00:59:00 1999 Дата индексирования: Sat Mar 1 15:03:40 2014 Кодировка: Поисковые слова: meteor shower

From owner-tof-limited@stsci.edu Thu Apr 22 15:27 EDT 1999
To: tof-limited@stsci.edu
Subject: my list of ideas on the table

Karla's List of Proposal Preparation ideas
------------------------------------------

The overarching goals of our tool environment:

ease of preparation, comprehensible & timely feedback
minimal "surprise" problems found at the Institute
most proposals prep themselves
human help available when software or documentation fails
tight feedback loop between reported problem and system change

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

Break down of individual goals and suggestions for meeting them:


Easy to get access to the software:

platform independence
easy to install

Easy to learn system:

objects in system meaningful to astronomer
astronomer specifies what he really needs
(e.g. wavelength range, S/N, target name, timing)
all tools should have consistent terminology and "look and feel"
consistent with other observatories
consistent with other well known software
intuitive

Easy to transition between stages:

interoperability between all Institute tools
no rework between various stages (e.g. Phase 1 -> Phase 2)
one interface to all the Institute tools

Easy to do first draft:

start with example/template proposals
first draft by analogy to existing proposal

Easy to know what to do:

guided (wizard) approach overall
guided approach for individual tasks
(e.g. acquisition, measuring coordinates from DSS,
measuring coordinates from HST image)
traditional specification still possible
anticipates questions
suggests improvements
(e.g. if you reorder exposures you can save time)

Easy to get at and store needed reference material:

data in archives
catalogs (for target coordinates)
papers
annotated example/template proposals
existing proposals (first draft by analogy)
store should be local to user
source of data goes with data even into proposal

Easy to understand feedback and tradeoffs:

graphical presentation when appropriate
(e.g. FOV against sky image to feedback or select
position, orient, patterns)
impact of choices should be apparent
reason for choice can be stored for user or Institute
only reveal level of complexity needed
system understands ability of the user
not just diagnostics - suggest fixes
(e.g. opening orient to 180-185 will yield guide stars)
have feedback loop - pis can easily inform us of graphs, tables,
or diagnostics that are cryptic so they can be improved

Easy to query system:

allows exploration (what-if mode) with undo feature
allows questions without full proposal, like:
when is this pointing in CVZ?
how much dark time can I get in May for this pointing?
how long is the SAA for this instrument?
how will my phase beat against the SAA?
why is this the default?

Easy to get answers to questions:

all needed documentation available in one place
documentation kept up to date
integrated documentation accessible to tools and humans
good search mechanism (natural language)
search mechanism should have automatic feedback loop
(e.g. user can tell the system what it had a
problem finding and the mechanism can add that)
simulated data can be easily generated
human help available if needed
proactive human help when appropriate (system alerts PC)

Easy to do the job right the first time:

all problems in proposal reported so they can be fixed
all constraints and checks available
(e.g. gs, mt, finder charts, duplication, bright objects)
most up to date software always available

Easy to handle change:

changes in observatory (new instruments, restrictions) which
affect proposals will be automatically reported to the PI
version of software used to create value tagged so notification
of update can be made (e.g. exposure time from ETC)

Rapid feedback:

information available as it is created (not batched)

Ability to control performance:

determine depth of search

Easy to get proposals to the telescope:

clean proposals "roll down hill" to scheduling
shorten pipeline to telescope

Easy to trouble shoot:

button to collect and send trouble shooting information to
developers and/or PC

Easy to maintain:

system captures expert knowledge
system kept up to date without the user having to do anything

Easy to add to and share:

tools should be exportable to other observatories
data should be open to other observatories for planning campaigns
tools from other observatories should be interoperable
open architecture or even open source
extensible design

Easy to query:

queries build themselves from simple questions
data about source of information that comes with proposal should
be queriable