Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/tof/tof_minutes/06-17-99_brainstorming Дата изменения: Fri Jun 18 19:36:07 1999 Дата индексирования: Sat Mar 1 16:34:27 2014 Кодировка: Поисковые слова: arp 220

Brain storming session from 6/17/99 TOF meeting
-----------------------------------------------

Here is the outline for the paper/presentation that we came up
with:

1) Why are we doing this, and why now?

a) First we had RPSS.

b) Then in 1994 we changed to RPS2.
This gave the user more access to operational information.

c) It's time for the next big step because:
The architecture designed quickly for RPS2 is really
at it's limit and we have farther reaching goals now
Many subsystems are (or are becoming) more capable and we
want to take advantage of this: TransVerse,DOC,NGSS
New enabling technologies are becoming available

2) What is the next big step?

a) Provide users with more functionality:

more information, more feedback, more insight, more views

b) Improve the existing functionality:

an interface that is interactive, dynamic, graphical,
intuitive, extensible, easy to install, platform independant
and fast

c) Improve the quality of the submitted proposals
(and therefore free internal support staff from repetative
trouble shooting)

3) What would this look like?

a) SEA demos (VTT, ETC, Exposure Dinker)

b) Screen mock ups.

4) What is the implementation strategy?

One lesson from the development of RPS2 was that a hard
early deadline forced design compromises and a release
with little feedback from the community. So we
propose a three stage process:

a) Early stand alone tools released incrementally

o Gives functionality early
o People can use them if they want
o We get feedback
o Community learns new things at a reasonable pace

b) New environment released with tools integrated

c) Additional capabilities added to new environment

5) Cost

This section needs to say want other groups at the
Institute we will need to coordinate with.

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

We talked about the two items from Andy's list that we didn't
understand last week:

The prop structure will be more open ended than today's model (5.2)

This was a goal that Danny had suggested. It means that
observations should not have to be rigidly entered using a
particular structure. Two examples: You don't enter
a specific literal syntax to link two visits - make it
and review it graphically. And Nick's concept of
specifying an exposure by what you want to get for S/N.

Interfaces we present will intuitively reflect models and
manipulations of the objects involved (5.12)

This means that when designing the graphical interfaces
the developers should strive for graphical representations
of data that are intuitive for an astronomer.

These concepts are similar let's put them together under B1.

Andy asked about our banishing the item about PC support to the "don't
mention" section. In the end we decided that the text should address
the role of the PC (maybe in the motivation section), but that it
shouldn't appear to be a goal of the system by being listed with other
goals.

We discussed having the tool be able to tell us how it is being used
so we get feedback. We decided not to mention this in the report, but
it should be considered in the design.

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

We went through the prioritization that Roeland sent around and
changed the priorities on a few items. I have attached a modified
version below:

----------------------------------------------------------------------
A. Release quickly; stand-alone, before complete tool.
----------------------------------------------------------------------

When appropriate these and other tools should be able to be run
independently from the Phase 2 process so they can be used to answer
questions - like in Phase 1.

* VTT with access to datasets in archives (5.5+5.7) | 1
|
* Guide star checking (2.2) | 1
|
--------------------

* ETC (1.3) | 2
|
* Phase 1 resource estimator based on Proposal Instructions | 2
|
* Bright object checking (2.3) | 2
|
--------------------

* Access to target coordinate catalogs and lists (1.6+5.3) | 3


----------------------------------------------------------------------
B. First release of complete Tool of the Future
----------------------------------------------------------------------

* Multiple views (ASCII, Table, Graphical) available | 1
for viewing as well as modifying (5.4+5.13) |
|
* There should be "wizards" where possible (5.1) | 1
|
* There should be some canned strategies (4.1) | 1
|
* Graphical exposure time dinker with access to overheads (1.5) | 1
|
* Instantaneous scheduling feedback (1.4) | 1
|
* Traditional graphical manipulation conventions | 1
- like cut and paste (5.6+5.11) |
|
* Consistent graphical conventions across all tools | 1
|
* Ease of installation (1.7) | 1
|
* Explore how user gets software updates (1.11) | 1
|
* Maximize portability (1.7) | 1
|
* Make as mission independent as possible (1.9) | 1
|
* Tight interface between software and documentation (1.1) | 1
|
* Access to execution status information from STScI (2.7) | 1
|
* Information can be entered in a graphical mode where | 1
representations are intuitive for an astronomer (5.2+5.12) |

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

* Ability to made and edit exposure groups | 2
|
* Wizards should be be tunable (lots of help, little help) | 2
|
* Exposure layout optimizer w/ visibility into reasons (5.9+2.11)| 2


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

* Automated data pedigree (2.5) | 3
where coordinates came from |
what software version produced an exposure time |


----------------------------------------------------------------------
C. Later extensions of Tool of the Future
----------------------------------------------------------------------

* Add ons to VTT (2.2) | 1

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

* Access to synphot (1.3) | 2
|
* Data mining (2.1) | 2
|
* Can import another proposal as a starting point (2.9) | 2
Including example proposals (4.1) |
|
* Open source (1.8) | 2

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

* Capture the "why" when appropriate (2.8) | 3
|
* Duplication checking (2.4) | 3
|
* Software learns over time (4.6) | 3

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



We should also maintain the list of things that we think are good
ideas to keep in mind for the design, but do not seem to be
appropriate for the list of ideas we use to sell the project.

Feedback button (1.10)

Store all data locally (1.12)

What-if capability (2.6)

Ability to obtain analysis on partially specified obs (2.10)

Uniform look and feel at Institute (3.1)

Have tool report back how it was used so we can plan improvements