Notes on meeting with Camille Ginsburg and Andy Hocker
from Fermi TD on June 23, 2006, 9AM in ICB3.

Vertical Test Stand (Camille) will start to use an elog
early next year.

Horizontal Test Stand (Andy) will start to use an elog 
in August.

Both have experience with AD Elog, CRL and TD weblog.

Camille was on a committee that reviewed logbooks last
year and recommended the CRL.  In the end the TD weblog
was developed instead - the deciding issue was that they
wanted local control.  Her notes are at:

    http://tdserver1.fnal.gov/ginsburg/mtf_elog.html

Both Camille and Andy agreed local control can be the 
right answer for a small project but is probably the 
wrong answer for a big project.

The magnet tests will be small scale but the cavity tests
will, in the end, be very large scale.

They agree with model in which they start up with one product and migrate to another.

An elog should not be confused with:
  - a database holding measurement data
  - a data catalog
  - document management system
  - slow controls data repository
  - a system to manage travellers
  - an analysis notebook

Dedicated systems are needed for the above.

An elog is for "operations", broadly construed to include
prep for and execution of module tests.

Vertical Test stand at DESY has automatted tools to
record data but they use a  paper logbook.

They both give zero weight to the issue of searching
attachments. Any attachment that is interesting to search
belongs in the document management system or the analysis
notebook.

It is important to be able to thumbnail many image
formats, not just gif/jpg.

If the "impedance" for making an entry is too high,
the entries won't be made.  This is very bad.

Andy's comments on existing products:
 - AD Elog - best fit with his mental model of what
   a logbook is.  Excellent readability.

 - TD weblog - poorer readability

 - CRL - fonts are too small ( I have heard the same 
         comment from several others ).

 - He likes being able to highlight text within
   an entry using bold/color, whether by html or
   other means.

What about mistyping of cavity names/numbers when making an
entry?  This is a weakness of the AD product.  The TD
weblog has pulldown menus for which cavity is under test
but no controls for adding entries to the list - 
so one device might get multiple entries with different
capitalizations.  Fortunately the product maintainers 
can fix these sorts of errors after the fact.

I suggested the following scenario.  They are doing
a test on a cavity and  the cryo system has a non-fatal
problem.  On first glance the data looks OK so it is 
written to the data storage system.  If someone later
notices a problem with this data, how would they
discover that the test conditions are suspect?  Camille
and Andy agree that they would likely look for the 
answer in the elog.  So this is a real scenario in which
some would look at old entries.