[#PICARD-255] The colors and list position used to indicate when tags are being added, changed, or removed is inconsistent when multiple files are selected - MusicBrainz JIRA

Picard

The colors and list position used to indicate when tags are being added, changed, or removed is inconsistent when multiple files are selected

Created: 03/Jul/12 03:59 AM Updated: 03/Sep/12 06:09 PM Resolved: 03/Sep/12 06:09 PM

Component/s:

Tags & Metadata, User Interface

Affects Version/s:

1.0

Fix Version/s:

1.1

Environment:

OSX 10.7

Issue Links:

Relates

This issue has related issue:

~~PICARD-256~~ All selected tracks are used in the "New Value" column calculations, indicating data will be changed when it won't.

Description

« Hide

This one can be confusing.

Here's how it works with a single file selected:
Original -> New Value -> How sorted with "Show Changes First"

Tag is correct:
Black -> Black -> Later
Tag will be added:
[missing] -> Green -> First
Tag will be changed:
Yellow -> Yellow -> First
Tag will be removed:
Red -> [missing] -> First

These results are all fine. It's when you start selecting multiple files that things fall apart. I can't make a full list of every possible permutation, but here are some examples of bad behavior:

If two files have the different "Original values" and different "New values", Picard indicates no change – i.e. it shows "(different across 2 items)" in both columns in black and does not place the tag at the top of the list.

If the "New Value" for two files is the same, one file is already correct and the other will have the value added, picard lists "(missing from 1 item)" in the "Original Value" column, but otherwise indicates no change. But if the second file has a value that will be changed, the "Original Value" column indicates "(different across 2 items)", the text is yellow and it's listed first (this latter behavior is OK).

If one file is having a tag added and another is having that same tag removed, both columns show "(missing from 1 item)", but otherwise indicate no change.

If one file is correct, and a second file is having a tag changed, if the "New Value" of the tag is the same as the first file, the change is correctly indicated. But if the "New Value" is different than the first file, no change is indicated.

You get the idea... The main variables are:
For each file in the selection: Are tags being added, changed, or removed, or are they correct, or are they correctly absent?
For all files in the selection: Are the original or new values the same or different?

Also worth noting: selecting a track that doesn't have a file associated with it still affects what's displayed in the "New Value" column.

Description

This one can be confusing. Here's how it works with a single file selected: Original -> New Value -> How sorted with "Show Changes First" Tag is correct: Black -> Black -> Later Tag will be added: [missing] -> Green -> First Tag will be changed: Yellow -> Yellow -> First Tag will be removed: Red -> [missing] -> First These results are all fine. It's when you start selecting multiple files that things fall apart. I can't make a full list of every possible permutation, but here are some examples of bad behavior: If two files have the different "Original values" and different "New values", Picard indicates no change – i.e. it shows "(different across 2 items)" in both columns in black and does not place the tag at the top of the list. If the "New Value" for two files is the same, one file is already correct and the other will have the value added, picard lists "(missing from 1 item)" in the "Original Value" column, but otherwise indicates no change. But if the second file has a value that will be changed, the "Original Value" column indicates "(different across 2 items)", the text is yellow and it's listed first (this latter behavior is OK). If one file is having a tag added and another is having that same tag removed, both columns show "(missing from 1 item)", but otherwise indicate no change. If one file is correct, and a second file is having a tag changed, if the "New Value" of the tag is the same as the first file, the change is correctly indicated. But if the "New Value" is different than the first file, no change is indicated. You get the idea... The main variables are: For each file in the selection: Are tags being added, changed, or removed, or are they correct, or are they correctly absent? For all files in the selection: Are the original or new values the same or different? Also worth noting: selecting a track that doesn't have a file associated with it still affects what's displayed in the "New Value" column.

Show »

Sort Order:

[ Permalink | « Hide ]

voiceinsideyou added a comment - 03/Jul/12 07:53 AM

Somewhat a side issue, but it's worth noting that the logic here for calculating all of these does not appear to scale well at all with large selections. Try selecting 10,000 files in order to then Scan, or something like that.

I think it should probably give up trying to render this view on the fly once you get to a particular selection size, as the results are probably useless, as well as extremely expensive to produce.

[ Permalink | « Hide ]

Michael Wiencek added a comment - 27/Aug/12 03:13 AM

I have a patch to fix these issues (and the first issue in ~~PICARD-256~~), but maybe some edge cases should be discussed first.

Consider if the user has four files selected. On file 1 "album" is being added, on file 2 it's being removed, on file 3 it's being edited, and on file 4 it's not changing at all. Should the color yellow be used for the album tag as a generic way to indicate "changes exist across these files"? It sort of muddles the current meaning of that color, which indicates that an existing value is being edited to a new value.

[ Permalink | « Hide ]

Michael Wiencek added a comment - 27/Aug/12 05:00 AM

One more edge case would be:

Two files are selected. In file 1 the "album" tag is being added, and in file 2 it's not changing at all. The new value will show "(different across 2 items)," but does it make sense to color it green even though it's only being added to one of the items? Or should yellow always be used to indicate that there are changes, but they don't apply to every file?

[ Permalink | « Hide ]

Ryan Torchia added a comment - 28/Aug/12 10:04 AM

I wouldn't call those "edge cases", really; they're pretty likely scenarios to be encountered by users. I think colors are appropriate when the same action is taking place (e.g. all tags have something added, all tags are removed, all are changed). Another color might be appropriate for anytime mixed action occurs (e.g. some added, some removed, some changed, etc.). I would exclude 'tag unchanged' from the color calculation.

I think it's unnecessary and unrealistic for users to expect more granularity that that for color. The information doesn't seem useful enough to warrant the amount of work it would take to have dedicated colors for each permutation of add/remove/change – just one color to indicate multiple actions. (I'd suggest something kind of like #303060, because it's distinct from the others, and I like that color.)

[ Permalink | « Hide ]

Michael Wiencek added a comment - 28/Aug/12 05:12 PM

The information doesn't seem useful enough to warrant the amount of work it would take to have dedicated colors for each permutation of add/remove/change

I agree, and I even wanted to avoid having a separate color for when things are mixed. Red/green/yellow are fairly common indicators for changes in a UI, but if I saw #303060, my first thought would be "what does THAT mean?!"

Wouldn't it make sense to just use the existing yellow/gold color when changes are mixed?

I would exclude 'tag unchanged' from the color calculation.

So in case 2 green should be used? I'm okay with that.

[ Permalink | « Hide ]

Michael Wiencek added a comment - 03/Sep/12 06:09 PM

Committed the changes in the previous comment in https://github.com/musicbrainz/picard/commit/5a2d849324b68276d70d9902c7148c43b6e9647f