CSV exports for the new publication platform

[dersmon]

Open questions:

• Do we even want a CSV export for the new platform or is JSON (the native format) enough?
• Do we want to mirror the structure of the CSV used in the desktop client (for import into desktop) or should the focus be more of a usage beyond the whole Field software system?
• Do we want an export for individual documents or is the (native) JSON enough on that level?
• Do we want an export of all data in a publication? What would that look like concerning multilingualism?

[lsteinmann]

Do we even want a CSV export for the new platform or is JSON (the native format) enough?
I'd say yes, we want CSV. From my experience, most people would want to create some summary statistics and overviews or plots using spreadsheet-software. Our typical user does not deal with JSON on a regular basis. (I think.)

Do we want to mirror the structure of the CSV used in the desktop client (for import into desktop) or should the focus be more of a usage beyond the whole Field software system?
Of course, being able to import these into Field Desktop would be great. But we might want to handle that in a different way. If we assume that people would use the CSV exports/downloads as mentioned above, it may be a good idea to structure them differently and replace the database keys / background values with the Labels translated into the currently selected language, or including an option that allows users to choose which one they want? So, I'd see more value in focusing on the usefulness of these exports beyond Field.

Do we want an export for individual documents or is the (native) JSON enough on that level?
I'm currently not sure what people would do with such an export of a single resource, to be honest, but it still seems reasonable to offer it in some way. Maybe the JSON is enough here, or for the case of single resources it could be useful to have a PDF export which would look a little like a catalogue page.

(Maybe something like: "mark for download", where users could mark multiple resources that they want to export and then get all of them together as a csv export? But what would be the purpose of that...?)

Do we want an export of all data in a publication? What would that look like concerning multilingualism?
And what would it look like concerning different categories? In which formats would we want this...? Technically: Yes, this would be the most useful thing for further working with the data from a publication. Language wise I feel like allowing users to select a language would be best. If not everything is available in that language, then that is a data problem, not an application problem.

[dersmon]

I also think downloads to be imported in the desktop client should basically be backups (as if created by another client).

The complete CSV download in the publication portal should thus probably be geared towards analysis.

[lsteinmann]

Now we only need to figure out what would be optimal for analysis - that probably depends on what programs & methods we would assume people might use. It might make sense to just ask around in some random projects, or via the field-users mailing list. What do you think?