One of the critical pieces of information about a piece of music in a music library is the duration, or about how long does it take to play this piece?
When planning a concert, music directors will often want to know this information, because a piece that takes 15 or 20 minutes to play will receive different consideration than one that takes just over two minutes. They each have their place, but it’s information a concert planner needs to know to make good decisions.
So now we come to that place in the development of LIDA where we have to provide for LIDA users to ask the question, “Show me all the listings I have that are [patriotic tunes, for example] that are less than 6 minutes long.”
Therein lies the rub.
First, we had to decide how we were going to STORE the duration of each piece, then we had to figure out how to specify the number to compare it to, and finally we had to figure out how to compare the two and return accurate results.
The solution, we found, was in being very careful with the FORMAT of how we stored the duration, and how we format the time to which to compare it.As you may know, there are two kinds of data you can store: numbers and strings. Numbers are things on which you can perform math, and strings are just a line of any kind of characters, which can include numbers.
The first thing to consider, of course, is what would users expect to see? What would they instantly recognize when they saw it? The answer is a time in the format “mm:ss”. We also needed to provide for those occasional works that are an hour or more long, which means we needed to have the format “hh:mm:ss”. That last is a bit more cumbersome, but it does provide the maximum capability.
Initially, we tried storing the durations as numbers, but due to the way the system handles numbers with colons, or multiple colons, we ran into a lot of challenges working with minutes and seconds.
Finally, we decided to store durations as strings, not numbers. We have made it so the user is guided to store the durations in the “hh:mm:ss” format, and anything other than that is either not permitted, or else automatically reformatted to that pattern.
More on that in a moment.
We then forced the number to which to compare the duration to be in the same format. This means if you want to see the tunes that are less than 6 minutes long, you need to enter “00:06:00” as the number in the comparison (parameter) field.
This produces super-fast and super-accurate results, but it still leaves us with an ease-of-use problem.
When entering a tune’s duration, a user will be tempted to enter “4:35” for a piece that’s 4 minutes 35 seconds long, but if they do that, the current version of LIDA (0.4.009 as we write this) will automatically turn it into “04:35:00” which is NOT what was intended.
The same thing happens when you enter a number, such as “6” into the parameter field.
This is NOT user-friendly, and one of the subsequent upgrades to LIDA was to fix this (see the next News post), to allow users to type in whole numbers and have them seen as minutes, or to type in just minutes and seconds and have them accurately formatted and not formatted as hours and minutes instead.
So there’s still some work to do in this area, to make LIDA even more user-friendly. Oh, excuse me. I meant to maximize the UX. (Droll look.)
We would love to hear your thoughts on this issue, and if you have suggestions to make it even better, please share!
You can use the comment form below, or you can email us directly on our Contact Us page, or become a Beta Tester (see the menu above). If you’re reading this after the beta test is complete and LIDA is live, we’d still like to hear from you.
So onward to keep building LIDA.