Split options dialog into 4 steps

[mhegazy]

We are getting strapped for space in the current installer options window. To give us more room, this change splits the Options Page into 4, each with a specific theme. 1. Install Root, 2. Tools, 3. Windows SDK components, and 4. Android SDK components.

See this video for the new flow after the change:

Changes include:

• Split into 4 pages
• Associated strings and layout changes
• Change label from "Options" to "Customize"
• Added "Back" button to allow for a smother navigation experience

[mhegazy]

CC @compnerd

[compnerd]

Hmm, can we make it a hyperlinked pagination? Something like:

Core

• Build Tools
• CLI Tools
• Debugging Tools
• ...

SDKs

• Windows [link]
• Android [link]

[mhegazy]

Hmm, can we make it a hyperlinked pagination? Something like:

We could. There is a "CommandLink" element, that is basically a hyper link that acts as a button. but i do not think it adds much value to clarity. this flow is not very different from what git for windows does today. a series of questions, and then install page. I think a simple and familiar interface is better than trying to over engineer it

[mhegazy]

for context @compnerd, it looks something like this:

which i do not find it very ascetically appealing

[etcwilde]

Overall LGTM.

Not sure how you want to do this, but it might be good to allow the user to select which platforms they want to install instead of pushing them through that page every time. If we ever added a Linux SDK on Windows, that would be another page on the installer so it might get cumbersome. Otherwise this looks pretty good.

[compnerd]

We could. There is a "CommandLink" element, that is basically a hyper link that acts as a button. but i do not think it adds much value to clarity. this flow is not very different from what git for windows does today. a series of questions, and then install page. I think a simple and familiar interface is better than trying to over engineer it

The difference is that this is not like the git flow. This is explicitly an options dialog that the user needs to navigate to in order to select features. It is not about the defaults. The Git installer has a feature tree.

[mhegazy]

The difference is that this is not like the git flow. This is explicitly an options dialog that the user needs to navigate to in order to select features.

we can make it so. we just need to make the first option page the first page in the installer instead of "Install".

It is not about the defaults. The Git installer has a feature tree.

so this is where it gets complicated. Git is just an msi (a single Package in Wix terms). so the built in Wix UI gives the feature tree for free. we are using a chain of packages (a Bundle), and for these there a handful of UI options we can choose from, and none is a feature tree.

if we want a feature tree there are two options. one option is to use one of the MSIs and mark it with DisplayInternalUI to show the UI within the chainer UI. it gets dicey quickly since now we have to use this feature tree to represent other components.
The other option is to build our own custom chainer. there are a few projects out there that can help with that (e.g. wixsharp)

[barnson]

An alternative if you want a feature tree is to use a BAFunctions DLL to fill the tree control and respond to the notifications to set the properties that control package state.

It would be a shame to introduce a .NET dependency just for the installer.

[compnerd]

Not sure how you want to do this, but it might be good to allow the user to select which platforms they want to install instead of pushing them through that page every time. If we ever added a Linux SDK on Windows, that would be another page on the installer so it might get cumbersome. Otherwise this looks pretty good.

Yes, this was exactly my thought and reasoning.

we can make it so. we just need to make the first option page the first page in the installer instead of "Install".

This would be unfortunate. Something that I've gotten a fair amount of positive feedback was the simplicity of the installer. I am somewhat hesitant to roll back on that. It feels like it should be possible to have a polished experience with the common path being really simple (we should aim to have the majority of users be happy with the default configuration).

@barnson thank you for the suggestion! That definitely sounds interesting and seems worth exploring. Would you happen to know of any examples that you could point to?

[barnson]

https://github.com/wixtoolset/wix/tree/main/src/test/burn/TestData/Manual/BafThmutilTesting has some UI manipulation.