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/
|