Hi WeiwuApologies for not replying sooner. I started drafting a response a few days ago, but I did not get back to it until today.
On 2014-08-25 18:18, Zhang Weiwu <zhangweiwu realss com> wrote:
It took me 3 days to make the mockup. Didn't know my skill became so rusted. The goal of this design is to make the software easy to use, and accessible to more audience. The problems I am trying to address are not the pain in your asses: I attempt to address the problems faced by those who tried EasyTag and gave up; those who have stayed in this mailing-list probably can break a few OSes overnight. The good news is: once we solved this "easy to use" problem we may expect expansion of user-base. But please don't refain to talk about your problems, because it should not be less useful to existing users after redesign.
A big pain point for me is the number of steps required to do some simple/common use cases. I predominantly use EasyTAG to tidy up tags of an album that I downloaded (or ripped from CD) where most tags are already present. I only occasionally have files where there is no tag information. For me, the process of group-editing tags, and then scanning the tags into a filename (with a separate dialog, that needs to have the right mode activated!) is a bit awkward, and I think this is a common enough use case that it should be streamlined.
You should follow these instruction to experience it and read "the reasons behind this design", after instructions. Instructions to experience: 1. Run the attached code to see the UI. 2. Select any one of the mp3 files on the left. - Notice that the Tags on the right side was not editable to start with. 3. Select a second mp3 file on the left. - Notice how the "Edit Tags" fieldset on the right changes to reflect the fact that there are different values from different files for the same tag now. - Notice that upon selecting the second mp3 file, "Concatenate" fieldset shows up.
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.
4. In "Edit Tags" section, chose a tag to click its "Edit" button - The edit button is at the right - I intended for the same "Edit" icon as Google uses for editing Gmail's contacts, but used a makeshift icoin instead - notice how it changes to a button to save the change.
I like this idea. I wonder if it would make sense to instead have a single edit button for all the fields? Something that I have thought about doing for a long time is to make the cells in the file list tree view editable. The could lessen the need for the tag area entry fields, and free up some more vertical space.
5. In the "Concatenate" fieldset, check "Concatenate these files". - Notice that selected files are listed below, with suggested chapter names, editable. Idealy users should be able to re-order them here.
This would be a nice feature, but needs a fair amount of work, both in supporting the chapter tag fields (which are generally not part of the tag specifications) and in joining multiple audio tracks into one. It is unlikely to be implemented soon, and will probably need some more refactoring before it can be considered. This is not a criticism of the design, which seems intuitive, just a reality check about the implementation.
To reason for the new design, FAQ:
Question: Why one column for both files and folders, instead of two?
Answer:
Consider these alternatives:
1. The current design, files inside subfolders are shown with a
different background. With no other visual cue, users can't
conceptualize the different background with sub-folder-content.
There are also some theming problems with this approach, although I think that those can be solved.
2. Change based on No.1: make files-inside-subfolders not shown
unless these subfolders are activated on the left-most panel. This
way the user lose the ability to edit all files recuirsively in a
subfolder. Consider the case "Classical Music" folder, user would
be unable to change Genre of all at once.
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.
3. Change based on No.2: make tag editing panel on the bottom
instead of right-most side, it should be as wide as folder panel and
file panel together. Conceptually associate it with folders when
user just chose a folder, associate it with files when user just
chose a file or a few files, and offer an 'act recursively' checkbox
for folders with sub-folders. The difficulty with this design, is
how to make an effective visual cue to let user conceptualize that
tags are applied sometimes for folders, and sometimes for files (the
act to move it away from right-most is intended so that users do not
considedr they are only associated with files).
4. The design we have in the mockup. The disadvantage, is that user
will have to open each subfolder in order to do a file selection
recursively. It's easier to understand and sometimes more clicks to
do.
Design 4 wins. Besides, having 3 columns let users feel more
pressure than 2 columns. It's a complicated situation, the user
should not feel helpless by facing a contraption, and they should be
encouraged to attempt. Fewer panels helps that.
I agree that moving from 3 columns to 2 would be a good change overall, even it would occasionally require more clicks. 3 columns are extremely restrictive for a UI layout, and give rise to several problems in the current design (a narrow tag area, for example).
There is another disadvantage of current design (design No.4): users
has to know shift-click to be able to select a really big bunch of
files. The solution is to add checkbox on every file and folder
item. I cannot show it, because TCL/TK cannot add ttk::checkbox on
top of ttk::treeview, and I only know how to make mockups using
TCL/TK.
Using Shift/Ctrl to modify selections is old-fashioned, but not too uncommon. It has been replaced with "selection mode" in more contemporary UIs, which seems to be what you are describing, with a dedicated UI mode for selection without use of modifier keys. I do not use many UIs with selection mode, so I do not really know whether it is an overall good change or not. There are certain advantages to a selection mode when using a touchscreen for input, but I do not know whether this would be useful enough to switch over to selection mode exclusively.
Question: Why do you make tags editable only when user clicked Edit button?
Answer:
Two reasons.
1. User should be aware they are breaking diversity when editing
tags that had multiple values in different files and they should
announce such intention. However this can be achieved by other means
too, the more important reason is:
2. A users facing an editable form feel pressed to actually edit
them.
- To help get an idea: suppose you are cleaning mud from your car,
sweating, and two people comes by. The first person says "Howdie!
I can see you prefer scenic route, right?" and the second person
says "Can you explain why you did not drive the high way?"
- An editable form, expecially a long one, gives the feeling like
that second person. You feel that you were supposed to fill it
against your wish. The only other time a computer user would see
and feel such way, is when registering as a new user on a Internet
forum, and it's the least happy moment using the Internet.
Yes, the tag area is rather imposing. I think that some other tag editors have a dedicated window/dialogue for editing fields, and this might be another option (and could be a good way to "hide" some of the less common tag fields).
One convenient design to avoid too many clicks over "Edit button",
is to make the UI morph from a label into an text entry box upon
clicking. We can adopt that design if we add a single edit button on
the upper-right corner of tags panel, which, upon being clicked,
simply informs user that they can edit them on the spot.
Ah, I already mentioned this, so it is great to see that you had the same idea. It is easy to implement a widget that would switch between a label (probably a button with no border) and an entry when it is clicked on. I wonder if most users are familiar with such a concept in desktop UIs?
Question: Why there is no "add new tag" button?
Answer:
Because I was too tired making this mockup already. It should be
there in the end.
Question: Why do you put mp3 file concatenation into this software?
Answer:
Chapter marks are a form of Tag, and EasyTag should do it as well.
My original design idea was, 1) to offer users to edit the
chapter-marks in a file if user only chose one file, and 2) to offer
user to concatenate files to form a multi-chapter file, when user
chose more than one files.
Chapter mark editing would be a nice feature to have, and is easier to implement than concatenating discrete files into one. I have added it to my TODO list, but I do not know when I will have time to get it done.
The first I am too tired to make into the mockup today. The second
feature I did make it, and it shows up when user did
multi-selection. Like I explained, it makes user feel better to
announce their intention by checking the checkbox "Concatenate these
files" before offering them the contraption UI of doing so.
In general, I think that this is a good idea. It hides a lot of complex UI until it is needed (or can be used), which frees up both space and user concentration.
Chapter marks used to be a trivial feature, but audiobooks are
advancing in an amazing speed, just read Google Trends:
http://www.google.com/trends/explore#q=audiobook
The need to combine multiple audio files into a big one is also a
frequent need of users of librivox.org (most popular opensource
audibook source).
Can a native English speaker tell if concatenation is a bad choice
of word? Perhaps we should use "bind" or "join" instead.
Concatenation is the correct word, but it is less frequently used than join. "Merge" might be more appropriate, as it not only implies (to me) joining the audio, but also merging the tag data without losing information.
Thanks for starting the discussion about a new UI design, and for the mockup, which makes the discussion much more real.
-- http://amigadave.com/
Attachment:
signature.asc
Description: Digital signature