Week 12

After last week’s demonstration, we had received a lot of feedback to work with in refining the final product. In particular, I worked on creating an output element that would display clues indicating characters which were entered correctly and those which were entered incorrectly. Before implementing this feature, there was a toss up between two different approaches to displaying the clues: either having individual boxes for each character and wrong characters would be highlighted, or have the correctly entered characters displayed in an output field, with the incorrect characters represented as underscores (_). For instance, if the user typed in ‘Sydney Oprah House’ the output would display ‘Sydney Op___ House’. These options were sketched:

Clues Option 1: individual character boxes

Clues option 2: correct characters displayed (see option next to (2))

The initial idea for displaying clues, was to add another letter from beginning to end (left to right) each time the answer was guessed incorrectly. It was brought to our attention however through some feedback that this might be frustrating for the user if the incorrect letter was one of the right-most letters e.g in order to correct ‘Sydney Opera Housp’ the user would need to make 17 attempts.

Attempting Option 1:

So in attempting to recreate the first option, I first looked at how to add individual text boxes for each character. This was done by adding a new input field for each character and setting its ‘maxlength’ attribute to 1. Once these were arranged side by side, I noticed that I had to move the cursor manually to the next box. This would be time-consuming for the user so the practical solution would be to auto-focus to the next box as soon as the previous box has been filled. There were two main issues with this option. First, although you could type forwards without having to focus on the next box, in order to backspace you had to manually focus to the previous box. The second issue was that it was difficult to dynamically add a different number of input elements for each question. The second option seemed more flexible to be able to adapt to different questions and word lengths.

Attempting Option 2:

There were a number of steps involved in implementing the second option. A preview of the final working feature can be seen below:

Working clue feature

Steps:

1. Each monument name is represented by groups of underscores, indicating number of words and letters. This also takes out the ambiguity of correct monument names so there is no need to check for different keywords - only 1 answer is correct.

• This is retrieved from the data.JSON file. For each monument question object, they have a ‘words’ and ‘bwords’ property. The ‘words’ property contains an array of the words in the correct answer, and is what will be compared against the user’s input. It is in capital letters, to take out any upper/lower case issues. E.g [“SYDNEY”, “OPERA”, “HOUSE”]. The ‘bwords’ property contains the underscores that represent the number of characters/words, and will be modified on the screen to provide the user with feedback on their given answer e.g for Sydney Opera House: [“______”, “_____”, “_____”]

2. What is displayed on the screen is the ‘bwords’ property. As the user enters input and checks their answer, the function ‘check()’ in the QuestionController does a nested loop: through each word, then through each character in the word - comparing each answer character with the input characters and modifying the ‘bwords’ array accordingly. If an input character matches the corresponding answer character, this corresponding character in the ‘bwords’ array is modified to show this correct character.

In order for this function to work, the user must enter the correct number of words. The answer is not case-sensitive, as it converts it to uppercase before comparing to the correct answer. A simplified algorithm can be seen below (excluding scoring system):

Check function algorithm for displaying clues

3. In terms of the score, each question is made up of a possible 20 points. Each time the user enters a wrong answer, 1 point is deducted from their possible score for that question. Since there are 5 questions for each round, this gives the user a total possible points of 100. For example, if the user gets the first question right in 2 attempts, the second question right in 3 attempts, and the rest were guessed correctly in 1 attempt, then the final score would be 19 + 18 + 20 + 20 + 20 = 97.

It was also decided to move the images to the left hand side, to give them more space and create more balance in the layout.

At the meeting on Friday, we ran through the changes to be made before the trade show and discussed who will work on the pitch and poster and what to include in them. A summary of the task delegation in terms of the technical aspects for the following week can be seen below:

• (Anuki) UI (styling)
• Colours, fonts, div styles, buttons, spacing/layout etc
• (Anush) JSON file
• Get the data.json file from google drive, take out qNum and searchTerm (since they’re not needed anymore) and add words and bwords (blank words) like in Oceania (bwords contain an underscore (_) for every character). The words and bwords properties are used for checking the user’s answer and displaying the correct characters.
• (Anush) Implement instruction page
• This will be a new page that will appear between the location and question page. Basically it explains the instructions of the game and how to play, then a button to go to the next page. It shouldn’t be too long in text, and use some visuals to better illustrate some of the instructions. I’ll add a html file in the partials folder called ‘instructions.html’ and this needs to be filled out with text + images.
• (Felipe) Wiki API
• Getting info from wiki
• Removing the answer from the info
• (Izzy) Implementation of levels
• Beginner:  
• Advanced: timed, no text
• (Izzy) Randomisation
• Each question displays a random monument within the chosen destination (i.e not in order of the array)
• Images being pulled are random (i.e. not the first 4 in the results)
• (Izzy) Multiple images
• Pull more than 1 (4) image and display it from trove

I feel there is a lot to do before the trade show, and it is important to ensure we are not overloading ourselves. The focus should be on implementing the core features well rather than implementing a lot of features poorly. The features with less priority are levels, multiple images and the instruction page. At the moment we are experiencing issues with the Wiki API, but will continue to look into it in the coming days.