Fish record entry

[bumpersp]

Currently thinking about designing the Fnotes entry form. In the filemaker version there is a place to enter fish records that we record in our field notes. We only do that by hand if it is the ONLY version of that data. For instance sometime snorkel records are only recorded in field notes, as opposed to some other datasheet that then gets entered and imported to the Fnotes Fish database. For our new database-should we just enter those by hand into what is currently sub-collections_organsisms? @mkleinha how do you envision this being best accomplished?

[mkleinha]

I could see a portion of the interface being dedicated to querying and displaying subcollection records from the same collection as is linked to the field note. If none are found, it could allow direct entry of subcollection records. I will send a version of the data entry example script I put together that allows display of records as well as entry within the same fields, enabling the user to update existing records. We could adapt this approach to the Fnotes entry form as well.

[bumpersp]

Cool. That sounds good. Along that same vein. How would Fnotes actually differ from the Acanthonus Collections Table? These seem like silimar tables that i'm not sure they need to be separate? Isn't this table the "Field number" level table? Maybe that is obvious and all I need to do is created a UI for this particular table...I was origianlly thinking we needed another "Field Notes" table but I'm not sure that is true.

[bumpersp]

If we don't ahve another table for this, it does mean a considerable number of paramters will need to be added the Collections Table

[mkleinha]

I've been thinking about this a little as well. How much would the new fields overlap with the water quality table? Would it make sense to split the information from a field note between the collections table and the water quality table, or do we want to keep the water quality table reserved for water quality-specific collection efforts?

[bumpersp]

A fair number of fields would overlap, such as, temp, do, spc, turbidity, substrate, stage condition, riparian conditions. Things that would not overlap would be sampling information like seine, kickset number, shocking time, etc. I like having them separate just for the ease of mentally boxing them but i'm not sure there is a strong reason to not join them. We could just add a water quality column to the collections tab or include a "collection type" field to distinguish invert vs fish vs water quality collections?

I'm not sure i would want to split a field note into 2 different databases simply for effecieny of entry-but maybe that's not that big of a deal. I could potentially be persuaded of that. Perhaps if the UI entry form has multiple submit buttons? One for each section and the submit buttons would push data to seperate tables but all within one entry form?

[mkleinha]

I see. If we did split the information into multiple tables, I'd definitely want that to be something the interface does automatically without the user having to remember multiple steps. The interface would also have to join info from both tables for displaying fnotes. I don't think either of these things would be particularly difficult. On the other hand, the number of field notes will probably be relatively small compared to the scope of imported data from other sources. Having a separate table with some redundant storage of values might not be prohibitively memory intensive. On the third hand, it might be nice to have all our water quality info in one table for things like map queries for water quality info and for joining species to sites to water quality like we discussed. I dunno, we could do it either way.

[bumpersp]

Well, let's both think about this a bit more and perhaps we can discuss this tomorrow? since i ended up not going in the field I've proabably done sufficient work to meet tomorrow if you would find it useful.

[bumpersp]

I made a draft field notes table that includes all of the fields from the Fnotes in file maker (excluding fish portal). This is just for us to see what paramters we have. Below the parameter (column heading) i listed an existing table that shares these fields so that we can see where overlap occurs. We could think about substructure like we have for subcollections. Mabye collections and collections_habitat? collections would have all information except for water quality and habitat parmaeters (like substrate, flora present). Collections would have the sampling information and notes? fnotes_fields_overlap.xlsx