Hi all,
Bill's email continues to resonate. Be interesting to hear from others
as to Karel's suggestion of forming a working group. Another working
group might be one that would provide guidelines on the issue of
co-authorship and acknowledgments; having the whole group concur on such
recommendations would clearly be very useful. I will set something up
for the AMMRL meeting to assist in the creation of such groups. If
enough of you are willing to join in, that will provide a start.
A few more cents worth about automation: I have always been a proponent
of automation, customizing the software, and writing documentation to
assist the user [when I first arrived at the UW, my writing up user
guides was seriously frowned on by some faculty; I won the argument only
by showing faculty the notes a few students had written up--and most
were using--that were riddled with incorrect information].
The more we can do to help chemists most efficiently solve their
problems has to be the right direction to go. And automation for some
groups of users and types of experiments is inevitable. So I suggest we
focus on guiding the process along, rather than fighting it. Well, my 2
cents worth, anyway.
Following this line of thought, the software should provide better
"learning opportunities". For the user that wants to learn more about
what they are doing with the spectrometer, the software should provide
simple opportunities to do so. Varian's removal of parameter names from
the vnmrj interface I think is a very bad idea. And I shudder to think
that removing the command line from users is actually done except in the
most tightly controlled environments. These two changes have the black
box getting black-hole black.... Having user progress to writing even
the simplest macros becomes much more difficult, as one consequence.
And for no gain in ease-of-use that I can see. Natural language
interfaces can still have the parameter name listed to the right, just
as commands usually have the keyboard shortcut listed to the right (a
standard in Windows programs). Just seeing this information has users
learning as they work. Removal of the command line cannot do more than
ease the fears of bolt-tightening administrators. If you're really
worried about power levels or long times being set, etc., there are
other much better ways to prevent those kinds of problems.
In a broader context, we should have a simpler Help systems that are
customizable and context sensitive. NMR-Guide has the right idea, but
simpler systems would be useful. Other "handles" that administrators
can use with complex software would be important. One might be a better
ability to query users with a dialog, and act on the responses. An example:
Do you know the range of 1H T1 values for this sample?
if no: Do you want me to setup a T1 experiment for you?
(This is hard to do with vnmrj automation software.) The
context-sensitivity help button would explain T1 relaxation, starting
simple and allowing increasing depth to be clicked into. The Help
button should explain to the user why they should care: e.g., if the
question came up during a NOESY1D setup, explain that T1 values are
crucial in properly setting up the repetition delay and mix times.
Well, maybe too much info. Sorry about that. See you all in just over
a week!
Charlie
~~~~~~~~~~~~~~~~~~~~~~~
Charles G. Fry, Ph.D. Tel: (608)262-3182
Director, MR Facility Fax: (608)262-0381
Chem. Dept., 1101 University Ave, Univ. Wisconsin-Madison
Madison, WI 53706 USA email: fry_at_chem.wisc.edu
Received on Thu Apr 13 2006 - 11:32:21 MST