[BiO BB] RE: BioInformatics Workbench project

[Amir Karger]

(Sorry, I don't know how to reply to messages I get in digest form)

Marcel, 

> I must agree with you that this project has a very broad scope. 

I don't want to sound mean or pessimistic here (so please put an IMO
before
each sentence that follows), but it still sounds like you
are glossing over the hugeness of this project. 

> However 
> part of the project should be to determine what (popular)
functionalities a 
> complete workbench should contain and with this information, compose a

> list of functional requirements.

There are hundreds to possibly thousands of software packages out there
in
many, overlapping sub-disciplines of biology. Which ones are you
planning
on supporting?  "My workbench will integrate every possible application"
only works if you have an extremely lightweight framework - like, say, X
and the command line.

How many dozens of people were you planning on interviewing in depth to
find out user needs? If your functional requirements aren't detailed,
your
project either won't get very far or won't satisfy actual users' needs.
Are
you supporting computational biologists? Non-computer-y biologists?
Students? If you say "everyone", then you probably need to code 3
separate
workbenches.  Are these people using it every day, or spending a month
in
the lab between uses? It makes a big difference in the tradeoff of
efficiency (lots of shortcuts, specialized GUI) vs. memorability ("How
do I
list my projects again?")

I suspect most of the existing workbenches took several years to write.
Are you (and your development team) prepared for that commitment?

> The differences between this application and other workbench projects,
in 
> my opinion, should be:
> 
> - Must contain an intuitive user interfaces 

Define intuitive. ("Easy to use" isn't precise enough.) What
details are you planning on sacrificing to make it easy to use, and will
it
still be useful for experts? 

> (taking advantage of standard 
> UI components from the .NET framework) so that the time needed to
learn 
> how to use the application should be minimized and the application
should 
> be attractive to (biochemistry) students without a lot of 
> computer/informatics experience.

I'm all for standards. But, when starting on a major project, is it
really
a good idea to pick your tool (.NET) before you've even gotten
requirements?

I don't know anything about .NET, but has anyone done a study to clarify
whether the standard .NET UI components are the best kinds of UI for
biologists to be using? Although some aspects of usability are universal
(as long as your users are all human), the average biologist is probably
much different than the average .NET app user in certain ways.

> - Integration and collaboration of different functions/tools within
the 
> workbench. This should allow the user of the application to work more 
> efficiently than a collection of standalone tools and saves a lot of
time 
> saving/opening/converting filetypes etc. Pretty much the same idea as
the 
> Open Office/Microsoft Office suite.. it just works better then using
all 
> standalone applications for example like Wordperfect, Lotus 123 and
dBASE.

I'm all for integration, too. On the other hand, the Office suite has
the
advantage of all being written by the same company (or project teams, in
the case of OOo). All these biology profs who hack together GUI-less C
codes ("It's just a one-time program that I'm sure no one else will use
,
so I don't have to code cleanly.") aren't necessarily going to follow
all
of your coding rules. They may even go and change formats while
you're not looking.

> - It allows developers from widely used languages as C++/C#/J#/Visual 
> Basic and Fortran to work on the project or allows them to easily
develop 
> a plug-in for it.

Sure. Once you've built a robust, tested framework, and convinced enough
people to use it that it's worth installing, learning to use, and
writing a
plug-in for.

> This project is too big to do it on my own, so any help is
appreciated. 
> The first step should be, in my opinion, to ask people what they would

> like to have in a workbench. From that point on we can always decide
> to change things according to the needs.

I know I've sounded very negative here. Maybe you're good enough to
actually pull it off. But the open source world is littered with the
wreckage of well-intentioned projects that never got off the ground.
(I've
created - or not successfully created - a few little ones myself.) 

It's several zillion times faster to start from an existing code base
than
to start from scratch. This could mean either joining an existing
project's
development team, or, if you disagree about their future direction, at
least
copying their code to start your own project.  Jeff gave you a large
list
of projects with widely differing approaches.  Are you sure that ALL of
them are so inadequate that it's worth starting Yet Another Workbench
for
Bioinformatics project from scratch? (If you do, you can call it YAWB :)
If
you don't want to join another project, should you maybe focus on one
detail of the interoperability problem? I suspect you'll have a better
chance of releasing something that way.

Anyway, good luck with whatever you decide.

-Amir Karger