In article <87snsed3f4.fsf at genehack.org>, "John S. J. Anderson" <jacobs+usenet at genehack.org> writes:
>> Perhaps more important than just "what's the code look like" is
>> "what's the documentation like?". MANY of the bioinformatics tools
>> have truely hideous command line interfaces which most users are
>> going to run away from.
>>Interface is hard. Good interface is even harder, especially given
>that the author(s) of bioinformatics software aren't going to be the
>same type of user as Joe Pipetman.
>>Command lines don't _have_ to be horrible, and can actually be quite
>nice -- if you're the type of person who understand pipe lines, and
>why they are a Good Thing. OTOH, authors who don't dump some
>documentation in response to a 'foo -h' or 'foo --help' should be
>smacked about the head and shoulders.
A command line interface can be not only rather nice, but also easier
to use than many graphical ones. The main reason is that graphical
interfaces are more complex to build. Just putting buttons and menus
does not solve every usability problems. The main benefit is that
there is not syntax to learn, but there are still many navigation
problems, not speaking about the intrinsic difficulty of the problem
addressed by the software. There are still too many people in bioinformatics
who program graphical interfaces without having even tested it with users
outside of their lab.
(I have some links there about usability issues: http://www.pasteur.fr/~letondal/These/links-ihm.html#use)
Command line interface are difficult partly because there are a lot
of different styles, which are impossible to remember. What is nice
with them is that you can indeed combine them through pipelines or scripts.
You can as well wrap them into an interactive interface (text or graphical
menus, Web forms,...). Having several levels of interface is anyway a good
idea, ...including an API.
Catherine Letondal -- Pasteur Institute Computing Center