What Do We Want for the User Interface?

The interface is going to be divided into two main areas, one for listing all the available file (the "File list") and the other to edit the tag content of the selected files (the "Quick Tag Editor") not to mention a Toolbar and a Status bar.

The Quick Tag Editor

In order not to overload the user with too many informations in quite small place, we decided to get rid of text label which explains to what text edit areas refer. Instead, we decided to use icons which should be explicit enough for the user to have no doubt about their meaning. Furthermore, if the user hover the text area or the icon, a tooltip will display the noun of the associated tag and if a field is left blank, it will be automatically filled with the tag name written in a greyish style so that the user can understand that it's just there to inform him. Another track towards use facility is the limitation of the amount of information: our aim is not to provide a way to edit each every tag in this place (for each format, there are at least several dozens of tags), or to let the user add its own customed tags (which is also possible). Instead, we would like to provide exactly the appropriate informations. Therefore, we chose to display only the tags:

  • artwork
  • track number and total track number;
  • song title;
  • artist name;
  • album name;
  • disc number and total disc number;
  • year
  • composer;
  • genre;
  • compilation;
  • comment.

To these editable fields, we added a button which enables to edit the lyrics.

When resizing the Quick Tag Editor, the text fields also get resized while the image would just stay centered and not be resized. Contrary to the text fields, the fields which have to contain number would not change: it wouldn't be logical to have a lot of space only to enter the track number. Therefore, we decided to give these specific fields (track, total track, disc and total disc number) a fixed length corresponding to three digits. The year and genre fields are going to be list boxes, and would indeed not be resizable.

Concerning the artwork, we would start by just displaying the image associated to the file. If the user wants to change it he can simply drag it and drop it anywhere in the Quick Tag Editor and the image would change with hopefully a fancy effect. When hovering the image with the mouse, we would display a clickable icon in the bottom right corner of the image which when clicked would hide the image displaying instead a text saying “Drag an image here”.

To display non-modifiable informations about the song selected, we want to provide a section called “Audio Properties” in the bottom of the Quick Tag Editor. This section would not always be displayed and the user could have it collapse in the bottom of the Quick Tag Editor by clicking a disclosure triangle.

It is going to be possible to select several different files to edit common informations. In that case, all the shared tags would be displayed normally whereas the different tags would still be editable but we would beforehand fill it with a greyish message "Various values".

The last element which would be part of the Quick Tag Editor would be a small activity panel accessible using a button in the status bar. It would be placed just below the Quick Tag Editor, having the same width (note that it's not really a part of the Quick Tag Editor, as, when appearing, it reduces the Tag Editor's height, but it always appears in its continuity). This window would only be used to display the progress of tasks that implies writing on the disk, but it should be able to separatly display the progress of different tasks processed simultaneously.

Finally, the Quick Tag Editor can be hidden, but as it is very useful and designed to be used most of the time, this possibility would only be accessible through the menu bar. Yet even when the Tag Editor would be hidden, the user would still have the possibility to show the activity window. Clicking on its button would bring the Tag Editor back with the activity window opened (without caring about its state when the Tag Editor got hidden).

The File List

The file list is designed to be composed of four levels (which are not mandatory and can be forgotten). The first level is the level of an artist, the second level has to do with a serie of records that can be grouped together, the third level is the album level and finally, the fourth level is the file level. Provided this organisation, the challenge was to display all these levels in a simple and elegant way.

To achieve this goal we've decided to display a thin line for the artist which would distance itself from the others by being in a different color. Then the serie line would be displayed in a bigger way displaying an image associated to the collection, in a similar way to the album line. The file line would be thin again but in its own color. The album, serie and artist line could be folded and unfolded by clicking on an arrow on their right.

This organization would provide easy ways to select many files sharing the same belonging: for example, clicking on the artist or on the serie line would select all the files inside these levels and would change the information displayed in the tag editor to display only artist or serie specific informations. Note that this behaviour differs from what happens when the user selects different files using the Ctrl or Shift keys which only changes what is displayed inside the text field, and not the whole organisation of the Tag Editor. On the contrary, when clicking on an album line, all the files would be selected just the same way as when selecting them "by hand", because all the informations displayed at this level would be informations that would be directly written in the file tags, whereas for the artist level and for the serie level, the metadata would either be saved in an internal database, or on the disk if the files organisation suits this behaviour (for instance, the image associated to the artist could be saved in the artist's directory). To explain this behaviour to the user, we would use tooltips and warnings that could be disabled (with a checkbox like "Never remind me this again"). The artist line would provide one additional feature: it would always stayed displayed when scrolling. This means, even if you have many two hundred files of the same artist, as long as you are scrolling among these files, you will always see the artist line at the top of the file list. This line would only be replaced by another artist line.

In case there are some missing informations, the serie line and the album line would disappear and the file line would grow as thick as an album line, but displaying different informations, specific to the file. Albums with only one file would be displayed in the exact same way.

You may have noticed that we never spoke about checkboxes to select files: this is because we think it's not very ergonomic for the user to be forced to click several times in a specific field, and that it's especially hard on a laptop using a touchpad. We think nowadays users are used to keys like Ctrl or Shift to select their files which is much faster and doesn't requires the same accuracy with the mouse pointer.

Toolbar and Status Bar

Right now, the only special item we want to add to the toolbar is, on platform that supports it, a button for previewing the files. It has already been successfully implemented on OS X and is going to share the same design as in other mac applications.

Concerning the status bar, we plan to use it to display the number of selected files, the total number of files and the size of the user's library.

Taking into account the user's action

We want to be able to provide undo and redo possibility for most of user's action. To do this, we don't want to add buttons, because we think users are accustomed enough to use keyboard combination like Ctrl-Z or to find this functionnality in menus. This feature would not be provided for all elementary actions (for example if the user is typing the artist name, we would not allow him to undo one letter), but rather for actions such as "editing the artist name" which could be undoed to come back to the previous artist name. The saving to disk actions would be realised either for specific actions, like reorganizing all the files in the filesystem, when the user would change of context, for example, when he had selected some files, made some modifications, and then selects other files, or when a certain amount of time elapsed.

All these action must not freeze the interface: for the user, even if a task takes a long time because of many hard-drive access, he must be able to keep on browsing his collection and changing tags, without even noticing that there are many datas processed in the background. Therefore, we will efficiently use multithreading to perform different tasks at the same time.

Last modified 12 years ago Last modified on Mar 17, 2009, 10:35:40 PM
Copyright © 2008-2017 The TagAdA Team. All rights reserved.