I'm porting a VR app to non-VR. In VR you can move your head to look around, which you can't in a Windows app of course. This means that I also have to change the controller layout. Users might use both versions of the app or maybe only one of them.
As you can see, there are advantages and disadvantages for both versions and I'm not sure what to do here: Is it better to go with something that's less complex but also less conform with a previous version or something that's more conform but also more complex?
Driving a car in a game and controlling your character usually use the same controls or at least very similar controls but that's different "modes", so is it common to map buttons twice with some kind of additional "mode switch" button while you're still in the same game "mode"?
I think that it depends more on the users' learning cost. Your users have already formed their behavior customs and cognitive of your app's function system.
So for your question :
Is it better to go with something that's less complex but also less conform with a previous version or something that's more conform but also more complex?
I prefer the later one. Because it's easier for users to adapt to a new version. However, the former one is a next-step-goal. I suggest that you can gradually iterate the functions layout in new versions based on every latest old version.
BTW, it will be more visual to give answers if you attach some prototypes :)
Short version: Skip to "Questions to help you decide".
As most things in UX, such a question is very dependant on context and user group.
I think in this case the most important question is how often are the different actions used?
Because in the end this determines how the user's workflow with your app will look like.
Imagine if you choose version 3 with different modes but users have to switch modes constantly. It would drive them crazy. On the other hand, if the switch happens rarely, they'd be glad to have room for more actions. So you should always keep your user's workflow in mind when making design choices.
Danlin Chen already mentioned the cost of learning, this is also supported by this NN Group article:
Don’t Prioritize Efficiency Over Expectations
Summary: Features meant to increase user efficiency by reducing steps can end up hurting users if they do not conform to existing mental models and expectations based on past experiences.
But in the same article they point out that design standards are not intended to stifle creativity:
Standards ensure a consistent vocabulary, but don't limit designers' freedom (and responsibility) in deeper design issues.
(You could also argue that they already have to re-learn the flying control for the new version, might as well let them re-learn something else on the way.)
In the end it is a trade-off between learning cost and possibly easier controls. And you have to decide based on what you know about your users. Because after all, your top priority should be to make their life as easy as possible with your app.
Questions to help you decide:
Ask yourself (or even better, your users!), how often do they need to fly up or down and how often do they need to use the special functions. Would it be annoying for them to have to switch between these modes?
Then pick version 1.
On the other hand, how important is the switching between models for them? Are there a lot of models, so that the user would be very frustrated by having to go through the whole list again if he missed his target?
Pick version 2.
Or you could ask your users and maybe adapt your design even further.
I haven't been able to find a gamepad layout that is both conform with the old one but also easy to learn, while still providing controls for the new features, so I ended up doing this:
Layout 1 (less complex but not as conform) is going to be the default layout, so older users should have an easier time getting used to the new version of my app.
There's also going to be a way to switch to layout 2 (more complex but also more conform to the old layout/gaming standards) in the options (this choice will be saved and restored on startup), which in turn shouldn't be a problem for younger users (/gamers).