Web elements are beginning to flex as they change position and size. What are their stretching rules? Here is a basic sketch beginning to explore the ideas behind giving interaction designers the ability to control how elements affect other elements around them. Be it stretching, squeezing or pushing. Concept B, begins to explore the idea of gluing where a relationship is set between two sides of any element.
In the traditional sense, form elements are building blocks for web based interactions. FluidIA will need to support the ability to draw up such form elements as radio buttons, input boxes, textareas, checkboxes, and selectors. Here are a number of ideas for how it could work.
During the last evaluation cycle, users were having trouble to understand that elements or objects are drawn in a nested fashion within objects. In other words, while drawing, parent-child relationships are developed. To help users understand this behaviour, the following cue sketches have been developed.
Here are the latest detailed layouts going into the second iteration.
The footer has been redesigned which now contains three divided sections for ideas, states and edit modes with larger font sizing. These three have been separated out in order to ensure a higher sense of awareness about these important areas. The footer also contains a bit more larger checkboxes, which will also contain subtle onmouseover states to strengthen the perception of their clickability.
An important new state has been designed for the first few seconds of a selected element. The idea is to display an arrow overlaying a newly selected element. This arrow is to emphasize to the user about the location where the next item will be drawn inside. This is an attempt at making nesting more understandable.
An “updated instances” controller is also being proposed in order to provide stronger feedback about the elements which are affected after each change on a master object. The instances inside this controller would become visible after a master object change containing multiple instances. This way users could quickly navigate through numerous updated instances and ensure that the changes are acceptable.
States and ideas controllers have also been redesigned. The “HOLD Z and X” hints have been made more visible in the footer. The state controller creates new states on the x axis, whereas the ideas controller creates new ideas on the y axis. These two axises have been made different in order to provide more subtle cues to users relying on these two similar yet different menus.
Keypress hints (CTRL+V in the bottom left), as well as onmouseover states for the toolbar are also being suggested. The text tool and form tool icons have been designed as well.
Any feedback is more than welcome. Feel free to post comments, send me alternative sketches, or if you’re really serious about jumping into detailed design, I could share the Fireworks file. Do let me know. Cheers, Jakub.
[nggallery id=16]
Controlling the layer order of elements in terms of how they should appear stacked on top of each other will be a required feature. Here is a sketch suggesting a more contextual behaviour which uses the workspace combined with an overlay menu to set the element order. In sketch B, only elements which are relevant (overlapping on top or below the selected item) would appear in the on demand layer menu.
Creation and specification of events or interactivity could be expressed in two ways – high and low fidelity events. More detailed events could be expressed as in the previously added sketch. However, if the designer wishes to document or record events very quickly and roughly, perhaps that could be done using textual descriptions.
It’s looking like fluidIA is becoming reliant on keypressing and keyholding. This is in order to speed up the interaction of prototype creation. Keypressing however comes with the burden of having a higher learning curve. In order to decrease this learning curve, here are some very quick and rough ideas on how to make keypressing combined with mouse interactions a little bit easier.
One thing which is great about paper sketching is that with each sheet of paper the designer can feel and control whether a new idea is part of the bigger prototype or perhaps just a free and stand alone sketch. This suggests that during sketching, designers feel a need to not only control the fidelity of the prototype but also the scope. Here is a sketch supporting the sketching of separate or related interface ideas.
A design tool should not force a level of fidelity or detail onto the designer. Instead the designer should be able to choose at which fidelity to work at – just as is visible when using paper sketching. More so, at times a designer may represent a prototype element in a rough way, while in the future the same element may be revisited and be revised with more detail. Here is a sketch to support just that.
A big part of doing interactive prototypes is the setting of events, triggers, conditions and transitions between various elements, pages and states. Here is a sketch suggesting a very rough onkeypress interaction for calling up an event manager. This overlaying menu would be consistent with the behaviour of the state manager.
