del82 / ezra Goto Github PK

Make a more robust front end for managing target level features.

https://github.com/del82/ezra/wiki/User-roles#creating-features-101

• feature#new contains forms for feature name, instructions, type, possible values, associated targets
• feature#new contains prominent help information that explains, for each field in the form, what its purpose is and (if applicable) what its values mean.
• feature#new: if user types in a feature name that already exists, when she navigates the cursor away from that field a message appears informing her that another feature exists with that name and she should choose another.
• feature#new: there is one input box for each possible feature value, and users may add or remove input boxes at will.
• feature#new: if the user attempts to remove an input box for a PFV that is not empty, a confirmation dialog appears reminding her that the information in that box will be lost if she removes it
• feature#new: user may select targets that the new feature should be associated with
• feature#new user is able to inspect the targets in more detail to ensure she's selecting the ones she intends to (bearing in mind that multiple targets may share the same phrase)
• feature#new: user is able to associate the feature with only the targets she has created
• feature#new: after clicking "save", user is redirected to the feature#index page, and a flash message appears confirming that the feature she created has been saved.

I think at minimum, an admin should be able to assign tasks to a normal user. These would show up on the user's page when he/she logs in.

There a few extra things I can think of:

• (#9) a recent target, so the user could go to ``user/user#/recent` and go right back to their most recent target.
• (#10) restrict users to only the targets they're assigned
• (#11) stat collection per user per target. the user/admin could then see his/her personal stats

A necessary prior step to MATLAB integration (#4) is integration with the forced aligner, so in addition to spitting out mp3 clips and annotation files, we also get wavs and textgrids.

Setting a window_start to 0:0:0:0 causes the POST to submit NaN, which fails validation and prevents updating.

If the purpose of the application is to streamline users annotating data, do you think it'd be worthwhile to remove Targets/Users/Features entirely from the basic user's capabilites?

Or perhaps an Admin interface that could restrict access, rather than hard coding it?

obvs.

When certain fields are changed in the hit edit screen, the "No changes" button fails to change to "Save changes" to indicate that the hit record has been changed.

I've added specs covering this behavior in the master branch on commit 917100f9adcf4bd60b902381e2e7fd0fd52d6eec

It would be nice to be able to allow multiple independent judgements from different annotators for specific feature values. That is, one annotator goes through and sets a value for a particular feature, then another annotator goes through and sets a value for the same feature without knowing what the other annotator's judgement is.

Add fine-grained user-access controls to limit annotators' abilities to view/edit targets not assigned to them (which will be possible once issue #2 happens).

When there are no static pages in the database, there should be some boilerplate fallback page that comes up.

In the production environment, the server returns a 500 instead of the hit#edit page when it's requested.

When a session expires, a flash message (alert.alert) appears containing only the word 'true'. This is in addition to the expected flash message about the session timeout.

The hits on a ``target#show` page should paginate so that they're not all shown at once.

Audio path information is currently hard-coded, as a quick fix of issue #28. But it needs a more intelligent fix.

The footer should appear at the bottom of the content or the bottom of the browser screen, whichever is lower.

I've added a notes field to the hit record as a place for users to put arbitrary notes about an individual hit. This field now needs to be added to the hit interface.

Mp3s don't load. Ideally the solution to this will allow some customization of how to request audio files and not a hard-coded site-specific solution. Ideally.

https://github.com/del82/ezra/wiki/User-roles#creating-features-101

• clicking the "features" menu bar item takes users to feature#index
• clicking the name of a feature on feature#index leads to feature#show
• for admins only, feature#index contains a link to create a new feature which takes users to feature#new

In the annotation screen, a number of things refer to the "transcript", which in context must mean something like "part of the audio that is selected and which the transcription transcribes".

This term is confusing. There is an actual, textual "transcript" right there, but you are using "transcript" to refer not to that but rather to a selected portion of the audio.

May I suggest you change "transcript" to "selection" or something like that?

Activity tracking for users and targets. This would allow stat collection per user per target. the user/admin could then see his/her personal stats and those of the users she is supervising.

It'd be cool to have a button for each hit that allows users (maybe only admins?) to download that that clip immediately. Perhaps this could also create a permalink to that clip.

Tasks:

• audio type detecting (mp3 at the moment)
• permalinks (likely via redirect to the locally saved file if the path exists)
• user restrictions

It would be nice to have some sort of visual display of the audio information on the hit#edit screen. It would be nicer if it were possible to click that visual display and set the various relevant timepoints for the hit.

Admins should be able to export the data once annotations are completed. Exported data should include:

• the audio clip (mp3 or wav?)
• the transcript
• other annotations in a reasonable format
• alignment? (issue #8)
• ...

Administrators must be able to create and edit features.

Pressing the "play transcript" button when the audio player is not already active doesn't do anything. This is confusing. It seems to me that pressing the button ought to cause the audio player to become active and to start playing the transcribed region. (It works as expected when the player is already active, of course.)

For each user add a recent target, so the user could go to `user/user#/recent and go right back to their most recent target.

I propose that the "save changes" button be broken up into three: "Save and next", "Save", and "Cancel".

"Save and Next" is the default behavior now and will likely be the most used version, but I think users should also have the option of saving and not nexting. The cancel button is strictly speaking unnecessary but might make people feel better-- It could force a reload of the page (thereby resetting the hit data) or just be a link to target#show or some such.

I like the visual indication of when a hit has changed that the current button is giving us, and I'd like for that to be in the interface somewhere, but I think separating that from the save button is a good idea. This will also allow us to write request specs more easily without dealing with the weird problems with Capybara and change events in the browser.

Thoughts?

The control button within the audio player that appears when you hit "Click to play" in the edit page for a hit is broken.

The edit button for hits in the target is blank (which is not how it should be, I gather).

Ditto for the individual page for a hit.

No two features should be permitted to have exactly the same name, including names that differ only by case or spaces.

Admins should be able to import hits into the database. Initially this can be some sort of batch import from a file containing full audio file location, (purported) hit location, and optionally transcript info.

I can't flag a hit, straight up.

I can edit and save every other property (transcription, transcript points, features, category), but when I check "flag this", it doesn't stick after I try to save changes.

This recourse could be something as simple as displaying the name of the audio file (with which there is presumably a problem) or as involved as creating an interface for (re-ºdownloading the missing audio.

Integrate it, yo.

https://github.com/del82/ezra/wiki/User-roles#updating-features-101

• feature#index: for an admin user, all and only the features created by this user have an "edit" link in the feature index
• feature#index: the "edit" link takes the user to feature#edit for that feature
• feature#index: when a user clicks the "edit" link, if the feature has already been assigned to targets, a confirmation box appears reminding the user of this and confirming that she wants to edit the feature. The box contains a list of the targets that the feature has been assigned to, and for each one it indeicates how many of the hits for that target have already been processed and how many remain to be processed. The box gives her the option to confirm that she wants to edit the target or cancel this action. If she confirms, she is taken to the feature#edit page for this feature

https://github.com/del82/ezra/wiki/User-roles#assigning-features-to-targets-via-the-features-interface-101

• each feature listed on the feature#index page contains the feature name, the feature creator's ID, the number of targets that feature is assigned to, and the first few words of the instructions for that feature.

There's no play button or time display.

Everyone loves stats. Everyone loves graphs.

We should make sure to keep in mind as we're adding enhancements, that we also have a way to retain that data for later visualization.

Like github!

It's handy that you can manually edit the start and end points for the "transcript" in the annotation screen. It's annoying that you can't do the same for the "location" of the hit. Why not add edit boxes to allow you to do this?

Besides making it less frustrating to mark the location of the hit, this would also regularize the interface, which is currently a little disjointed because of the way the location label is jutting out to the left of the text box.

The tabular index of hits in the hit index lists the name of the target in the second column. Why bother displaying that at all? As it stands, you can only view the hits associated with one target at a given time—so it adds no information to see the name of the target listed alongside its ID, confirmation status, and flag status. (Of course, if you are ever able to view hits associated with more than one target at the same time, this objection will no longer be valid.)

• Document tests that don't work
• Mark them as pending
• Manually check pending tests

Annotators need to be able to set feature values on the hit annotation page.

I think everything's in place on the back-end for this, and it just needs the interface written. Let me know if I'm wrong.

When I try to save changes to a hit I'm editing—or, for that matter, when I hit the blue "No changes" button—it sends me to an error message page.

Nevertheless, inspecting the hit afterwards, it seems that the changes I made were in fact saved. For example, the transcript still shows the edits I made, and the target index registers the fact that I marked the hit as "confirmed".

https://github.com/del82/ezra/wiki/User-roles#creating-features-101

• feature#show contains details about the feature, including instructions, possible values, and associated targets
• feature#show contains a link back to feature#index

https://github.com/del82/ezra/wiki/User-roles#assigning-features-to-targets-via-the-features-interface-101

• feature#show page contains a list of targets the feature is assigned to.
• for admin users, feature#show page contains an edit link if and only if the current user is the creator of the feature
• for admin users, feature#show page contains a link near the targets list that allows the admin to add targets for the feature.
• "add targets" link on feature#show page opens an interface for adding and removing targets to this feature. This could be a redirection to the feature#edit page if appropriate.
• after the target additions/deletions are saved, the admin is returned to the feature#show page

Not sure how to add the correct path so that if you click on the links in the targets/:id table it will link to a filtered list for that target.

Site-specific information, like static page content and config information should live in the database rather than in the repository. This is necessary for public release, as we want people to be able to get the application without also getting all the the static content and site-specific config.

Do we return to the User page? Go back to the Target page? Maybe we need to play around some more.

The columns in the hit index: what do they mean? The index does not say. What is "10012"? What's "false"? What are "1" and "0"? What's going on here?

https://github.com/del82/ezra/wiki/User-roles#updating-features-101

• feature#edit: contains all of the fields that the feature#new screen does, as well
  as the instructions on the feature#new screen
• feature#edit: contains a "save" and a "cancel" button. When the user clicks the "save" button, the feature is updated and she is returned to the feature index. A flash message appears confirming that the feature updates have been saved. When the user clicks the "cancel" button, the feature is not update and she is returned to the feature index. A flash message appears confirming that the changes were not saved.

The hit index gives four counts for the target's hits: total, confirmed, unconfirmed, and not present. When viewing the total hit index, these counts are fine. When viewing other hit indices, however, such as the index of unconfirmed or nor present hits (which you access by clicking the number under "unconfirmed" or "not present"), the numbers given are unusual. The "total" number is the number of hits just of that category, and the other categories are empty. This image shows what it looks like in the "confirmed" index, for example.

This is not necessarily an error, but it strikes me as a not-so-helpful way to present the numbers.