You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When I add a new sensor and hit the save button right next to the input fields, I expect the sensor to get an ID and to be saved.
Actual Behavior
After hitting the save button right next to the input fields, additionally, I need to hit the save-symbol in the upper right corner of the page to save the sensor and generate an ID. Otherwise there is no ID displayed and the sensor is not saved.
What are the advantages of "allowing to add/delete multiple sensors at once"? The advantage is that there are less requests to the API if I guess right?
-> Since I guess it doesn't happen that often that users add/delete sensors (especially several sensors at once), maybe it would be more straightforward to directly save changes. (And therefore risking that there is another request if a typo should be recognized instantly after clicking the save button)
Otherwise additionally to making the presence of unsaved changes more present, the first "save" button should be renamed something like "add" to avoid confusion. Maybe the button with the save-symbol should have an additional text "save" as all other buttons on the sensor page have additional texts as well.
I would definitively go with the unsaved changes solution.
What are the advantages of "allowing to add/delete multiple sensors at once"? The advantage is that there are less requests to the API if I guess right?
It is one advantage.
Since I guess it doesn't happen that often that users add/delete sensors (especially several sensors at once), maybe it would be more straightforward to directly save changes. (And therefore risking that there is another request if a typo should be recognized instantly after clicking the save button)
It happens quite often that users are changing there sensor setup. I would suggest not to change the behavior. Think about the side effects: users clicks the delete button and the sensor include all measurements are gone. See the first save more as a stage (compared to git) and the second save as the commit.
Otherwise additionally to making the presence of unsaved changes more present, the first "save" button should be renamed something like "add" to avoid confusion. Maybe the button with the save-symbol should have an additional text "save" as all other buttons on the sensor page have additional texts as well.
If your have better suggestions for the captions just open a pull request inside the opensensemap-i18n repository first and a second one here.
A hybrid approach could be to let users add or edit sensors directly but require a second confirmation when deleting sensors.
One thing to keep in mind is that changing the sensors array of a box document in the database triggers some side effects (like deleting the measurements, updating the model of the box, ...) which initially led to the process we have right now on the page.
Activity
ubergesundheit commentedon Apr 1, 2019
The process is designed to allow adding/deleting multiple sensors at once. It also allows to correct typing errors before the final save.
I guess it would be possible to make it more clear when unsaved changes are present.
mpfeil commentedon Apr 1, 2019
Maybe we can add a
Unsaved changeslabel next to the save button in the upper right corner.bkari02 commentedon Apr 1, 2019
What are the advantages of "allowing to add/delete multiple sensors at once"? The advantage is that there are less requests to the API if I guess right?
-> Since I guess it doesn't happen that often that users add/delete sensors (especially several sensors at once), maybe it would be more straightforward to directly save changes. (And therefore risking that there is another request if a typo should be recognized instantly after clicking the save button)
Otherwise additionally to making the presence of unsaved changes more present, the first "save" button should be renamed something like "add" to avoid confusion. Maybe the button with the save-symbol should have an additional text "save" as all other buttons on the sensor page have additional texts as well.
mpfeil commentedon Apr 1, 2019
I would definitively go with the

unsaved changessolution.It is one advantage.
It happens quite often that users are changing there sensor setup. I would suggest not to change the behavior. Think about the side effects: users clicks the delete button and the sensor include all measurements are gone. See the first
savemore as a stage (compared to git) and the secondsaveas the commit.If your have better suggestions for the captions just open a pull request inside the
opensensemap-i18nrepository first and a second one here.ubergesundheit commentedon Apr 2, 2019
A hybrid approach could be to let users add or edit sensors directly but require a second confirmation when deleting sensors.
One thing to keep in mind is that changing the
sensorsarray of a box document in the database triggers some side effects (like deleting the measurements, updating the model of the box, ...) which initially led to the process we have right now on the page.