Evaluating the current Prototype

With 4 weeks remaining we were at the stage where, in order to continue in the right direction and make good use of our time, we needed to evaluate where our project currently stands, as a functioning prototype, against the original MoSCoW analysis to look at what features had been fully implemented, as well as to evaluate the effectiveness and quality of the implementation. The Trello board we had been using helped to keep track of who had been working on which feature, but a fully analysis alongside our MoSCoW document would help to ensure features were matched to our intial vision of the final build.



Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.

Sounds to describe phrases must be of high quality and clearly audible for the user, and should not breach any copyright or intellectual property laws

The sounds we have included in this current build are all available under the creative commons licence, some with attribution meaning we need to credit the original authors. They are of high quality and can be clearly heard in the application – future sounds that we still need to add will also be checked to this same degree.

Sounds must make sense in their connection with answers, and relate to corresponding phrases through use of word-sound association as per detailed in examples

The content is in the process of being rewritten after feedback from RedBalloon in order to make better connection between the sounds and the corresponding phrases, however the general logic still remains the same.

Sounds and their connections with answers must elicit relevant information to the magna carta history, and legacy as per the current part of the app, and with appropriateness to the target demographic group

Upon selecting the right answer, the current prototype does change to a new view showing a relevant fact. In the final evaluation of content some of the facts may be rewritten dependent on the feedback from user testing, in order to better suit the demographic.

Sounds must be able to be manually played by the user with the option to repeat if needed

The sounds are played using a prompt on the main view of the app, for each question, and can be repeated by the user as many times as needed.

The app must save progress on closure automatically, requiring no input from the user to do so, and be persistent during total closure of the app, or shutdown of the device

The app automatically saves user data on closure, reloading it when opened.

The app must offer the choice of three different answers to the sound combination, of which one is unequivocally correct and two are incorrect

Each question has 3 different answers available, offering a challenge to the user yet, once the correct answer is selected, it can be understood what makes it correct as opposed to the other two.

The app must include a separate view in which the relevant fact or info is displayed for the correct answer, and be of a legible font, colour, size, and arrangement

The current prototype includes a separate view in which to display the relevant fact for the question, and once completed, will be of a legible and clear aesthetic.

Graphical elements and the design of the app must be adaptable and fit on all proposed devices properly.

Constraints for each view are built in such a way to fit on all proposed devices able to run iOS7 and above. We have been testing on an iPhone 4 and the app displays properly. Graphical elements are in line with the design bible supplied by Haley Sharpe



Represents a high–priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.

The mechanics of the game should be self-explanatory and easy to understand through the use of appropriate design cues, visual hierarchy and consistent graphical elements

The current prototype still requires work on the graphical elements to be completed in the next 4 weeks; however the concept is broadly speaking, easily understood due to design cues such as a “Play” icon for the sound and native iOS elements.

The app should suggest to the user, or prevent the user from, playing sounds during prayer times at the cathedral, taking care not to sound patronising or offensive, perhaps through the use of looking at the system timer and displaying a relevant message

The app currently does not feature this suggestion; however it could be added in the last 4 weeks.

The app should have a clear visual sense of progression narrating the structure of the game

The mascot character has been completed and implemented with a story feature, supporting a solid narration of the game. The progression bar has also been included, showing a sense of progression

The incorrect answers offered should be feasible, and/or believable as correct ones, in order to provide a challenge to the user when selecting a response

The content is being carefully designed for the final release in order to ensure all questions are a challenge, but of reasonable difficulty, for the user. Only some of the questions currently meet this suggestion.

The app should explain how the sounds provided result directly in the correct answer as opposed to the incorrect options through literal description, or potentially synchronised animation with the sound clips in the “correct answer” fact view

The facts being presented currently do draw a link between the sounds used, the answer chosen, and the final fact being presented



Describes a requirement, which is considered desirable but not necessary. This will be included if time and resources permit.

The app could include a mascot character narrating the playthrough if it appeals to the target demographic, which can be explored through user testing prototypes with said demographic or looking at available research

This consideration has been fully realized and implemented in the prototype – a mascot character has been fully designed and given dialogue which has been implemented into the prototype. This will be explored in the final weeks through user testing with relevant parties.

The app could include a view showing instructions explaining the mechanics of the game which would be clearly legible and in line with other graphical elements of the game, providing a succinct yet helpful tutorial on playing the game

The app does include an instructions screen that explains how to show the game, and is visually consistent with the rest of the app.



Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.

The app wont rely on QR codes as previously discussed due to adding a further layer of complexity and possible issues with architecture in the location

The app does not use any QR codes in the final build, ensuring that it is kept as simple as possible.

The app won’t be geolocated in the environment as previously discussed due to possible issues with GPS in the cathedral and a lack of necessity for the current feature set

There is no GPS functionality in the current prototype or planned final build.

The app won’t have a unique or irrelevant visual style in order to remain adaptable to other apps and the design guidelines

The app has its own visual style based on the design bible supplied to us, however is adaptable to other schemes if need be post-release

The app will not be available in a landscape orientation, due to the lack of content that affords this, and the types of usage by the user that might require this

The app does not offer landscape orientation

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s