- How much horizontal and vertical?
Our medium fidelity prototype will be moderately vertical, with some horizontal aspects. Our prototype will include the ability to browse the news feed and post news stories. We will only have a select few stories that the user will be able to view, and the user will not be able to get out of the boundaries of the story posting workflow. Also, each news story will be either marked as trusted, or not trusted (depending on the news source) this aspect will also be horizontal since it exposes the feature of the app that tells the user whether a particular news source is trusted or not. We will have a horizontal upvote, downvote, and a report button on the bottom of each news story because these buttons won’t be functional. Finally, we will have several tabs at the bottom of the screen, such as “Newsfeed”, “Browse”, and “Share”, which will hint at the other pockets of the application.
- What (simulated) functionality must it contain? What can be faked? How specifically, from a technical standpoint, do you plan on doing the faking? The goal should be that the subjects are as unaware as possible that the system is not fully implemented.
The simulated functionality that our prototype must contain is a necessary and sufficient set of features for reaching our experimental goals. One of our goals is concerned with the ability of the users to share news stories within a consistently short amount of time. This question can be answered by exposing the users to the sharing functionality in our prototype, and comparing the outcomes to the user sharing a story on Reddit. Since we are letting users to actually make posts we don’t have to fake this functionality. However, for our second goal regarding the satisfaction of users with the overall experience we must take a more nuanced approach because satisfaction is usually measured by the overall feel of our application, and thus it is dependent on the app offering seamless functionality. Since we will have limited functionality in our prototype, we will be faking other aspects of our prototype by having dummy buttons (I.e. upvote,downvote, report buttons) and other fillers like whether or not a news source for a particular story is trusted. The faking of these aspects is relatively easy to implement in our application because our prototyping tools allow us to put in dummy buttons and other fillers that look real but aren’t functional.
Subjects will most likely be unaware of the faked functionality of our prototype initially, however they will become of it as soon as they try it and see that no results ensue. The task posed to the users will not include engaging with the faked aspects of our prototype. However, the purpose of including the faked features is to increase perceived user satisfaction by making the prototype visually appealing so it looks more like a realistic application.
- How important is appearance?
The appearance of our prototype is quite important because one of our experimental goals relies on user satisfaction, and appearance usually plays a big part in a user satisfaction.
- If your interface includes physical (non-graphical) elements, is it useful and/or feasible to augment your functional prototype with form mockups?
Our interface will not include physical elements.
- Finally, decide which prototyping tools to use. Most likely you will want to use one of the tools available in X360 (this includes all software available on the general CS ugrad lab machines as well software only available in X360: https://www.cs.ubc.ca/ourdepartment/facilities/hci-learning-studio/resources). Use a combination of your group’s skills / comfort level, and the requirements for the prototype to make this choice. IF YOU ARE EXPECTING TO USE A LANGUAGE or TOOL NOT INSTALLED ON x360 COMPUTERS and THAT IS NOT OTHERWISE EASILY AVAILABLE, CONTACT COURSE STAFF FIRST.
We will be using Atomic.