We plan to release a new server update soon which rewrites most of the relationship editor code and makes some improvements. The new code has been on beta for some months already, with steady updates in between, but we’re nearing a proper release and wanted to give one final call for testing:
(Remember that the beta server uses the live database, so any edits you make there affect the live site too.)
On most types of entities you can access the relationship editor under the “Edit” tab, except on release pages where it’s under “Edit relationships.”
The most visible changes are in the release relationship editor. Some changes you might notice:
We tried to make the interface more consistent between the release relationship editor and other entities, so the release version now looks more similar to the others, using icons to edit the relationships and grouping them by relationship type. (That’s MBS-7981.)
The relationship type selector now has a search function, and remembers which types you’ve recently selected.
“+” icons have been added next to each relationship group to let you quickly add another relationship of the same type (with the type pre-selected).
The general “Add relationship” button now remembers which target entity type you last selected.
The “Batch-create new works” button no longer creates works immediately: it waits until the entire form is submitted. You can edit the name, work type, and languages of individual works before they’re created.
You can reorder works in the release relationship editor (if needed).
You should be able to edit relationships for releases with a large number of mediums or tracks without the server timing out. (Like the main release pages, mediums can be collapsed and expanded as needed.)
Besides these changes, other goals were to try and reduce the number of bugs and make it easier to add new features in the future.
As the banner message on the beta site says, “some interface changes are intended, but if anything there doesn’t work as you feel it should, or a change seems like a significant downgrade after testing for a bit, please do let us know.” If you do find an issue, the best way to report it is through https://tickets.metabrainz.org/ (where you can log in with your existing MusicBrainz account).
Thanks for the heads-up! Just to check, there are no expected differences related to seeding, right? I haven’t noticed any yet, but I figured it’d be good to confirm.
From my own limited testing, query parameters like rels.0.target and rels.0.type still function properly when seeding artists and works via GET requests. I assume that there’s still no way to seed non-URL relationships in POSTs to https://beta.musicbrainz.org/release/add (since the relationship editor isn’t exposed in that page – as an aside, are there plans for that to change in the future, so that relationships can also be seeded when adding releases?).
There shouldn’t be any breaking changes related to seeding (thanks for trying it!). I only recall working on two tickets related to seeding recently, MBS-12849 (which lets you seed source_credit and target_credit) and MBS-12850 (a bug fix).
You’re right that there’s still no way to seed non-URL relationships through the release editor. I think that’s something we’ll allow in the future, but probably only for release relationships (not recordings or works), at least at first – i.e. we might embed a mini-relationship-editor for the release but not the whole tracklist. But the release editor needs to be converted to React before that’s possible.
one thing I’ve noticed, the “Change credits for other relationships” button doesn’t always seem to work. I haven’t tested it thoroughly, but it seems to happen sometimes when you’re adding new relationships, not when you’re editing old ones… I’ve gotten it to happen a couple times while editing this release, if that helps. could have something to do with the collapsible sections too, as I’ve been taking advantage of that~
also, a couple minor things while we’re here, I wonder if the “Credited as” fields (both artist and instrument) could be auto-filled from previous adds on the release? that would be a major improvement in my opinion, and at worst would be an additional backspace if the artist or instrument name is inconsistent across the release.
Edit by @yvanzo: Too big changes to be done any soon but it will certainly come up again in the future.
I am also noticing that entering an edit takes a good bit longer with the new relationship editor… I wonder if this is an easy fix or not? it’s especially apparent when making changes to several tracks on one release. for example, the release (linked above) which I’ve been testing the relationship editor with. I’ve been doing like, 10-15 tracks at a time, and it takes a good minute or so to save my edits…
It takes longer to save the edits because it submits them separately rather than in one go (which means if something errors you can fix the error and continue from where it stopped, and also should mean that it won’t time out anymore when submitting a ton of relationships). I agree it’s quite noticeably slow though, and I do wonder how doable it would be to batch the submissions, but in smaller batches unlikely to overwhelm the server.
@jesus2099, thanks, we’ll need to figure out a better solution then
Unfortunately we can’t keep the relationship phrase text clickable, because it groups multiple relationships now.
Some ideas off the top of my head, some of which may be mutually exclusive:
Add more spacing between the icons (won’t help with them being too small)
Increase the icon sizes even more (which will increase the vertical height of all relationships, causing more scrolling, etc.)
Remove the “x” icons and have a button to remove the relationship inside the dialog instead
Remove the edit icons and make it so that clicking on the target entity name opens the edit dialog (may be confusing, and if you wanted to navigate to the target entity page, you’d have to click on a link inside the dialog)
To be fair I agree the icons are a pain to use on mobile. I don’t have any issue with them using a mouse, but probably because I use a scaled resolution to see everything better.
not sure if this is the right place to put it, but I got a pretty bad looking error when I tried to add a begin/end date to an artist relationship… this is on the recording relationship editor, not the release. it popped up after I hit “Done”
Error: The given value was not found in the tree: [object Object]
at l (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1583963)
at L (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1030990)
at Object.p (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1585256)
at Z (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1031236)
at Object.p (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1585256)
at M (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1031533)
at Object.p (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1585256)
at z (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1031772)
at p (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1585256)
at Object.p (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1585401)
at F (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1033111)
at Ze (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:956195)
at https://staticbrainz.org/MB/common-chunks-573fed4.js:2:954609
at https://staticbrainz.org/MB/common-chunks-573fed4.js:2:873312
at Object.To [as useReducer] (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:162607)
at IAYK87R.t.useReducer (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:235176)
at c (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:957649)
at wo (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:161331)
at Cs (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:182200)
at wl (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:219488)
at yu (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:207563)
at gu (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:207491)
at mu (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:207354)
at su (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:204499)
at Ui (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:145617)
at https://staticbrainz.org/MB/common-chunks-573fed4.js:2:202102
it only happens on the beta site, so I’m guessing it’s something in the beta…
I’ve mentioned it before and will mention it again. The new relationship can be disastrous for certain workflows, especially on smaller screens where low display resolutions are still common.
Here is an example of how fast and straightforward e.g. changing the direction of a relationship used to be (using Tab ↹):
And this is how it would look like with the new relationship editor:
Since tabbing is no longer viable one would have to use the cursor:
It’s easier to misclick, the layout is shifting and requires considerably more space. On a small screen with a low resolution it might not even fit the viewport. (Not to mention the space needed when help text is displayed)
As you can also see when tabbing through the dialog it will automatically select some attributes.
How about utilizing more of the available horizontal space, e.g. putting attributes to the right?
Attributes are optional so it might make sense to not place them where they are “in the way”.
In the recording column unloaded mediums are checked by default but can’t be interacted with while in the work column they are unchecked (and can’t be interacted with either)
Maybe it makes sense to disable checkboxes for unloaded mediums to make it clearer they can’t be interacted with?
Also I’ve noticed layout shifts in the work header when batch checking:
If that button is last in the tab order, use SHIFT+TAB to run backwards.
I do agree with you it is a bit of an odd place to put it. Breaks the flow when reading the page. The current location is more natural when reading and comprehending the page.
Also how many Relationship Type would ever need a text box that wide?
Filling this page in from empty would be an even stranger work flow. You pick a relationship and then need to play “Hunt the button”. Not very clear for a new user and even worse for someone tabbing the page.
Is there testing for non-mouse users? I am thinking disability/accessibility design.
