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

From owner-tof-limited@stsci.edu Wed Jun 2 07:59 EDT 1999
To: tof-limited@stsci.edu
Subject: What should/shouldn't be included in our tool?


In response to Nick's demo, I've gone through the comprehensive lists
of ideas and goals and off the top of my head, divided each of the
items into one of five categories:

1. Items I think we should be sure to address in our report, that are
not currently evident in Nick's demo. (Denoted by a "MustInclude")

2. Candidates for inclusion in our report as possible add-ons or
growth path. (Denoted by a "PossiblyInclude")

3. Items I'm not sure about. (Denoted by a "NotSure)

4. Items that, in my opinion, should remain beyond our scope. (Denoted
by a "LeaveAlone")

5. Items currently included in Nick's demo. We should be sure and retain
these. (Denoted by a "AlreadyIncluded")

The five lists are attached first. After them, I attach the compendium
of ideas and goals, correlating each one to one of the items.

I hope this will lead to a discussion of exactly what items we should
include/exclude in our tools' functionality.

Andy G

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

THE FIVE LISTS
--- ---- -----

1. Items we should be sure to address in our report, that are not
currently evident in Nick's demo.

1.1. How will our tool integrate with HST user documentation? What
characteristics (e.g. format, internet availability) are needed for
our documentation to support integration? How will we share data with
the documentation system?

I'm inclined to finesse the entire issue of the documentation itself
in our group. Steve Hulbert has formed a committee to address this and
I don't think we need to duplicate their efforts. It looks like Dave
S. and Jim Y. will be our connection to that group.

***However***, this doesn't mean we should omit all discussion of
documentation in our report. I'd suggest we need the following:

- A discussion of how our tool will allow automated access to the
documentation. What entry points will we want in the documentation?
What types of actions in our tool will get us to those entry points?

- What attributes (e.g. format, internet availability) does the
documentation need to have to be available to the users of our tools?
This might be turn out to be a way to highlight our insistence that
our documentation adopt an XML organization.

1.2. How could users exploit a subset of our tools for Phase I
exploration?

We should, in our report, explore how users could easily exploit a
subset of our tool's capabilities for their phase 1 explorations. If
this isn't obvious, we should rethink our design. I claim designing
for ease of use implies providing layers of increasing complexity and
detail.

1.3. We need to include ETC tools as part of our demo. We should
include details of our interaction with SYNPHOT.

1.4. I believe we need a tool that provides instantaneous
schedulability feedback.

1.5. I believe we need a tool that lays out the orbit and allows
observers to adjust exposure times and see the result of their
adjustment instantaneously on the orbit packing.

1.6. We should mention and demo our capability of connecting to a
variety of catalogs and the ease of adding a new catalog.

1.7. We should mention a strategy for installation and providing
updates. There seems to be some interest in doing better than we do
now, so we should include some ideas and an intention to research
them. Possibilities include informing observers of updates and changes
and tagging data so that relevant updates can be identified.

Automatically updating is not as simple as its advocates make it out
to be. The technology's easy, but the implications are not. I don't
think it should be automatic (funny, this observation was fine
yesterday, but this %$# &@@*%# tool doesn't like it today...) Would we
want a window to pop up and say "the following changes have become
available since your last update do you want a new version?" Worth
discussing.

1.8. We should talk about how we would offer this to other
missions. E.g. should we adopt an open source model?

1.9. We should explicitly note that all objects are observatory
specific subclasses of observatory independent objects. I.e. It's easy
to customize for other observatories. We also want our tools to be
interoperable with tools from other observatories that don't choose
our design.

1.10. We should make a point of adding a "feedback" button which sends
suggestions and gripes back to us. Also automatically sends crashes or
software problems.

1.11. We need to consider portability in our report.

1.12. We should make clear that storage of information (i.e. saved
proposal) is at the local site.

2. Candidates for inclusion in our report as possible add-ons or
growth path.

2.1. Data mining and search capabilities for online information.

2.2. Upgrades to the VTT to do guide star availability, offset
patterns, target coordinated measurement, bad pixel information, IRAF
connection and spectral lines, grisms and coronography.

2.3. Bright object checking made available to observers.

We should wait and see for this one. Let's see how big a problem it
is when the guide star availability issues begin to be addressed. We
should certainly note it as a growth path.

2.4. Automated duplication checking made available to observers.

2.5. Tag data with a pedigree which tells where it comes from.

2.6. Support for "what-if" exploration capabilities.

I never understood what the big deal is here. Isn't this as simple as
a Save As/Revert capability?

2.7. Connection to baseline data at STScI for status checking.

This comes up frequently but always seems to get third priority.
Someone asks for it, but when we actually get down to implementing it,
no compelling justification is ever found for the effort. How useful
would this be?

2.8. Input tools allow specification for what observer really intends
(e.g. wavelength range, S/N, target name, timing)

2.9. Ability to customize an already existing proposal or completed
observation.

2.10. Ability to obtain analysis on partially specified observations.

2.11. Allow more visibility into how decisions such as overhead times,
schedulability and optimization are made.

2.12. User tools feed scheduling system with .af's, .tic's etc.

3. Items I'm not sure about

3.1. Uniform look and feel across all STScI user software.

This is going to get more important as time goes on. I'm torn about
this. On the one hand, this is a daunting task and if we make it a
critical design goal, that greatly ups the probability of failure. On
the other hand the institute would like to move in this direction.

3.2. Data simulators for S/N analysis.

I have to confess, I'm not sure what a data simulator is.

3.3. System automatically alerts program coordinators when a problem
is encountered.

On one hand, help comes before you even ask for it. On the other, I'd
feel reluctant to explore if I felt a wrong answer would interrupt a
human being.

4. Items that, in my opinion, should remain beyond our scope

4.1. Prefabricated science and acquisition strategies.

4.2. Give information to the observer to remove *all* sources of
manual rework.

We're chiefly handling the tall poles in our proposal. As long as
SOGS remains monolithic, non-portable and opaque to observers, I think
it will be hard to achieve perfection here.

4.3. Guided help dependent on answers to questions already asked.

4.4. Trans-on-demand

Trans-on-demand remains elusive. We've failed to make a case for it in
the past, and I see it as too risky without well-understood benefit to
tie the success of our work to it.

4.5. Long Range Planning and Short Term Scheduling available to
observers.

We're not ready for this yet.

4.6. System accumulates intelligence, gets better the more it's used.

4.7. Hard proposals "announce" themselves.

To my seeing, this appears to orthogonal to the development tool -
we could do it just as easily in today's system.

5. Items currently included in Nick's demo. We should be sure and
retain these.

5.1. We will provide a scientific advisor at each stage of
development. Provide "wizard" style help for navigating dialogs.

5.2. The proposal structure will be more open ended than today's
model.

5.3. Tool choose targets from existing catalogs rather than
copying them by hand.

5.4. All proposal data will be represented graphically.

5.5. Inclusion of the VTT

5.6. Cut and paste capabilities wherever it makes sense.

5.7. Access to archives supported.

5.8. Our operations concept still includes the existence of expert
Program Coordinators who will help deal with operationally challenging
proposals and for cases where a small amount of human interaction will
avoid large headaches in learning to use our tools.

5.9. The user will be able to direct a search of optimal solutions.

5.10. The system developers a model of the user. Less experienced
users are treated differently from more experienced users.

5.11. The look and feel will be consistent with well known
tools. (What tools?)

5.12. The interfaces we present will intuitively reflect models and
manipulations of the objects involved.

5.13. We retain the ability to modify proposal information directly.

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

MARKED UP COMPILATION:

>Date: Wed, 21 Apr 1999 14:40:55 -0400 (EDT)
>From: Andy Gerb
>To: tof-limited@stsci.edu
>Subject: My compiled list
>Sender: owner-tof-limited@stsci.edu
>Precedence: bulk
>Content-Type: text
>Content-Length: 7388


>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 (MustInclude 1.1)

>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. (MustInclude 1.2)

>o Provide a "scientific advisor" similar to the SEA's interview
mode. (MustInclude 5.1)

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

>o Allow a more open ended proposal structure to facilitate
>exploration. (AlreadyIncluded 5.2)

>OBSERVATION PREPARATION

>o Ability to choose targets from existing catalogs rather than copy
>parameters or type them up by scratch. (AlreadyIncluded 5.3)

>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. (AlreadyIncluded 5.4)

>o Ability to connect to SYNPHOT to provide observatory simulation
>during exposure time calculation. (MustInclude 1.3)

>o A visual tool similar the the SEA ETCs to allow selection of an
>observation's scientific parameters. (MustInclude 1.3)

>o A visual tool similar to the SEA VTT to allow visualization of
>pointing, orientation and guide stars. (AlreadyIncluded 5.5)

>o A visualization tool for offset patterns, possibly as part of the
>VTT. (AlreadyIncluded 2.2)

>o Automated target coordinate measurement, possibly as part of the
>VTT. (AlreadyIncluded 2.2)

>o Bad pixel information in the VTT. (AlreadyIncluded 2.2)

>o IRAF functions in the VTT. (AlreadyIncluded 2.2)

>o Spectral lines, grisms & coronography in the VTT. (AlreadyIncluded 2.2)

>o Tool which provides availability of shadow and CVZ. (MustInclude 1.4)

>o Bright object check available to observers. (PossiblyInclude 2.3)

>o Incorporate duplication checking tool. (PossiblyInclude 2.4)

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

>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. (MustInclude 1.6)

>o Tag data with a "pedigree" that records its source. (PossiblyInclude 2.5)

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

>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. (PossiblyInclude 2.6)

>o Prefabricated scientific and acquisition strategies which users
>could import. (LeaveAlone 4.1)

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

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

>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. (AlreadyIncluded 5.7)

>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. (LeaveAlone 4.2)

>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. (AlreadyIncluded 5.8)

>o Instantaneous update of computable information such as overhead
>times and creation of support activities. (MustInclude 1.5)

>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. (AlreadyIncluded 1.9)

>o User directable search for optimizable or difficult to satisfy
>criteria. (AlreadyIncluded 5.9)

>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. (AlreadyIncluded 5.10)

>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. (AlreadyIncluded 5.1)

>o System can avoid questions that are not appropriate based on answers
>to previous questions. (LeaveAlone 4.3)

>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. (MustInclude 1.7)

>o Uniform look and feel across all STScI observer interfaces. (NotSure 3.1)

>o Need an easy way of entering improvement suggestions to the
system. (MustInclude 1.10)

>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. (LeaveAlone 2.12)

>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. (LeaveAlone 4.4)

>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. (LeaveAlone 4.5)

>o System accumulates intelligence by experience. It gives better
>advice each time a problem is encountered. (LeaveAlone 4.6)

>o Hard proposals should "announce themselves" when being entered or
>when operational changes make reprocessing necessary. (LeaveAlone 4.7)

>DATA ANALYSIS

>o Data simulators for signal-to-noise analysis. (NotSure 3.2)

>SOFTWARE ARCHITECTURE AND MAINTENANCE

>o Use an open-source model to allow other observatories to adopt our
>code and customize it. (MustInclude 1.8)

>o Merge human readable and machine readable data. (MustInclude 1.1)

>----------------------------------------------------------------------
>Date: Thu, 22 Apr 1999 15:27:02 -0400 (EDT)
>From: peterson@stsci.edu (Karla Peterson)
>To: tof-limited@stsci.edu
>Subject: my list of ideas on the table
>Sender: owner-tof-limited@stsci.edu
>Precedence: bulk
>Content-Type: text
>Content-Length: 4688

>In case you would like an electronic copy.

>- Karla

>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 (MustInclude 1.11)
> easy to install (MustInclude 1.7)

>Easy to learn system:

> objects in system meaningful to astronomer (AlreadyIncluded 5.10), v (4.2)
> astronomer specifies what he really needs
> (e.g. wavelength range, S/N, target name, timing) (PossiblyInclude 2.8)
> all tools should have consistent terminology and "look and feel" (NotSure 3.1)
> consistent with other observatories (MustInclude 1.9)
> consistent with other well known software (AlreadyIncluded 5.11)
> intuitive (AlreadyIncluded 5.12)

>Easy to transition between stages:

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

>Easy to do first draft:

> start with example/template proposals (PossiblyInclude 2.9)
> first draft by analogy to existing proposal (PossiblyInclude 2.9)

>Easy to know what to do:

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

>Easy to get at and store needed reference material:

> data in archives (AlreadyIncluded 5.7)
> catalogs (for target coordinates) (AlreadyIncluded 5.3)
> papers (PossiblyInclude 2.1)
> annotated example/template proposals (LeaveAlone 4.1)
> existing proposals (first draft by analogy) (PossiblyInclude 2.9)
> store should be local to user (MustInclude 1.12)
> source of data goes with data even into proposal (PossiblyInclude 2.5)

>Easy to understand feedback and tradeoffs:

> graphical presentation when appropriate (AlreadyIncluded 5.12)
> (e.g. FOV against sky image to feedback or select
> position, orient, patterns)
> impact of choices should be apparent (MustInclude 1.5, 1.6)
> reason for choice can be stored for user or Institute (PossiblyInclude 2.8)
> only reveal level of complexity needed (MustInclude 1.2)
> system understands ability of the user (AlreadyIncluded 5.10)
> not just diagnostics - suggest fixes (AlreadyIncluded 5.1)
> (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 (MustInclude 1.10)

>Easy to query system:

> allows exploration (what-if mode) with undo feature (PossiblyInclude 2.6)
> allows questions without full proposal, like: (PossiblyInclude 2.10)
> 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 (MustInclude 1.1)
> documentation kept up to date (MustInclude 1.1,1.7)
> integrated documentation accessible to tools and humans (MustInclude 1.1)
> good search mechanism (natural language) (MustInclude 1.1)
> search mechanism should have automatic feedback loop (MustInclude 1.10)
> (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 (NotSure 3.2)
> human help available if needed (AlreadyIncluded 5.8)
> proactive human help when appropriate (system alerts PC) (NotSure 3.3)

>Easy to do the job right the first time:

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

>Easy to handle change:

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

>Rapid feedback:

> information available as it is created (not batched) (MustInclude 1.4,1.5)

>Ability to control performance:

> determine depth of search (AlreadyIncluded 5.9)

>Easy to get proposals to the telescope:

> clean proposals "roll down hill" to scheduling
> shorten pipeline to telescope (LeaveAlone 4.2,2.12,4.5)

>Easy to trouble shoot:

> button to collect and send trouble shooting information to
> developers and/or PC (MustInclude 1.10)

>Easy to maintain:

> system captures expert knowledge (AlreadyIncluded 5.1)
> system kept up to date without the user having to do anything (MustInclude 1.7)

>Easy to add to and share:

> tools should be exportable to other observatories (MustInclude 1.9)
> data should be open to other observatories for planning campaigns (AlreadyIncluded 5.7)
> tools from other observatories should be interoperable (MustInclude 1.9)
> open architecture or even open source (MustInclude 1.8)
> extensible design (MustInclude 1.9), (AlreadyIncluded 5.2)

>Easy to query:

> queries build themselves from simple questions (NotSure what this means)
> data about source of information that comes with proposal should
> be queriable (PossiblyInclude 2.5)
>----------------------------------------------------------------------

>Date: Fri, 30 Apr 1999 15:24:12 -0400 (EDT)
>From: peterson@stsci.edu (Karla Peterson)
>To: tof-limited@stsci.edu
>Subject: 4/29 brain storming - for limited distribution only
>Sender: owner-tof-limited@stsci.edu
>Precedence: bulk
>Content-Type: text
>Content-Length: 10222

>Brain storming session from 4/29/99 TOF meeting
>-----------------------------------------------

>.
>.
>.

>Summary of concepts:
>--------------------

>1) Integrated visualization tool is an excellent idea. (MustInclude 1.3), (AlreadyIncluded 5.5)

>2) Integrated single exposure time calculator would be useful in both
>Phase 1 and 2. (MustInclude 1.3)

>3) Don't make PIs do a full Phase 2 in Phase 1. (MustInclude 1.2)

>4) Don't let Phase 1 needs drive Phase 2 tool design, but if the Phase
>2 tool had Phase 1 utility that's a plus. (MustInclude 1.2)

>5) Give the PIs all the scheduling constraints, they want the bad news
>up front while they are still working on the proposal. (PossiblyInclude 2.2-2.4), (LeaveAlone 4.2)

>6) Allow PI visibility into system - black boxes are hard to trust. (PossiblyInclude 2.11)

>7) Don't make PI iterate or ask PC to answer standard questions. (A combo of a bunch of these)

>8) Integrating the documentation with the software should be explored. (MustInclude 1.1)