Difference between revisions of "History:Intuitive Picard Interface"
m (13 revision(s))
m (16 revision(s))
Revision as of 08:49, 15 March 2009
|Status: This Page is Glorious History!
The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.
The new interface has two panes that each has a tree-like structure. The left pane represents unmatched stuff, and the right one matched stuff.
This means you load files into the left pane. You can group them by album there, and analyze them so that they get PUIDs, but that is about it.
You can load metadata from MusicBrainz into the right pane, and then you can match files by dragging them (or the whole album group) from the left into the right pane.
Comment by David Srbecky - I like this idea since it minimizes the number of panels and it seems intuitive to me.
Comment by DawnTreader - Do not make the left pane album centered but rather artist centered. Please put the artist as the first tier of the tree, then under them the album(s) and then under that the songs. This is the most logical way to show music. It groups things from the largest possible group and leads the user to the smallest items. I like the icons, I like the intuitive interface, but I hate the fact that I cant sort by the columns and that the albums are the dominant organizing factor.
More Interface Thoughts
Here are some notes that I scrawled out in response to DonRedman's Picard Mock up:
- The current left hand side panel can still exist in the new picard -- it should be off by default but with an F key someone can toggle it open, drag some files and then toggle it closed again. People who don't care for it, never see it.
- Instead of relying an a tree to collect all the matched album information, use one control to list all albums (#3) and another control to list all the tracks of the selected album (#5).
- Panel #2 lists all the tracks currently being processed with the icons as in your proposal
- Panel #4 contains a tree control that lists all the album groups
I think this design too will be overwhelming for the user -- we should consider reducing the number of panes.
If we drop pane #4 and have #3 take up all the vertical space and then list album groups in #3 we can simplify the UI a little. By doing this we are grouping like data (groups and albums) as opposed to giving them separate panels. In panel #3, albums have one icon, groups have another -- the albums/groups are shown in a list with a column headings: album, artist, x of y, %match, unsaved. The track listing has a header that shows icon, #, name and duration.
This interface works for these three UI approaches:
- Drag and drop: drag a file from #2 to #3 and we attempt to match it to the proper track in the target album. Drag a file to #5 onto a specific track to match the file to the target track. (File can also be dragged from #1) To move a track to a different slot in the album, drag it. Album groups can be matched to albums by dragging them onto albums.
- Buttons: "Move to album" does the match to album (as D&D to #3). An Up button moves the file up one track, down moves it down one track. How can we find a way to use a button to guide a file from #2 to a specifc track? How can we merge/match albums/groups with buttons?
- Keyboard: Shift-right arrow, performs the same as "move to album" button. In #5 shift up/down move the file up/down one track. To match an group to an album or to merge two groups/albums: Hold shift and then press up or down until the selection is placed over the album/group that you want to move this group/album to -- then release shift and the group/album gets matched/merged.
Ooh! And another idea -- we can include a "All Albums" default album for panel #3, the users who don't care about albums can use this to list all the tracks that have been matched in #5 -- much like the old tagger did. If the user double clicks a file or track, the file/track is looked up and we can show the track oriented tagger icon next to the track matches. If the user clicks on the track tagger icon, the track that is selected in Picard (most likely the current track being looked up) will be matched to the track from the web page. Then the user can click on the next file to lookup and repeat the process, effectively using picard to match tracks without regarding albums. That should make both track and album camps happy and should make it easier to tag a few lose tracks with picard.
Many users like picard's traditional drag and drop interface. Some smaller changes that don't require a large scale rewrite could be done to make it easier to understand for new users while still keeping the good concepts of the old interface. The following could be done:
- Split the main treeview into two panels (with a horizontal separator between them).
- The upper panel contains a notebook with tabs "incoming", "album groups", and "error".
- The lower panel contains a treeview (the old treeview's "Albums" node).
- The metadata notebook is removed, instead local and server metadata are displayed side by side.
- The cover art panel is moved to the right and can be turned off.
Advantages: Not much rewriting required, the interface is easier to explain, metadata differences can be spotted easily.
Single panel variant
(by David Srbecky)
Comments are welcome - dsrbecky at gmail dot com
In the current Picard, directory structure is immediately lost. This variant tries to make as much of it as possible – the tree represents user's directory structure and the user matches MB metadata to the structure. To match directories with albums select the directories and click “Automatically match selected directories to albums”. Close matches are automatically selected. For the other cases, right-click on the directory and either pick one suggestion or click 'Look up' and find the album manually.
The advantage of this approach is that files will not get mixed up - one directory will be matched to exactly one album. That is, one file can not be accidentally assigned to completely different album and if there is some extra file in the directory you will see it.
On the other hand, you can still press “Automatically match selected files to tracks” in which case every file will be considered individually and thus every file in a directory can belong to a different album. (This is useful if there is massive amount of random files in one directory)
This interface is basically something like a shell extension - you navigate directory structure and select commands from context menu to tag files. I think this should feel familiar even to non-geeks. Removing the whole concept of clustering should really simplify things.
I also like the concept of matching metadata to files - it is closer to the user's intention: to tag files. They want to assign metadata to files, not files to metadata.
This interface also makes it very clear what is going to happen to which files. It is also very scalable – you can tag 10 or 100 albums but still not get lost.
I think it should satisfy the needs of album-centric users more then the current Picard and it should also simplify the life of track-centric users.
(Comment relating to previous mock-ups: The two sided comparison of metadata at the bottom of the window is not a bad idea. As long as it can be hidden, I would implement that as well)
File icon legend:
- Green tick (eg “Gladiator theme”) - File has saved MB tag
- Match indicator (eg “The Rock theme”) - File has been matched to MB track, but the tag was not saved yet. The name is the title of the MB track it was matched to.
- Two notes (eg “There You'll Be.mp3”) - File has no MB tag and was not matched.
Directory icon legend:
- Standard directory icon - “Mixed Directory” - Files in this directory do not relate to each other – each can be from a different album. This is analogous to the old MB tagger. This may also mean that the directory has not been mathched yet.
- Grey CD - “Pure Directory” - Content of this directory represents exactly one album. All matched files within the directory must be tracks of that album. The directory must not have any subdirectories. The listing starts with list of all tracks within the album (if file is missing, track is in gray). All unmatched files are in 'Unmatched' subtree. This is analogous to the new Picard.
Toolbar: (same order as in the mock-up – that is, roughly in order in which user will use the buttons)
- “Options” - Opens the options dialog box
- “Acoustically analyze” - Recursively go throught the current selection and obtain acoustic fingerprint and PUID.
- “Automatically match selected directories to albums” - Recursively go throught the current selection and try to match 'leaf' directories to albums.
- “Automatically match selected files to tracks” - Recursively go throught the current selection and try to match individual files to tracks.
- “Show differences in metadata” - This is a switch. If pressed the difference between file's metadata and MusicBrainz metadata is show in the tree.
- “Save all matches to tags” - Saves the tags
- “Submit PUIDs to MusicBrainz”
- “Play selected file”
- “Stop playing file”
Context-menu of file or dictionary:
- <Suggested match 1>
- <Suggested match 2>
- <Suggested match 3>
- <Suggested match 4>
- Automatically match
- Remove match
- Save tag now
Show differences in metadata
Here is an example of how the "Show differences in metadata" switch could work:
When "save" is pressed the tags will be modified. Colors are user to show how they are going to be modified:
- The parts of the string that will be deleted have red background
- The parts that will be added have yellow background
- The parts that won't change have white background
I have already written an algorithm that will do the diffs.
Of course the cool stuff is that all this should be mostly automatic.
Picard will have an AI called "Data" that will try the following:
- read the metadata of new tracks
- if at least n files have the same album tag, group them.
- do a lucene lookup for each album and load the metadata of the first match into the right pane, if the match is better than n%
- move the files over to the right, if they match better than m% (> n%)
- for the remaining files (ungrouped or no exact enough lucene match)
- analyze them and create a PUID
- lookup that PUID
- load that track's metadata into the right pane
- move the track into the right pane
While doing this Data should comment all his actions in a log window. Ideally each action could be reverted (unless something has been done on top of it). If you want to be really cool, then each file will have an action history, and you could undo steps for each file.
Also the different aspects of the AI should be switchable via options:
- Group files into albums [yes/no] if at least [n] files have the same album tag.
- Lookup albums by tag (web service enabled text search) [yes/no]
- Required match to automatically load album data into Picard [n%]
- Required match to automatically assign files to album [m%]
- Lookup albums by local lucene index [yes/no] (later, not initial UI revamp)
- Lookup files by PIUD (acoustic fingerprint) [yes/no]