trompamusic / music-scholars-annotator Goto Github PK

We updated the solid library that we use to authenticate to a pod. This has some new functionality to manage permissions, which we added in the annotation component. We need to re-implement that functionality here

I'm posting these comments here for information, and so they have some visibility to MELD developers... They are based on my experiences creating hello-meld-4 and hello-meld-5 through adaptation of TrompaMusic examples, work conducted as part of a small Software Sustainability study based on MELD.

• there appears to be no selection type for whole piece (e.g. no fragment): I would have thought being able to attach annotations to the whole piece is a fairly common requirement?

• In annotationItem.js, about line 600, code does a crude attempt at URI resolution. A better approach would be to use a URL handling library to do the resolution properly. E.g. rdflib.js contains a module rdflib.js includes https://github.com/linkeddata/rdflib.js/blob/master/src/uri.ts. https://nodejs.org/api/url.html or even https://developer.mozilla.org/en-US/docs/Web/API/URL/URL would be better options.

• In selectablScoreApp.js it's not clear why the motivation switch logic is required - it appears to be setting class values on annotations. E.g., why isn't this handled in annotationItem.js?

• I would have liked documentation of "<SelectableScore>" abstraction used. [Documentation issue noted in SSI report]. I did later find documentation at https://github.com/trompamusic/selectable-score - maybe place a link in a source code comment?

• I found the music-scholars-annotation code structure seems to entangle a number of different concerns; e.g. duplicated logic between annotationItem.renderSwitch and selectableScoreApp.onReceiveAnnotationContainerContent (refactor for DRY?).

  A particular thought I had for this was that each annotation type could be implemented as a separate React element, with all of the associated logic in a single module. Then, at the level of (something like) annotationSubmitter.js/annotationItem.js, the appropriate annotation type element would be selected, and avoid the need for further tests. Maybe use an "annotation object factory" element to encapsulate all the annotation switching logic?

Replace auth library with solid-client-authn, and instead of using meld-clients-core to read/write annotations, use the SolidAPI from trompa-annotation-components

It'd be nice to show a list of all annotations for a work rather than having to look on the score and click a box before seeing the contents of the annotation.

This could be a list of annotations on the left hand side, including information about the bar that the annotation is in (we'd have to find the elements that are in the annotation target and then count the bars in the score to determine this)

Clicking an annotation should highlight it on the score. Clicking an annotation that isn't on this page should flip the score to that page.

When we make a selection (e.g. of notes) and then save an annotation, the selection stays made. We should undo this selection once the annotation is saved (but not undo it if there was an error when saving the annotation)

When we added the navigation menu bar to the top of the app and moved the position of the score div, the boxes that we use to draw around a measure to say that there are annotations have ended up in the wrong place.

A few improvements that we can make to this:

• Ensure that the <SelectableScoreApp> component renders all of its children inside a bootstrap grid layout (#15)
• Try and see if we can identify the top of page offset of the score svg automatically, so that we can draw the boxes in the right place regardless of the score's position
• In order to make the SelectableScoreApp component easier to understand and follow, it'd be good to move the code that does the annotation processing and box drawing into a set of well defined utility functions, in order to make it easier to understand what the code is doing and separate each specific sub-part.

Overall page needs a rework

not really sure if this is possible based on how SOLID works

Initially reported in #9

The <AnnotationSubmitter> expects to receive a list of targets (i.e. selected notes or measures) that are being annotated. If no items are being selected, the annotation should apply to the whole file.
We should ensure that there is some indication about what is happening in this case - maybe some text that pops up if you start writing an annotation - ("This annotation will apply to the whole score"), or a specific checkbox that the user has to select to indicate that they want to annotate everything.

If some types of annotation can only be applied to a whole score, or only to a specific element (or elements), then we should disable them depending on what music elements are currently selected.

User was not able to find it and complained about the lack of a help section

The user would like to see how much %s of zoom they are using.

If we want to continue development on this app after trompa support has finished, we should develop a way to search the collection of early music scores from CPDL without using the CE.

Currently the cue media input for an annotation requires an input of a link and a timestamp. Once a link is added we should show the media player from t-a-c, and allow the user to play back and select a range interactively to set the timestamp.

When displaying annotations, such an annotation should be rendered with the audio player with the indicated range selected.

Take an annotation that's saved in solid and re-save it to the CE

User wants a quick way to reset the zoom level to the initial amount

Instead of the custom composition selector that we have in the f-tempo search part of the app, replace it with the multimodal compoment.

Once an annotation has been publicly published (#21), we need a way of showing all public annotations (including ones by other users)

We currently have 3 trompa-specific motivations used in the annotator: trompa:cueMedia, trompa:cueImage, and trompa:playlist. These motivations aren't defined anywhere. We should create custom motivations in the CE which represent these motivations so that linked data agents can determine what they are (i.e. what their skos:broader is)

Currently in AnnotationList/AnnotationItem there's a bunch of code which manually modifies the dom based on user selections to hide/show annotations and replies.
This should be rewritten to use state/props to indicate which items to show or hide, allowing react full control of the dom.

Search should be able to be used by people without logging into a solid pod.

We can replace the "annotate this score" button with something that says "Log in to annotate" if the user isn't logged in, and then allow the rest of the app to work.

When we are loading the score or the annotation there is no indication that we're waiting for something to happen.
There was a "loading" div that we showed and hid, but this isn't a good way to manage the layout of the app using react.
We should look into perhaps creating some hooks that allow us to obtain a loading boolean when while items are still being loaded.