Alphabetized lists?
(re MS v3.6) This has probably been brought up before, so sorry if I've overlooked it.
I couldn't help noticing that MS’s lists (Palettes, Format > Style, Style > Text Styles, etc.) aren’t alphabetized. I don't detect any order to them at all. This seems to make it unnecessarily difficult to find things.
I’m guessing it's because each localized version of MS would have to be sorted according to its particular language, right?
Has any effort been made to address this? Not only would it make MS easier, but it'd make it look much more "polished" as a project.
Is it possible this free C++ localization library might help?:
Boost.Locale
https://www.boost.org/doc/libs/1_52_0/libs/locale/doc/html/index.html
Comments
Alphabetizing in English won't make mich sense in translations.
If we'd make the alphebetizting dynamic, that'd change the order of entries depending on language and so make the handbook (esp. its translations) more complex.
Yes, alphabetizing it would be different for each language and, therefore, completely arbitrary. Also, some languages don't have an alphabet. You can move the palettes up and down to suit your preference.
This is covered in the Handbook:
https://musescore.org/en/handbook/3/palettes#change-palette-order
In most lists, the order is actually quite carefully considered and has been fine-tuned over the years based on user feedback to be logical ergonomic - keeping similar types of things together, working gradually down from the more "global" to the more "specific".
As mentioned, the desire to have the application consistent between language is one important reason not to rely on something like the alphabet. Another is that alphabetical order assumes you know the name of the thing you are looking for, not always the case. But also, alphabetical order is notoriously inefficient. Consider the palette - clefs, key signatures, and time signatures are quite obviously related and things one often wants to access during the same phrase of score creation, so it makes sense they be adjacent. Or in the text styles list, title, subtitle, & composer very obviously "go together" logically and are likely being changed together, and it would be extremely awkward to have them separated.
So far from seeming "polished", alphabetic order generally makes lists look like no attention was paid to usability. Not true for all lists, of course - some lists really don't have a way to organize them logically, so alphabetic is the default when nothing better presents itself. That's true for the list of text fonts, for instance. But usually we can do better.
That said, for the palettes specifically, if you do prefer alphabetic ordering, you can have it, just drag the palettes around however you like.
In reply to In most lists, the order is… by Marc Sabatella
The list of sounds in a soundfont might good candidates for alphabetical order rather then GM order. On top they are not translated
In reply to The list of sounds in a… by Jojo-Schmitz
That comes up often, but to me that's vastly inferior - no way do I want flute and piccolo not near each other, or alto and tenor saxophones. Nor do I want the order to be different from one GM soundfont to another. But what would help immensely are headings for the groupings - "Keyboard", "Woodwinds", "Brass", etc. And that could apply also to other lists. Could be especially interesting, I think, for the palettes.
In reply to That comes up often, but to… by Marc Sabatella
Jojo-Schmitz > Alphabetizing in English won't make [much] sense in translations. If we'd make the alphebetizting dynamic, that'd change the order of entries depending on language and so make the handbook (esp. its translations) more complex.
Well, yes, I theorized it had something to do with translation, knowing this project starts in German. But there are many international software projects that manage to deal with this. I don't know the actual mechanics, but it doesn't seem like a huge technical challenge. For example, just have each translator provide that language's alphabet (or get it from Wikipedia?—come on, it can't be that hard), and have each version's controls populate according to it.
MS is the ONLY program I've used, as far back as I can remember, whose lists were jumbled up like this. I'm sorry, but it's just inconsiderate, requiring users to look through long lists each time they need a certain function. It looks like either:
• It didn't occur to you that German alphabetization wouldn't work in other languages; or
• It did occur to you, but you couldn't be bothered to do anything about it.
Believe me, alphabetization is a standard thing in software localization. But it's not automatic; you have to care about it.
underquark > Yes, alphabetizing it would be different for each language and, therefore, completely arbitrary.
No, it wouldn't be "arbitrary". (Arbitrary means "based on or subject to individual discretion or preference, or sometimes impulse or caprice".) I don't see why you'd even suggest that. It would be an antonym of "arbitrary", like "rational" or "reasoned". It'd be according to that language. That's the point.
underquark > Also, some languages don't have an alphabet...
So for those languages, you'd just leave everything the way it is, wouldn't you? (Although I'd feel sorry for those people, having to sift through every list, everywhere, to find anything... Not much we could do about that, though!)
underquark > You can move the palettes up and down to suit your preference.
Thanks! I've just hand-alphabetized my palettes, and they're tremendously easier to find. But should every single MS user need to do that? And to know it's possible in the first place? Why?
Marc Sabatella > In most lists, the order is actually quite carefully considered and has been fine-tuned over the years based on user feedback to be logical ergonomic - keeping similar types of things together, working gradually down from the more "global" to the more "specific"...
Dude, I know you mean well—but you can't imagine how condescending that sounds, and how illogical and un-user-friendly it'd seem to people just starting out with MS.
I've written documentation for many complex commercial software projects. At any point in those projects, a developer could say, "Why bother making this feature more intuitive / consistent / easier to find (etc.)? People should just learn it. It makes sense to us." (Of course it does—because they put it there.) And a few times, they actually have. That's why the best development meetings had people there from the help desks, too.
Software can't just be easy for people to use who already know how to use it. Look through this forum. How many of MS's functions do you end up explaining over and over—even though, to you, they seem quite sensibly designed? That should be a clue.
Music notation software is notoriously user-UN-friendly—not because people don't try to write it well, but because trying to create a computer version of something as non-linearly complex as notation, in a non-crazy-making way, is extremely challenging. So good notation software development means looking for every possible way to make things more natural and sensible. That means listening to people who don't have experience with your software, who don't already know where everything is hidden.
That's why I'm trying to give you the benefit of my experience as a life-long musician and music editor, and my lack of experience with MS. Hope that makes sense!
Marc Sabatella > As mentioned, the desire to have the application consistent between language is one important reason not to rely on something like the alphabet...
"Consistent between languages"? Or do you mean "easier to use in the original language than in all the others"?
Marc Sabatella > As mentioned, the desire to have the application consistent between language is one important reason not to rely on something like the alphabet. Another is that alphabetical order assumes you know the name of the thing you are looking for, not always the case...
Dude, you are way over-intellectualizing. I know what "notes" or "beams" or "accidentals" are. These are very standard notation terms. If, in some cases, MS has decided to call something by a secondary name (for example, "bar" instead of "measure"—although it doesn't do that), I almost certainly know both of those names—and if I can't find it under one, I'll look for the other. But none of this explains why I should need to look through an entire list for something whose name I know. It's just wacky.
Marc Sabatella > But also, alphabetical order is notoriously inefficient. Consider the palette - clefs, key signatures, and time signatures are quite obviously related and things one often wants to access during the same phrase of score creation, so it makes sense they be adjacent... Or in the text styles list, title, subtitle, & composer very obviously "go together" logically and are likely being changed together, and it would be extremely awkward to have them separated.
I totally disagree—and that's not just personal opinion, but based on the experience I've had using multiple notation programs through the decades, and software of ALL types.
I think you're way underestimating MS's users if imagine they don't know the difference between "Title", "Subtitle" and "Composer" text styles. People willing to take on something like music notation are, if anything, probably a bit smarter than the average person. We know which settings we're looking for.
Marc Sabatella > So far from seeming "polished", alphabetic order generally makes lists look like no attention was paid to usability.
Funny—I could say the very same thing about UN-alphabetized lists. Hey, wait a minute—that's just what I was doing here, wasn't it? How about that! 😃
Jojo-Schmitz > The list of sounds in a soundfont might good candidates for alphabetical order rather then GM order. On top they are not translated
Obviously, with something like instrument families, grouping similar instruments is more important than alphabetizing them... It's just common sense.
Really, guys, you don't have to "reinvent the wheel". Notation software, and lots of other software with things like feature leasts, has been around for a long time now. There are many good examples to observe and learn from. I'm not making this up, just trying to draw it to your attention. Cheers!
In reply to Jojo-Schmitz > Alphabetizing… by Andy Fielding
It looks like either:
You for got the 3rd option: it has been done that way on purpose. Those lists are sorted in a certain way that makes sense, grouping things that belong together, and not even in German this is the Alphabethical order.
Also note that the language used in MuseScore's source code is American English, all the way.
Example: "Accidentals" are pretty important, right? So they are placed pretty much at the top.
In German they are named "Versetzungseichen", so wohld be very much to the bottom
"Consistent between languages"? Or do you mean "easier to use in the original language than in all the others"?
No, more like something like the 3rd palette from the top is always the same, content wise, regardless of language.
In reply to Jojo-Schmitz > Alphabetizing… by Andy Fielding
> "Look through this forum. How many of MS's functions do you end up explaining over and over"
Surprisingly little. Most of the things that need explaining over and over are those where the users don't know the correct term for something (like voices).
There's a surprising amount of people that get confused because they can't find "Measure Properties" because they're using British English in which it is called "Bar Properties" etc.
You make a claim for people inputting music knowing music and the correct terms; there's a ton of forum posts here proving that this claim is simply not true. And in those cases having similar ordered lists based on functionality over language makes support of those users a lot easier.
Which again doesn't mean an option to alphabetize those lists is not without merit either (and in the case of Palettes, as you've discovered, the option to rearrange them to your liking is present already).
> "Obviously, with something like instrument families, grouping similar instruments is more important than alphabetizing them... It's just common sense."
Almost too funny, considering again the regular forum posts that request exactly this; to not group them according to similarity at all. Or do we just conclude that those users don't have your common sense and be done with it?
We provide the answers we do mostly because we are aware of the forum posts and different user inputs. And yes, we do value them. And no, that doesn't mean that every suggestion will make it in eventually (or even ever). But that doesn't mean that we shouldn't show/explain the thought process behind some of the logic.
And yes, that logic won't always be the same as a random users mindset. And no, we don't share that because "you must become more like us"; but in hopes that when you grasp the intention it might become easier for you to work with it as well (at least until the suggested change is enabled).
In reply to Jojo-Schmitz > Alphabetizing… by Andy Fielding
When I wrote “consistent between languages”, that’s what I meant. Not sure if you’ve ever done software support for a living (or for free!) but it really does make things easier if one can explain things or show screenshots as they are in English and have those same descriptions apply in other languages.
But that to me isn’t the main reason to avoid alphabet lists for something as crucial as palettes - it’s much more about logic and efficiency, as I said. Elements that logically belong together should be grouped together and sorted in a meaningful way regardless of spelling. This is common not just in notation software, not just in all software, but all user interfaces that rely on labels at all. That’s why the shifter of an automatic transmission is labeled PRNDL rather than DLNPR. It’s why a grocery store places apples near pears and not near allspice. It’s why every program’s Edit menu places Copy and Paste close together even if there are unrelated items between them alphabetically. It’s why the list of paragraph styles in Google Docs has Title, Subtitle, and Heading 1 in that order rather than the reverse. And on and on and on.
Only lists that don’t have such logical groupings to them are normally sorted alphabetically. As you note, there are tons of examples to draw from, and most of them show this same principle in action. Use logical groupings where they exist, sort alphabetically only for lists have no logical grouping. Also, alphabetic is somewhat common for lists that are long enough to require scrolling.
Look at Sibelius and you’ll see this is true there too. Their ribbons (closest analogy for palettes) are not alphabetic at all, they are logical. Finale and Dorico sidestep this by avoiding text labels for the most part, showing icons instead - which then of course are grouped logically rather than alphabetically.
This isn’t over intellectualizing; it’s common sense that you see being used in real life every day, even if there are exceptions and also room for differences in opinions. It’s definitely not about assuming users are particularly dumb, or that are they particularly smart. It’s trying to do what most users are likely to find comfortable, knowing full well that there will always be some who prefer something different. And that’s why we allow customization as well.