Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/tof/related/rps2_vision Дата изменения: Wed Apr 14 16:33:58 1999 Дата индексирования: Sat Mar 1 09:00:58 2014 Кодировка: Поисковые слова: http astrokuban.info astrokuban

Vision for RPS2 meeting held on 2/24/99
---------------------------------------
(enhancement/reformatting of Peg's notes)

Present: Rob Douglas, Danny Golombek, Glenn Miller, Anuradha Koratkar,
Dave Soderblom, Andy Gerb, Peg Stanley, Karla Peterson

Start off in brainstorming mode. What would you like to see?

Rob: No files, persistent objects, more interactive, more logical,
more graphical, more integrated, more reactive, search for solutions.

Danny: Integrated, with tools like SEA, blur the Phase 1/Phase 2
boundary, eliminate double work of PI running and then redoing here,
in short term get away from advisories mode, special releases (like
for Ron Gilliland), same look and feel as for data reduction.

Glenn: Sky surveys, catalogs, access to literature, simulates
telescope: images, spectra, communicate operation of telescope to user
without unneeded detail, direct observation - transparency.

Anuradha: Varying levels of expertise but same tool, don't go into all
the details unless you want it, graphical from exploration phase to
submission, no repetition of work for PI in Phase 2, access
information easily: (instrument info, catalogs, examples),
intuitiveness of process, proactivley inform PI about changes in
telescope, incremental availability of information (work on several
things at a time - like partial loading in Netscape).

Dave: Want intuitive solutions (based on what other software does)
like the microsoft office look and feel, Phase 2 instructions is no
longer a document - just help (same with instrument handbooks), RPS2
is not one tool - it is the tool platform

Karla: Fixes available ASAP, seamless installation

Peg: Not just more graphical - fully graphical

Andy: Extensibility of tools to other telescopes, control over
performance - run trans for short time to get a quick answer - a long
time to get the best answer.

Other ideas/comments:

Don't want to focus on speed to the exclusion of reducing iterations

Don't show them time that can't use

How do we make it easier to maintain and test?

Everything comes in ready to execute (AFs already made)

Better to have persistent data

We have too many objects that the users don't understand

Everything in the OO design must be comprehensible to the astro user

Documentation is a large administrative problem, design should relieve
this maintenance nightmare

Steve Beckwith is interested in pushing a cohesive HST system as a
whole. This will require cooperation between Archive, STSDAS, Starview

Is more telescope information inconsistent with hiding telescope from
the observer? We have to provide the relevant information in a way the
user can understand. "Virtual Observatory"

All SIRTF and VLT proposal will be form templates. Even now they use
templates, but there are other proposals. Our official HST templates
are too simple.

MicroSoft model: "it looks like you are writing a letter...."


Then we started to try and summarize and analyze:

List A: Characteristics that we would like to see
--------------------------------------------------

2,3 Enabler Persistent data; no files
1 Fully graphical, no forms and menus
1 Fully interactive and reactive to changes
1 Integrated into Planning Tool
1 Tool available for Phase I
2,3 Objective Get away from Advisories Mode
2,3 R,S Objective Release flexibility
1 Simulation incl. Simulated data
1 Improved observatory operations description
2,3 S Objective Provides for varying levels of expertise
(incl. Users and operations)
1 Fully integrated with data analysis
1 Intuitive, consistency
3 S Result Intuitive process
2,3 S Enabler Invisible installation
3 R,S Objective Documentation only as help
1 Exploration interface available
2,3 R,S Enabler Extensible design
2,3 S Enabler Platform independence
3 Enabler Give control over performance
3 Enabler Incremental availability of information (when
visit 1 done you see results; visit 2 still processing)
1 Transparency of system including observatory
3 S Objective Recognizes impact of Observatory Changes
3 Objective Produces zero defect flight "prepped" visits
2,3 Enabler Everything in design must be comprehensible to
Astronomical User
1 Create a virtual observatory

Key:
----
1: Virtual Observatory
2: Maintainability
3: Usability

R: RPS2
S: SEA


What do we already have?
------------------------

RPS2: works operationally, PED (100 screens), DOC (non-HST specific),
NGSS (without connectivity), Visit Status Page, Trans, 1/4 Transverse,
CASM, SPIKE, Export SPIKE, Plan Window SPIKE, Display Generator,
Syntax Table, MOSS, Context Sensitive help

SEA: VTT, ETCs, Interview Mode, Browser Mode, Access to DataBases,
Access to Instrument info


List B: Ideas for Cycle 9
-------------------------

Integration of documentation/Help online
Orientation Guidance
Flexible Release or Specialized RPS2 releases
Reduce RPS2 iterations
Remove parsing problems
Standard description of objects
Click & drag exposures
"you're done" message
Get rid of PED - create alternative
TCL 8.0 conversion - speed
Stay around DG - speed
PED writes PP products - speed
Graphical interaction with preparation process
NGSS/RPS2 interface
MOSS/RPS2 interface
More robust, extensible, easier controller for RPS2
Special requirements for better orbit packing
Eliminate need to add special requirements
More accurate average orbit model (SAA accuracy)
Visit status through RPS2


Two action items were assigned:

(1) Andy and Rob: Work with SST and other Presto members to a
address the items on List B for assessment of cost and benefit, what
else they enable, etc..

(2) Anuradha and Dave: Develop an ITM addressing describing our "ideal"
user interface package from list A below.