Week 13 - Trade show / Course Reflection

In the final week of the semester, the team demonstrated our project Guesstoric in the trade show. There were aspects of the project that were working however there were also aspects that were not working properly. Overall, unfortunately I would say a lot of the aspects that were not functioning properly had impacted greatly and negatively on the user experience, particularly in the first hour of the trade show. These aspects are outlined below:

What was working:

• The user could enter their name in the welcome page and be displayed in the scores page
• The user could choose a continent which would set up the content for the following questions
• Some continents could display an image from Trove fine e.g Oceania. Users were then encouraged to choose this location while the issues were being resolved
• Checking the input and displaying correctly/incorrectly entered characters
• The scoring system (some of the time)

What wasn’t working:

• Although the user could choose a location, the Trove API calls were not yielding any images for many of the continents
• The Wiki API to extract relevant text
• The plan B which had to be implemented due to the lack of Wiki-extracted text. This was to hard-code the text into the data.JSON file from Wikipedia, and then pull it from the JSON file onto the page. There was a syntax error which was impossible to pinpoint in the data.JSON file and the questions were unable to display any of the text.
• The scoring system would display a score outside of the range e.g 600/100.

What was an interesting and unintentional outcome, was that because the images rarely appeared and there was no text, this had made the game incredibly challenging and some users actually enjoyed trying to answer these ‘impossible’ questions. Although this was not intended, it was interesting and a little humorous to see.

We had also conducted user testing (lead by Sho) during this session and received an array of feedback. It discusses information about the users themselves as well as what frustrated them about the game, what they liked about it, what could be improved etc. These findings can be found here: https://drive.google.com/file/d/0BzY5tywhuJqrdVNKeFdKTkc4Vk0/view?usp=sharing

Reflection on Demo:

Overall I felt the demo (as well as the pitch) had communicated and given users a basic idea of the concept, however there were a lot of issues that arose during the demonstration that unfortunately did not give justice to the true capabilities and features of Guesstoric. A lot of these issues could have been prevented and solved through various methods, however the biggest lesson to take home was that this should have been tested in-situ a lot earlier. The biggest contributing factor to the issues that arose was that a lot of the functionality was quickly integrated into the system all at once without first testing bit by bit if it works the way it should. Instead of implementing a feature and relying on the fact that it should all work, it would have been best to test the feature working in relation to the rest of the system.

By proper testing before the demonstration, this would have prevented the need (and stress) to fix bugs while people wanted to test our product. Another contributing factor to the issues that arose, was that it wasn’t communicated early enough that the Wiki API would not be working, and that a plan B would need to be set in place. In fact this was only found out less than an hour before the demonstration. Earlier communication surrounding this, or even proactively attempting to implement a plan B by the responsible team member themselves would have helped to alleviate this last-minute hurdle.

The individual technical issues faced and proposed solutions are further discussed below:

• Syntax error in JSON file:
• After the demo it was discovered what the syntax error was. Because it contained information that was copied from a Google Doc, the quotation marks in the Google Doc were actually a different ASCII value to the proper quotation marks needed in the code. This would have been solved by using an online syntax checker to pinpoint exactly where the syntax error occurs. This was needed as my current code editor (Brackets) does not show the location of errors in JSON files.
• Trove images not appearing:
• Many of the images were not appearing mainly due to the search term not yielding any results. This was overcome in 3 ways:
1. by slightly modifying the search term e.g ‘Empire state’ yielded more results than ‘Empire state building’
2. by completely changing the monument if absolutely no images for that monument are found
3. by adding more website sources e.g Flickr, nla.gov, etc
• Scoring system not displaying correct score:
• Sometimes the user would get a score over the range of 100. This would suggest the score is not resetting properly at each round, and so this reset was added to the code each time a user enters a new question round. A check for negative score values was also added.

Next Steps:

The next steps for the team is to work towards the final report and make several changes to the final product.

The changes I worked on was getting the images from Trove to appear, pulling multiple images from Trove, randomisation on both the questions and the images that appear to enhance dynamic behaviour and add a loading animation/image. Unfortunately due to time constraints the features of the project that were unable to be completed by the end were levels of difficulty, an instruction page and extracting text from Wikipedia.

Getting the images to appear from Trove involved the 3 approaches as described above. Adding multiple images just meant wrapping the ‘$(outputName).append(image)’ line in the processImages() function in a for loop that looped twice (if more than 1 image was found). It was necessary to check if more than 1 image is found for each question before appending the output with the images in the loadedImages array, so as to avoid an Uncaught TypeError: Cannot read property '0' of undefined error.

Randomising the questions that appear for each continent involved creating a new ‘shuffledQuestions’ array and using a ‘shuffle’ function to randomise the order of the questions. E.g [1,2,3,4,5] could become [3,5,1,4,2]. These numbers in this array would then be used as indices to access the question content i.e questions[2].outputNum became questions[shuffledQuestions[2]].outputNum. The shuffle function works by iterating through each element in an array and assigning its value to another random element in the array. This function was also used to shuffle the images extracted from Trove. The algorithm can be seen below:

Algorithm used to shuffle/randomise items in an array

Reflection on the Course:

Overall I feel that I have learned a lot from the course over the semester. I feel as a team we had pulled together a product that we are all proud of, albeit not all features were implemented. In saying this, I’ve also learned in team projects such as this, it is important to not plan/aim for too many features, however judging what’s potentially too much versus just the right amount of work to be done is also a skill that is learned during these projects. I’ve also learned a lot about teamwork, and where these processes could have been improved throughout the semester.

I found myself frequently taking on a leadership role throughout the semester. I did not necessarily appoint myself in a leadership role, rather I took charge and delegated tasks wherever I felt it was necessary. Other team members had also shown leadership in some aspects of the project and so the roles within the team were not set in stone but rather depended on the situation and context. Haven taken a leadership role for a large part of the project, I felt responsible for making sure the project is progressing as it should and that each team member (including me) has an equal share of work and pulling in their weight. I found this to be a challenge, and had some concerns particularly towards the end of the semester, that the work delegated was not equal. I may have taken on too many tasks, and some of the team members may have been looking for things to do. It is essential in these situations to communicate openly and honestly, and ensure that each team member knows how to contribute as they should.

Overall I enjoyed this course, collaborating with others creatively and learning both technical and project management skills.

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.

Week 11 - Experience with Digital Prototype and User Test

This week the team demonstrated the digital prototype of Guesstoric and conducted some user testing. We were able to get the user to enter their name, select a location (at the moment all continents link to the same questions), and answer 4 questions surrounding various monuments: Sydney Opera House, Sydney Harbour Bridge, Stonehenge and The Leaning Tower of Pisa. The score is then displayed at the end.

During the digital prototype demonstration, a lot of feedback was received through user testing. We asked the users questions like “would it be easier if there were multiple images rather than just one?” and “how difficult/easy do you find answering the questions given both the images and the text?”. We also received a lot of general feedback concerning various aspects of the game. This can be summarised below:

• Include multiple images for each question, so it can be easier to decipher what the monument is when the images aren’t as relevant
• Randomise the given images and text to make it more dynamic
• Get rid of alerts
• Randomise/shuffle the questions so they aren’t all the same each time
• provide clues/hints
• Zoom in/cut the image in half to make it more challenging. This is also in regards to images from Trove like for the Sydney Harbour Bridge, where the answer is written in the image
• Reduce the amount of text, and shift the focus on the images. User testing suggested that people rarely read the text, and look straight at the images
• Discussion of difficulty levels:
• As time increases, score of possible points decreases
• Level 1 - no timing
• Level 2 - timing
• Level 3 - timing + no text
• Wording for ‘select location’ is misleading. Some users thought it meant to select where they live, rather than which continent they want to explore. Perhaps ‘select destination’ might be clearer.
• Some users have suggested to just use a few lines of text, however as long as we market the game towards the right audience - grade 10-12 - then the amount of text is appropriate.
• Each letter that is typed incorrectly could be highlighted, to help the user guess correctly
• Perhaps the blurry-to-clear image idea can be omitted, since it could be too difficult to implement in the given timeframe.

During the team meeting this week, I felt it was necessary to completely switch the structure of the game to Angular’s MVC structure in order to allow for more dynamic and interactive behaviour. While this is happening, the rest of the team continued to work on their individual parts and can integrate their sections once the new structure is up on the zone.

This is not a very effective way to collaborate on the code. Using version control (such as Git) would have been more practical for this, and would enable people to continue working without having to wait on other code. Unfortunately the team decided not to continue using Git since it had been causing more issues and hindering work progress. Perhaps more time spent familiarising ourselves with version control at the beginning could have solved this issue.

This coming week I will work on improvements based on the feedback received, and helping Felipe with the Wiki API where I can. Since most of the data has migrated to a separate data.JSON file (easier to handle than hard-coding all this data in the html/javascript files), I also delegated to Anush the task of populating the data with information for each question/monument.

At the moment, the project seems to be mostly about getting the product where it needs to be, and less focus is put on the processes within the team. The challenge at this point is to continue to ensure that everyone is pulling in their weight and what needs to be done can be divided up equally.

Week 10

This week the team continued to work on their individual tasks which can be referred to in the Implementation Plan section of the progress report. I had worked on creating multiple questions (and therefore dynamically changing sections of the webpage) and a scoring system.

In order to create multiple questions without having to leave the html page, I had used some AngularJS to make the web page more dynamic and switch to different questions. To do this I had created multiple div elements (each containing information for the question) and used the ‘ng-show’ directive of AngularJS to allow that particular element to be displayed only if a certain condition is met - in this case, it would depend on the question number:

questions.html with added dynamic functionality using Angular

When retrieving the images from Trove, it makes a url get request multiple times to pull multiple images. These images then get appended to the output div element in each question:

Using multiple get requests to pull multiple images

Currently this is not very dynamic - it is pulling a predefined set of images all at once which then get displayed in each individual question. In order for this to be improved it should dynamically pull an image from Trove based on the information of the current question, rather than at the beginning. The code is also quite redundant, and could be improved by making a call to the ‘getJSON’ function once at each question. These improvements are to be made in the coming week.

In terms of the scoring, at the moment it is able to add 1 to their score for each question guessed correctly, and then displayed at the end on the scores page:

Incrementing score for each correct answer

Displaying score