(And another user helped out by yours-truly under my other nickname.)

Another day, another user confused by the scan button: https://www.reddit.com/r/MusicBrainz/comments/1jmexus/whats_with_music_files_or_picard/

nullhawk Happy to help, and happy to brainstorm (though it might be better to just iterate via email.

The wizard idea was certainly one I had, though aerozol will undoubtedly also have ideas on this.

But before we start to think about what to do to Picard, my first advice would be to encourage you to get some perspective by installing MP3Tag and MediaMonkey free versions (and any other Picard alternatives you fancy or that others recommend) and see how their tagging functionality works, what their strengths and weaknesses are for both novice taggers, experienced taggers just using these tools for the first time and experienced taggers/users, looking at both functionality and the UI. I would encourage you to start a personal log, and take each tool step by step documenting your experiences (screen shots and your thought processes) as you go so that when you have become an experienced user you can look back and still see how it felt to be a novice user.

These tools also have other functionality that Picard doesn't have. For example, from a functionality perspective, MediaMonkey does several things that Picard doesn't do - it is a media transcoder, it is a media library and it is a sophisticated player. I doubt that we would ever want Picard to be all of these, but perhaps some things might be worth considering.

As for a means of communication, why don't you think about that too. If we want to do wireframing, what is the best way to generate and share wireframes? Would Github discussions be a good place to share ideas (and if so do we want to ask someone to create a Picard-Futures repo just so that there is somewhere to hold these)? (I am happy to have the occasional Skype video call too, as a means of getting to know each other better and perhaps to chat about specifics if we think it would help, but I would like to keep things open so that others can contribute if they wish, and I think that documenting these open discussions is also a good thing to do. (I have experiences of other open source projects and cliques and factions and politics, and Metabrainz is free of these (or free-er than other projects at least) and I do not want to be the one to introduce them!! But I am happy to be guided by more experienced or more official Metabrainzers on any of this.) 

(The only thing I would say is that we should stop polluting this ticket by continue to discuss digressions here. )

Hi sophist ,

First of all, thank you so much for taking the time to guide me in the correct way. Your life lessons are really valuable to me and give me motivation to keep trying new things, even if they seem difficult. As aerozol  suggested, I think starting with a wizard will be a good starting point. aerozol , could you share some more details on this? Perhaps where I should start or anything specific I should be aware of before beginning?

sophist , along with this, I am willing to brainstorm with all of you to move things forward regarding this issue. If you wish, I am happy to create a demo of a simpler UI, and over time, we can iterate it until it meets our expectations. All five of your points look interesting to me, but as someone always willing to explore new things, I am more interested in points 3 and 5. Specifically, I am more inclined to continue our discussion with you. Please let me know what would be the best mode of communication for you.

Hi nullhawk

aerozol is not wrong when he says that delivering a full solution to this ticket is complex and that it is not at an implementation stage yet, but that does NOT mean that your help couldn't be invaluable to move things forward (and outsidecontext may indeed have suggestions for things you could work on).

But equally, providing that you are happy to experiment yourself and to put forward stalking-horse suggestions for people to review, and comment on and maybe then to iterate, then there are many things you could do.

As an aside, when I was a student (more than 4 decades ago), I had a small microcomputer (Acorn Atom) and I decided I wanted to build an add-on board. I had never done any hardware design or build before, so I was very uncertain that I would succeed, but I researched the chips, made a design, bought the parts and built a board - and amazingly it worked. Unfortunately it only worked for a few seconds before data got corrupted, and it only worked some of the time - in real terms it failed miserably. So I redesigned and rebuilt and it still didn't work, and I decided that the breadboard (rather than etched PCB) approach - with lots of wires running alongside each other that had cross-talk - would never work, and I gave up.

BUT, boy did I learn a lot about a subject I new nothing about, and although I never built hardware again, I learned a lot of general lessons about life and projects that I used later.

So much as I encourage people mostly to pick projects they can successfully deliver, occasionally picking a project that you know from the outset that you are unlikely to deliver can actually teach you more. This particular "unlikely" project could teach you something about: wireframing, UX/UI design, getting feedback and iterating a design, dealing with dispersed and diverse user communities, handling vague or uncertain requirements, picking other people's brains, synergising the ideas of others and your own etc. etc. The one thing I will say, though, is that if you are going to pick such a project, make sure that the community you are going to be working with is a supportive one (and in my own experience of several open source projects, MusicBrainz is the best community by far I have been a part of).

That said, there are perhaps one or two points in this discussion that are deliverable - e.g. extending the existing context help to more areas shouldn't be too difficult.

So the choice seems to be between: 1) moving the thinking for this specific ticket along; 2) delivering something discussed in this ticket which is not this actual ticket; 3) moving the thinking for more general evolution of Picard forward; 4) doing something else Picard or Musicbrainz or Metabrainz related; or 5) doing something entirely different. (If you want to discuss 3 or 5 privately, reach out as I have some ideas.)

Kia ora, hello, nullhawk, that is excellent! Unfortunately this ticket is indeed complex and isn't at an implementation stage yet.

outsidecontext may have suggestions for related things that you can work on - or have a suggestion for elements of this ticket that are not controversial and that I can mock up for you to work on now (maybe a wizard?)

Hi aerozol ,

I hope this message finds you well. I'm reaching out because I'm keen to contribute to the development of a simple mode for our application. I've been following the brainstorming discussions on UI ideas and would like to offer my assistance in bringing this concept to life.

I believe I can bring valuable insights and skills to the table to help refine and implement the proposed ideas. Could you please let me know how I can get involved in the ongoing discussions or if there are specific tasks I can start working on?

rdswift I just checked it out and in options pages it is fantastic - and it couldn't have been achieved without your excellent documentation site.

But except for options (which is also by far the most important place for this functionality), F1 working and taking you to the most useful page is patchy or non-existent. Most notable in the limited testing I did were F1 in `Search for Similar Albums` (no help), no Help entries in right-click context menus, and no context for help on main screen regardless of what was last clicked. And default F1 on main page should probably be here rather than here.

sophist regarding contextual help...  Pressing F1 (or ⌘+? on macOS) opens the Picard User Guide website to the appropriate page to match the current context.  This is described in Appendix D of the User Guide.

kuldeep1a I see you have now unassigned this again, suggesting that you have had second thoughts - which is fine, because it is entirely your choice about spending effort on this. I do hope, however, that you didn't take outsidecontext's comments to mean that you broke some rule by assigning it to yourself - because you didn't! As an open source project you are absolutely welcome to try to work on this, and such work may be beneficial even if it is not merged, but you need to understand what you are getting yourself into before committing the effort, and IMO Philipp was simply trying to warn you of the difficulties you might experience working on this UI issue. 

However as someone with (literally) c. 50 years IT experience, I would definitely agree with what Philipp has just said.

If you are going to work on UI improvements which have not had a robust and comprehensive brainstorming, including exploring a range of different approaches and user consultation, then IMO there is a significant risk that your PR will be rejected and your efforts won't make it into the app. That said, in that situation, any such work will help everyone understand better the UI challenges.

Good UI is extremely difficult to achieve and although Aerozol is a specialist in this area, the user base for Picard is very diverse (complete beginners vs. experts, people with album libraries vs. people with single files, people with good starting metadata vs. people with no starting metadata, people with lots of scripts and plugins vs. people who are happy with the defaults) etc. and developing UI improvements that assist some groups whilst not disadvantaging others is definitely not easy.

Personally I see four areas where new users consistently have problems:

1. Workflow - how do you tag new files - cluster/lookup vs. scan.
2. Contextual help - the Picard Docs web site is IMO excellent (thanks to rdswift), but it is not integrated into Picard.
3. Options - there are lots of options, and deciding what to setting them to is not easy to understand.
4. UI complexity - the UI can be daunting for new users - and the wireframes attached to this are one possible way to simplify it a bit, but not a completely thought through design nor one that addresses all the issues.

and I do not feel that there has been nearly enough brainstorming on what the requirements are, and how it might look afterwards.

I would personally like to see a different approach to making it easier for new users.

1. Use of Wizards - an Options wizard, which will ask simple plain-language questions about your music files and so forth and help set up many of the options. And the wireframes above could also be provided by a Tag new files wizard which takes you through similar steps.
2. Contextual help - help buttons everywhere which either open the relevant web page or get snippets of web content and display them in tooltips.
3. UI complexity - this is where the above wireframes seem to be aimed - how to simplify the UI complexity for new users by providing better hints and by removing expert-only options.
4. General UI modernisation - without sacrificing expert user functionality or efficiency. It looks and feels like a 1990s//2000s app (because fundamentally it is).
5. A separate strand of UI thinking for expert users - how can the expert UI be improved (if at all).