Ease of use in danger? SQL, entities, relationships, ...

Hi,


I remember the first Instant-JChem version one, where I had the grid-view and if I delete some substances


in the grid view, they were not existent for me (the user) anymore. Now I always need to make sure


to do an "SQL table drop" check the old "DB relationships"


and make sure that my "DB Entity" is empty and my "CD-hash and fingerprints" are OK.





Do you think any biologist or chemist cares about what an SQL


table is or a hashed fingerprint is? I can tell you most (90%) probably do


not care. Not because they are ignorant, but they just don't need it for their work.





I think besides the flexibility all that entity and SQL stuff allows


its actually a great danger to the ease of use for Instant-JChem. Not only


in terms of daily work but also complexity which is exposed to the user


and creates more confusion than it helps.





Hey Tim and Petr, as developers don't pick on me,


I would like to hear some other voices (please).





Tobias

You seem to be referring to the Schema editor which is the expert adminstrative interface for the database. This is where the administrator configures things like the database tables, the relationships betweeen them and the indexes in the database. In normal operation of IJC (e.g. viewing data, searching data....) you will not need to use this.





We of course want to make things as simple to use as possible, but, for instance there is a need to be able to manage indexes in the database, and so those indexes have to appear somewhere. Having them appear only in the adminstrative tool, and providing the ability to collapse the section displaying them so that you don't have to see them seems to be the most sensible approach. Similarly with relationships - IJC can't manage them unless thay are displayed somewhere and there are tools for creating and delting them, and the schema editor is that place.





One of your issues seems to be the naming of the indexes (SQL07100...). In this case the index name is generated automatically by the database when the table is created. We can't change this. Where a user creates an index we allow them to give it a friendly name.





Of course making the interface as simple as practical is a key concern to us. We are always looking at how to make things as simple and usable as possible. And we welcome suggestions for improvements.





Tim

Hi,


I even have to revise my critique, in a current article in Genome-Tech Biologists, Start Your Computers


Jeanene Swanson writes (citing Dana-Farber’s John Quackenbush) "He advises students — and,


indeed, all biologists — to learn SQL, or some basic database


programming language" like Perl, Python, Java, C, C++.





Still keeping it easy and powerful at the same time


is an act of balance, thatswhy I liked the structure


search window open all the time and already activated


for substructure search (and some of the other most


important fields). It avoids mouse clicks.





Link, you can create a free login:


Genome-Tech article


Tobias