Re: A UI design idea mockup for discussion

[Zhang Weiwu <zhangweiwu realss com>]

Dear David

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.

> > 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.

This may work for the tag editing panel:

1) every tag's field value are labels to morph to entries upon clicking, 
with an "OK" button for users to save that label only. The UI should be 
suggestive, using subtle visual cues to remind users the lables are 
editable.

2) a single Edit button on the top, when clicked or activated with a 
shortcut key (or right-click context menu "Edit"), coverting all tag values 
from labels to entries, and offer a big "Save" button on the bottom right of 
the form, to apply the whole form.

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.

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).

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.

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.

> 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.

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.

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.

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.

> >         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.

I agree. Luckly we don't have to decide this by now. There are built-in 
designs and add-on designs, and "adding checkboxes when there is already 
shift-select" is an add-on design, hence can be done in later versions when 
we see fit (or given up), without lose.  Some designs decisions better be 
built-in, like not displaying all tags for editing.