Creating good Javascript GUI interfaces through state and behaviour engineering

|
In web applications there is a lack of formalized GUI components that can be reused quickly. Therefore a lot of times developers need to re-create custom GUI components for them selves. However do the the level of interactivity involved in JS heavy pages this task can end up out of hand when dealing with multiple on page elements.

My solution to this problem is to adopt my software engineering professor's (Geoff Dromey) approach of using behaviours to engineer software. The name for this discipline is behaviour engineering. Behaviour engineering involves mapping requirements into behaviour trees (PDF) that allows the engineer to express functionality as a series of behaviours and states in a system. Using their publicaly available example an oven would allow the user behaviour of Door Open, which would cause the Door state to be Open, which would trigger the states of Power to be Off.

For Passbook's group name managing inteface I used a similar technique to ensure that I have covered all user interactions and system states that can occurr with it to ensure a quality user experience. I started with the basic inteface design of three states, which are: view and edit/create. Edit and create are really derivatives of each other and can be implemented as a single bit of code or two separate components. The GUI states are visible below.

Create

Edit

View

The three GUI states may look simple but due to the need for them to transition into and out of each other and other page elements it can become quite a complex dance of showing and hiding elements. To get my head around all of that I used a three column table that mapped the state, action, and behaviours of each action. I will not reproduce the whole table, but the following are a few examples.

State:View > Action:Edit > Behaviour:View.Title.Hide, Editor.Attach(View.Title)
State:Edit > Action:Save > Behaviour:Editor.Controls.Hide, Editor.Loading.Show, Editor.Form.Submit

The above shows that when the edit icon is clicked in view mode I need to hide the title then attach the editor to that group. The technicalities of how it is implemented is not as important as making sure that you have covered all needed GUI and state transitions. The second line of saving an Edit form is a better demonstration of how we can abstract the complexity of what is involved in updating through edit.

To translate the above action and reactions list into Javascript is pretty simple. The view can be created as an object that associates it self with a page element that encapsulates a group view, or in the way I implemented it in Passbook, to be a group of functions that initializes click events for all views. Edit behaviour is more complicated as it deals with a lot of page elements and off-page behaviour. However each behavioural item can be translated into a function in the Editor object, ie. function hideControls(editor), showLoading(editor). Alternatively you can nest objects for further abstraction, ie. var controls = { hide:function(editor) { ... } };

For me using behaviour engineering on Javascript GUI design was a bit of an experiment as behaviour engineering was intended to work at a higher level of software design to allow a good overview of how requirements translates into object states and functionality. However this experiment has shown that it is also possible to apply the theory at a much lower level to allow the programmer to gain clarity on what functionality must be implemented and what states need to be set with each user action.

The results of this exercise were positive enough for me to want to try it on my password records management feature before implementation. With my limited time per day dedicated to my project without proper design and engineering I would be spending more time re-thinking over the same problem instead of just implementing properly thought out functions.

To conclude, I would encourage other developers to take a look at the behaviour engineering documentation and try it for a sample function in their current projects. If it doesn't work you may have wasted 1 or 2 hours max, but when it works your productivity will increase and stress will decrease.

0 comments:

Post a Comment