Suggestion: Better preset management tools

KaptanJackSparrow

Active Member
Issue: When making an experiment with ISO's its not uncommon to end up with 100's of presets at various levels of completion.
it would be nice to have some better tools to deal with this built into Ntlite.

1) A compare function, that does a side by side comparison and highlights the differences between two or more of presets. similarly to how many websites have product comparison pages.

2)A Merge Function. it would be nice to be able to merge similar preset files inside NT lite. espescially given how when your experimenting it makes a new preset with every run even if you only make minor changes.

3) Auto incrementing name function. having more control over naming and being able to specify a project I.e Boss's Computer and have Ntlite auto name the subsequent presets with an incrementing version number. Version 00- similarly to how things like the Antrenamer has sequential naming. so in the end you would end up with
Boss's computer V01
Boss's computer V02
...etc
Yes I am aware that the presets are just text files and that there a probably external tools to text by text comparison however it's a hassle and no external tool is ever going to know what those text values mean better than NTlite itself.

This shouldn't be that difficult to implement and it would be a very nice house keeping update that would make the program a lot more friendly to use.
 
1) A compare function, that does a side by side comparison and highlights the differences between two or more of presets. similarly to how many websites have product comparison pages.
This gets tricky since NTLite can read presets from old versions of NTLite, and the XML looks radically different. You would have to import, then re-save under the current XML format.

2)A Merge Function. it would be nice to be able to merge similar preset files inside NT lite. espescially given how when your experimenting it makes a new preset with every run even if you only make minor changes.
You do this by opening a preset, then right-menu on another preset Load -> Overwrite or Load -> Append.
No, it's not intuitive this feature's been there forever.
 
This gets tricky since NTLite can read presets from old versions of NTLite, and the XML looks radically different. You would have to import, then re-save under the current XML format.

NTlite is still always going to be a hell of a lot more knowledgeable on what the values of the XML presets mean than Me and my text editor are going to be. If the values of the Xml are different between versions that's even more reason to have NTlite handle it as long as NTlite is able to read them it can post the configuration differences side by side in a human readable format. I'm not thinking of side by side Xml I'm thinking more of a Feature comparison page like you would find when comparing motherboard, or CPU's Even Tv's where there are rows listing features and 2 or more Columns stating which features or values each preset has. if implemented with a Merge value function you'd be able to very easily compare and merge between different presets. it would certainly be helpful in trying to figure out why Version 5 of an ISO worked and version 6 or 7 did not especially if different version of NTlite were involved in the ISO manufacturing process which is quite likely to be the case.

You do this by opening a preset, then right-menu on another preset Load -> Overwrite or Load -> Append.
No, it's not intuitive this feature's been there forever.
Thank you I'll take a look at this feature. If the feature isn't naturally initiative perhaps making it more so is a suggestion in and of itself.
 
An interesting case is when you import a preset targeting a specific Windows release, onto a different release. NTLite tries to carry over as much as possible, but discards anything that doesn't match. For example, I want to use a W10 baseline on W11 -- or apply Pro to Home. There's no audit trail that lists which items are inapplicable, and silently dropped.

You're already lost data there, before it gets to an apples-to-apples preset comparison.

NTLite could make an intro tour to highlight different UI elements, even if it can't explain in detail. Or cycle thru a new "did you know?" tool tip every time you start a new session, until it runs out of tips.
 
An interesting case is when you import a preset targeting a specific Windows release, onto a different release. NTLite tries to carry over as much as possible, but discards anything that doesn't match. For example, I want to use a W10 baseline on W11 -- or apply Pro to Home. There's no audit trail that lists which items are inapplicable, and silently dropped.

You're already lost data there, before it gets to an apples-to-apples preset comparison.

NTLite could make an intro tour to highlight different UI elements, even if it can't explain in detail. Or cycle thru a new "did you know?" tool tip every time you start a new session, until it runs out of tips.
True about losing data if you try to apply say a windows 7 preset to a windows 10 build I can definitely see that being a thing. I'll circle back to that later.

I was more thinking of a preset to preset comparison tool built in. Trying to make the apples to apples comparison of the presets themselves I think this would be a massive help to trying to troubleshoot problems especially when a user is trying to figure out why one version works and another doesn't if the two versions were made at different times which is likely the case the NTlite Xml will likely be different making a line by line comparison difficult at best. having the current version of Ntlite do an intelligent comparison between them would be the best way to go. it already has to know what those values mean if it is able to read presets made by older versions.

In terms of issues from applying a windows 7 preset to a windows 10 OS that can be handled simply enough by tagging the preset (windows 7, windows 8 windows whatever...etc) and providing a warning message detailing any conflicts/inapplicable settings between that version of windows and the preset. even in the odd case that the preset is so old that NTlite can't parse it, it should still throw and error or compare what it can parse.

Again as Ntlite has better inside knowledge of what's actually going on it's always going to be in a better position to handle these kind of conflicts.

I think this is the right way of handling it and it would make the program much better for both new users and experienced users who made a working preset 6+ months ago and are now trying to figure out why the new slightly different one they just made isn't working.
 
Back
Top