Considering the flow-on effects of Picard UI improvements before MB UI improvement

Tags: #<Tag:0x00007f050b742860> #<Tag:0x00007f050b742720> #<Tag:0x00007f050b7425e0> #<Tag:0x00007f050b7424a0> #<Tag:0x00007f050b742360> #<Tag:0x00007f050b742220>


To be fair, it’s not always easy to go from “I find the UI confusing” to “here is an actionable ticket”.

We could all do more to help bridge those gaps and herd those cats.


All the following is based on my experiences and observing the posts to the forum of failing users.
The hypotheses I have drawn have no other support.

I think that there is a major problem around knowledge and perceived knowledge in the MB project.

Those heavily involved in the project are very knowledgable.
But they can not conceive the level of ignorance that many people bring when attepmpting to use Picard and add to MB.

“Herding cats” is about right.

By “general release” I mean “accessible to the top 7 deciles of IT skill levels of internet users wishing to use or contribute”.

I estimate that the current UI and skill set required makes Picard and MB accessible to the top 1 or 2 deciles.

The inaccessibilty to an estimatef 50% of internet users who have rough average or better IT skills is what I point at with “not ready for general release”.

It could be that music tagging and metadatabase construction are essentially too complex for 80-90% of Internet users. Or are seen as such by MB.
In either case a statement warning new users of this would be a responsible approach. Leaving people to fail is not generally a pathway to repect or success.

And maybe I am wrong.
Right or wrong, either way; a major project that is not seeking to gather data on what I address is not orientated towards being accessible to the general population of internet users.


I regret that my explaination of the comment that opened this thread that you qieried, failed to make its purpose clear.

I do see a possibility that you find my statements around low IT skilled users and the accessibilty of Picard and MB to them disturbing.

Is this the case?


I have re-titled the thread to remove any implication that samj’s contribution is anything other than very valuable and highly appreciated.


I think it’s pretty clear that I agree with your opinions on the subject mmirG, but I still don’t see why we would want to “warn off” low skilled users?
Either they try and fail, or we have (even if there’s only a small chance) someone who gives it a shot, wades through the early learning curve, and we have a new contributor.

Obviously we lose low-skilled users by the truckload but I think rather than actively trying to not encourage people to try use MusicBrainz (which seems to be your suggestion?) via making Picard look nice, there are perhaps some other quite simple options we could try.

One would perhaps be a bit of a mentor program for new users (as simple as some volunteers leaving a “hello, let us know if you want help” message, or a readily available chat window where people can ask for help)
…as well as various other solutions that would involve a bit more coding though - eg a limited ‘basic’ interface for limited users to start them off slow, or contextual guides/docs for new users.
Again, I think everyone’s focus is elsewhere, but perhaps now that the server move and related issues have slowed down (?), staff/devs might have a bit of interest.
I wonder if something like a mentor/more community orientated help system might be something @Freso might be interested in :slight_smile:


I too think that it would be better to find ways to have new users succeed.

And that your proposals are on target.

However chirlu tells me that MB has been live for some 15 years.
That suggests to me a very large number of new users who have failed.
And a culture in MB that has been prepared to leave the majority of new users to fail.
This would be fine with me if that was the best that could have been done.
(But a simple warning would seem to have been in reach.)

The “warning off” is confined soley to the two cases outlined in that paragraph.

“Try and fail” takes peoples’ time.
Say an average of 2 hours. (But maybe more like 3 hours. I don’t know.))
For MB to be taking 2 hours time off 80% of new users and giving them failure in return does not demonstrate respect.
Or build a positive relationship with the failed user.

At some stage the reputations of online projects may become important to their success.

I think it’s time that MB looked at reducing the number of users that fail. (my assumption is that this is a significant % of new users)
If a warning is the best that can be organised then a warning.
If resources and structures can be developed and directed then even better.


I wonder to what extent it’s also a culture shock vs hard to use. The major influx path indeed seems to be Picard, and I have the impression that the majority of users there is tagging downoalds (legal or otherwise) rather than own rips (would some sort of anonymous usage tracking be possible there? I’d be interested to know the % of Picard tagging actions related to releases found by discid lookup vs acoustid lookup).
Those people might visit MB, but from a “tagging my music” perspective, not a “creating good metadata for everybody” perspective. I’m inclined to think they will rarely result in a “good” MB editor; they are likely to ignore style rules, drawing ire from editors that have to repair things, which is then likely to chase them away.
I believe people finding MB from a more data/metadata context are more likely to be interested in following the rules and ensuring data quality, including but not limited to coming to these forums for guidance.

So I suppose I’d be interested in looking how influx of the latter kind may be improved. Could the wikidata integration be done both ways, so that wikipedia articles with an associated MB entity get a link to MB in the sidebar (preferably with an MB icon next to it for visibility)? Some partners, like BBC Music, already link back (text only link, so not super eye-catching, but still); is there data available on the amount of traffic those links generate, and how many people sign up as editor after coming here fom such a link?


I came via Picard, sometime pre-NGS. I can’t tell you exactly when I started editing, but I bet it was post-NGS. It was a slow process to get from “I just want my tags” to “if I have to enter all this anyway, I may as well put it in the database” to entering data for its own sake. I was very frustrated a lot of the time at first, but fortunately I am both patient and stubborn. I’ve also been a librarian, so I understand the value of good cataloging and metadata. I read some documentation, but probably learned more by experience than by reading.

I find the documentation more useful when I know what I’m looking for and can search for that specific thing, such as classical titles. As intro material goes, it would be more valuable to have it right in the editor, as has been proposed in the past. (Personally, I find it very disruptive to my workflow to have to juggle multiple tabs/windows, but I’ve learned to get by.)

Oh, and my collection is a pretty even mix of rips and downloads, but I’ve never once used Disc ID. I always have the files in electronic format already.


This is achieved by using the authority control template,
In wikipedia add the following to the bottom of the page after the references section.
{{Authority control}}
If there is a wiki data item and this links to the wikipedia page in that langauge as well as a link to musicbrainz it will link to us (and other databases).

Someone on wikidata runs a bot that automatically creates a link back to us if we link to them.
The process should then be:

  • find a wikipedia page for the artist
  • find the wikidata item link on the left hand side of the wikipedia page.
  • Add the wikidata url to musicbrainz.
  • optional - edit the wikidata item to link to musicbrainz or wait for the bot to add this link.
  • update the wikipedia page and add the ahtority control template.

see and scroll down to the bottom of the page


But it depends on Wikipedia countries, for example, AFAIK .fr doesn’t link to MB (and it sucks).


100% agree!
Discogs for instance achieves this by being a collectors hub + a marketplace, which both encourage good data. Some places fill a niche for a very specific audience/community which encourages an influx of very dedicated people (eg VGMDB).
I think one of the ways MB draws people in this kind of way is when other sites integrate our data - I’m sure a lot of people here came from! Apart from that and people trying to find a quick and dirty way to tag their mp3’s I can’t really think of another reason many people would end up here.
One thing I think is that we could perhaps push the community aspect a bit more? It really is a bit like throwing edits into a black hole for a new user right now, and comments and votes are seen more as a nuisance rather than a team effort. Easier said than done though.

Anyway, just some thoughts :slight_smile:


Well, here’s a case study of what a new user struggles with:

One thing that crossed my mind, based on this, is that maybe there should be an easy-to-access flow chart of the relationships between releases, release groups, recordings, etc on every such page.


Just for the records:


Is that Chemical Brothers WP link supposed to show a link to MB? For me, it does not - the External Links section at the bottom only links to the band’s site, discogs, and imdb.
The page for Madonna has 7 such links, none of them MB.


It’s not about the External Links section (which is regular page content), but the Authority Control template after it.


My two cents as a newbie going through this thread.

I sense a current that assumes that the quality of a potential contributor could or should be measured by his/her ability to learn and understand a (possibly) not-to-easy to understand and learn user-interface.

I would argue the opposite.
You might chase away potential very valuable contributors with valuable knowledge and understanding of music/artists/genres/labels etc., because they are not particularly seasoned, savvy, or interested in spending much time and effort in learning a sub-par user interface first.
Or, the opposite, a computer savvy person who understands the interface fast, might be mediocre in the quality and/or value of his contributions.

In my opinion you should separate the underlying challenges, and strive to improve each of those specifically.
A sub-par interface? Try to improve that.
Sub-par and problematic contributions? Try to improve that. (by e.g. training/monitoring, and possibly a warning/ban system.

But in my opinion trying to solve possible problems at ‘location B’ shouldn’t be addressed by refraining from making improvements on, or fixing issues at ‘location A’.


As someone who has contributed to Picard and also contributed edits to MB I would summarise all of the above as:

  1. Music metadata IS complex - and it is not that easy to simplify it to the point that someone who doesn’t understand any of the complexities finds it simple.
    The effort needed to provide the quantities of context-help necessary to guide a user through the complexities and simplify it for mortals would be huge. And experts would find that sort of hand-holding would slow them down substantially, so you would need to make it adaptable to the user’s level of knowledge - which makes such guided help even more difficult to deliver.

  2. MB and Picard are charitable open-source developments - which don’t have the money to employ the armies needed to provide the degree of perfection you might expect from a commercial product - but then people like us get access to the data and functionality for free. In reality it is probably not viable on a commercial basis, and crowd-sourced / open-sourced is probably the only way of delivering this.

So, yes, it’s messy and imperfect and haphazard - but it exists and gives us all benefit. And it is inevitably reliant on volunteers like samj, Freso, Zas and many others to voluntarily deliver enhancements - and you cannot order volunteers to do x or y.

(I should add that samj is an absolute star - he has jumped in and moved Picard forward at least a magnitude faster than before. And he has been willing to pick up other people’s ideas - like some I came up with - and make them happen within hours. Without meaning this as any sort of negative reflection on any of the other volunteers, samj is simply a hero!!!)

The philosophies we need to encourage (and ones which sadly are lacking in society today) are:

  1. Giving back - if you benefit from free open-source software and data, then when you see something needs doing, take the initiative and give something back. So, if there is functionality which is missing or annoys you, at a minimum document it so it can be addressed, and if possible do what you can to fix it.

  2. Make the effort - whilst it would be great if you could do everything without having to learn how to do it, in reality life is about needing to put the effort into learning new skills in order to do anything meaningful. So if you want to suggest enhancements, find out where to log them. If you want to fix MB data, take the trouble to read the 10s of help items that will help you learn about edits. If you can’t learn to program, volunteer as a tester.

So my message to those on this thread griping about MB or Picard is to stop complaining about how other people aren’t delivering, roll your sleeves up, and get stuck in yourself.


In my view one of the long term problems of MB has been the ignoring of naive user’s experiences.

The project has aimed small in terms of user-base - at just those with high IT skill levels.

I see every contribution that reorientates MB towards being accessible to the vast majority of internet users as valuable.

The posters pointing out design flaws and users obstacles on this thread have already contributed significantly to MB.

edit: Those raising problems are volunteers here too.
What you write about volunteers is good.
And it applies to volunteers who go to the time and trouble of raising problems too.


I really don’t think that the MB team have ignored the experiences or needs of naive i.e. inexperienced users.

  1. Music metadata cannot be easily simplified so that naive users can enter quality data.

  2. I don’t think you need high IT skills to enter quality data - you just need to be willing to learn what is needed. If the user base of MB editors is small, it is not because users need to be highly skilled IT coders.

  3. However, code needed to support the complex metadata is itself complex - and therefore you do need to be a bit of an IT expert to contribute significantly to the programming of the MB website or Picard tagger.

However, I am not saying that we should not strive to improve the usability - and more importantly to encourage users of MB and Picard to contribute back partly through better publicity and partly through providing functionality to make it a easier to contribute.

So, as part of the UI improvements we have started talking about a new user wizard which gives users a quick introduction to tagging. As part of this we could talk about where Picard gets its data, and how users can give something back by improving the data.

We could also think about using technology to harvest quality metadata or to use statistical methods to eliminate non-quality data. So, for example, we could get users to use their mobile phone cameras to update CD covers and booklets and use OCR to extract track listings. Or ask users to check and correct a proportion (say 1%) of the metadata they use and use statistics from (say) 5 or more versions to work out what data is accurate and what isn’t. (But the above needs significant programming effort to achieve - and a more structured approach to harnessing the volunteer efforts in order to deliver it.)


I just wanted to note that both myself and @Zas are actually currently employees of MetaBrainz:

That said though, Picard development/contributing are not part of my contract and AFAIK neither is it part of @zas’s, so specifically for Picard stuff, these are still volunteer contributions. :slight_smile:

@samj1912 is amazing and a huge boon to Picard and hands down the primary reason we’re non-jokingly talking about a 2017 release of Picard 2.0 (and 1.4, for that matter…).