Hi David,

On 18 May 2010 20:20, David Gallagher <gallagher.da at gmail.com> wrote:

> (See user-interface issues, item 2 below.)  The text is quite clear, but
> there is too much information here, so many people will not read it in
> detail.  If you want to upload a file, you do not need detailed instructions
> on using the "Draw" function. So, the detailed instructions for using the
> "Draw" function could be put on the "Draw" tab, and would only be viewed
> when that tab was selected.  Similarly, the detailed instructions for using
> the "Upload" function should be put on "Upload" tab, etc.
>
> The current text could then be replaced with:
>
> First, enter your chemical structure using one of the three methods below,
> then click the "NEXT" button

I'm afraid we won't be able to introduce per-tab contextual help
before the Berlin meeting and would rather keep the current per-step
contextual help for the time being. However, the per-step help text
could be easily modified and we're open to any suggestions for
improvements.

> This gives a cleaner looking page which is faster to comprehend, and if
> necessary, the user can explore the various tabs to find out more about the
> various options.

Well, I agree that shorter texts are somehow easier to read, but I
wouldn't give up clarity for curtness. In particular, if we move the
description of the differences between the tabs inside the tabs, the
user would have to click at least three times in order to grasp what
she/he could do in each of the tabs, which might be more inconvenient
than reading a bit longer introductory description. We're in the
progress of implementing a hide functionality for per-step help boxes
-- let's see how this would work out and decide later on whether
per-tab help boxes would be really preferable, ok?

> Why is it necessary to do a search at this stage, if the user didn't ask for it?  I would have thought that the
> search would be performed (by default) at the same time as the Prediction,
> so all results could be presented together

There are quite a few good reasons for this:

1) The user might have used a search term that doesn't translate
readily to a structure (without a database lookup), e.g. name, cas,
einecs number, or any other keyword (except SMILES or InChI). The
database search allows us to find out the most likely structure(s) the
user is looking for;

2) The entered structure (SMILES, InChI or drawing) might already
exist in our database (which contains in fact all REACH-relevant
substances, officially listed by ECHA), along with a range of
pre-calculated descriptors and other corresponding data (identifiers,
names, quality labels, properties, etc). This data is a pre-requisite
for any REACH reporting, which is part of the ToxPredict workflow.
Without a database search there is no any means to associate a given
structure to these kinds of data. In addition, it is not a good idea
to store thousands of times the same data (with some possible end-user
generated typos -- a consistency penalty) and calculate thousands of
times the same descriptors for the same structures (performance
penalty).

> If they do not or can not use the draw or upload functions, then they would
> have to use the search function to see if their molecule was already
> available, and if not, they would be told to upload or draw the structure.

If we decide to hide the search function behind an unsuccessful
draw/upload option, this would complicate use of the application for
users that want to perform searching right from the beginning.
Moreover, as explained above, searching would have to be performed in
all cases, regardless of whether the user explicitly asked for it or
not.

> Of course, searching for a particular molecule by name or registry number
> involves similar confidentiality risks as uploading the actual structure.

Yes, but the risks are certainly not of equal magnitude. In general,
when you search for something, the only trace you leave is what you're
interested in. However, if the structure you're interested in is not
present in the database, uploading this structure actually magnifies
the privacy risk substantially, doesn't it?

> Just the bottom right should be sufficient.  This simplifies the top bar and
> prevents it wrapping when the window is narrowed.

Navigation bar at the bottom of the screen has been already
implemented and deployed. We're looking currently for options to make
the bar shorter and narrower, in order to keep it nicely aligned on
lower resolution screens as well.

> The current OpenTox logo (18-05-2010) seems about the right size, so perhaps
> the ambit logo could be made a similar size, then these items could be
> centered at the bottom of the page.  Also, just one single font style for
> the accompanying notes might look better.

Yes, we've already changed the logos size. Former height of both logos
was 72 pixels, now it is 32 pixels. I hope this solves the size issue.
Regarding centered versus right aligned, we prefer the second option.
And finally, could you please clarify what do you mean by "font style
for the accompanying notes" -- we're a bit lost...

> If there are errors this makes sense, but why would you not go straight to
> the results page if there are no errors?  Or even show any errors along with
> the successful results?

It wouldn't be consistent with the workflow design, which requires
user interaction for navigation back and forward. Again, depending on
the outcome of the processing in step 4 the user might prefer to go to
some other step in the workflow, not necessarily the previous or the
next one.

> I think this is already addressed above, for consistency, it should be
> possible to perform a prediction and/or search (for tox info) on any
> compound, regardless of the method that was used to enter it (i.e. Upload,
> Draw, or Search)

Let's make a few things clear:

1) *any* input method would involve a search operation for good
reasons some of which I've mentioned above;

2) *all* input methods allow currently to perform a prediction,
provided that the underlying search operation has returned some hits;

3) you have highlighted the fact that structures which doesn't exist
in the database can be predicted only if they're uploaded through the
upload tab (this is in fact a design decision we've made for reasons
I've stated already several times); we also agree that this might be a
limitation that needs to be addressed; however, considering the fact
that the database contains currently a superset of all REACH-relevant
chemicals, this issue is perhaps not the most burning one; BTW,
please note that if someone searches for the structure you've uploaded
yesterday, he'll find it, along with all the descriptors that have
been calculated for it -- isn't this nice? ;-)

We're open to suggestions on how we should deal with unseen chemicals
(which doesn't exist in the database). In particular, we should
consider the following open questions:

1) what would be the minimum mandatory information (InChI, SMILES,
CAS, EINECS, IUPAC name, drawing any combination of those  (which?)?

2) when should descriptor calculation occur for unseen chemicals (some
options are: (i) in real time (ii) at scheduled intervals (how
often?)?

3) should we add this functionality to the Search and Draw tabs, e.g.
by replacing the "not found" error message with a dialog for entering
the mandatory information for a new chemical, or should we restrict
this functionality only to the upload tab (like it is implemented in
fact currently), or should we design some new tab for this purpose?

We don't have strong opinion on these topics and any input would be
most welcome, so please don't hesitate to come up with
comments/suggestions.

>> For consistency, it may be better the change "Step 4, Estimate" to "Step
>> 4,
>> Predict", as this would then match the title "ToxPredict".  Otherwise, the
>> question arises, what is the difference between Estimate and Predict?
>
> Agreed.

Done.

>> 8.  Disclamier
>> There should be a disclaimer at the bottom of the page (in small print)
>> explaining that computational chemistry predictions should not be relied
>> upon alone, but used as part of a weight of evidence, etc., etc......
>
> Agreed. Could you suggest the text for this Disclaimer?
>
> Good point, we need some legally acceptable text here that will protect our
> users and ourselves, (which I am not qualified to provide), so lets chat to
> Barry about this issue.

Barry -- would you comment on the disclaimer issue and suggest some text?

Kind regards,
Vedrin