Target audience/customers/users for Picard and MB?

Tags: #<Tag:0x00007f2a0373f800> #<Tag:0x00007f2a03753d00>


There was one question that I probably should have raised while watching the MB summit live on youtube.

A user interface is best designed with specific user groups as the target.

Who are the specific audience/group/s that the new user interface/s are being designed for?

There are those who contribute code and understand database tech. Thats one group.
There are the experienced MB editors (who don’t understand database tech). That’s another group.

Then there are new users. They have a very wide range of skill levels.
I’ve got people I can sit in front of Musicbrainz and they will be hopelessly lost just trying to navigate or search.
What skill level of the online population is being aimed at?

Or is the approach more “make it as simple and clear (while still being powerful and fast) as we can think how to and let the learning curve determine the user population”?
This is an entirely valid approach. As long as we know that that is the approach that we are taking.


Having come from Wikipedia, this is definitely quite different. Hell, just the other day, it took me 6 hours to do what I could have done in 3 minutes on WP doing copy-and-paste or 20 minutes doing it all free hand.

But, I also get a feeling that the tedious effort it takes to edit keeps away some of the spam the WP gets.


There is an unexamined (as far as I know) assumption that removing unnecessary barriers to new editors is a “good thing” in that it should allow the numbers of editors to increase.

Some thoughts:
If the aim is “a global encyclopedia” then some breadth of coverage is necessary.
I would like to know how much commercial recorded music is released each day globally.
And then we could compare that with the amount of commercial music being added to Musicbrainz each day.
My wild guess is that MB is not adding that amount each day, given the little Chinese, Indian and African music I’ve found here and the relatively massive sizes of those populations.
(Though human editors will eventually, if the promise of “better than human” AI is ever realized, not be needed.)

An “encyclopedia of some rapidly reducing proportion of recorded music” doesn’t sound that motivating of participation. Nor does, “use Picard to tag your popular records if your have high level IT skills”.

I can see the benefits of keeping things spammer unfriendly, difficult, arcane. But the costs of doing that, look to outweigh the benefits by a lot.


But then the problem becomes -
Do you want to be a database of all things music (right down to your ex-girlfriends’s sister cousin’s college roommate’s drunken uncle that sang one song with the band at the wedding reception), or do you want some minimum requirement (notability) before inclusion on the site.
Because there is no way to verify that justcheckingitout made an album in 1969 via 3rd Street Music, because 3rd Street Music closed in the 70s after a fire, the owners died in the 80s, and all of the employees (if still alive) have moved on to parts unknown. It was 30 years before the internet. There are no verifiable mentions anywhere to be found.

So, you either have to take me at my word that I am not spamming, or you have to say “it isn’t notable enough to be included”.
It is more believable that I am adding legitimate information when it takes an hour of my time vs the 3 minutes it takes on WP.

But, I think it needs mentioned, that I do think there should be a notability guideline that needs to be met. That “drunken uncle” scenario I mentioned above should be excluded from the database.


We’ve just had that discussion, and most everyone else agreed “as long as you have some way of verifying it exists”:

You might have a valid argument there (though I’ll say now it still probably won’t sway anyone), but this thread isn’t the place to discuss it. The UI deterring spammers, sure; what counts as spam, no.


I’m thinking this might be less the interface and more the lack of translation – German, Dutch, and French isn’t a particlarly large slice of the population. Maybe we see an uptick if some of our Chinese-speaking users help translate the site and Picard, and then (gently) promote it on other Chinese messageboards. Switching fully over to the aliases might also help, but it’s probably not as much of a hurdle as nearly all the documentation and discussion being in English as well.

My concern is that we simply don’t make MB less powerful as we make it easier to edit. Advanced users are already used to working on several pages to get all the data we want added (or using scripts if they actually have a browser that supports them) so that won’t be as much an issue, but as slick an interface as BookBrainz has, it always felt like I could only could only touch the surface rather than really digging in like I do on MB – and I acknowledge that’s likely not reflecting its actual capabilities and is more just my perception. I know web design now involves some degree of flashiness, but I feel we should be able to find a common ground that is sufficiently polished to not give the new generation the impresssion of being outdated while still allowing editors and scriptwriters the ability to actually work on the data.

EDIT: Realized that made a good statement, but not a particularly helpful direction. I meant, roughly, “make the CSS pretty, but keep the HTML logical and the Javascript minimal.”


But that is a trade off.
If you make it more accessible by changing ease of use, you have to accept that more people are going to use it - and not everyone has honorable of intentions.


I agree. The easier it gets the more “cheap thrills”, “drive-by spamming” will be happening.

But I think the benefits of more editors will outweigh that downside.
And I suspect that the current ratio of “commercial recordings released”/“commercial recordings added to db” would be better improved.
And there may eventually be a internet user population sentiment that values and patronises truly inclusive projects.
And, like I’ve said before, the inclusive model for Musicbrainz is a thrilling project in that a large world-wide group of editors would be something very different in the world and the effects unknown.

Sure it might all crash and burn.
That could happen anyway.

Trying out an inclusive approach will throw more light onto what a global online project can be.


I would think technical users would prefer some help to make automation of tasks easier, since however good the UI is manually adding data to all the fields MusicBrainz supports is always going to be hard work. At least for new releases we have a way to seed a release, the trouble is that the database doesn’t treat the release and the tracks on the release as an atomic unit and so if the database is overloaded it is very easy to end up adding a release but without any tracks (MBS-7296), and it doesn’t seem to take much at all for adding new releases to get overloaded, I wonder if the code can actually only add one release at a time ?

Another site in a completely different domain but with similar issues is - they want more people to add more data but they are wary of users adding bad data so they have a similar fear of automation. They have recently introduced a new gedcom importer this allow a user to export his ancestry tree and import it into Wikitree without typing, BUT for each person they have to check against possible matches to the same person already in wikitree and only then can they add in new people, family by family.

The advantage of this process is if the original data is good then little manual editing is not required , but all the data has to be checked before it can be imported, and the system can cope with one user adding alot of new people. I think the technological ability of wikitree (developers and users) is much simpler than those of MusicBrainz, but they have managed to create a system where multiple people can be added fairly painlessly, it would be great if MusicBrainz could also achieve this for releases.

Advanced editors: tailored GUI

You lost me at “gedcon importer”.
But I think I get the general idea of what you are proposing.
Is this close?

I think such a GUI could be a real game changer for UX - no longer would advanced editors be limited to something that new users can (hopefully) get a handle on.

And new editors, and encyclopedia users, could be tailored to, wrapped in cotton-wool even, giving them a better UX.



But I don’t think its quite the same, you are indicating a powerful editor that lets you add in complex things. I’m saying we need a powerful way of adding in the basic data, and the main point is a reliable way of adding multiple releases, and perhaps extending the seeded release idea so you van provide the data for multiple releases in an import file rather than having to copy and paste data, then just check the imported data before creating each release.


OK, that’s clear. I do think that advanced editors would be better given more powerful tools.

Tieing those tools to a (Advanced Editors) AdEd GUI would:
Restrict their use to AdEds, keeping normal and new editors from creating large messes.
Have the tools in an environment optimised for their use/editing.
Strengthen that in the MB culture which pushes the skill levels & technical abilities of AdEds and actively promotes the evolution of AdEditing.

(For the record: I am very much a shopping trolley type editor. And I intend to remain so.)


Sure, but how many advanced editors are there ?

Of course I’m not against better tools for advanced editors but I would think the priority would be making it easier for the masses to add in good data easily rather than concentrating on a small subset of editors.

But one general problem is the flexibility of advanced relationships mean the user is not directed towards using them, in the UI they are very much an optional extra, we should change the UI so that there are data entry fields for people like composers, lyricist and producers

An analogy when I wrote the MusicBrainz Search I didn’t rank releases based on their popularity because my view was that its unfair for established artist to always usurp smaller artists. But people have always complained about this and I expect the new search will bias towards more popular artists. In the same way whilst its great that we can add relationships such as Art Direction in the real world the majority of people are more interested in relationship s such as Composer, hence we should give precedence to these relationships.


Restating the good sense you’ve made into “target audience” terms:
One important target audience for the/a UI are “technical editors” who …

(The idea that more editors can be retained in, and attracted to, this highly productive group by making editing quicker and presumably more enjoyable for for these editors, is reasonable. Optimising the benefits to MB from this group seems certain to accelerate db growth.)