As a rule any system should prevent unwanted data loss. This can be done by warning the user some data is lost through an action, or give the user the opportunity to undo an action that caused the unwanted data loss.
Suggestion for a modal, either in the web app or on the device touch screen:
‘Are you sure you want to overwrite the preset “TX81Z”?’
@urbanspaceman Thanks for the feedback. We will consider such modal dialog.
However, even if you overwrite a preset in your Electra, you still have it in your account. So you should not lose any data. Or am I missing something? Thanks for clarification.
One should have the data in still their account, but I didn’t find it breaking a convention to overwrite on a device without a warning. I was finding that I forgot to change slots on the device, and then I had to go back and load 2 presents (to restore the overwritten one and change slots to add the new one). A warning would prevent that.
@urbanspaceman Yes, you are right and I agree. I just wanted to make sure I am not missing something, when you mentioned data loss. Thanks for the clarification.
I kind of agree generally (though perhaps its should be optional, as I quite like not having to approve )
either way, this needs to be optional on a ‘per preset’ basis…
(i.e. a preset needs to say it allows overwriting)
Ive a project that continually updates ‘its own’ preset due to the dynamic nature of the application.
if the user had to approve this every time - the project would no longer be viable.
My opinion on this is that this should be handled by the application that creates / manages the preset. Electra hardware should not display such modal. It should, however, support an API call to find out what preset is in the active preset slot (and therefore will get overwritten).
Perhaps in the web app the user could set the preset to be ‘memory protected’ and this would trigger the warning about the overwrite.
but this could then be directly in the web app, i.e. it can warn its going to overwrite.
it be better to warn there anyway, no need to have to reach over to the E1 to approve the message, when you are already at the keyboard.
that said… when you are hitting ‘upload’, aren’t you already committing to overwriting a preset?
its not really the same as ‘save’ on a filesytem, since we only have a limited number of preset ‘slots’
I wonder if perhaps this is a solution to ‘the wrong problem’
I think the issue we have here is that when we upload from the web editor, its to the active slot - which unless you look at the E1 you dont know what it is…
(hence you are concerned about accidentially overwrite the ‘wrong’ preset)
so the underlying issue here is … the editor does not show you whats going on the E1.
perhaps rather than just a simple upload button on the editor.
when you upload, it could ask you which preset slot to write too (showing you the name of the current preset loaded into that slot)
(one could see the web ui perhaps later having features to manage these e.g. delete presets, moving them around etc)
Good idea / approach!
I already overwrote presets a couple of times by accident
I fully agree. You know, Tomas and I, we have this iterative/agile mindset, so the first implmentations of the features are always rather minimalistic. I see the point here and just added that to the development todo.