Responsive Design: don't block the workflow

I’m currently designing the interface and testing the workflow for the whole iPad/iPhone application I’m making and everything is well when everything works. However, in the current setup that I have the Insteon nodes don’t get messages from time to time; with power line signaling there is always something that can go wrong and this is why I prefer dedicated wiring but I had no choice. What happens when a message is lost is quite irritating; the GUI just sits there util the server hits a timeout. This really breaks the flow of the user. So let’s look at why this happens.

The GUI #1 puts a message on the message bus to “Turn On Kitchen Lights” (or {“action”: “set_level”, “level”: 255, “device”: “Kitchen Lights”} for the technical guys). The Bridge app reacts on this message by transforming it to an insteon message and passes it over to the PLM. Meanwhile the GUI waits for the event “The Kitchen Lights changed level to 255”. If everything goes well we’ll get that even in no time (under a second usually) and the user can continue, this is not the condition we’re looking for. What is very bad is how the whole system reacts under abnormal conditions.

First what happens here ? Simple, the GUI is coupled with the bridge application and so when one fails the other does too; they might as well be a single monolithic application. From a responsibility point of view the GUI should only ask something to turn on the kitchen lights and be done with it; it doesn’t care whether the lights turn on now or in a few seconds; they just should. This is where a bus architecture shines; the GUI can just put a message and move on. The bridge must accomplish it’s job. Problem solved !

The only problem is the user feedback. Remember I said I had an event broadcast when a change in level occurred, well the bridge app will also send one when it was unable to send a message (it retires it self a few times [100ish]). The solution I am currently implementing is a push notification system that would inform the user an action has not taken place in a reasonable delay; this will appear on all the GUIs. I’ll let you know how it turns out !

2 thoughts on “Responsive Design: don't block the workflow

  1. I think prevalidation can come from the status of your queue. You can evaluate if the queue is full, how many message there is and evaluate how long it will take, then just show “The lights will come on in x time”. It’s the optimistic approach, depends how dependable is your bridge / serial communication.

  2. You could add a “state sync” push queue, it would notify all the gui of the current state, so if gui #2 sets the state to off, the gui #1 would get notify.

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.