Документ взят из кэша поисковой машины. Адрес оригинального документа : http://www.stsci.edu/ops/tof/tof_minutes/04-15-99_brainstorming Дата изменения: Tue Apr 27 18:10:58 1999 Дата индексирования: Sat Mar 1 16:34:12 2014 Кодировка: Поисковые слова: storm

Brain storming session from 4/15/99 TOF meeting
-----------------------------------------------

[The upper case regions are the pithy phrases that summarize key
ideas. Let me know how I did - is this a reasonable way to record a
brain storming session? Please let me know if I've lost or mangled
your idea. - Karla]

Goal for this brain storming session:

Imagine you know nothing about the HST proposal flow, ground
system, preparation tools, SEA etc. Instead you are starting
an observatory (or more than one) from scratch. What kind of
processes, tools, etc. would you provide to prepare and process
observations?

We should answer the question, "What will our process be?" and "What
will our culture be?" instead of merely asking "What will our tools
be?".

We want to encourage sharing of tools between observatories.
INTEROPERABILITY should be a goal.

Andy likes the Linux model (OPEN SOURCE) - give out the code for free
and ask people to give you their upgrades so they can be incorporated
in the main system. This has produced a reliable system with high
functionality.

Nick wants the DOCUMENTATION AVAILABLE FROM ONE PLACE. No versions -
changes are right there once they are made. The software also should
be like this. New functionality and bug fixes should be available as
soon as it is ready.

Nick also suggests that the documentation contain a FEEDBACK LOOP on
the search engine. This way the user can give us feedback on whether
they found what they needed.

Andy mentioned a search engine called "ask jeeves" (www.ask.com). It
has a NATURAL LANGUAGE FRONT END that allows you to ask a question and
it tries to find web pages that answers your question. He said that it
rarely answered his questions appropriately, but was fun to play with.

This reminded Nick of a program that his professor had in college. It
was supposed to be able to ask you questions and from the responses
tell you what animal you are thinking of. But if it couldn't get it,
it would ask you to enter a question that would help it get that
answer in the future. So it learned as people used it. (ADAPTIVE
SOFTWARE - learns as it makes mistakes - just like people!)

The system should be INTUITIVE to use and/or query.

Anuradha thinks the user should have ACCESS TO ASTRONOMICAL
INFORMATION which is on line: both data in archives and the
literature. We should be interoperable with our mission's archives and
all the other archives. The user should be able to create their own
local "file folder" of data and literature that have found with the
tool and want to keep around.

Nick thinks that the user should be able to tell the system, "Hey I
would like to do what PI X did in proposal YYYY except on this other
target." So all the user would have to do is retrieve information
about the other target and the system would recompute all the exposure
times to give the user the same S/N that the other PI had. (FIRST
DRAFT BY ANALOGY)

So what view into our observatory do we want to give the PI? There are
two extremes: "Every screw is visible to the PI" versus "Only talk to
the PI about science things". The ideal would be only give the PI
information that is needed. The SYSTEM SHOULD UNDERSTAND THE ABILITY
OF THE USER and give them what they need. Just like a PC does.
Sometimes the PCs head off questions by anticipating what the next
question will be based on experience. The system should be able to do
this too.

Anuradha gave us an example of what we don't want to be. She just
finished an XMM proposal and she had the darnedest time over a
language barrier. When given the choice of Fixed vs. Non fixed target
she choose fixed because her target was not a solar system target. It
did not even have proper motion. But the system kept prompting her for
her timing constraints???? Turns out that a fixed target by XMM's
definition was one for which the observation was fixed in time.

The real lesson here is that the system should GUIDE YOU THROUGH THE
PROCESS, give you explanations when prompted and be able to explain
why it wants something.

Andy drew an analogy to the Microsoft windows "Wizards" (hey just like
the PCs!). These are systems that know how to set things up on your
computer (like configure a printer). You have the choice of doing it
yourself (more control, but you have to know more), or having the
WIZARD GUIDE YOU THROUGH THE PROCESS by asking you questions and doing
most of the work. So for instance the wizard could tell you when you
really don't need to be filling the orbit any more, but it you really
want to torture yourself - it could help you do that too.

The system should have both SCIENTIFIC KNOWLEDGE as well as PROCEDURAL
KNOWLEDGE.

Nick pointed out that SATs can now be taken at a computer terminal in
much less time. The old model was to ask a whole bunch of questions
with a range of difficulty. The interactive test changes based on
how you are doing. Answer a question right, get a harder question,
answer a question wrong, get an easier question. The system quickly
hones in on your skill level. Using this model, our system SHOULD NOT
ASK UNNECESSARY QUESTIONS.

The INSTALLATION PROCESS SHOULD BE SIMPLE and whatever it needs to
know should be remembered for the next time you install. Maybe there
should be no installation.

Anuradha cautions that the XMM system had no installation but had some
serious drawbacks. First of all you could easily loose a bunch of
stuff you had typed into a screen. Secondly when you did save, the
information was saved _there_ and you had no visibility into it. (MY
COMPUTER SHOULD BE MY FILING CABINET)

Another downside of remote processing is being blocked by other users
during the crunch time.

Andy thought that ultimately we need to still give our users a HUMAN
TO TALK TO if they need it. This would be reassuring to people even if
they don't use it. Large companies have learned the hard way that
multi layer tech support where the first line of defense is not very
knowledgeable can be costly.

Anuradha wants the system to sense when the user is beyond the realm
of automated help and PROACTIVELY PROVIDE THE SPECIALIZED ADVICE.

Nick wants the "hard to schedule" proposals to identify themselves as
soon as they come in. Anuradha wants affected proposals to line up for
inspection when changes to the satellite occur. Maybe the system would
notify the PIs about the change. (EASY, SELF BUILDING QUERIES)

We should SHORTEN THE PIPELINE to the spacecraft.

Andy thinks that proposals should "RATTLE DOWN HILL" on their
own. Only the ones that get stuck along the way should take someone's
attention. If there are no problems with a submission, the submission
tool should put it through the processing, at least through the steps
necessary for the LRP. No human interaction unless there is a problem
in which case the PC is contacted.

Why should you have to collect a big pile of proposal to make an LRP?
The scientists should plan their own proposals. But what does the
scientist care about scheduling (let alone efficiency) of the
observatory?

If we give the PI a slot and then the proposal can be crafted to a
particular day or plan window (generated after Phase 1).

The PI should just have to specify the S/N desired and the system
should generate the rest of the proposal.