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

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

If Picard UI is improved before MB UI then MB will face more lower skilled new users (edit: who will fail in their attempts to contribute to MB)

As a lower IT skilled MB user myself I predict much dissatisfaction with MB amonst these users.
I don’t know if there is great benefit to be gained by improving Picard first. If there is a great benefit then the increased dissatisfaction could be outweighed.

1 Like

So you think we should send @samj1912 away and reject his (present and future) work on Picard? Or what is your proposal?

2 Likes

As with most open source projects, what is actually being worked on depends to a large extent on what volunteers choose to invest their time in. @samj1912 has chosen to invest his time in Picard.

We have decided to spend MetaBrainz resources on improving the UX of MusicBrainz using some of the “Google Christmas bonus” we got at the end of last year, but there will likely be nothing user visible coming from this for at least the next half a year, probably longer.

But then again, any invasive UX changes to Picard will also likely not happen for the next few months anyway. The upcoming Picard 1.4 release (which has been upcoming for over 1½ year by now) will not have any major changes in user interface or any other things. We’re talking about bumping some of Picard’s dependences (Python and PyQt) for a Picard 2.0 release at a later point, which would also be a good candidate for a UI/UX overhaul—which is what @samj1912 is looking into. (@samj1912 is also the driving force right now behind bumping Python and PyQt versions, FWIW, and is currently our most active Picard developer, even though he’s only been around for… A month or so?) With all the changes being planned for Picard 2.0, I’m not sure that that will be released this year either, so Picard 2.0 may still land after a MusicBrainz UX overhaul.

TL;DR: The effort to improve UX for MusicBrainz and MB Picard do not depend on each other, are both currently being worked on (in the planning phase), and do not detract from each other.

8 Likes

@mmirG: I think most people using Picard are not the one contributing to MB.
IMHO, Picard users want to tag their music collection with the already existing data on MB. As long as Picard can’t contribute directly back to MB, I don’t see a direct influence.

Can you explain your reasons why Picard would attract lower skilled new users to MB?

1 Like

Most casual users use Picard to tag their stuff, and (hopefully) add one album or two when they’re missing in order to tag those too.

1 Like

I agree with the sentiment, but the policy at MB seems to be ‘better imperfect information than none at all’. Or in other words, I haven’t seen any indication that users signing up, adding a bad release our two, and then getting frustrated and leaving, is high on the priority list - I want to say that I haven’t seen anyone really care about low skilled user experience but I don’t think that’s fair to say, devs here are just buried in other things (I hope)

Personally, if the ridiculous ‘submit’ button UI is fixed (which causes obvious confusion, and must cause it’s fair share of false disc Id submissions as well) that’s enough for me to consider any update a huge success :expressionless:

3 Likes

Why would you create that misunderstanding?

I think samj’s contributions are better valued and praised.
They are likely to be of much use to me.
I’m finding that without constant practice MB quickly grows counterintuitive and opaque.
And I’m not getting constant practice.
And so plan to get the easy stuff tagged and then see what looks exciting and fulfilling.

Why increased naive users coming to MB if Picard UI is improved?

The current UI at Picard functions as a signal that “This stuff takes significant IT skills” and for those unable to recognise that signal, it functions as a barrier - they will fail and keep failing at trying to use Picard. And many will give up there. I did just that over many years.

If that signal and/or barrier is removed then more of the low IT tech skilled will take the natural progression from using Picard to contributing to MB.

My proposal: More effective ways to steer new users to these excellent and helpful forums.

3 Likes

[quote=“reosarevok, post:5, topic:190192”]Most casual users use Picard to tag their stuff, and (hopefully) add one album or two when they’re missing in order to tag those too.[/quote]I’m afraid that the second part of your answer is wishful thinking.

For sure they press the most misleading program button ever - aka “Submit” - but then realize, this function does “nothing” useful or visible with their data.

If this “Submit”-button would really do something like seeding the available data and provide a really beginner friendly, very basic upload GUI, then Picard could be the starting point for many new user.

Actually, I don’t believe that many new user get attracted by the GUI from Picard or MB to contribute new data.

3 Likes

Can you create a ticket for that and propose changes there ?
See also @samj1912 's work at Picard: Survey and First Impressions

2 Likes

I believe MB needs more of these editors without “significant IT skills”. Many of them will give up but the more feedback we get the more is being done to improve the user experience. Most of us agree that UI could be more user friendly. I don’t believe it’s just because of the lack of developer time. We can’t just ask developers to “make a better UI” without knowing what features are confusing and difficult for new users. There could be some smaller things that could be easily fixed. We’ll never notice them without the feedback from non skilled users.

12 Likes

I’ve posted some very specific UI ideas/examples (eg ‘submit’ button changes) with no serious developer interest or feedback, so it better be a lack of time - because otherwise it’s a lack of interest which would really suck :frowning:

2 Likes

Where are they, though? Your only tickets are four area requests, as far as I can see.

As an aside, there currently are 1718 open tickets for MusicBrainz server …

[quote=“chirlu, post:12, topic:190192”]
Where are they, though?[/quote]

In the old forums and somewhere on these ones too.
I didn’t make a ticket because I never had any developer interest or feedback.

That said I’m super happy with @samj1912’s in-depth approach and looking forward to seeing what comes out of it!!

1 Like

Developer interest and feedback are mainly expressed in the ticket tracking system, so without any issues you’ve found existing in that system, you likely won’t get much.

1 Like

If somebody had asked/advised me to make a ticket at the time, this would pass as an excuse.

edit: I don’t really want to get into an extended discussion on this, I’m grateful for everything the devs do, and I definitely don’t think they’re lazy, but I think their interests don’t lie in the usability/user-friendly department.
There’s hundreds, if not thousands, of posts and comments from non tech savvy users outlining their struggles, and we all know it. “should have made a ticket” is pretty emblematic of how we treat those users - sure, it might be clear that you’re a low skilled computer user that struggles to use our interface, but let’s direct you to yet ANOTHER tech/dev/backend focussed site for the feedback to even be acknowledged.
I don’t think I’m being facetious, I really think that’s being honest about the current situation… I hope it doesn’t come across as ungrateful either, that’s not my aim :disappointed_relieved:

4 Likes

I am pretty tech-savvy, but this resonates with me. I don’t like to make a ticket until I know there’s really something actionable. Although I’ve made so many tickets that turned out to be duplicates, even after trying to search, that I’ve kind of given up searching as a waste of time. It’s a little better now that tickets frequently get linked from the forum, but still.

3 Likes

Prelude: I view the all contributors as having done very well with the resources avaialble. If what I write next harms the progress of MB then I’ll have failed in my attempts to communicate.

In my time contributing to MB I came to the view that MB was still being developed towards readiness for general release.

Things that contributed to this understanding:

  1. The years (?) long lack of requests for user feedback on UI friendliness and the absence of grasping at, and highlighting the usefulness of, user feedback by developers. (Actually I’m not even clear about who would want to get user feedback.)
  2. Server failures and slow-downs that suggested that the system was already over-loaded.
  3. The continuation of the “Submit” button and “New Tags” column heading on Picard after the issue has been raised. The Submit issue; monthly?, weekly?
  4. The continuation of the “Artist Search” box with no drop-down arrow visible in the top corner of MB in Firefox; PC and Android, hiding searches for all other categories from naive users.
  5. Documentation that does not function to make adding metadata quick and easy.
    eg Want to add a classical release?
    https://musicbrainz.org/doc/Style/Classical/Release/Title
    will leave many new or rusty users floundering when they don’t combine it with
    https://musicbrainz.org/doc/Style/Titles
    It’s not that this form of documentation is wrong.
    It’s that it’s not in form a that makes it easy for new and low tech users to add metadata, in my own experience.
    I’ve got two elderly parents if anyone wants to conduct tests on documentation friendliness.

Things that challenged this understanding:
The graphic design; the layout and colours evoke an established, well functioning, user friendly, reliable website.
I’ve pointed out the mis-match on 2 (or 3?) occassions.
I got nada response in terms of changing UI - which ends up reinforcing my “in-development” understanding.

If I’m in error and MB does view itself as already open to all web users then, “Who do I talk to about the target users and user friendliness?”

2 Likes

I’m (again, like with the comment that opened this thread) at a loss understanding what the purpose of your comment is. What does “general release” mean to you? The MusicBrainz website has been live for fifteen years or so, and everyone may use it without applying for permission. At the same time, it is constantly evolving (mostly improving, hopefully).

1 Like

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.

7 Likes

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.