Hi Weiwu On 2014-08-29 23:59, Zhang Weiwu <zhangweiwu realss com> wrote:
On Fri, 29 Aug 2014, David King wrote:It seems to work well to show the contents of 2, and maybe 3 different tags, but I wonder if it scales well with more files? I notice that you have the ellipsis to indicate more files.I forgot to explain that I intend only some values for a given tag be listed, when user chose multiple files to work on. I did not design any action on the ellipsis, leaving it to future work.
Ah, sorry, I was reading too much from the mockup. :-)
The intention of the design: 1) those who work on a single tags do so easily, strees-free. Practically, some player (iPhone) make heavy use of a select few tags, categorizing all media library by these tags. Expedient users are motivated to set them right.
I think that in those cases, it is also useful to improve automated techniques of filling in tags, with things like acoustic fingerprinting, and CDDB/MusicBrainz searches.
2) those who want to edit every tag should be able to use <TAB> key to go through all tags without the "OK" button in their way or refrain themselves from doing so by not seeing a form to start with. Presuming this is a valid use case (I don't use it that way).
It depends where a user lies on the continuum of "fill in the tags for this set of untagged files" versus "correct this single tag". EasyTAG currently fits relatively well in between those two extremes, with some useful batch processing features which make some of the more laborious tasks simpler.
It would be beneficial to make casual uses simpler, and I think that your design ideas are a good way to do so.
About "+ more tag" button: I earlier proposed the removal of ID3v1, because, if we only work with ID3v2, we can make the interface terse. Only Title, Artist, Album, Genre or tags that have values, would be shown, and "+ more tag" button offers a full list of all ID3v2 tags to suit the tastes. But, after having worked on the UI for a few days and read wikipedia, I now realize there are only 7 tags in ID3v1. If there are valid use cases that make use of the 3 additional less-used ID3v1 tags (Year, Track, Comment), there should be some space to let the 3 be packed shown by default.
I do not use the comment fields much myself, but the track number field is useful for library-based music players (so that tracks can be ordered correctly when playing an album).
The year field can be useful when creating playlists, but the search feature in EasyTAG is not flexible enough to make this good for (as an example) selecting all music from 1985 to 1992, so again this mainly benefits library-based music players.
Others would say the important fields (always show up) are Title, Artist, Album. I added Genre because people have many reasons to build playlist on Genre, hence needing to tweak this tag. I give you a funny use case: Chinese would think you highly if you play New Age music (typically Bandari), and start to talk in civilized way upon hearing it. I need to quickly build a playlist of New Age music when guests visit, but normally I don't like them.
I have always thought that the genre field was strange, but again it is useful for creating playlists and as a means for categorization. It can be difficult to get genre information from online metadata databases, so having a manual way to set the genre is useful (although it does not need to be prominent).
A more radical change could be to, on startup, select a folder (or files) to edit, and then to change the view and show just those files in a (flat, with no directory hierarchy) tree view once the user has chosen. This reduces the 3-pane layout to a 2-pane layout, which makes sense while editing files, as there is little need to simultaneously examine the directory hierarchy.I think it would work perfectly if users are allowed to right-click on a folder in file manager and choose to run EasyTag on it.
This work well with the new Nautilus extension, which adds an “Open in EasyTAG” item to the Nautilus context menu for files and directories. This is in the master branch, but has not made its way into a release yet. Thanks to Victor Santos for writing it!
There are 2 problems with existing design that this new approach will inherit: 1. Users are unprepared to open a very very long list. In my case I have 3000 hours of collection, and the start of EasyTag took long time.
Eventually, most of the file access in EasyTAG will be done asynchronously, and the UI will be usable while files are being processed. This is, however, a long way from being complete.
2. Actually, EasyTag crashed on some of the buggy files, but since it intended to read all files to start with, it crashed on start. I took the painful process of try-and-error to locate the buggy file. Usually I should be able to tell the buggy file by seeing a software crashing opening its directory, but EasyTag crashed opening its parent-parent-parent-parent directory.
It would be great if you could report bugs with stack traces for the crashes. The crashes might me inside a tagging library, and difficult to fix (especially for the unmaintained ones like id3lib), but if they are inside EasyTAG it should be possible to fix them.
Both two problems well exist in any library-based player software, including iTunes (managed to skip the buggy file without crashing itself) and Rhythmbox. It's not EasyTag specific. There are workaround designs. Can we list this in a seperate topic and wait for people to criticize it, in case someone have good use-cases that is broken by this. Same to ID3v1, maybe someone will cry for it.
OK. -- http://amigadave.com/
Attachment:
signature.asc
Description: Digital signature