Below are some notes on how the Phylografter web interface could be made more user-friendly.

The goal is to instill confidence in those using the interface. Anything that's unclear is going to lead to anxiety and that will reduce the speed and confidence with which people will upload new data sets. In general every user interface element should probably have documentation.

Notes from Jonathan:

• Treebase id: A user will wonder whether they have to include the 'S' in the treebase id, or omit it. A mouseover (or other readily available documentation) should explain this, perhaps by giving an example. [The 'S' is optional but there is no way to know this ahead of time.]
• "Focal clade" - it's not clear how important this is or what the consequences of getting it wrong might be. In the example I tried the superfamily (Pipoidea) was not recognized and I didn't know what to do. The documentation might say "do your best, it's not critical" or "this can be updated later" or "it's OK to leave this blank" or "leave blank if the taxon isn't recognized". (Leaving blank might be best since then we can write a query to find all the missing ones - which is far easier than finding incorrect ones.)
• Bibliographic reference, year - fill in from DOI if DOI is provided (this is now implemented?) - or if not give an example and specify which citation format to use, so that there is some hope of uniformity.
• DOI - explain that this is the "digital object identifier" for the article reporting the study. Personally I [JAR] think DOI is quite important. I've been finding these manually via Google Scholar. The documentation might suggest this as a good way to do it. (But it would be better if the system used Crossref services to find the likely DOI automagically.)
• Label, comment: I have no idea what to put here. I left them blank but if that's OK then the documentation should say it's OK to leave them blank. Alternatively the documentation could give examples.
• "Contributor" is a peculiar term. We're not talking about a contributor to the study; perhaps "curator" or "uploader". In any case the documentation should explain that this field should have the name of the individual entering the study into Phylografter. Eventually an ORCID should be allowed in this field.
• After clicking on "insert study" the confirmation is quite a distance from the 'insert study' button and therefore difficult to notice. Initially I thought the operation hadn't taken place at all and only saw the confirmation because I looked around for it. I suggest putting the confirmation indicator close to the button.
• The URLs in the interface really ought to reflect the object or record being modified, in a RESTy style - e.g. for studies it should contain the study id ("identify" the study), not be session sensitive. This will help with bookmarking, workflow, etc.
• When I entered a study all the taxa show up as being "new". this is odd because most of the taxa have NCBI ids, and all have namebank ids. The meaning of "new" should be explained since otherwise it feels like there has been an error.
• It's offering "Import 9 new OTUs". There should be an explanation of what "importing" constitutes. ...
• Similarly the semantics of "taxon match" should be explained.
• 'Edit OTUs' led to 'no data available in table' - what table? What is the "data" that's missing? This should be explained.
• Upload tree leads to "You've uploaded a Nexml file that conflicts with an existing record:" - this should be explained. What existing record?
• 'Import / edit trees' leads to "Tr48962: con all compat" - what does "con all compat" mean? What is Tr48962 ?
• Users should be expected, even encouraged, to explore the UI, so if any control is discovered to be invalid or inappropriate after attempted, the reason for its not working should be explained in plain terms. (Alternatively the control can be disabled when it's not going to be useful.)

Notes from Laura:

• Major issue: the OTU matching is unclear
  • when first importing, there are these pre-checked boxes for "taxon match" and "new"... the meaning of these was unclear to us. I think "new" here means "present in study being uploaded," but I'm not sure... (see new_vs_match.tif)
  • we went forward and got to the next screen, but we were unsure what to do until we saw small 'edit OTUs' at bottom (see what_do_we...tif)
  • It was then unclear to us what we were supposed to do to add taxon names without a match in the database. We tried editing OTU and clicking submit but nothing seemed to happen. Is this a problem at our end? Is something happening behind the scene? (see adding_OTUs.tif)

• Small things:
  • there was almost a minute delay when we try to log in and again when entering treebase ID to submit. Is this a problem at our end or is this slow for others? IF this is slow for others, will it get worse on the 30th with multiple users?
  • I'm not sure why but we had to enter doi and focal clade twice for each study -- got deleted after first time
  • when entering trees, we were a bit confused about terminology of "clade labels" . Would it be helpful to clarify that these are internal branches, not taxon labels? Perhaps add choice for none?
  • can users delete studies? We uploaded study from our lab where the tips had dumb, in house labels. We were curious to see if these would/could be matched with appropriate taxa from the taxonomy database. Instead, the dumb names appear to have been accepted: (e.g. Leuk_SS__JS12y_A1_con_seq_2111_bp, etc. Can you enable us to delete this study or can you do it for now? Have these dumb names been added to database? Can we provide some guidelines for users prior to and/or during submission on standards for names?