And a problem when submitting no changes:
I added some early mockups to the ticket, have a look and let us know if any of this would solve the problem. Or if Iâm missing the mark.
Looks pretty good, I personally currently prefer the ones where the difference is more obvious: different background in 4 & 5 and the lines in 7 & 8 (all of these also works best when zoomed out). It also looks a bit weird that the headline âperformanceâ and the selectable âarranged/arrangerâ currently is on the same level. Youâve also highlighted how bad the indentation currently is, so increasing that is a minimum imo if you decide to do any changes, because it really helps a lot when distinguishing between the different options. Increasing the indentation + make sure that the headlines are not on the same level as selectable options might be the way forward? âBoldâ is afaict now used to show the selected item, which I like because it matches how the relationships are shown after the pop-up window is closed, but this also means that it probably is not a good idea to make the headline âboldâ. I also have no idea if you plan to introduce more colours here in the upcoming redesign, which could be an additional option to somehow make the distinction a bit clearer.
Some lines are headlines and selectable, so this isnât a clear difference imo. I wouldnât want some headlines to look really different when Iâm scanning the page looking for groupings/headlines. Does that make sense?
I also thought more indentation seems a pretty clear way to improve this in general.
Oh, I didnât realise that the real problem is that headlines can be selected. I guess this is similar to the old âguitar familyâ and âmembranophoneâ problem then. It really only becomes a problem in edge cases like this where you have something that should be both noticeable (headline) and not be noticeable (canât be selected) at the same time, which obviously is not optimal.
Increasing the indentation makes the difference much clearer, but there will be an inconsistency which means that some headlines are harder to spot than others. You went with only light-grey for âcanât be selectedâ which makes sense because thatâs how most websites does it. In the old MB rel editor you combine light-grey text with a dark-grey background. Replicating the old MB css style (which also have bigger indentation) OR adding a new headline to âarranged/arrangerâ (all of the other selectable items are already on level 2) plus new unique css to the headlines, seems like the two best solutions to me.
Basically, thereâs no such thing as a headline, in concept, right now. Thereâs ârelationships that can be selectedâ (black) and ârelationships that cannot be selected and are only used for grouping othersâ (grey), but they all live in the same tree. For example some entity combos (like artist-event) have a lot of top-level selectable relationships plus one used for grouping, and some (like event-recording) donât have any grouping types at all. So, itâs kinda weird and itâs hard to decide âthis is a heading but this is notâ
This is now out, thanks for all your help! That said, if some of you who werenât usually using beta keep using it in the future, it will surely help us find more issues with our changes before they get released to everyone, so weâre thankful to anyone who decides to stick around as a beta tester
It looks like a feature regression slipped through. IIRC previously it was possible to expand dates on relationships by adding them anew.
Edit by @yvanzo: now tracked as [MBS-12966] Regression: Specifying an attribute to a relationship duplicates it - MetaBrainz JIRA
Yes, my edit there. I commented on that earlier in this thread. Quite annoying, especially since batch-helping scripts no longer works.
One thought after using the editor a bit: Would it make sense to hide the âThese relationships have a specific orderingâ checkbox on relationships that donât actually have more than one value? In the common case of a single recording being linked to a single work this checkbox takes up space and the unconditional plural is a bit confusing.
Edit by @yvanzo: now tracked as [MBS-12967] Hide the ordering checkbox under lone relationships - MetaBrainz JIRA
This is a mess left after a merge.
On the left we see Imperial March is added twice. But this is now not shown on the right. I canât see any mention of (cover) like in the past.
Imperial March should appear twice on the right in this image.
The release in question: https://musicbrainz.org/release/3e68c7c1-4a01-43c2-a14a-7f72fae2abd8
(I have now added edits to clean this up⌠so the error will not show next weekâŚ)
Edit by @yvanzo: Now tracked as [MBS-12968] Regression: Release relationship editor's âRelated Worksâ column is missing recording's attributes - MetaBrainz JIRA
Also, when I do mark the works to delete, this is not being shown on the right hand side
By seeing all the duplicated errors on the right hand column it makes it easy to clean up messes caused by merges. Not seeing this make duplicated work errors very hard to spot. I assume this is an unintentional regression?
Edit by @yvanzo: Now tracked as [MBS-12969] Recording relationships are not shown as deleted in the "Related Works" column - MetaBrainz JIRA
Yes to that 2 remarks.
And actually, the right-hand side no longer really shows the recording-work relationships.
It is now more a list of works that appear on the recordings.
Slightly off topic
I used to be able to mass apply recording dates on several recording-work relationships but, now, on a release with studio and live recordings of the same works, I can no longer mass set dates on live recording-work relationships only, or even not at all.
But it was a feature from a userscript, so it doesnât count much.
Maybe I will find a way with the new layout.
I find it quite a large regression as now it is hard to see dates, cover, live etc. This was very useful in the past to allow quickly seeing when duplicate works are attached and fixing the issue. And the Dates feature you mention was really useful for concerts. I hope this comes back.
Maybe I do too much editing âtidying upâ artists \ releases. This change makes it hard to quickly fix a multi-disk release as you canât see the errors now.
@bitmap paid a particular attention at keeping support for userscripts during the beta period, with the noticeable help of @kellnerd. If your script is broken, it is likely it can still be adapted to work with the new implementation. If that is not the case, please open a ticket or get in touch with them on IRC.
For what itâs worth, itâs not a bug that it only shows once: itâs intended, because the right just shows âworks related to this recording and info for themâ now, while the left shows, among other things, âway this recording is related to said worksâ.
This thread is largely off-topic since the beta version discussed here has been released.
All regressions and improvement requests posted in this thread after that are now tracked as tickets; See links added in the posts. So Iâm closing this thread now.
Please consider adding a ticket directly (with open registration/login using MusicBrainz account) to report further issues, as structured information is much better for issue tracking.