MarshWorks

Manipulative Interactivity is a method of User Interface Design that is characterized by:
• Non-modal interactions (described below)
• Dynamicism
• Presenting data in a graphical or image-based form as the primary interaction method
• Use of sliders and handles to change the on-screen view without requiring keyboard control
• Ideal for touchscreen or tablet-based input devices
• Assumes that numerical data is not the "native format" for human understanding
 
Manipulative Interactivity (MI) focuses on three interaction patterns:
• Data entry - the ability to get data into the system
• Search - the effort spent in finding the data you are interested in
• View - the ability to absorb the data in the format you want
 
So much computer/human interaction is around navigation/search and data entry, that improving the context of these two areas alone will increase user satisfaction, decrease time spent, and result in more accurate data. View is the more complex and difficult of the three patterns to implement, and I’ll take that up in a future post.
 
Data Entry and Save
In a simple form, MI asks that every data input field have knowledge of valid values, and an immediate, non-modal interaction model that communicates violation of these values.

Modality is evil – sometimes necessary, but always evil. A modal dialog is one that prevents a user for do anything until it is addressed. And it always breaks a user's flow and thought process. The worst example: the would-you-like-to-replace dialog. I want to replace 98.6% of the time, but the dialog presents itself every time! However, the programmer’s law is equally valid: never destroy the user’s data unless given explicit permission. So, the solution? Always save a backup file, or two or ten, and provide an easy interface to go back, in order to handle that other 1.4% of the time. Currently, I have to train myself to name files with version numbers, and many other in-human processes, to achieve what an auto-backup system would make seamless. Just let me get on with my work.

I'll discuss data input fields in another post, because there are just so many better ways to represent data on-screen than the way we've been doing it!

Search
MI treats data navigation from multiple levels. For example, human interaction for navigation includes the "known path", the "typical path", the "known but rarely used path" and the "unknown path". For a road mapping program, this means that the "known path", requires very little detail: the user can represent the goal of driving to church in very little detail and this sparse detail is what the user needs and expects. The "typical path", also requires little detail, but perhaps has extra detail around the end point, such as extra information about possible parking places. The "known but rarely used path" is for an acquaintance's house that the driver has been to before, but it was about a year ago, and the major turns and certain reminders are needed. Perhaps the distances between each turn become superfluous data. The "unknown path" requires as much detail as possible, whether a turn is the first left or the second left, how many blocks to go and look for what physical landmark, etc.
 
All computer interactions should represented in the same way as this example. If you communicated to your "smart car" that you wanted to go to church, you would be frustrated by an interaction model that requires you to look at and interact with the level of detail in the "unknown path." Instead, the interaction should be restricted to the "variables", such as whether you need to get there early to speak with the church clerk before the service. The "knowns" should be minimized, but not eliminated, from view.
 
Interacting with large complex data models has the same problems. A user shouldn't have to search through records for every customer with a name of "Smith", if the system already knows that "Jane Smith" had an appointment today. Nor should it make it impossible to get to the other Smiths, but it should attempt to reduce the required interaction. Or, if the mapping program has knowledge of both Washington, Utah, and Washington, DC, but the user lives in Washington, DC, then the system can assume that "Washington" means DC 99.999% of the time, and the little town in Utah is almost completely ignored.

View
The most complicated, and potentially most important concept, will need to wait for a future post.