Third Interactive Prototype
Final Design Description
Functionality
In short, what you can do with the final prototype of our design is try out the interaction. There is no support for actually creating any sort of output, and a lot of the buttons have faked or static responses. Still, the functionality of this prototype is in its design. Our final changes have been made so that the interface is clear and understandable. And, there is enough feedback that anyone could understand the interactions and the flow that we are trying to present. So, this final prototype is not functional to actually use, but it is plenty functional for seeing the idea of our design.
Interaction Flow
The user is initially presented with the mail merge sidebar. After selecting a data collection or making a new one, the user can choose a document type, then drag fields into the document. This is our primary interaction, and where we feel the heart and focus of any mail merge application should be. For power users, there are conditions and groups available to help make complex field interactions quick, easy, and repeatable. Individual records can be previewed and edited, and then output can then be customized to any extent. Finally, the user can have the computer "Do it!" and create the output, whatever that may be. The highlights of this interaction flow are that other than choosing a data collection and creating output, these steps can be performed in any order, and repeated as many times as desired. The interface is also constant throughout all of these varying tasks, simplyfing the user interaction. The flow of our sidebar is augmented by the layout's top-to-bottom nature, aiding any user who isn't quite sure where to go next. This entire interaction flow is something that we think is better than the current system, and will be intuitive for users of any experience level to grasp.
Unimplemented
Most of the intense, mouse-oriented interactions remain faked in this final version of the prototype. These include the fields, groups, and conditions interactions. Also, no spreadsheets or databases are actually ever opened, as that aspect of the program is faked as well. So, there are many parts of our prototype that appear to have been implemented - and are well enough to perform our scenarios - but where the generic backend is not actually present.
In addition to those, the preview and edit mode remains unimplemented in any way, meaning that this interaction has not even been faked, and therefore, never really been tested. Of course, we questioned our interviewees about this feature, and all of them said they understood its purpose. We just can't be sure if our specific implementation would go over well.
Tools Used
As we originally stated, we planned to use a mixture of PowerPoint, Visual Basic for Applications (VBA), and Flash. However, the Flash aspect of our program never once made it into any prototype, and we in fact ditched the idea shortly into our first interactive prototype. The use of PowerPoint, in hindsight, is actually completely unnecessary. We used it as an interface for VBA and as a way to easily distribute the program, but if we had to do it again, we would forego using PowerPoint and VBA. Instead, we would use a full-scale programming language known for quick and easy development. VisualBasic.net would seem an ideal choice based on these criteria. It would have saved us some headaches if we would have had all the functionality of a full language in the prototype from the beginning. But, we were afraid that using something so technical would slow down development and potentially lead to other unforseen consequences.