In-Reply-To: <920610121457.20204ef9 at SEQVAX.CALTECH.EDU>; from "David Mathog" at Jun 10, 92 12:14 pm:
> Part of my job is to support software for my users. Part of that includes
> telling software developers when their programs need work. Since the GDB
> just came up in the discussion groups, now might be a good time to give you
> some feedback.
>
David,
Thank you for your input. We really do appreciate input from our users,
particularly other developers. Thanks for the suggestions.
In the future, I would make one request of you. PLEASE direct your suggestions,
enhancement requests, and/or bug reports to the GDB User Support group, at
help at welch.jhu.edu or 410-955-7058 (voice) or 410-614-0434 (fax). They track
every message very carefully, and make sure it is logged, routed to the
appropriate developer or manager, etc. Given the volume of mail that I
deal with single-handedly, messages sent directly to me disappear
sometimes. Again, thanks for your suggestions.
> [...lines deleted...]
>> Let me be blunt: the problem with GDB is not that it is character based,
> the problem is that is a pain in the butt to use. Please consider
> implementing the following suggestions before you spend too much time on
> the rest of the "high tech" stuff that you describe in your post.
>
We realize that many of our users find GDB extremely difficult to learn and
use, and that this is not simply attributable to its character-based interface.
However, a large part of the problem is the incredible complexity of the data
which is contained in the database. Most other public biological databases
(eg. Genbank, PIR, PDB, Swiss-Prot, Prosite, Medline, etc.) have ONE basic
record type (sequence, citation, molecule, etc.), and are either stored as
flat files or relational databases with a relatively small number of tables.
GDB has a highly normalized relational schema composed of some FOUR HUNDRED
tables at present. The complexity of the interface is a direct reflection
of the complexity of the underlying data. The community has clearly expressed
to us what sorts of information they expect to find in GDB. We cannot provide
adequate access to the data with the rudimentary interface found on
applications such as Gopher.
> Suggestions:
>> 1. Remove all use of control characters and multiple on screen menus.
> Go to a simple menu system with a single menu present on screen
> at any one time, with all options presented as numbered items, and
> selection by number <return>.
The control characters and menu bars are an unfortunate part of Sybase's
APT forms development system. Since GDB had to be developed from idea to
production system in 13 months, it was imperative that we use a front-end
tool closely tied to the DBMS, and that meant APT. Since GDB came on-line
in September 1990 at HGM10.5, we have still essentially operated in crisis
mode, to accomodate major genome workshops since that time. We are just
beginning to come out of that period, and are coming to a point when we
will have the luxury of sufficient time to evaluate the state of the art
in front-end development packages. We hope that GDB Version 5, due this
fall, will be one small step in that direction.
We cannot rely on some simple-minded 3GL subroutine library for single
line menus and one data entry prompt. It is simply not possible to represent
information in that format and still allow our users to specify complex
relationships among a myriad of data objects (eg. "what probes are associated
with this gene?", "what loci were mapped to which location?", "show me all
of the highly polymorphic markers on the short arm of chromosome X for which
PCR primers are available, along with the corresponding references.")
> 2. Selecting a field that can be modified should bring up a line that
> the user types on, and entry should be terminated by a <return>.
> Multiline entries differ only in that they are terminate by a blank line.
> In either case, the original menu returns showing the now filled in
> field (or as much as will fit).
As above, this is simply not sufficient.
> 3. Simplify, simplify, simplify. Field test it on computer illiterate
> undergrads.
Agreed. And we ARE trying. But we cannot allow the science to suffer
because people cannot ask sophisticated questions of the data due to interface
constraints. It is VERY difficult to ask complex questions with a simple
interface. Take any of the queries described above (particularly the last one)
and try to ask it with the Mac or Windows WAIS interface. These interfaces
are very intuitive (in my opinion), but are basically incapable of forming
these sorts of questions.
Whatever tools we provide must be adequate to the job at hand.
We are striving to find a compromise between ease of use and adequate query
power.
> 4. You should be able to make this all so intuitive that no one need ever
> hit the "help" option.
>
In principle yes, but since even the nomenclature in this field is not
standardized across laboratories (sit down with a group of geneticists and
ask them to define "gene", "locus", "marker", "index marker", "reference
marker", "probe", "clone", etc. and you may begin to see what I mean), we
must rely on on-line help if for no other reason than to define the
terminology that WE are using in the presentation and entry of data.
> [...lines deleted...]
>> >Having said that, I can also tell you that we are looking to address this
> >need. GDB is exploring the development of supplemental GUI-based tools, both
> >in-house and through external collaborations. Initially, these applications
> >will be in addition to GDB's character based front end, but as the community
> >moves to more powerful platforms, more and more functionality will be
> >addressed with GUI tools. The earliest prototype graphical applications for
> >GDB will probably not be available until the 3rd or 4th quarter of this year.
> >
>> Why a GUI? There is nothing intrinsically GRAPHICAL in your database! Ok,
> some drawings of the genetic maps might be nice, but I'd be happy if
> I could just get Postscript or Tek 4014 versions via e-mail or download.
>
GUI's are NOT limited to pictures. GUI's provide visual analogies for
manipulating pictures AND symbols (characters). Scroll bars, pop up menus,
radio buttons, multiple windows, etc. -- all are powerful visual tools for
manipulating pictures and text. Also, don't forget that GDB's primary role
is as a MAPPING database. More and more, map information will dominate
GDB, and almost EVERY mapper we have asked has told us that graphical
display of maps is essential (try to describe a complex contig map in words).
>> I hope that you find some of this criticism constructive,
>> Sincerely,
>> David Mathog
>mathog at seqvax.caltech.edu> manager, sequence analysis facility, biology division, Caltech
>
We do indeed. Your basic point is well taken, and we are working very hard
to address it even as we "speak." Thanks again for your suggestions!
Ken Fasman
Co-PI of Informatics Core
Genome Data Base
Welch Medical Library
Johns Hopkins University School of Medicine
1830 E. Monument St. 3rd Floor
Baltimore MD 21205
ken at welchgate.welch.jhu.edu
P.S. David, I hope that you do not mind my taking the liberty to post this
response to some of the BIONET groups. I'm sure many other people have
the same questions that you do. - Ken
