[FR] Branding and swiftDialog Options

[popaprozac]

PLEASE NOTE THAT FEATURE REQUESTS ARE ONLY CONSIDERED AGAINST v.28.0+

Is your feature request related to a problem? Please describe.
There are no configurability options that would help with branding to help users trust the process when deployed via MDM or used in an org. Additionally, the dialogs can be closed while not cancelling the process which could cause users to lose track of the progress.

Describe the solution you'd like
I would like the ability to change the icons used that would allow orgs to add branding.
swiftDialog has newer features such as setting button1text to none which would help keep dialogs in view while the process is running. As a side note here, I was playing with the idea of cancelling the main script if the user cancels the download dialog for example.

Describe alternatives you've considered
I authored a thin layer (internally developed) over erase-install with custom dialogs with branding and used very insecure and credentials alongside silent modes to achieve the desired look and feel.

Additional context
I have a branch I can submit if this sounds like something worthwhile that initially adds options to set icon size, confirmation icon, and a new flag "force" to remove the default "Ok" button from download and upgrading dialogs.

[grahampugh]

Hi, thanks for your request.

I can get behind the customisable icon feature.

Regarding the button, I will need convincing of this since if you use --fs mode you don't get a button. I'm not sure why you would not use full screen mode if you wanted to prevent the user from dismissing the dialog (so that they could carry on working, saving documents etc).

Also I don't like "--force" as it implies that the process is forced (or not). The process continues regardless of whether the dialog is dismissed. If there's a use for this feature at all (see above), it would need to be something like "--enforce-dialogs".

[popaprozac]

Thanks for the feedback! Glad to hear about the icon customization.

Admittedly when I think about this there is context missing. The thin wrapper I used around erase-install was built to be cancellable by default (dialog with a single cancel button up to a certain point in the process) and a "forced" mode that removed buttons and persisted the dialogs to ensure users don't lose track of the progress.

Cancellation is out of scope for this so I completely understand your thoughts. The one remaining rationale for persisting/enforcing dialogs even when not fullscreen is to again ensure users do not dismiss the dialog and think they have cancelled the update. To my knowledge besides tailing the log the end user has no way of checking back up on the progress and they could step away and come back to their machine rebooted applying the update. Having an option when not fullscreen allows users to continue working or backing up any last minute files since the process can take 10-20-30 minutes.

[grahampugh]

Hey, that's what --rebootdelay is for. They then get an up to 5 minute countdown which cannot be dismissed.

[popaprozac]

Yes speaks to the surprise reboot but I still think there is an argument to be made about keeping progress available at any time for the user to see while not completely obstructing their usability of their machine during the download and update process. Don't mean to belabor this point, we find this to be a benefit when we apply it in practice to end users.

[grahampugh]

They don't have to press OK though?

Two people just asked about this in Slack but neither were aware of the rebootdelay option.

I just think if you remove the OK button, either the window is fixed in the Center in which case they can't work anyway, or it's not fixed and they will move it completely off the screen, in which case they may as well have the OK button.

There may be a case for a more explicit message that states that the preparation will continue regardless of whether they press OK. But even that will lead to needing even more code than there is currently, because the message would have to be different depending on whether it's full screen or not (or whether there's an OK button or not).

I'll have to think about it. There's all sorts of things that could be added to increase flexibility, e.g. customisable messages, but they also come at a cost of increased complexity and support. I've got to the point where I think it's already too complex for people to understand half the existing options, based on the number of questions I get about even the basic functionality. I dread to think what it's like supporting things like Super and Setup Your Mac where there's separate configuration files and dependencies. I don't want to go there.

[popaprozac]

Okay, I hear you, and completely agree with the sentiment surrounding complexity even if I think there is value in the proposal. Is the juice worth the squeeze? and I'm happy to concede it might not be worth it. I will remove the --enforce-dialogs from the PR.

Thanks for your time to hash through this.

[grahampugh]

Thanks. Give me a day or three but I should get to it early next week. I'm in the middle of moving house, job and country! There's also a new swiftDialog to test.

[popaprozac]

Sure thing, thank you and good luck!

[grahampugh]

https://github.com/grahampugh/erase-install/releases/tag/v32.0 to test

[popaprozac]

Works great, thanks!