A new user interface for EasyTag for the 14-year old well-known Music tagger software.
This is the user interface as of version 2.2.2:
- User operate from left to right. In this snapshot the folder “Collection” is selected.
- Not only the files in selected folder shows up, but also files in its subfolders. “to be by your side.mp3” actually is in “Nick Cave” folder, not in “Collection” folder. The special light-cyan background color denotes this fact.
- Files with modification unsaved are in red color. In other software they are often prefixed with an asterisk. EasyTag would automatically correct incorrectly tagged files, and prompt user to save the collection, which resulted this reddish scenario.
- After the user selected the folder “Collection”, he further proceed on selected “When you believe.oga”. The 3rd column (the from on the right) shows the tag information of the selected file.
- The “Abc” button here saves this tag to the files selected. The original idea was to hint users that the tag is to be saved to multiple files, where “Abc” denotes “multiple files”. It is difficult for user to conceptualize this, because the “Abc” button does not show up when user choose multiple files – it always shows up, like in this case when user selected only a single file.
- Filename is repeated in this entry box, because user may wish to change filename too when he changed important tags like Title or Artist.
- The tags are placed in two tabs, “Common” and “Images”. Users can see or edit the image tags, like CD cover, in the “Images” tab.
How do we improve it?
(You can skip this section and scroll down to see the new design if you are not interested in the theory.)
The old user interface is functional. In fact, the software has been serving thousands of people and constantly being updated to date. Those who knows how to use it find no problem of using it.
As the software is meeting its 14 birthday, new users are demanding to enjoy the same level of ease of use they can obtain from modern designs like Android/iOS. The design needs to cater USAGE and EXPERIENCE in order to catch up to that level.
Usage-centric design requires software not only to function, but also to cater the way users intend to use it.
Let’s look at a simple scenario. A user opens a music file, it is Célion Dion’s “Let’s talk about love”. He probably intends to check Genre, but he noticed that instead of the sensual pose of Célion Dion, there is a picture of a man sitting with crossed legs like a budda. Apparently the image was misplaced. He proceed on to delete the incorrect image. This is the same workflow one would do to maintain their bookshelf: he happens to see a misplaced book, and put it to the right place.
However this workflow is not working for EasyTag. As marked in ➆, Image Tags are collected together and placed in “Images” tab. Since our user did not see the man sitting like a budda, he will not correct it. He probably will want to do so when his MP3 player shows the wrong picture, but that was a moment when editing tool was far-fetching.
Let’s consider another scenario. When a user wishes to update a same tag for multiple files, he would select these files. At this precise moment, he would look for widgets that allows him to do changes to a batch of files.
This is the moment when batch saving tool, marked ➄, should be available to the user. “Abc” button is not a good way to represent the idea of batch saving – because it does not suggest an action (while the user is thinking about doing something). A button that has action connotation would work better, like “OK” button or “Done” button. But even the “Abc” button would perform well if it shows up or highlights upon mutiple file selection.
In conclusion, the 2.2.2 old design reflected the popular design philosophy of 90s: a function based design. Each function maps to a widget or an area of user interface control. For example: “Let’s make image-editing function” would result directly an area of user interface called “Images”. Modern usage-centric design does not see software as a collection of functions, but that the use of a software is a process, and the design reflects not function, but the way of using it.
It’s likewise can be explained by example.
Let’s focus to the tag editing area, the right-column of our 3-column layout. What does a user feel about it? Imposing. It’s a delicate long form, and it feels imposing. Now let’s ask: what do we want user to feel at this time? Do we wish the users feel imposing?
There are times we do. But for this case, the user just opened a software that is more complicated than average, and handling a task that requires more precision than usual. The user has a music library, and he may damage it. This is not a text editor, and undo feature wasn’t expected there (it isn’t neither). The user feels unsafe. He needs a garantee that he isn’t breaking his library (some did anyway, according to forum posts).
The design to cater this feeling is to not make everything editable at once.
An editable form, expecially a long one, gives the feeling that user is supposed to edit it. This feeling is unwanted, especially consider that in a normal session users would leave most fields untouched at most times. 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.
To help getting this feeling: 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 personsays “Can you explain why you did not drive the high way?” A form-like interface gives the feeling like what this second person gives, that you feel someone is supposing you should answer for your inaction (of not filling the form).
The red color in current design have a simliar issue. It prompts users to be very careful to the extent that makes the UI unconfortable, without suggestion on what to be careful with. Let’s put aside the auto-correction feature, which leaves most files in red to start with. Even if the files are really edited by users and unsaved, it would be more approciate to colour them red when user intend to quit or leave this set of files without saving, not when it is freshly edited.
To help getting this feeling: Let’s suppose you walk out of a supermarket, and the alarm is set off. While you are stunned, an officer comes up explain to you that you used more than 30 minutes for shopping and your car would be charged a small parking fee. The warning is given at an inadequate level. You were alarmed when nothing actually went wrong.
This inadequate level of warning appears everywhere, and was only being improved in the recent years. Many people had the experience, that when he attempts to withdraw, the ATM machine tells him “Error: insufficient balance”. This is inadequate, because nothing went wrong. Insufficient balance is a situation, not an error. The user didn’t do anything wrong in operating the machine, and the machine is not misbehaving and giving out cash for free. Nothing is going wrong; where is the error? If ATM machine has insufficient internal memory, it is an error; insufficient balance is not an error.
Concluding our analysis, we can improve the user interface by catering the user’s feeling at the moment he handles the task.
A new design
Since the new design involve a lot more dynamic change of UI elements, it cannot be explained in a single screenshot with circled number marks. I’ll introduce it with many screenshots of different stages of usage.
- 2-column layout is used in place of 3-column layout. Since we always work on files, it is not necessary to use one column specificlly for folders.
- Tags of the selected files are listed on the right column. Only tags that have value are shown, except the important tags frequently edited, like “Artist”, which would always show up.
- User clicked the Edit button right to the “Composer” tag, and the tag morph into an editable entry.
- The file is saved when user use OK button. Here a check is used to represent OK button.
- User click the “add tag” button, which, in the previous screenshot, is represented by a plus sign (“+”), a pop-up menu suggests a tag to add.
- These tags are uncommon tags that had no previous value, and is well hidden until user click the plus sign, hence avoid users feeling pressed seeing a big form to start with.
- User clicked the “Edit All Tags” button, all tag labels morph into text entries.
- This is to cater two types of usage:
- Some users intend to do heavy editing. He should be able to navigate through all tags using keyboard, without having to mouse-click “Edit” button for every tag.
- Some users developed the habit of looking for the word “Edit” when they intend to edit. The word has to be there to be found.
- When user selected multiple files, the tags are updated to contain the most frequently used values. This is for 3 purposes:
- For the user to observe whether or not they need to unify values for a certain tag.
- When the users decide to do so, for them to see the old values and even copy & paste them to save them as a unified value.
- When user is saving to a batch selection of files, make it very clear on the UI that they are doing so, so that they do not mistake that they are working on a single file in a second of slip of mind.
- Please notice that upon multiple files being selected, one “concatenate” tool box appers on the lower-right corner, offering users to join the files to a big one with chapter marks. This toolbox only appear when user chose more than one file.
- When user checked the checkbox to concatenate the files, the tools for the deed shows up. This way, users are bothered with this part of complicated UI when necessary.