Picard - 100+ warning?

After that fun rant from earlier, can I suggest a warning is added to Picard? Far too often we see people trying to tag hundreds or thousands of files without checking. I don’t know if this is some YouTube video or “how to tag your files” blog post, but it happens every few months. Too many new users assume Picard is magic.

Can I suggest some kind of “new user” warning? If a fresh install of Picard spots it is being asked to tag more than 100 files can a message box be thrown up as a warning? Suggesting a backup? Suggesting to double check before committing?

On the message box have a tick box to say “I know what I am doing” or “Go away and stop pestering me” so it can be dismissed permanently.


This is a conversation I am now having on two completely different open source projects… How to reconcile having an easy to use and very safe UI for beginners whilst still giving expert users the full power of the tool without any onerous safety UI features?

UIs are (in my experience at least) very difficult things to do well at the best of times i.e. difficult to deliver a great UI for either new users or alternatively for expert users. Achieving a UI that is great for both sets of users is thus even more difficult.

Personally I have no issues loading several hundred albums that have been previously tagged by Picard i.e. several thousand files. However I would probably add new albums by the 10 rather than the hundreds.

IMO the issue with new users is not quantity - but rather the huge flexibility afforded by Picard and a UI which by itself gives very little guidance to new users - so it is very easy indeed to screw things up if you don’t know what you are doing, and the (genuinely excellent) online documentation is not up-front enough to prevent new users from doing silly things whilst they are learning.

I am not sure that I have the answer - except perhaps a vague idea that we should provide wizards for configuring naming scripts and for helping users with workflow for new albums that do not yet have MBIDs.


I agree that making help and documentation more up-front is probably the better solution, though a warning might be good to have too

ideally, I’d imagine the first time* you boot up Picard you’d get a popup screen with links to the documentation, forums, and the like, as well as a button that says something to the effect of “I’m familiar with Picard, hide all help”

*and maybe subsequent times until you tick a box that says “don’t show start-up help”

for example, Audacity has a similar setup, and I’ve seen it elsewhere too


A setting like this could definitely be useful for both new and power users. I can’t think of many times I would personally want to tag over 100 files at once and, if I am, it is more likely a mistake. If you can choose to ignore it forever after the first warning, I think that would probably be a good compromise for power users.

For the larger picture, I agree that it’s very difficult to create simple, yet comprehensive, UI/UX for an application that, by its nature, is very complex. A good portion of the work I do centers around designing, developing and teaching libraries and museums how to use open-source technologies. The people I work with range from complete computer beginners to people who are pretty comfortable in a convoluted UI because they manage digital collections and it’s what they’re used to. 3D printing is a pretty good example of needing to have a thousand features for power users, while maintaining a simple, streamlined interface for new users.

Cura, I think, is a good example of trying to toe the line between new and experienced users. The print settings menu defaults to a very simplified interface and uses default settings. You can also tweak specific settings, if you are more comfortable with 3D printing. Even further, you can tweak how ‘advanced’ you want your custom settings window. Each setting comes with a tooltip to slowly introduce you to the new concepts. A lot of the people I have worked with respond well to this kind of interface, where you can pick your level of comfort, but it doesn’t leave you completely in the dark if you need to make custom ‘advanced’ tweaks.

Picard is obviously not a 3D printer slicer and a very different beast than Cura. Having a way to simplify the interface could help bridge the gap and provide some guard rails for new users. With or without a wizard-type interface, I think less buttons overall at one time might be a little less intimidating.

Another open-source app I use sometimes is OpenShot video editor. It has a menu bar open that switches between a ‘simple’ and ‘advanced’ window view. This approach usually amounts to some panes being open while others aren’t. An extension of this could be the ability to choose between ‘workflows’, such as adding/matching, tagging/renaming, submitting AcoustIDs, etc. Cura does similar by having workflow tabs for setting up a print, previewing it, then monitoring it through the print job.

It’s not open source, but Premiere Pro is pretty good at workflows.

Maybe I’m overthinking it! This would obviously be a huge change with a long design process, if there was even interest, but I thought I’d give my two-cents.


Definitely needed imo - the ticket to vote and leave notes on is here:

1 Like

This is what I think many do. The key is those MBIDs implying you have already searched once. Loading up 100+ files with MBIDs will not lead to bad matches. It is when the files are being tagged for the first time I think the issue happens the worst.

I am not really suggesting a full “noobie mode” re-write. Just a warning box. Something that points out that their actions are irreversible. Something that warns that blindly pushing buttons can potentially destroy a music collection. A Noobie safety catch.

1 Like

The original idea was to warn when tagging over 100 files, not loading. Two different things…
IMHO the title of the ticket is incorrect and should say ‘tag’

How about an ‘undo’ feature, log all the changes in a session and be able to undo them?
I think this would be useful for everyone?

1 Like

I think it’s better to display the warning as soon as possible in the tagging process, so when the files are loaded instead of tagged. I’d also like it to be a setting, and I’d like a check box “Don’t show this message again” on the warning itself, so that experienced users are not bothered by it.

An undo function may or may not be useful, but it’s a lot of work to add and test. I know this is MusicBrainz, but let’s not overcomplicate this, please.

1 Like

Let’s not forget that we are not sure what the rant user did to cause Picard to make the changes that it did. @outsidecontext seem to suspect that a custom renaming script was in use which indicates a level of sophistication.

The title of the ticket is correct for what it is, but you may want to open another one!

I think ideally we would have warnings at each step that can really cause problems (when loading, saving, or scanning a buttload of files), with a ‘don’t tell me again toggle’.

The quote from above is about tagging not loading

1 Like

the ticket shared seems to be an older one, it was created in 2016

1 Like

I think the problem with the old ticket and why it never got somewhere are:

  • Part of the reason for this ticket was performance issues of Picard, and some thought it would be better to address the performance and allow Picard to load a couple of thousand files than to add a warning
  • It was hard to agree on a number of items the warning should trigger. It also would give a false impression. Of course Picard can load more than a 100, 500 or 1000 files, and of course you might be able to handle it as a user. But it all depends, both on the experience of the user and the types of files being tagged.

I think the (dismissible) warning dialogs @rdswift implemented on startup and saving files (see [PICARD-2671] Show a first run information dialog - MetaBrainz JIRA and [PICARD-2676] Show a file save confirmation dialog - MetaBrainz JIRA) are a better and more generic overall solution.

Hence I’d be in favor of closing PICARD-840 finally.