Sorry I didn’t notice that difference before. This is due to a change in layout, so it’ll take some extra effort to change it back.
In the new editor you can also use Enter to submit and move focus, currently if a type is automatically selected, the focus will go to the next input box, otherwise it’ll go to the type selector. Maybe we can make it go to the checkbox as well, I’ll look into that soon, thanks for reporting.
I wonder if it’s worth adding ‘tabindex’ attributes to these pages to make it easier to change up in future/to avoid ever having to rearrange tables.
Vaguely related ticket + discussion (about not setting anything to -1 for accessibility reasons)
Right, that’s also a possible way, but needs to be tested.
I tested that on test.musicbrainz.org
The behaviour when you press enter in a field is usually (and currently on MBS) to submit the form.
I usually press enter on one of the URL to submit the Edit artist page.
It seems a little strange to me to expect pressing Enter in a field for anything else than submitting.
The test server has not been updated for a long time.
Unfortunately we have to use that for links submission and merge confirmation as for now, but you could still press Enter in an empty field to submit the form.
There’s now two new features on beta for the URL editor, which were mentioned by @yvanzo on this earlier post:
Go give them a try, maybe?
Overall it looks good, though I think the current layout is a bit messy:
Mock up showing what I would prefer (but that’s just me):
- move Add another relationship under existing relationships
- invert position of delete / edit icons (like they are just above in this example)
- add a separator to ease reading
- I feel the ? icon isn’t needed, the entity could display it on rollover directly (for example, BBC Music ? could be replaced with just BBC Music, but still displays extra infos on rollover)
Just a quick feedback, the whole thing is quite an improvement already (finally only one Bandcamp URL)
Also, what’s the purpose of numbers? If they are here to stay, they should be first (from the left), as it is usual for numbered lines.
Not had time to test yet, but one question. Why is the interface not consistent:
Compare top part of screen to lower part. Are all pencils now going to the end of the line instead of the start? Are they tidier at the start of the line?
Yes, that seems better. The current UI a reference to the ‘Add release event’ button, this could be change indeed.
That’ll introduce an extra Tab click unless we change the tab sequence. Currently it goes directly to the ‘x’ icon, while it needs to go through the edit icon after switching.
Do you mean like how abbrevation is displayed here, like “e.g.”?
That’ll work, but for type selector we still need the icon, so there’s an inconsistency.
It’ just based on the fact that the ‘x’ icons were placed at the end of line before, it’ll probably be tidier at the start, just not sure if users are comfortable with that.
Thanks again for your advice. Sorry these days I’ll have to prioritize other things, but I’ll be happy to improve it once we have an agreement on this.
As I am one of those fussy Tab users I would think having the pencil and x at the front like the sections above would help us. That way they don’t suddenly spring up and have to be tabbed past when a new item is added. It seems a simple way of solving the extra Tabclicks after adding a new URL.
But you have heard enough from me in this thread already It is just my eye spotted the neatness of where the previous GUI had positioned the pencils.
That’s different from what I thought, but I’m curious about this. What is the tab sequence in this case? And when would they get focus if they’re not tabbed through?
With this new GUI the pencil and X are added after the new URL is typed. And dropped in as the next items to be clicked on. So if the pencil and x are inserted in FRONT of the URL then they are now out of the way of the next steps of the tab order.
It is rare that you need immediately change what you added so it makes sense to me that they are out of the way. (And could be reached with a shift tab if needed)
This is how it currently works when adding data in that section above. You add the data in an edit window, hit ENTER, and move on to the next item. Cursor is highlight on the ADD ANOTHER ARTIST ready to move forward. If you need to edit what you have just done you shift tab backwards.
That is the EDIT ARTIST page in @Zas example. Go play with it and see how it is working. And how those pencils appear behind you as you move forward. In your URL edit you’d speed things up loads as after entering a URL the cursor would then go to either < Add another relationship > or to the next URL box ready to add the next URL.
That’s right, but things are different in external links editor. Currently it already supports moving to the next item (type selector or next input box) when pressing Enter, but it has to preserve the default behavior of pressing Tab, which is going through those icons.
This is what I am pointing it. Why make me go through icons that will be used only when I have made a mistake? Instead treat it like other places where those icons are used.
The pencil and x icons are more likely to be used by an editor who is returning to the page to change something. And it makes sense they have these before the text they need to change.
When I am adding a new URL does it not make sense to leave my way ahead clear to add the next URL? Like when artists are added on the above part of the page? Can you see how I have tweaked the image above? See how this would flow better in the tab order? Leading the editor forwards towards adding their next URL?
(I just been to beta page to try this) I type text in the Add another link box. I tab away. It converts my link to the blue text and cursor goes to the X and the Pencil. INSTEAD convert to the blue text, but stick pencil and X in FRONT of that text and take my cursor to the Link Type dropdown list. Mmmm… nice…
What I mean is in the current UI it has to preserve this behavior, due to the layout. I didn’t mean we can’t change it. Now I fully understand what you mean, and I think it does make sense.
I feel like I may have found this issue a few weeks too late (the relevant MB devs may have moved on to other things):
I think it’s dangerous if we try to clean up random site URLs.
This is not a Facebook URL, this is a random site.
A random site could rely on arbitrary
?fbclid= named parameter to display the correct page.
I am not saying it’s the case here but we can only cleanup standardised known sites.
Quite the contrary. It breaks stuff:
Ugh… yeah… 99.9% of the time “fbclid” stands for “Facebook tracking crap”, but I guess we should allow for the instance where some web designer decides to have “fbclid” stand for “Futurepop Band CD List ID” or something weird like that, that is necessary to that website.
Hmm… wonder what would happen if you had one of those hypothetical URLs where “fbclid” means something useful, and fed it through whatever fbclid-adding Facebook engine does this crap. Would Facebook just happily break all the URLs from this hypothetical website?