Picard: Survey and First Impressions

I am thinking once we agree on the the decisions with picard v1.4 and v2.0 with today’s meeting we can start with an online user survey of picard based on the doc I posted above and then proceed to build upon it.

As for the 2 pane problem I am thinking I will take an indepth look at some of picard’s competitors and how they handle it and make a few ui mockups based on picard’s current solution for tagging files and its competitors and include them in the survey. This is one of the most major problems that picard has.

Apart from that I think we need to tackle the issues of browser lookup and find a way to include that in picard itself instead of using the browser for a much more uniform UX across all platforms. (A research on whether it is possible to replicate the behaviour in picard using MB api and trying to do the same)

Also, a wizard/onboarding also seem necessary and I will start researching how to build an onboarding in pyqt ( see http://www.appcues.com/blog/the-5-best-user-onboarding-experiences/ for examples)

These three are the 3 major UX changes I imagine we can all share a common consensus on.

Apart from that there are various subtle and small changes needed to the Menus, toolbars and dialogs which can be discussed in length in today’s meeting.

The UI overhaul will also include providing picard with a more modern look in terms of icons.
So we might need a designer for that. I can try my hands on it with my illustrator skills, modifying existing CC licensed icon vector packs.

6 Likes

I love the idea of an on-boarding wizard.

But we might also think about “learning overlays” (no idea whether they have a better name already) by which I mean pop-up layers over the UI giving the user information about what particular features do. These might pop-up in sequence i.e. first pointing the user to loading files. Then when they have done that, highlighting the status bar counting down on the files being loaded and the web calls being processed etc. etc.

Yes :slight_smile: I was thinking about something similar. :smiley:

This is similar to how some new mobile apps/websites have an onboarding.
This is called progressive onboarding, see https://medium.com/welcome-aboard/essential-onboarding-tactics-part-1-progressive-onboarding-ad2847b83fbf#.27lhq6fiu

I am divided on what to use. A wizard or this?

Perhaps the wizard could be a story-boarded introduction for new users. The very basic explanation of tags, MusicBrainz and Picard.

Yes, we can do that, I’ll have to look into how to make this possible using pyqt though.

Should be doable with a little bit of stylesheets and tooltips along with a few signals.

I would suggest, however, that before anyone works on “progressive onboarding”, we decide whether the overall UI layout of Picard needs to be updated as there is no point in creating nice overlays only for the stuff underneath to change position.

Also, worth thinking about how we can create generic wizard and progressive onboarding code that can be easily tailored with e.g. xml files so that we don’t have to rework code every time we want to change them.

1 Like

Yes. 2.0 will come with a lot of changes and we need to make all the changes in appropriation with the others.

Once we are done with releasing picard 1.4 ( tentatively in Feb) we can shift our focus on unifying all the purposed changes and then creating a plan on how to code it

2 Likes

Another option would be to enable (by default) a ‘basic’ interface.
Which is basically: Add Files > Cluster > Lookup / Scan > Save
Since they more or less would be greyed out/ become available in sequence, I feel like it would be hard to go wrong with those. Otherwise you could number them or something. Trying to show the difference between scan and lookup will always be a problem though.

Just a thought, a wizard does the same thing, just leaves the other buttons available (for better or for worse)

1 Like

As a newbie I apologize beforehand for taking the liberty to ventilate some issues I encounter that sometimes confuse me or even hinder me.
These are likely to already have been mentioned before, or maybe after more experience and investigation I would learn it was just me ‘not getting it’ yet.
So this is not to criticize (far from it), and not to start some lengthy discussion and get answers, but solely to add input that might resonate and might be useful.
Here are a few observations:

  • The names on buttons in Picard are very brief and not very explanatory. That might be improved on. It would also help a lot if they had informative tooltips on hover-over, but currently ‘Scan’ says ‘Scan’, ‘Submit’ says ‘Submit’, so that’s useless now.

  • I find the implementation and use of ‘cluster’ confusing. When you start by selecting ‘add folder’, you can navigate to it, but you cannot see the contents. If you accidently chose a wrong folder, and want to remove or re-select correct (sub)folders that can’t be done (I think).
    Well at least, I currently just restart Picard all together to fix such.
    I think it would be a more natural workflow to be able to navigate to the desired folder, see all it’s contents, possibly (de)select concerning files by means of check boxes, perhaps being able to re-order them, and then voila: you have defined your cluster at one go.
    To me it’s confusing having to do that as a separate action afterwards.

  • The several different icons in front of tracks are very useful and important. It would be great if there was some legend available from within, and/or hover-over tooltips for them. E.g. when I used ‘look up in browser’, I nicely got a list of the tracks in the right panel, with nice green music notes in front of them, but I had no clue what that meant, or that I next was supposed to drag files from the left to the right panel.

  • Perhaps some (optional) car-wash-like workflow could be implemented to Picard? Taking new users a little bit more by the hand and walk them through?

Of course one should read the fantastic tutorials available, but also we must admit only very few will be able to grasp all that information at once. So if Picard itself became a bit more user-friendly and explanatory, chances are that when you are then using Picard, you will much easier make links to features and functions you have read about, but could not completely grasp yet at that moment and are slumbering in your brain to be awoken.

5 Likes

Documentation is nice, but unless software does something very complicated, how it should be used should be clear without having to read any manuals. And tagging music really isn’t that complicated.

It’s not that easy to come up with an interface that is both powerful and easy to use though. It’s probably more work than just rearranging some bits of Picard’s interface* or adding a wizard.

* But please just remove the submit button, add it as a context menu item for matched releases instead.

Why not just rename it to “Submit acoustIDs”? That’s what it does, after all. I find it useful and it would be a pain to have to get to it through a right-click menu on a per-release basis, but it’s definitely badly labeled.

4 Likes

Sounds good to me!

1 Like

First questions after changing the button-text:
What is an AcoustID?
Why should I submit it?
What is the advantage or how can I use it?

What I want to say:
Please link to something that explains what this submission does.

2 Likes

You could make the same argument about other functions that don’t currently have buttons. For instance, I reload a release way more often than I submit AcoustIDs. It’s a pain to dig in the right click menu for that, especially when it can only be found if you click on the release heading and not anywhere else.

2 Likes

Another Picard problem for me was the column named "New Tags"
Surprisingly, after getting my New Tags column looking good, and going on to another album, and then another, eventually I’d find that the New Tags were not on the files.
Eventually it became clear that they were not New Tags at all but rather misnamed Proposed Tags.
And that I needed to click “Save” for the proposed tags to be saved into the files and become my new tags.
How about changing “Save” to “Save Tags”?
Or “Write Proposed Tags” or “Save Proposed Tags”?

1 Like

Actually save does more things than just save tags( eg save coverart to files, move files, rename files etc) so a ‘Save Proposed Tags’ will be a bit of a misnomer

2 Likes

Nice to see some user testing of Picard and I am looking forward to the new improvements off the back of it. I do feel however you have a limited user case for it - individual files only. As we all know Picard works best (and always will) if we have albums/releases not individual tracks.

I would worry about dumbing down Picard too much (which is implied the way you are going with this) Cluster, scan and lookup do different functions and although the need more explanations. Combining into one (and not having the option of using the separately) can lead to many issues. Off the top of my head the problem of the “locked in” artist on a scan when it goes wrong. (now it is multi-artist it still can go wrong) e.g. a release that would be classed as “various artists” in MB if it is a few of the same artist on there the Cluster will hard lock it into that artist and never find the release on lookup.

We have know for years now many of this issues raised in this thread. (Scan button description/meaning, non useful tooltips and misleading Submit button, what do all the crazy array of icons mean, etc, etc)

For 2 panels I feel that is fairly common and mostly self explanatory (but as we know we still need to explain more with more descriptions and useful descriptions) it is going for your current file their tags (the left side) to the new/proposed tags.

Other major headaches for users of Picard.
a) Users adding tens (or hundreds) of thousands of files or more and expect it to magically sort them perfectly without any sort of interaction or effect on the part of the user. Education here is the key.

b) The eternal problem of users wanting their random track tagged to the album it came from and never see it from a compilation. (Sliders as we know are confusing and actually you cannot get them to give the desired outcome for this common scenario)

There are probably much better matching to be done in Picard (more details of comparing track length, etc) before it is ready for the much more automated way it is looking like going.

I don’t think this thread is talking about automating or dumbing down, just making the UI/workflow clearer.

Also things like the 2 panels (if we’re talking about the panel on the left of Picard and the one on the right) I don’t think that’s self explanatory at all, which becomes clear whenever a new user braves their way onto the forums wondering why the program has a ‘bug’ in it.
For those users I don’t think they could care less about better matching to be honest, they’re just going to use another program anyway, if they can tag and walk away I doubt they know or care about what’s happening under the hood or how accurate it is.
For tech savvy users of course it’s a different story entirely of course!

1 Like

Maybe I misunderstood but there is plenty of talk about reducing the complexity and thus you have to be careful about dumbing down the other richness of features. I was pointing out you need to be careful about reducing the existing functionality. I have seen that happen far too many times before in the quest for progress and was think it is a fair warning to point this out.

For the 2 panels I think that is the way that most others do it and I personally I cannot think of an easier way of doing it.
There is “before” state and an “after” state. Obviously (as has been stated before (not just here on this thread but many years in the past)) we need text descriptions on it e.g.“Current/original files” for the left and “New/proposed files” for the after.
But the concept of the 2 panels was questioned and I think is fairly self explanatory. If you have a better suggestion please share.

I understand your worries, but I think it’s a misunderstanding that samj is wanting to remove any functionality/features.
MB’s users in particular would kick up a huge fuss if there was even a hint of that happening, so I think we can relax on that front :stuck_out_tongue:

As for the 2 panes let’s wait and see what UI mockups samj comes up with before we pass judgement.
I agree that the concept (before + after / your files / database items) is solid, I was just disagreeing that it’s ‘self explanatory’ which I think is what you’re saying anyway re. needing text descriptions as well.

2 Likes