No I'm not.
I found it pretty entertaining!
Absolutely. In my day job as a web developer there's a lot of details that will either make the user's experience better or worse. It's sometimes a battle against the engineer mentality of "how it is easiest to program" when doing it right, so that the feature is easy for the user, takes more care and effort.
Nah, that's arguing for more sort/filter options. Which would be very welcome too! Gain range, heads vs combos, low power vs high power, USA vs European made, simple vs complex controls...lots of criteria that could be applied.
If you add more sort filter options, you potentially add needless complexity to the device. There is currently nothing in the UI (and presumably underlying engine in terms of meta-data and databasing?) in Axe-Edit and the HW to allow this kind of sorting. That is exactly the kind of feature creep I have to put shields up against every day!
Sorry, man. I didn't mean to (and expected that I had) put words in your mouth. I almost deleted that post (but I'd already garnished some precious "Likes" LOL.)
Except the model naming scheme is not consistent, when e.g all Marshall models don't start with "Brit", Fender models are all over the place, Mesa models are not all "USA" and so on. That's the whole issue! Better naming has been requested a long time ago, going afaik as far back as Axe-Fx 2 at least.If you add more sort filter options, you potentially add needless complexity to the device. There is currently nothing in the UI (and presumably underlying engine in terms of meta-data and databasing?) in Axe-Edit and the HW to allow this kind of sorting. That is exactly the kind of feature creep I have to put shields up against every day!
In real-terms, the Axe FX III doesn't even have a sense of manufacturer. It has user-facing strings for the amp model name, and that is it.
"Okay cool. Add a meta-data system."
Which potentially leads to bloat, slows down amp model and channel loading because all of that information needs to be parsed when a model is instantiated, and breaks all of the gapless switching they've just spent a load of time building. Potentially anyway. Hard to say without knowing how the underlying engine and core allocation works.
I'd much prefer to solve that issue by running some user research and figuring out what people actually want - coz it might be that we're both entirely wrong in this.
But my ultimate point is, you can easily argue against your premise. From the perspective of "Oh shit, we can't use Manufacturer names in our models because we'll be sued into oblivion... okay... pseudo-ize them." ... from that perspective, the model naming scheme is already fairly consistent.
Consistency isn't the issue. Familiarity is.
I certainly have, but I still get e.g Edit vs Enter wrong often enough because those swap function in the layout grid for no particularly good reason. Or similarly have to reorient myself with the various views operating in a different manner, or all the other inconsistencies.
I appreciate both yours and Laxu's points of view here. In general, I'm for keeping things simple wherever possible. On the other hand/ FWIW, tasks like processing metadata filters are trivial in terms of CPU overhead. The bigger issue is designing the presentation layer in such a way that it doesn't become more confusing for the end user, and defeat the purpose.
I'll admit I'm not sufficiently familiar with my FM3 yet. (So not my hill to die on yet.
) But in general, I think the point of consistency is to make familiarity easier to achieve (and retain.)
I knew I heard that somewhere before.....Ha! You stole my "cushy UI" phrase.
