It seems you have tried these 2 right now.
Oh, I had made those changes a couple days ago after you left your comment here: [MBS-11847] Port the relationship editors to React - MetaBrainz JIRA
The icons are slightly larger on touch devices only.
If you’re happy with it now, then great! But I’m open to further suggestions if you have them.
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…
Developer edit: added MBS-12874 for this issue.
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”.
For unloaded mediums the chekboxes are a bit weird:
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:
Developer edit: Added MBS-12875 for this issue.
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.
That didn’t do the trick:
If you have been reading the Discourse upgrade thread you might already know I use a touch capable device.
So I’ve tried what it would be like to tap (no pun intended) instead:
(used mouse click to open the dialog)
Not really fun either.
The new layout would make that slower yes, but obviously whatever is now at the top would be faster? I don’t know if changing the position of the ‘change direction’ button would be that big a task though. I do think it makes sense to a new user at the bottom.
I’m not sure if it breaks accessibility stuff/browser functions and so forth, but have we ever thought about adding key shortcuts for MB edit buttons? e.g. alt-shift-c for Change direction.
Now that is a worry. It seems to have fallen off the dialog? That is a GUI bug.
I just tried it. OUCH. The dialog box just disappears. That ain’t good. Does the same if you TAB too far forward. It makes it impossible to use the keyboard 
TABing a dialog should go in a constant loop.
The whole of a computer screen should be accessible via the keyboard. Try any other application (and older MB pages) and you can tab between every edit box. You hit escape to hit the Cancel button.
Hit TAB to go to the next edit box, SHIFT+TAB to go back to the previous one.
You should not expect people to have to map new keys when there are already keys available by standard. Some people cannot use a mouse and need to rely on keyboard access. I deal with a lot of differently able people and you would be blocking their ability to edit the page by breaking standard interface design.
Other little tricks: When on a list box, SHIFT+DOWN ARROW will open the box. Enter selects an item. SPACE will operate a check box or press a button. Standard interfaces since at least the 1990s.
I can’t speak for the blind but maybe the blind could speak?
Almost two years ago I stumbled upon a user who said he is blind.
The point with computers is they make everyone equal. Computers are designed with multiple interface methods to allow for this. One of my clients has a screen reader. It is only if you sit with him would you know he has been blind since birth. Another of my clients uses a “head dobber”. You’d never know if you only talked to him through this website.
We should not have to rely on these people speaking up and testing the betas. We should design with them in mind.
The TAB key thing will be a bug. It works perfect everywhere else. I am a 90% keyboard guy and always fill in forms with TAB and SHIFT+TAB. Go try a normal edit page and you can just press and hold TAB and it will whizz down the page, when it hits the bottom it just goes back to the start of the tab order again and keeps whizzing away for ever. This new page just suddenly closes. Which also would loose your edits.
Developer edit: Added MBS-12870 for the shift-tab issue.
Note - SHIFT-TAB works fine. What it is currently “non-optimal” is when you TAB past the last item the dialog closes. What should happen is it should wrap from end to start. If you SHIFT-TAB back past the first item, the dialog also closes instead of wrapping backwards to the last tab stop.
I only have some general comments.
Like
Don’t like
Neutral
Developer edit:
That’s intended - the left shows the relationships, the right shows the works (once). It might not be the most intuitive though, given some comments on this thread.
I think that’s intentional either because that’s not always a 1:1 replacement for the instrument/vocals (for example, you’ll sometimes see opera singers listed as “soprano vocals [Role]: Artist”, where replacing “soprano vocals” with “Role” would probably not be an improvement - same for “violin [1st]: Artist”)
Them being grey is meant to show they can’t be selected, but maybe it can be made a bit more visible while still being clear. I added a ticket for that (MBS-12866)
Keyboard data entry - a followup. So it doesn’t just sound like bug complaints.
I want to add some loud positives to the way the keyboard data entry works on this new page. It feels good. Little short cuts like it remembering that I am entering instruments. Selecting things from the lists feels quick and smooth and tabbing works well. Also good to see the OK button focused so I can select the instrument and just hit ENTER twice to submit the data.
Double Plus Good. 
Or at least that is what I got when I added a number of works on the Relationship page. And also good when adding instruments.
BUT I have another little bug…
I am entering a PLACE. 100% by keyboard. So I am tabbing down the page. Only using TAB, Cursor keys and Enter. Zero mouse.
Select Place, tab, arrow down to select RECORDING, Enter, Tab, arrow down to select location, Enter, Tab down towards the date boxes… and some how I have now magically selected DRUMs and Lead Vocals as I tab past the instruments and Vocals box en-route to the date.
(Drums was the last instrument I entered as I had entered instruments earlier in the same edit session).
Few more experiments and I am finding that any tabbing over a listbox is auto-selecting the first item even if I did not interact in any other way. I need to be able to TAB past a box and leave blank it as it was.
Simple test to reproduce:
On current interface, click ADD RELATIONSHIP and hold TAB key down. It will now jump from box to box to box and make zero changes. When it gets to last item it just rolls back up to the top.
On Beta interface, click ADD RELATIONSIHP and hold TAB key down. Now it jumps from box to box autoselecting the first item every time. Then gets to the last item and just auto-hits CANCEL.
(Sorry - I can be a good destructive tester… 
)
To end on a positive note. I really like how there is now a sensible order on the left. Instruments together, places together, etc. Always seemed a little odd when that was just alpha-sorted on the current page throwing vocals down the bottom and splitting places up.
Do you remember which recording and relationship you were editing? Can you still reproduce the error?
it was this recording in particular, adding Nyanners as the vocalist (I added it with the regular website right after)
it took me a bit to reproduce it, but I got it trying to add a date to the saxophonist relationship on this track, but not on the vocalist… weird… (there’s no date known here, just tried for testing purposes). I didn’t get the error when editing existing relationships (after adding the artists seperately)
I’ve already added this to the ticket you added
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 p (https://staticbrainz.org/MB/common-chunks-573fed4.js:2:1585557)
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
I will note it doesn’t happen every time, and I expect it could happen on artists besides Nyanners…
I’m generally quite happy with how this is developing, including how MBS-12693 was addressed.
Some specific comments:
Are we sure that less experienced users will be able to tell that “red field” = required, whereas “white field” = optional? When I first tested this, I was instinctively drawn to the white field (Credited as) rather than the other ones. I guess I didn’t really expect a field I hadn’t interacted with to turn red, or perhaps my brain found it unusual compared to the current relationship editor.
For efficiency/productivity: when adding a relationship based on existing ones (i.e. using the + button next to a pre-existing relationship type), I would expect the focus to be placed on the first empty field, not the already populated ones.
Similar to the above, but less clear cut: when editing an existing relationship, should the focus be on the relationship field or the entity field? Most of the time I edit an existing relationship it is to replace an incorrect entity (rather than an incorrect relationship), but other editors’ experience might vary.
Thanks for the feedback, sometimes a nudge to iterate more can lead to much better results…
I would like this (or whatever we end up with) to be universal across MeB projects so it should feel natural to new and old editors with time. I don’t want us to get held back by familiarity with what used to be there - however maybe I’m an outlier re. a desire to make red fields become green fields 
Here we have the current look (1), what a lot of other forms do (2), a variation on 1 (3):
What do people think? I think the red is very clear for new users who can be overwhelmed by our very complex forms (I think a lot of users start entering something and then give up/leave…), but it may well be too much. 2 would be a ‘standard’ option.
Whatever colours are used, check out you are not confusing someone who is colour blind.
Personally I like the red border more (3). But the * in 2 is more standard for what you see on other internet forms. And colour blind friendly. Maybe use that * alongside the colour as a double clue?
Excellent news 
Reading your description in the ticket please don’t select anything when tabbing past. Ideally keep to standard interface rules otherwise a page like “Places” becomes unusable if you previously had been editing instruments. Thanks.
Flipping back and forth between old and new at the weekend emphasised a lot of the good in the new one, but this auto-select in empty boxes meant I had to return to the old to keep working.
