|
|
|
|
|
by blagie
1510 days ago
|
|
The vast majority of users of music notation are amateurs, and being more friendly to amateurs would mean even more users. The vast majority of decision-makers are experienced users with a vested interest in the status quo. The issue is very similar to why corporate systems have such horrible user interfaces. The people making the decisions in IT aren't the normal users of the system. IT cares about features, integrations, and high-level analytics. Employees care to be able to sanely input their time sheets, file an expense report, or buy a stapler. I'd like a system simple enough to use by all the kids in my local elementary school music class, much more than I care about what happens in the local orchestra. |
|
I'm not sure the claims you and OP are making here are actually in tension. They said:
> the most common users of music notation (experienced musicians)
which is ambiguous, and might mean something like "of all the people that ever do any music-reading at all, the majority are experienced musicians," which would indeed be the opposite of your claim. But it might also be "of all the people that are reading music at any given moment, the majority are experienced musicians," which would be a proxy for "most hours spent reading music are spent by experienced musicians"; this could be true simultaneously with your claim (it stands to reason that experienced or professional musicians spend comparatively more time reading music than do novices or amateurs).
I don't think it's a foregone conclusion that the thing you want to optimize for is maximizing the average quality of experience for all users regardless of how much they use the thing, vs. maximizing the quality of the average hour of use.