GUI

[José R. Valverde]

On Mon, 21 Apr 2003 12:54:29 +0200
Carlos Quijano <cquijano at iib.uam.es> wrote:

>    * My effort is to comprehend my users' needings, and give them the 
> best solution. I think give them the "easiest" solution is not the right 
> direction for the research community, for science. We need the max. 
> accuracy, and it's not the same concept.
> 
That's a common misconception. Accuracy is not the goal. Meaningfulness is.
Having measures to the tenth decimal point may be absolutely meaningless in
many contexts. And worst, misleading too.

What users want is meaningful results. They want to get something they
can a) understand and b) trust, and if by the way the get some measure of
the reliability of results, well, it won't hurt.

Now, what does that mean?

	To provide meaning, you need to understand the methods AND the
data. *We* do understand the methods, but only users know the data they
are using.

	There are two ways around this: one is to try and foresee all 
possible use cases and provide options and explanations for each (kind of
an expert system), and the other is to give the user hints to realize when
something is going airy and pointers to further information.

	Since foreseeing every possible use case is quite difficult (if not
impossible), the first solution may give a false impression of overaccuracy
and be misleading too. If you go for it, you better be *real good* at it.

	So, from my point of view, users need to get what they need *iff at
all possible*. Note the double 'f': *if and only if*. If you can't give them
what they need you better don't. Overbloating a user interface with bells
and whistles may lead them to blind believing in the results, and we don't
want that, what we want is escepticism on the results. Always. Dot.

	To sum it up: concentrate on meaning, and make sure the user always 
knows what to trust and what not, and provide enough pointers (e.g. as 
hyperlinks) to further explanations.

	An extra note on this: provide SHORT tips and explanations FIRST.
Assume users won't maintain attention more than 10 seconds. Anything that
takes longer to read won't be read on a first sight. Once they decide, based
on your tip, that further investigation is needed, you can THEN lead them
to longer descriptions.

> So, if you want to develop a new GUI, think about how are you going to 
> overcome the other ones. For doing the same that others already do, dont 
> waste your time. Try to innovate! (cloning focus.... good idea)
> 

That's a good one. And it leads to an important conclusion: it is probably
a waste of time to duplicate other people's work. So, if possible, don't.

Consider joining some of the existing efforts. Jemboss may be a good one 
since being Java it runs everywhere. Instead of duplicating effors, add
to it what you feel missing.

Contact the Jemboss team and find out how to add new functionality to it.

> Some ideas about what I think are other GUI's weakness:

> 1- There is no GUI with all the options for all the programs (and you 
> have to do it without turning the GUI dusky).
>
> 2- There is no GUI focused in an output usefull for publishing - papers, 
> if you follow me - (great weak point).

Right. Turning emboss output into something more useful (like editable
vector graphics, PostScript, etc.. is a nice goal. Furthermore, a simple
output 'editor' that allows adding some arrows, notes, or simple graphics
to program output might be good enough.

> 3- There is no a really windows-based GUI without using Java or 
> web-browsing (I love GNU and Linux and Sun, so forget this unlucky 
> advice, for more detail, read line * ;-)

Java runs everywhere. True, Jemboss is a pain to install. Why not make
it easy to install? Furthermore, why not create 'ditributions' that
are ready to run (and install) for several architectures?

> 4- ¿Have somebody dreamed about pipelines between emboss apps?.
> 5- It could be great to have an expert system. For example, send a 
> sequence and receive all information possible (very usefull, a lot of 
> people is lost with the bioinformatic's protocols, with this utillity 
> they shall see how is all done). A cloning expret system? ;-)

For the reasons explained above, I would rather propose development
of 'wizards', simple tools that guide the user through the basic
process, providing tips here and there, and these with hints that 
results may be a lot better if one uses the fool power of the tools,
with links to the actual tools and to documentation on them. Then
the casual user will have an easy entry point, and after a few trials
and if s/he finds it worth, wannabee power users will have the starting
points to become proficient.

> 6- It could be interesting to enhance the EDIT - VIEW interface of 
> emboss (and their GUIs do little about it, only presenting the output... ).
>
Yep, a feature browser, a sequence editor, etc.. might be good add-ons to
Jemboss.

Note that if the extensions are properly done, so they may be independent
from Jemboss and have a good interface to the main program (a bit like
Jalview), and written in Java, then they might be added with little
effort to other web based GUIs, increasing the utility of the tools.
 
As I said, I would contact the Jemboss team and find out with them how to
contribute.

					j

-- 
	These opinions are mine and only mine. Hey man, I saw them first!

			    José R. Valverde

	De nada sirve la Inteligencia Artificial cuando falta la Natural