Adjust User Interface(UI) for different "data types"

[JakobMiksch]

The current UI is very overwhelming for many users. There are ideas how to improve it:

• Many many tabs for the plugin
• each tab should contain as few information as possible
• the tabs are green or red depending if the content is valid or not
• ...

[andersfi]

I think one of the things I learned today is that likely one is trying to do to much in one application. That creates a lot of buttons to push, and a steep learning curve for usage.

[ninsbl]

I do not know how the test worked today, but I would expect there are some trade-offs between different interface solutions (one big interface vs. several simpler windows). We had a solution with the standard forms which had drawbacks that made us go the plugin way. In principle I would say the current solution is very good in that sense that it saved a number of clicks and simplifies especially the issue users had with the concept of "toogling layers into edit mode". We should also bear in mind that Darwin Core is complex, esp. f we aim at getting full DarwinCore records. Maybe a solution could be to highlight mandatory fields and to make optional fields less prominent. It could also be a possibility to adjust the interface based e.g. on a kind of sampling protocol. E.g. deactivate all quantitative fields for sampling protocols which do not produce quantitative data... Just some thoughts on that matter.

[andersfi]

Full records (i.e. datasets containing all relevant terms) are complex are rarely, if ever, used. I think for further development it may be worth while thinking in lines of different "data types" that may or may not be in line with the sampling protocol. This would, however, require some thinking up front.

For the current applications, I think that there are two/three principally needs for an non-programmatically interface in terms of data adding (besides the most obvious, which is an explicit link between the biological data and waterbodies and then the spatial part of the database - without this one could just use artsobs or iNaturalist user interfaces instead)

1) The possibility to screen through existing occurrences on map, and update the database 2) Easily add new occurrence records, with graphically (i.e. through map) locate the water-bodies from which they have been observed.
3) Batch add occurrences of species to several lakes

The visual control against maps are important, and the reason we are using QGIS for this in the first place (I guess). When I mean "occurrences" in these therms I mean the datasets that referrers to observations of fish, introductions and stock status. These are always linked to locationType = "waterbody centroid", and to a subset of SamplingProtocols. So, my suggestion is to start simple, grey out non relevant terms (i.e. they could be there but not active) for the moment (if easier than rewriting the whole code) and get things working for these relatively simpler data-types. Once the simple stuff is working, one could think about going further on adding more complex data-structures.

There are a couple of issues left that I don't really know how to solve. The first and principally is off course that organising the data according to a data-model based on DwC is quite new to most researchers and technicians, and writing a fully fledge manual for documenting this is beyond the scope of the INVAFISH project. One could however write documentation on how the different datasets are organized in terms of fields and tables (i.e. metadata), but that's another story. The second that came to my mind is that we have some issues with who has write access to different datasets. Although there should be possibilities for row-level authentication in postgres 9.5, I have no idea on how this works. Another way around that came to my mind is working through updatable views, specific for each dataset. Is that a possibility?

[ninsbl]

From Anders last comment I would extract that we do not want a complete new interface, but rather adjust the current one for different data types if needed. We can maybe even close this issue and open a discussion about adjusted UI when that is really an issue...