Florian, many thanks for the prompt, generous and gracious reply to the prior post (about optimizing cover art space).
Your mention of optimizing vertical space motivated me to do a mock-up applying some hard learned methods to do just that.
Extra commentary and a bit of over-explaining is not meant to "talk down" to anyone, but offered with the hope that it might be accessible to a wide audience. A slightly abridged version of the following text is repeated on the attached image so it can be easily referenced while viewing the mock-up.
The methods below, pushed to the limit, could probably reach 14% in vertical space economy in the attached example, without compromising utility to the user or legibility—and perhaps even enhancing legibility a bit. A few more tricks might get the example to 18% with little downside to the user. However, depending on the program libraries in use, the development time beyond 10% or so might be unreasonable.
Field names forced to all caps to offset a 20% reduction in base font’s vertical height. All caps also avoid descending characters which allows the labels to move closer to the field box for additional reduction in vertical height and a tighter association with the field. This also gives the field labels a diminutive size and distinctive look. According to human interface theory, as field labels do not (typically) change often and are quickly learned with data-entry and cleaning, diminished prominence (contrast, size, etc.) is appropriate.
Removed the bright single-pixel highlight of the field box to avoid visual interference with bright field text and content—simultaneously reclaiming a tiny amount of vertical height.
Darkened field data box to improve contrast for readability and increase focus and to offset decrease in border contrast (a result of above step).
With reduction of field label height and tighter field label spacing, fields can be moved closer and retain improved legibility. The space between fields and their labels must of course be much smaller than the space between fields to preserve proper intuitive association.
The relaxed multi-line spacing of ~1.3x is recommended for longer text bodies than typically encountered in metadata. Therefore, this example uses tighter spacing of ~1.2x to recover additional height.
The font size for field values remains unchanged.
Note: Custom colored thumbnails make file-type apparent at-a-glance, avoiding the need to display the extension and saving horizontal space in filename lists.
For further study: These concepts are covered in courses on Human-computer Interface (HCI) for programmers and developers and in texts such as "Looking Good in Print", originally published to help desktop publishers obtain an understanding of visual appearance and legibility in print and on screen. They are also similar and related to ergonomics.
Yes, vertical space is precious. I recently started employing a horizontal bar because I am starting to run out of vertical space and now need to scroll down to see the whole cover art. Unfortunately if I want to work with MP3Tag and another program side by side, that inhibits the functionality of the horizontal tag panel because the screen is now shared horizontally (though I could display each program side by side vertically, though I do not find that as usable).
A lot of the things you have suggested I have thought about. You offer some good solutions. The spaces between the fields can also be condensed a bit. I will also add that I have proposed adding a tiniest field, which if half the size of the tiny field. That would also great enhance my use of space, both vertically and horizontally. It would also be helpful to add the ability to reduce the size of the cover art display instead of having it based on the width of your vertical tag panel.
Often programmers use pre-built libraries for the user interface, so it may well be that some/much of the demonstrated fine-tuning isn't an easy fix. However, it seems that making the field names all caps and slightly smaller might be low-hanging fruit.
DataCleaner, thank you for your interesting suggestions. However, I have my doubts.
For years there were complaints in this forum about the Mp3tag font size being too small. Eventually the developer increased it and (for me anyway) it is now just right. Now you come along and want to tamper with that long-sought-after improvement
Well, my labels do change often because I rearrange and add to or remove columns and field boxes almost every time I use Mp3tag. My selections and their sequence depend on the tasks that I will perform that day.
Not clear if you were referring to the tag panel, to the column headings, or both. For the columns, that reduction would surely degrade their legibility. Below is a 1:1 screen shot showing some of my headings. My resolution is 1920 x 1080:
The default font size is barely large enough as it is now. All caps would help a little, but to me it would look odd to have the heading font height lower than the data font.
As for the tag panel, I happen to like the current large labels. Yes, they consume vertical space, but to my eyes they make the whole panel easy to scan at a glance. They also reduce my annoying tendency to start typing into the wrong box....
I wonder how many users will see a pressing need for showing a few more rows per screen without scrolling. The developer has been cautious about major interface changes over the years, and with good reason, I think.
I found this guideline from the Harvard University which says: Avoid using all caps. Readability is reduced with all caps because all words have a uniform rectangular shape, meaning readers can't identify words by their shape.
So apparently there are different opinions about what is best to apply.
Or the other way round: there are good reasons for the way it is now as there may be reasons for other designs - but a decision has to be made.
You see what the current decision looks like.
