Week 9 - Demo

In week 9 the team had demonstrated the functionality of the game so far to the rest of the class. It was good to be able to receive feedback and advice on some of the aspects of the game. I feel the team had enough of the game implemented to show the basic functionality:

1. Home page: user enters their name
2. Location page: user can hover over continents within a world map image, and this displays which continent the user is currently hovering over
3. Question page: monument is set as Sydney Opera House. Retrieves the first image from Trove and the text is hard-coded information from Wikipedia. The user can enter their answer in the input text field and the game checks if it matches the term ‘Sydney Opera House’. If incorrect it says ‘try again’. If correct it progresses to the Scores page.
4. Scores page: displays ‘Your score: 10’ - this is mostly hard-coded at this point

Some of the feedback the team received, was to expand the game globally, as well as to try retrieving the text through the Wikipedia API. This was a particularly useful suggestion, as we were not sure how to retrieve text from Trove. The issues surrounding retrieving text from Trove were that:

• Many of the results that appear in the search results for articles, books etc are not textual passages themselves, but rather are references to their physical location within a library. It would be impossible to extract text directly from this information.
• Even if we were able to get textual content from the search results, many of them were not completely relevant to the topic and did not provide the kind of information that was needed for each question. For instance, ‘eiffel tower’ did not yield many results containing content that can be accessed online. This search term was then modified to ‘eiffel tower france’ which yielded a first result: “Fears over copycat suicides at Eiffel Tower; France.(News)” - this is obviously not relevant to the topic in the way that is intended.

Before the demonstration, I had worked on getting the pages to link together properly and integrated Trove so that it could retrieve a single image for ‘Sydney Opera House’. The image retrieval is done in the same way as the example website as shown in the week 8 blog post. Issues that arose:

• Images that were being retrieved were not displaying properly. This was solved by just retrieving from nla.gov as the images seem to display fine from this website
• Error appears in the console from accessing an element from a variable that is undefined (in processImages(), troveItem.identifier[0] causes an error):

Uncaught TypeError: Cannot read property '0' of undefined

This was solved by checking if the identifier is undefined first, before accessing any of its elements:

Added a check to fix the ‘Uncaught TypeError’

This week the team also worked on and submitted our progress report. I worked on the Implementation Plan which also served as a breakdown of tasks and responsibilities for the team in the upcoming weeks:

Task	Team member
Question content: Choose and divide world monuments between regions and difficulties	All team members
UI/UX: Aesthetics (layout, colour scheme, styling etc) Navigation bar at the top of each question (home, prev/next and help buttons) Addition of buttons to choose level (easy, medium, hard) on welcome page Incorporation of levels elements (timer, gradual ‘unblur’ of trove image)	Anuki, Anush
Data structures and Database interaction: Set up database to include all chosen monuments, with ‘region’ and ‘difficulty’ attributes Write code to be able to randomly generate and retrieve appropriate monument from database to client side	Felipe, Izzy
Trove API: Write code (API) to use the retrieved monument as a search query and retrieve the image from Trove.	Anuki
Wikipedia API: Write code (API) to use the retrieved monument as a search query and retrieve the text from Wikipedia. Remove the name of the monument from the text	Anush
Dynamically change question: Use AJAX to dynamically change to the next question (modify monument text/image, reset user input etc)	Izzy, Felipe
User Testing: Come up with various personas and scenarios (including fringe scenarios) that work through the flow of interaction Test application with various users and conduct user testing methods (e.g interview, observation etc) to gain feedback on the user experience	Sho

Week 8

Week 8 has been a bit of a quiet week for Team Tribu. In the contact session, we had tried to setup version control for our project, and each team member installed Git and SourceTree on their computers. I have some experience with version control and using git, so also explained the basic concept behind it, how it works and how to set it all up.

Setting up Git and SourceTree

Unfortunately the setting up had taken up most of the contact session, however I felt version control is an important aspect of web development and code collaboration, and it’s worth understanding how to use it in regards to our own project.

The basic html/css templates have been created and uploaded onto the zone. I have also started to look at how Trove can be integrated into the project, and have tried some examples from the UQCloud site of retrieving images. I created a separate project to test a simple website retrieving a single image from Trove. Please note a lot of the code is taken from the source code of the examples given on the UQCloud site for testing purposes:

index.html - outputting an image from Trove

index.html

style.css

main.js

At the moment it seems the team has a good foundation to work upon: with the knowledge of editing and transferring files through FileZilla (or equivalent apps), version control and a clear direction of what the game will look like, it should not be too difficult to get stuck into implementation. The next steps are to continue understanding the Trove API, integrating it into the project and continue implementing the rest of the app - styling, content etc.

Week 7 - Experience with Paper Prototyping

Paper Prototype:

This week in the contact session the team created and demonstrated paper prototypes for Guesstoric. The paper prototype was largely based on the wireframes that were created by Anuki, based on the sitemap sketches from last week’s meeting:

Guesstoric wireframes

The aim of the paper prototype is to demonstrate the basic functionality/interactivity of the game without having it being fully implemented. The basic format consisted of the printed out wireframes, and an ‘input’ field which was made out of a paper keyboard that users can use to formulate the answer. This prototype used only one monument for an example question - the Sydney Opera House:

Example question used

The paper prototype including a paper keyboard

The team had received some feedback upon demonstrating the paper prototype. The main criticism received was that the user did not know what question was being asked, so a further clarification (i.e Question: What is this monument?) needed to be added. Some suggestions included having the letters jumbled and the game become about re-constructing the words, maximum number of skips and deciding on the the monuments (rather than getting Trove to generate a list of monuments from a particular continent). Other suggestions talked about how the UI should be colourful to attract children (this also depends on the target audience, as we may want to be targeting older students rather than young children) and accommodating for multiple ways to answer a question e.g ‘Uluru’ and ‘Ayers Rock’ would both be counted as the correct answer, as would ‘The Sydney Harbour Bridge’ and ‘sydney harbour bridge’ etc.

Feedback was received upon testing with our paper prototype

Next steps:

The feedback received has given the team a lot to work with, and the coming week will be about continuing to implement features of the game as well as coming up with 10 monuments each to use for the questions. Unfortunately the Trove implementation is behind schedule, and it looks more and more difficult to be able to extract appropriately formatted and relevant text from Trove, although extracting images should not be as big of an issue. Here is an example (taken from Facebook) of team communication and delegating tasks for the week ahead:

“Hey guys, here's a list of things we should focus on this week. Basically we want an outline of the game up on the zone with 1 question and 1 image to start off with. I'm happy to do the html/css template. Just comment with which part you're happy to work on - there are 5 parts so 1 for each person, I've tried to make them as equal as possible in terms of workload but they can overlap if you feel you can do more/is too much:

• (Izzy) HTML/CSS template for all the pages, make sure it all links to each other, some styling
• Content for Welcome, name and location pages. Content for question page (input box, output boxes etc, look at mockup/wireframe).
• Instructions overlay - display description of what each element does, can be done once question page and nav bar is done. Maybe it appears in a separate div on top
• Question page - come up with 1 monument and get and display first image from Trove results
• Final score - content (name, score etc), navigation bar for question, maybe start thinking about scoring system and how to store the player’s score after each question”

Week 6

The team has made some progress this week in beginning to implement Guesstoric. In the contact session, the team discussed possible data structures and flows that may be involved in Guesstoric.

Data and Data Flow:

In designing a game like Guesstoric, it is important to understand the kind of data it deals with, how it is being stored and how it will be retrieved. The basic concept will be to retrieve data (from Trove), display the data on the screen, retrieve input data from the user and then analyse this information in order to display the appropriate feedback (“correct answer” or “try again” etc) to the user. The game will contain various data structures, brainstormed ideas for this can be seen below:

Player

-name

-score

Question

-level

-continent

-number

-correct answer (monument)

-keywords

A flowchart of data has also been drafted in the contact session. It was good to be able to stand around the whiteboard and discuss interactively as a group where the data flows within the game. A sketch of this can be seen in the following picture, drawn by Felipe and collaborated on by the whole team:

Flowchart of data sketch

The team also had a meeting on the Friday - in attendance were Felipe, Anuki and myself. We had discussed the sitemap for the game, and started to formulate wireframes that can be used towards the paper prototype. We went from screen to screen, discussing the necessary UI elements for each one and debating whether some elements should be changed/modified. For instance, it was decided through sketching the sitemap that the welcome page and the ‘enter name’ page should be combined, since we thought it was unnecessary and involved too many clicks if they were split into two pages. The sketches of the sitemap can be seen below:

(first) Sitemap sketch: Question & Score pages 

(second) Sitemap sketch: Welcome, Enter-name and Location pages

The visual elements and styling was also discussed this week, which was delegated to Anuki who also conversed with the rest of the team in making design decisions. The colour schemes and possible logos that were suggested are as follows:

Colour scheme with majority of team votes

Potential logo designed by Anuki

Potential logo designed by me

We also discussed the levels of difficulty for the game, with suggestions including having multiple choice for the easier levels, and using a timer for the more advanced levels.

Overall it seems the team is making good headway in implementing the app, however I feel getting information from Trove may be one of the most challenging aspects of the project, and so we should aim to start working on this as soon as possible. Leaving the Trove implementation to later in the project may become problematic. In the coming weeks we should aim to start playing around with Trove and how it can be integrated into the project, and start building a basic html/css template.