View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000041 | MMW v4 | Properties/Auto-Tools | public | 2003-02-06 05:37 | 2007-03-15 20:31 |
| Reporter | rusty | Assigned To | |||
| Priority | low | Severity | tweak | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Summary | 0000041: Make Properties dialog smaller / more grid-like & dockable | ||||
| Description | The current properties dialog functions ok as a basic property/tag editor, however, it has several usability problems: 1) User is forced into multiple clicks to access commonly used/view information because of the multiple tabs/large fonts/presentation 2) User must change file properties from a different dialog even though this is something that is often done in a single sitting (i.e. the user cleans all aspects of the file--not just the tags and not just the filename. 3) User cannot access auto-tag/auto-rename functions to automate editing when relevant 4) User cannot easily edit one song, then the next one, and so on... 5) User must change context (open browser or click web nodes) in order to get artist information. Recommendation: 1) Make the dialog into a resizable and configurable grid (with smaller text font) so that more/relevant information can be presented at once. -Fields can be divided into their current groups, and the user chooses which of those groups should be visible by default, and in what order. e.g.: Basic Info......Classification ---------------------------------- Title:..........Mood:............. Artist:.........Tempo:............ Year:...........Occasion:......... Track #:........Preference:....... Genre:..........Custom1:.......... Rating:.........Custom2:.......... -User should be able to <Tab> between all fields, facilitating data entry. -Rather than using a dialog box, when the user clicks Views-->Properties, the bottom portion of the songlist pane is filled with this panel (i.e. the panel is not 'floating'. 2) User should be able to easily edit the file's path and name. This can be accomplished by adding 'file directory', and 'file name' entries in the Basic Info group. 3) Auto-tag and Auto-rename buttons should be present on this form to facilitate automatic adjustment of properties 4) Add a 'Previous' and 'Next' button to the dialog instead of the 'OK' button and get rid of the cancel button. Also, use this panel whenever the user attempts to edit properties (i.e. don't bother having 2 versions of the panel). 5) Include the 'Get Album Info' button for Freedb, and add a new 'Search AllMusic' button, that causes the internal www browser to open above the properties pane. | ||||
| Tags | No tags attached. | ||||
| Fixed in build | |||||
|
|
1) Yes, I plan to make such a list of all fields, which will be quite powerful. 2) Do you want to let user edit it directly? Ok, I'm not against, then it should be also possible directly in the main songs list. I think that just one field - fullfilename - should be enought, there is no reason to complicate it by two fields. 4) I would implement Next and Prev as two small buttons/arrows. I think that Ok and Cancel should stay there, they are standard and also useful. Ok - confirm change and close. Cancel - do not modify the info and close (how to achieve this, just by the small close button on the top-right corner?) |
|
|
Re. 2) I suggested the 2 fields only because I thought grid column width might be an issue Re. 4) I should have specified my assumptions. Assuming the user has set left the default of 'save tags immediately' and has 'docked' the properties tab: -An ok button should not be used because it provides no feedback (i.e. normally 'ok' is used to 'commit changes' and 'close dialog', and the fact that the dialog closes is what tells the user that the 'commit' occured; in this case the dialog is always open, and so there's no way to provide feedback to the user that the commit occurred. UI convention in this case is to either: a) Use an apply/update button b) Use an in-place editing paradigm In this case, option a) is generally not used because the use of 'Previous' and 'Next' buttons will cause users to sometimes click 'previous' or 'next' assuming that the changes will be committed. This leaves us with option b), and assuming option b) is used, the 'cancel' button is no longer required, because in an 'in-place' editing paradigm, the user assumes that changes are committed as soon as they're made. Now, supposing the user just clicks Edit-->Properties rather than View-->Properties, in this case I would suggest that the implementation be identical (i.e. the docked properties 'dialog' appears--the user can close it if they desire). |
|
|
Something else that I forgot about: In addition to auto-tag and auto-rename, two other editing-related buttons should be available on this pane: -'Get Album Info': this is already implemented, although the 'Details' button should be changed as indicated -Search Allmusic: I've played with many of the music databases, and found this one to be extremely valuable. If the user couldn't find needed info from other locations, they could easily press this to get the missing info. I've added an item 5) in the bug accordingly. |
|
|
[triagehigher] |
|
|
Fixed in build 481. I made just changes that I see as necessary in this version (full rewrite of the dialog with completely different logic would require too long). Two arrows were implemented - upon clicking them everything is saved and next/previous song is shown. I tried to make other changes as well, but there is problem with arrangement of the dialog: - put filepath and filename to the first tab? It would be too complex, what about keeping it in its current sheet, but allow to edit them? Any other proposal? - new buttons: - do you think that freedb query is appropriate here? Because of its album orientation I don't see it useful. - search AllMusic: they do not have any interface for making queries in their database (I mean from developer point of view), it would be probably possible to solve it by making query directly to some webpage, but the page can change and also I am not sure if they allow such kind of usage. - integration of auto-tools: I think we should review this after new version of auto-tools is made, simple calling of their dialogs would probably not be so much useful, we will see. In the future I suppose that View|Properties could bring something like what you described - a special part of the main window with a possibility to edit all properties easily. However the current dialog will always be useful - e.g. for graphics, ... |
|
|
I tested the back/forward arrows, and this works nicely. It actually makes a big difference when editing properties for large numbers of files since it means that the user doesn't have to continually click different panels. Re. the other changes: -Filename/path on basic table: Comments are generally 1 or 2 lines, yet we take up 1/2 the dialog with that pane. Can't we shrink it and add an _editable_ filename/path field? (note: no buttons are necessary--just commit the change when the user cause an 'update'. -freedb query: There already exists a 'Details' button which gets info from Freedb. This button should be renamed to 'Album info'. I was suggesting a 'Track info' button on the assumption that bug 0000085 is going to be resolved. -search AllMusic: given the limitations, you're right--probably not that useful -Auto-tools: these buttons are quite useful here (see musicmatch for an example of this). The user uses this dialog when they're editing all kinds of track properties. In this context, they would be very likely to Auto-tag/Auto-rename items. The buttons could easily be placed right above the existing 'Info/buy' and 'Details' buttons. -Grid view: I think that this is extremely important, since changing to a grid view will solve all of the space issues that plague the current dialog. That said, I agree that it's probably beyond the scope of the current release. |
|
|
Fixed in build 484. - File and path renaming is possible now. The field are still on the info sheet, we would need to move three fields from there to the Basic sheet. Opened for future modifications... - The 'Details' button gets information from Amazon and not Freedb (isn't it cause for confusion in another bug?). What will be done with this button depends on bug 0000085, we will see. - I started to implement auto-tag, but the logic there is not so easy (Show dialog, modify something, auto-tag, modify something, press Cancel or similar command for groups of songs). I will need to think about it a bit, any proposal is welcomed. |
|
|
Tested in 1.484: File/Path renaming works well (although if the Auto-Rename button is on the basic tab, the file/path will also have to be on the basic tab) - The 'Details' button seems to work, although it has the same problems as documented in bug 0000085. I don't think the terminology is a problem, since the way I think this type of functionality should work is that if an Album is selected, then 'details' gets Album info, if a Track is selected then Track info is gotten. But like you say, we'll see once bug 0000085 is resolved... -Re Auto-Tag, I didn't expect the logic to be complex. I thought it would work along the following lines: -User opens properties and notices that filename is bad -User clicks AutoTag button -->Auto-tag dialog opens (forced focus: no other function can be accessed while the dialog is open, so user must <Update Tags> or press <cancel>). -User is returned to Properties dialog (properties have been updated to reflect any changes). The <Update Tags> wording for the button within the dialog makes it clear that changes are being commited at the earlier stage. If we want to completely remove any ambiguity, then we could use the 'Show Properties' dialog any time properties are edited, but change it so that there's no <Update> button, and the Close button also updates properties (i.e. the Properties dialog follows an in-place editing paradigm and there's no way to back out of changes made). |
|
|
Fixed in build 494. - Auto tools were added, there are some inconsistencies with using them together with Ok/Cancel buttons (as discussed above), but they are quite negligable. |
|
|
Verified in 1.494. Works great!! I'm leaving this bug open, because there are still a couple of issues that need to be tracked, in context of the discussion in this bug: Priority Urgent: -Path/filename info should be on 'basic' pane for this to be more useful. Tracking this issue in bug #377, and raising to 'Urgent' Priority Normal: -There should be a single mode of operation for the properties panel. The single-mode of operation panel should be implemented as a dockable grid (i.e. it still needs to integrate with the rest of the UI, but should take up much less space) -Minor changes to improve users understand of when a change is committed. tbd. |
|
|
Fixed in build 495. File info was moved to the Basic sheet. |
|
|
Re-opening to track the remaining open issues. Bug 377 can be used to track the file/path issue. |
|
|
This has all pretty much been fixed. Creating a new bug to track the remaining problem that the View:Properties isn't dockable. |
|
|
This has all pretty much been fixed. Creating a new bug to track the remaining problem that the View:Properties isn't dockable. |
