Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Interface for managing data fields #130

Open
dreams-togo opened this issue Aug 21, 2024 · 1 comment
Open

Interface for managing data fields #130

dreams-togo opened this issue Aug 21, 2024 · 1 comment
Assignees
Labels

Comments

@dreams-togo
Copy link
Collaborator

There are currently two interfaces for selecting the data fields: there is the collection of checkboxes when one first sets up the transcription package, and then there is the one that also allows control of field order, field widths, colour, etc. It will be easier on transcribers to have just one interface. This interface would include a view of the register image so that transcribers don't have to memorise the order of the fields, and it would include a table of all available FlexCSV fields for the event type. The table would need one column of checkboxes for controlling whether the field is to be written to the CSV or not, one column of checkboxes for controlling visibility, and additional columns for controlling width, colour, etc. The gear button, which the user is supposed to click to have the attributes for that field accepted, can be dropped, as this seems unintuitive. Instead attribute values could either be accepted as they are changed, or all at once when the user clicks the Back button (which could be labeled Submit to make it clearer). Ideally, the order of fields would be controlled via clicking and dragging rows in the table, but if this is not possible, then the current system of typing in ordinal numbers can be used-- but this is cumbersome, and the more time users spend setting things up for each file, the more desirable it will be to allow them to save their own layouts, which would be tied to individual accounts rather than global, because there will be too much variation in personal preferences.

@BevStubbs
Copy link

BevStubbs commented Aug 22, 2024

Sounds good as long as you can still go back and add another field or hide one if you come across a less common field not on the reference image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants