Hello all. 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Attachment:
mockup.tcl
Description: Tcl script