Method For Generating High Fidelity Software Prototypes Directly >From A Physical Low Fidelity Prototype
Original Publication Date: 2005-Dec-09
Included in the Prior Art Database: 2005-Dec-09
Low fidelity software prototyping such as paper and pencil has many advantages, including low financial cost and low time investment, making design changes in the early stages quite easy. When a design becomes somewhat solidified in a low fidelity form it would be beneficial to translate that into a higher fidelity prototype will minimal effort in order to more quickly move to more advanced stages of design and user testing. The current invention proposes a method for bridging this gap between low fidelity and high fidelity prototypes. It enables designers to render a higher fidelity software prototype directly from a physical, low fidelity prototype that they have created. The low fidelity prototypes would be created using physical representations of software controls or groups of controls. These physical control representations would be placed on some medium that would serve as the container for the control. Containers could themselves be a physical representation of a control or control group such as a portlet, property notebook, or wizard.
Method For Generating High Fidelity Software Prototypes Directly From A Physical Low Fidelity Prototype
The low fidelity prototypes for the current invention would be created using physical representations of software controls or groups of controls (see Figure 1). These physical control representations would be placed on a physical medium that would serve as the container for the control. Containers could themselves be a physical representation of a control or control group such as a portlet, property notebook, or wizard. So, a given item could both serve as a control and a container for other controls.
Figure 1. Physical representation of an OK button.
A container would have an overlay on top of it, perhaps similar to a plastic transparency (see Figures 2 &
3) or computer touch screen technology. Like computer touch screens, the overlay would have a grid embedded in it, perhaps not even visible, and each square of the grid would represent a pixel. As mentioned, a control that serves as a container can also be treated as a control to be placed within another container, such as placing controls within a portlet and placing the portlet on an overall web page. Controls would need to have an overlay on the back of them, and containers would need to have an overlay on the front with an embedded grid to identify locations of controls placed on it. So the container-control designation for a given physical item is somewhat arbitrary.
Figure 2. Container representing a portlet
Figure 3. Implied grid on a portlet container
Controls placed within a container will intersect a specific grid location (x-y coordinates) and be recognized as being positioned at that location (see Figure 4). The back of each control will have a plastic
overlay on it. Such an overlay would need some sort of circuit or something to store both its numeric ID and also have some metal contact at the top left corner so its container could detect that metal contact and thus discern the control location. The backs of all controls on a container would make contact with the grid of their container (Figure 5).
By embedding all necessary functioning in transparent overlays rather than in the physical object representing the control, designers are more free to use any medium they wish to create the low fidelity prototype, such as cardboard or foam board, with hand drawn or printed control faces.
Figure 4. OK and Cancel buttons on the implied grid.
Figure 5. The top left corner of each control would be recognized as intersecting a specific location in the grid.
Control type recognition by a software rendering...