Help test the relationship editor on

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.

1 Like

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.

Why is “sibblings” doubled for Bruce Springsteen ?


Developer edit: Added MBS-12871 for this issue.


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 :frowning: 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.

1 Like

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.

1 Like

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.


  • Looks much better now compared to how it looked some months ago (it had more padding iirc?). Big improvement if you compare it with the old buggy existing version.
  • The basic gamification of the add relationship process. You have to finish one step before the next step is displayed, which I guess could be easier to understand for the noobs. Not sure if this is an improvement speed-wise or if it’s slower (didn’t compare). I especially like the preview in the bottom + that the invalid date error message now only is displayed after you click outside the field instead going crazy as soon as you enter the “wrong” number.
  • Some information overload prevention like “Hide descriptions” is always good! The grouping (or headlines) of the relationships in these droplist could be clearer though. Light-grey headlines are hard to spot when the rest is black. I also wish that this pop-up window with the droplist, etc, was much wider so that you don’t have to scroll so much, but I understand that this could be hard to achieve.

Don’t like

  • The never ending “show more”. Would be much better to show how many more there actually are in the list. “Show more (10 items)” or similar.
  • There’s still an inconsistency for “credited as”, where it’s displayed in a separate [] for instruments, but in the clickable blue AC for artists and you have to hover over to see the original AC. The latter should be used for both imo.


  • It’s a bit weird seeing “recording of” only on the left side when you have the work info on the right side, plus when you can add “recording of” from either side. This might also be bugged when there are dupe “recording of” relationships of the same work. The correct number of relationships are displayed on the left side, but it’s only displayed once on the right side regardless of how many “recording of” rels there are, but that’s perhaps intended?

Developer edit:

  • added MBS-12866 for the unclear grouping relationships issue.
  • added MBS-12867 for the “show more” issue (this is how it has always worked though, so it’s not directly a new editor issue).

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)

1 Like

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. :smiley: :+1:

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… :laughing: :crazy_face:)

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. :+1:


Do you remember which recording and relationship you were editing? Can you still reproduce the error?

1 Like

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 code this time
Error: The given value was not found in the tree: [object Object]
    at l (
    at L (
    at Object.p (
    at Z (
    at Object.p (
    at M (
    at Object.p (
    at z (
    at p (
    at p (
    at Object.p (
    at F (
    at Ze (
    at Object.To [as useReducer] (
    at IAYK87R.t.useReducer (
    at c (
    at wo (
    at Cs (
    at wl (
    at yu (
    at gu (
    at mu (
    at su (
    at Ui (

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 :wink:

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.

I had noticed that on one of the @chaban gifs above, and added MBS-12872 for it :slight_smile:


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 :slight_smile: 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.

1 Like

The old one only autoselects when you tab after you make a search, so not when tabbing past, and that was also my proposal in the ticket :slight_smile: So, you tab past and nothing happens, but you open a search (with down arrow or whatnot) and then you tab and it selects.


Perfection. :slight_smile:

Some of us spend all our time just using a keyboard. And the new interface seems more keyboard friendly. I was swapping back and forth between the two at the weekend and can see plenty of positives and was touching the mouse less.

Just the little things like being able to select “trumpet” by typing “tru” and then just hitting Enter Twice to select the data and close the box. That didn’t work correctly in the current interface as the OK button was never focused. :partying_face:


At release credit, to add either of instruments technician / publisher / liner notes (before having them in recent items), the last of which is fairly frequent, you have to goto bottom of list, click “Show more…” (which should have a space before ellipsis: “Show more …” as ‘more’ is not cut short), then redo theat same thing to get those last 3 (and even then looking out for a 3rd button with that same command). I do not expect having to redo things, so 1st click should do the job (“Show all”). At least a trigger requirement of >3 items for re-hiding – but if so I would expect similar things elsewhere (“Show tl;dr descriptions” → “Show full desriptions”) and interpret them as user-click-track-enhancement and myself do less.


note that both boxes are search boxes, so you can type in “Liner notes” and find it without scrolling to the bottom of the list

Noted, thanks. However the fault is not mass of work, but the redo feature and it being triggered by too low a threshold.