In developing our medium fidelity prototype, we divided the functionality of the application into two parts to support the two phases in our experiment: buddy matching and walking.
How much horizontal and vertical coverage?
In terms of horizontal and vertical coverage of the application, we will have a vertical coverage for the selection of SafeBuddy and both horizontal and vertical for the trip. The user will be able to look at all the SafeBuddy profiles and inform the experimenters of their top 3 choices. The graphical user interface (GUI) of the matching section will have clickable relative links that will bring someone from a screen to another, cover flow, and have a realistic look to the envisioned system. However, it will not display other possible features of the application such as creating or cancelling a trip. The map will be both horizontal and vertical, including the map, timer, and the emergency button. The GUI of the real-time trip part will be fully realistic with regards to user interface (UI).
Simulation of Behavioiur
In terms of simulated functionality, we must be able to go through the flow of the system until we select a buddy, and from there, we must be able to pull up an application that will show a realtime map, with an emergency button. In terms of creating profiles, we will be manually simulating social media parsing. We will be manually pairing the participants based the results of the users’ top 3 choices instead of a matching algorithm. The functionality of the realtime part of the application is more fully featured, and will be able to do realtime location tracking based on an android application template, and will have a emergency button to simulate the emergency response design, that will contact one of the experiment staff.
Appearance
In terms of appearance, we will place greater emphasis on modelling how the application will work than on the actual outer design for this prototype. Hence, we will be using template UI elements, as to look like a standard mobile application, whereas a final implementation of the application might use custom UI elements.
Non Graphical Elements
Our interface includes non-graphical elements in the sense that matching algorithms, and geofiltering/fencing must be completed. We plan to get around these by limiting the choices to be made in the interface and by hardcoding some features in the mockup.
Prototyping Tools
We plan to implement our medium fidelity prototype in two parts. The real-time mobile app will be completed with a Google Android Studio map activity template, with an emergency button element. This will allow us to leverage data available during the trip. The matching section will be implemented as a Microsoft Powerpoint presentation with clickable relative links to ensure the flow is followed. In addition, Powerpoint is a platform that allows us to easily add slides like profiles, without having to use code. These choices were made because of the familiarity of our team with these tools, which reduced the length of time it took to create the prototypes.
Demonstration
A link to download the interactive buddy matching prototype is available here.
It is preferable to use Powerpoint 2016. Captions are available on each slide explaining functionality, and in presentation mode, the system is interactive in terms of navigation. Clicking on the appropriate buttons will show appropriate flow and functionality at each screen