Timeline for When to commit user data (a humble request from a systems guy...)
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 27, 2011 at 14:55 | comment | added | Michael Zuschlag | If the system can't provide more feedback than OK and ERROR to the UI, any chance you can get a video of the machine, perhaps through a microscope so the user can track status and progress? I'm envisioning a Set Phasers to Stun (aegeanpublishing.com/phaser1.html) situation developing here. | |
| May 27, 2011 at 14:46 | comment | added | Michael Zuschlag | For the caching approach, I was thinking the Loss Focus event never disables/changes the Start button --only the other controls. If stop also cancels text box data transmission, that's another good reason to have separate buttons. | |
| May 27, 2011 at 14:44 | comment | added | Michael Zuschlag | My physical DVD and CD players have separate pause and play buttons. Virtual media players get away with combined play/pause because they don't have lag. With lag, you can get users repeatedly playing/pausing if they don't notice the label changing, and they won't understand why it isn't working. Could be bad for a medical device. Definitely bad for a fire suppression system like in the story I linked to. | |
| May 26, 2011 at 15:57 | comment | added | Ed Swangren | certain actions only which would still ensure that the data is always committed before a run is begun. Thanks again for the response. | |
| May 26, 2011 at 15:56 | comment | added | Ed Swangren | The system had not yet responded (the client may be used from any PC with an internet connection). That doesn't mean that disabling controls is the only/best way to go about it, so I'll rethink things a bit on that end. The start/stop button is analogous to a play/pause button on a DVD or CD player, so I'm not convinced that it is always a bad idea. The problem with caching the start command is that the click handler does not fire until after the text area loses focus and the data commit has begun. Perhaps I will simply remove the commit on lost focus entirely and do so after | |
| May 26, 2011 at 15:53 | comment | added | Ed Swangren | Thanks for the response, there is some good feedback here. I didn't go into much detail as to what the machine actually does, but most of the commands that a user will send involve motion that must be accurate to .25um. As such, these moves can take some time. We currently do maintain a queue of commands, but if we did not disable the controls we would have to either throw away some commands as sending them would cause a "hardware busy" error. If we waited to send them until the busy state had ended we run the risk of the user clicking around more quickly than they should assuming that | |
| May 26, 2011 at 12:54 | history | answered | Michael Zuschlag | CC BY-SA 3.0 |