highlighter is currently extremely trusting (vs eg possibility of SQL injection) because if you're doing a malicious injection into your own data I think you have larger problems than whether a tool running on localhost saved you from it.
2. Why do it anyway
I want to host highlighter remotely with a stripped-down database to simplify the process of having other people come in and test inter-coder reliability. This prevents user error installing/running locally (or user resentment of npm or whatever) and removes the step where I have to have people send a large file back to me etc.
3. Differences from highlighter main
Things that are daunting are in italics.
Sanitization (see point # 1)
Some level of user identity (i.e. login credentials) to differentiate people a) from randos, b) amongst themselves
Ability to track multiple people's individual viewings and encodings (see above)
Integrated dummy training data (must not overlap with testing data)
The scary parts have the redeeming feature of being an excuse to learn to roll WebAuthn. Absolutely refuse to get into the "responsible for passwords" business. Cursed affair.
Ways to make having users more navigable for me:
Interface for showing differences between two iterations of a database (i.e. coders between themselves, or checking against me) without having to edit in each address
Side-by-side statement display for skimming differences (exact word selection is less important than "was this code ever applied to this body text?")
Ability to filter by code used in single or comparison display
3 also. Just shove in filters like the project name is Brita over here.
Dynamic assignment of approved samples to coders (e.g. for 4 people doing 50 each guarantee evenly distributed random overlap without perfect duplication)
Statement database adds coder assignment tracking
Features for users:
Diff "flag" in the "I want to come back to this later" and a "report" button for "Cyrus holy fuck"
Comments, everywhere, as options. Definitely comments. Anything I can add the ability to add commentary to I will.
Open glossary in its own tab maybe? Ability to add clarifying notes to self in glossary?
4. Anticipated problems
Q: Keeping desktop highlighter and website highlighter in sync
A: Same kind of casualty of "welp, this is the issue with being the owner of both dev and prod" that having my local (using) highlighter installation existing at the same time as this one does presents.
Conclusion: New repo when I decide it's time to actually do this.
Q: Other people wanting to follow suit for the web version (that would be cool)
A: See above; maintain same "public version contains development, bugs sometimes, dummy database" distinction, port features resulting from deployment backwards
Addendum: gitignore database files, deploy from here maybe. Depends what works.
Q: a11y or display issues for volunteers
A: Beyond baseline attempts at best practices plus making things accessible to me (i.e. design motive here), address as needed, highlight as a concern with are-we-sure-this-works pre-usage testers.
Corollary: Anyone who wants the text size to be small can ctrl+- I'm pretty sure. But jokes aside I worry about assuming covering the bases for my own disability is enough, like, constantly.
Q: Risk of people making inappropriate disclosures in raw data
A: scrub scrub mother fuckers
Note: More seriously, I'm doing multiple rounds of data cleaning to interact with this data at all, but selecting samples (as randomized as possible but it's not going to be completely unmonitored, that sounds like a nightmare) for coder verification is going to involve as excessive of additional checks as I'm capable of imagining. Doubly so if and when stage three happens.
Q: Yeah but what if I also rewrote it in Phoenix, I just think--
A: Alexander, for fuck's sake.
5. To do
[ ] Set up a milestone/project pair for this
[ ] Make explicit list of features I want in highlighter main beyond "working" before this is worth working on (e.g., wait for #75 ? for #63 ?)
[ ] Badger people for feedback on interface as in something they could imagine themselves using before starting this
[ ] Deployment options research
[ ] Security options research
[ ] "All right, what does talking to an IRB about this look like" research (for third stage)
[ ] Break things in this master issue into actually actionable issues eventually (not now) (when you start working on it) (Alexander I swear to G-d)
[ ] Ask people what would make my codebook usable for them.
1. Non-negotiable concerns
highlighteris currently extremely trusting (vs eg possibility of SQL injection) because if you're doing a malicious injection into your own data I think you have larger problems than whether a tool running on localhost saved you from it.2. Why do it anyway
I want to host
highlighterremotely with a stripped-down database to simplify the process of having other people come in and test inter-coder reliability. This prevents user error installing/running locally (or user resentment of npm or whatever) and removes the step where I have to have people send a large file back to me etc.3. Differences from
highlightermainThings that are daunting are in italics.
The scary parts have the redeeming feature of being an excuse to learn to roll WebAuthn. Absolutely refuse to get into the "responsible for passwords" business. Cursed affair.
Ways to make having users more navigable for me:
3 also. Just shove in filters like the project name is Brita over here.
Features for users:
4. Anticipated problems
Q: Keeping desktop
highlighterand websitehighlighterin synchighlighterinstallation existing at the same time as this one does presents.Q: Other people wanting to follow suit for the web version (that would be cool)
Q: a11y or display issues for volunteers
Q: Risk of people making inappropriate disclosures in raw data
Q: Yeah but what if I also rewrote it in Phoenix, I just think--
5. To do
highlightermain beyond "working" before this is worth working on (e.g., wait for #75 ? for #63 ?)