Difference between revisions of "History:Intuitive Picard Interface"

From MusicBrainz Wiki
((Imported from MoinMoin))
((Imported from MoinMoin))
Line 8: Line 8:
Comment by David Srbecky - I like this idea since it minimizes the number of panels and it seems intuitive to me.
===More Interface Thoughts===
===More Interface Thoughts===
Line 44: Line 46:
Picard will have an AI called "Data" that will try the following:  
Picard will have an AI called "Data" that will try the following:  
# read the metadata of new tracks  
# read the metadata of new tracks  
# if at least n files have the same album tag, group them.
# if at least n files ha
# 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]
[[Category:To Be Reviewed]] [[Category:Development]]
[[Category:To Be Reviewed]]

Revision as of 04:01, 31 March 2006

RobertKaye and DonRedman have started to work an an intuitive user interface for the PicardTagger, because the current one is, well, shitty.

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 left pane, and then you can match files by dragging them (or the whole album group) into the left pane.


Comment by David Srbecky - I like this idea since it minimizes the number of panels and it seems intuitive to me.

More Interface Thoughts

(by RobertKaye)

Variant 1

Here are some notes that I scrawled out in response to DonRedman's Picard Mock up:

picard notes.jpg


  1. 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.
  2. 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).
  3. Panel #2 lists all the tracks currently being processed with the icons as in your proposal
  4. 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.

Variant 2

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 seperate 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:

  1. 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.
  2. 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?
  3. 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.


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:

  1. read the metadata of new tracks
  2. if at least n files ha