Tagged ‘ui_editmode’

Here is a new idea for how the master edit mode could operate based on the results of the last user testing. Basically the idea is to really differentiate the master edit mode from the standard and default edit as instance mode. The master edit mode also could require an explicit action and would highlight everything surrounding the selected object as a blue and transparent overlay. After returning from editing an object as a master back to instance edit mode, the inheritance controllers could grab the user’s attention by highlighting.

FluidIA right now allows to view an element in two ways. First, in instance mode, the selected element can use properties as defined by its inheritance rules (for position, size, content and events). These rules allow a more modular way of assigning properties to the element by letting the user to choose which properties are inherited and which not.

Secondly, an element can also be edited in the master edit mode which absolutely uses the master object’s properties and ignores all instance properties and inheritance. This however is a temporary view as in the final prototype view, the various elements will rely on inheritance settings when being displayed. However, the problem right now is that the selection between master edit mode and instance mode becomes remembered. So if someone leaves an element in master edit mode and returns to the saved file after some time, the master object’s properties are used and not the instance’s inheritance.

Perhaps a better solution would be to boomerang from the master edit mode back to the inheritance mode after 10 seconds of inactivity. This would allow the user to understand that inheritance settings are dominant and the most important. While editing the master in it’s pure form is only temporary.

Here are two sketches outlining the problem and possible solution.