Jazzy
8va ~ Going the octave higher
Staff member
Administrator
Amplify Staff
Site Supporter
Founding Member
If we're just starting to label the booster pass retros with its console counterpart then shouldn't we be doing this with all of the other retros? I know the answer would be no because no-one would want that, but it just seems to be a bit strange that we'd just start this now.
Yes and no.
For something like MKLeaderboards, it would make sense to be consistent. Since a lot of people come to sites from MKLeaderboards from outside the community, it's also easier to understand.
For talking in chat, people are still going to call the tracks what they want, which very well may be what they are used to.
But what we are used to doesn't always align with including the prefixes, although it often does. If the goal is to be the "easiest" to remember, understand, and type, this is what makes the argument a bit tougher.
The idea of the prefix can be looked at two ways:
- Expected for any track
- Expected only when necessary
I've seen the "new" Mario Circuit referred to as 'mc8', which is an example of clarity, which is interesting here.
The whole idea of prefixes is also interesting because we frequently use for example 'dsbs' when there is only one SBS.
Ultimately, I'm not even sure this matters much at all. Given that we already refer to several tracks in chat differently than their official abbreviations, and we speak in our own vernacular out loud in call, this proves that it's not necessary for official abbreviations as used in computer software to be the same as how we communicate with each other.
Personally, I heavily lean towards including the console code as a prefix in small lettering on MKLeaderboards, since it doesn't really sacrifice considerable visual space (efficiency) and it is very easy for the average person to understand (clarity).
As for human interactions, this doesn't matter as much. It's nice to provide a recommendation, which i still suggest could be any of the following:
- The abbreviation as used in the original game, on its own, but only if there are no conflicts (e.g NH)
- A prefix or suffix of the console code in full, with or without a space (Wii CM, CMwii, etc)
- A condensed prefix or suffix, with or without a space, as suggested by Vike (64CM, CM64, etc)
- For existing tracks, the old abbreviations are fine too.
For something like Toadbot, it's best to accept any of the above options, and be flexible, not dogmatic.
With all these options, I think that will be enough for the community to decide what they prefer out of social habit.
If somehow there is something extremely inconvenient, some other abbreviation will naturally catch on. If it's not too inconvenient, it's probably not an issue.
If the whole scheme as outlined in the above 4 suggestions somehow is so bad, we can revisit, but i personally doubt anyone would find it that bad with the amount of options.
For a computer program or site that displays track names, I think it's up to the developers here, and same with what inputs it can accept. Naturally a developer would want to make it as usable as possible (for example by accepting multiple possible inputs) so this is good imo.
Ultimately, the utility of having a single specific abbreviation is less than I think we take it to be. With the options listed above, I think in some cases there will be no difficulty in understanding each other regardless of the option you choose, and where there is, you can choose a different option. If somehow it is still not clear (which I find hard to see), then we'll find a solution.
Personally I find the Vike's idea of condensed console names as a bit tough to naturally catch onto. From a learning standpoint, I have to first remember which game the original track is from (I actually have it easier since I own all the games up until 8d), then convert it to something shorter, and finally tack on the actual "root" abbreviation.
Optimally we only have to do the last step (root abbreviation) if we can get away with it. After that it's up to the community to do what they feel is easiest.
I do want to ask where it's actually necessary or provides a substantial benefit to all agree on a single abbreviation. I don't see anywhere personally, since it's just about a way to understand each other, so I don't think it's too important to resolve this beyond some recommendations and let people figure it out from there.
And that's as far as we need to go here imo. This is just a situation where there is no specific solution that gets everything right, so allowing flexibility is what I consider the golden mean here.