Browse Prior Art Database

Method For Generating High Fidelity Software Prototypes Directly >From A Physical Low Fidelity Prototype

IP.com Disclosure Number: IPCOM000132370D
Original Publication Date: 2005-Dec-09
Included in the Prior Art Database: 2005-Dec-09
Document File: 9 page(s) / 593K

Publishing Venue

IBM

Abstract

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.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 53% of the total text.

Page 1 of 9

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.

1

[This page contains 1 picture or other non-text object]

Page 2 of 9

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

2

[This page contains 2 pictures or other non-text objects]

Page 3 of 9

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...