Hi Russ:
I certainly don't wish to imply any disrespect to those who have
developed the tools I use almost every day. I still remember command
line input for SPM, and the excitement when Karl first proposed a
GUI interface - it was a revelation and played a major role in
popularising SPM.
My point is to try and encourage that type of innovation to
continue. The GUI interface made imaging analysis accessible to a
much larger audience: it became more intuitive, easier. Now that the
voume and complexity of both the data and analysis have increased it
is a reasonable plea that the checks and balances that are seemingly
being recommended be just as accessible, intuitive and easy.
Of course we all have a responsibility to know what we are doing but
science doesn't take place in a spiritual zoo with all the
scientists in separate cages. We interact with each other through
the contributions we make to help lists, the papers we write and the
tools we develop. When we make these things easier for our fellow
scientists to follow or use we make things better for everyone.
Fraternally,
Stuart.
---- Begin Original Message ----
From: Russ Poldrack <[log in to unmask]>
Sent: Tue, 15 Mar 2005 15:31:58 -0800
To: [log in to unmask]
Subject: Re: Any Papers on Presenting fMRI Results?
The SPM developers can speak for themselves, but I would generally
disagree that it is the responsibility of the developer to make the
software user-friendly. I think that their prime responsibility is to
make sure that the software does what it says it does, and does it
correctly, and on this count I think Karl, John, and the rest of the
SPM crew are to be commended.
I think that all users have a responsibility to know what their
software is doing. I do think that greater documentation would be
useful. The FSL group spits out a short bit of text with each
analysis
report describing the analysis that was performed, and it might be
useful to have SPM do the same (perhaps as a field in the SPM data
structure).
In addition, I think that it would be useful to develop a page
(perhaps
as part of the spm wiki) describing a set of "best practices" for SPM
data analysis. In some cases these could be prescriptions (e.g., "do
not use GRF corrections with unsmoothed data") but in many cases they
would just outline what the range of reasonable parameters or
approaches are. The danger, of course, is that something like this
could become entrenched and stifle creativity, but I fear that the
alternative is probably worse.
One particularly important part of this is quality control - So far
as
I know there is no published outline of reasonable quality control
steps that one should take to make sure that one's data are sound and
analyses have been applied properly. This seems incredibly
important,
and if I had more time I would add it to the wiki right away. As it
stands, unless someone else does it in the meantime I'll try to add
it
to the wiki this summer.
cheers
russ
On Mar 15, 2005, at 12:19 PM, Dr. Stuart WG Derbyshire wrote:
> I am coming to this debate very late and I don't have anything
> intellectual to add, I just want to make a plea.
>
> I am one of those SPM users that knows enough to sound knowledgable
> when I really only know enough to be dangerous. I try to stay
> informed but it is a moving target that gets more complicated by
the
> minute. I have just spent 2 hours getting up to date on the SPM
list
> and I now have a dozen open browsers with additional material in
> each.
>
> We can't expect all users of SPM to be experts. Several
contributors
> have argued that the researchers, editors, reviewers and readers
all
> need to take responsibility for ensuring the methods are
> appropriate. Indeed. But those who provide the stats tools also
have
> a responsibility to ensure that the tools are user friendly. If
> diagnostics are necessary (to look at residuals, stds,
unthresholded
> maps, whatever else is considered important), but are not easily
> accessible or understandable, then it is likely they will not be
> used or will be used inappropriately.
>
> Similarly, where there is a lot of argument it is difficult for an
> outside user to decide what to do. Somehow we have to provide
> reasonable guidance. I think Tom's internet page describing what he
> would like to see in any imaging paper is good (although it is one
> of my open browsers and I haven't read it in detail yet!). I might
> add that perhaps we should have a list of things all the experts
can
> agree a researcher should absolutely do or not do (or risk
immediate
> rejection) and then things a reviewer might reasonably look for but
> which are debateable.
>
> Just my 2c,
>
> Stuart.
>
>
>
>
> UPMC MR Research Center
> PUH B-804
> 200 Lothrop Street
> Pittsburgh
> PA 15213
>
> Sent by Medscape Mail: Free Portable E-mail for Professionals on
the
> Move
> http://www.medscape.com
>
---
Russell A. Poldrack, Ph.D.
Assistant Professor of Psychology, UCLA
Franz Hall, Box 951563
Los Angeles, CA 90095-1563
email: [log in to unmask]
phone: 310.794.1224
fax: 310.206.5895
web: http://www.poldracklab.org/
---- End Original Message ----
Sent by Medscape Mail: Free Portable E-mail for Professionals on the Move
http://www.medscape.com
|