When the decision to use a Visual Pipeline-based Editor for
BAMM, the development team is fortunate because it is one of the few very rare instance where one really start with a blank sheet. The brief was a one-line statement: " Build a Pipeline-based Editor for BAMM". This give us the opportunity to evaluate everything from writing a software from scratch to using off-the-shelf software. In fact, we evaluate a few possible approaches and softwares before deciding to use the
Eclipse Platform. In fact, the Eclipse Platform was not even on the radar screen until the very last moment.
The first thing we did after deciding to build a Visual Pipeline-based Editor was to see whether can we stand on the shoulder of others by using available software. I (Cinly Ooi) was keen on using Open Source Software, but do recognized that business needs need to come first. Thus, my preference for open source software will not influence any purchasing decision unless we reach a point where we found to equally compelling software and simply have to choose between them In this case only where I will allow my preference for open source software to decide the software to use. I think this would be better than flipping a coin. In the end, I am glad to say that this was not necessary.
We did a review on how users expects to use our software. The most important aspect coming out from this review is the need to excel on user experience:
- the software must be easy to install and maintain. It is a shame to say that most academic software, like open source software, are rather difficult to install. They requires onsite technical expert to work through the problems of installation. We find that our assumption that an onsite expert will always be available a rather flimsy assumption. Outside the United States, it appears that most of our target users appears not have dedicated expert on site, but rather must call in expert as needed. This leads to delay and frustration.
- Second, a lot of our users download and use our software when they have problems other softwares cannot resolve. This is what I call "Impulsive downloading". At this stage, users are impatient and worried about their project. Thus, we need to solve their problem at double quick time. Any delays are bad and will cause us to lose them. One delay users can really do without is the need to acquire new license to run our software. This means using commercial software is a stumbling block. Since we are targetting academic users, we find that normally the bureaucratic delay in transfering license fee and not the license fee that is the major cause of delay. Some vendors require us to collect the license fee for them. Others workaround this problem by allowing "trial" version of the software to be shipped to users immediately, or allow us to develop special compilation where we can ship freel to users. These approaches increase our operation cost and complexity. Any benefits we got from using commerical software will have to be discounted against this overhead.
- Our users very patient bunch of users and do really do not mind jumping through the hoops in search for better results, everytime they communicate with us to resolve issues, both parties suffer: They have to spend more time on their problem, and we have to take time out helpping them to figure out the problem. Users are often very frustrated with the delay.
- Lastly, users expect everything to be graphical: This means any typing done must be only for simple job such as inputting filenames or simple data. Anything that carry a hint of "programming" must be avoided.
Kepping in mind requirements above, we make up a list of programming requirements:
- The development team is capable of customizing and is prepare to contribute to the development of the chosen software. We believe that some customizing work is needed even for the software that most suit our needs. Waiting for the vendor to update their software is a cost that we hope to avoid.
- Our Visual Pipeline Editor must be capable of accepting contributions. In BAMM and the field of functional Magnetic Resonance (fMRI) Imaging Research, we collect data from a large variety of sources: Magnetic Resonance Scanner, Stimulus Delivery machines (big word for video projectors/audio speakers etc or anything that "stimulate" a response from users), equipments that measure users response and proprocessed data from different software. These data have to be converted into forms that BAMM can understand. The predominent approach in fMRI is to ask the user to take care of the conversion. We would like to explore an approach where converters are provided for the users. However, it is virtually impossible for any single provider to provide all of these. It must be a collaborative effort, hence, the need to accept contributions.
- fMRI is a complex research requiring not only data analysis support but other supports such as "archiving" and ontology. At present, they are all developed separately. If possible, we would like to bring it on to one platform to foster collaborations.
- Encourage software reuse. not recoding or recompilation. The Visual Pipeline Editor should be capable of running the program as-it-is. The high speed of evolution in fMRI research make this an even more important criteria.
From a political point of view and the need to foster collaboration, we have to ensure that
- Nobody, including us, is seen to be a dominent player. Rather, we will take steps to ensure that it is clear that everyone is an equal partner.
- There is no one dominant task pefromed by the "Visual Pipeline Editor". Every task is equal, i.e., Ontology or Archiving can take the center stage if needed.
In the next installment, we shall discuss how these requirements is used when evaluating software.
