Hi WeiwuAh, sorry, I was reading too much from the mockup. :-)
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.
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.
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.
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.
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 would be beneficial to make casual uses simpler, and I think that your design ideas are a good way to do so.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).
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.
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.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).
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.
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!
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.
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.
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.
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.
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.
OK.
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.
--
http://amigadave.com/
_______________________________________________
easytag-list mailing list
easytag-list gnome org
https://mail.gnome.org/mailman/listinfo/easytag-list