QuizUp Single Player Web
Gunnar Marteinsson
Kristinn Júlíusson
Sonja Jónsdóttir Steinar Þór Árnason
May 12, 2016
Instructor: Stefán Freyr Stefánsson T-404-LOKA
Examiner: Lóa Jóhannsdóttir School of Computer Science
QuizUp Single Player Web
Abstract In this report we discuss the B.Sc. project named QuizUp Single Player Web. The project was developed at Reykjavik University in the spring of 2016 in collaboration with Plain Vanilla Games, the makers of the world famous QuizUp app. We developed a Single Player Web application based on the original multiplayer game.
2 QuizUp Single Player Web
Contents
1 Introduction6
2 Product Description7 2.1 The Project...... 7 2.2 Development Environment...... 8
3 Work Procedure9 3.1 Kanban...... 9 3.2 Repositories...... 9 3.3 Work Hours...... 10 3.4 Kanban Board...... 11 3.5 Backlog...... 14 3.6 Milestone...... 14 3.6.1 Milestone Planning...... 14 3.6.2 Milestone Review...... 15 3.6.3 Milestone Schedule...... 15 3.7 Meetings...... 16
4 Project Structure 17 4.1 Time management...... 17 4.2 Calendar...... 17 4.3 Backlog...... 18
5 Risk Analysis 19 5.1 Managing Events...... 20
6 Architecture 26 6.1 Components...... 27
3 QuizUp Single Player Web
6.1.1 Frontend...... 27 6.1.2 Backend...... 27 6.1.3 REST URI...... 28 6.2 QuizUp Single Player...... 29 6.2.1 Home Screen...... 29 6.2.2 Topic Screen...... 30 6.2.3 Question Screen...... 31 6.2.4 Continue Screen...... 32 6.2.5 Wildcard Screen...... 33 6.2.6 Game Over Screen...... 34
7 Milestones 35 7.1 Milestone 0...... 35 7.2 Milestone 1...... 36 7.2.1 Status...... 36 7.2.2 Milestone Backlog...... 37 7.2.3 Summary...... 38 7.3 Milestone 2...... 39 7.3.1 Status...... 39 7.3.2 Milestone Backlog...... 41 7.3.3 Summary...... 41 7.4 Milestone 3...... 43 7.4.1 Status...... 43 7.4.2 Milestone Backlog...... 45 7.4.3 Summary...... 45 7.5 Milestone 4...... 47 7.5.1 Status...... 47
4 QuizUp Single Player Web
7.5.2 Milestone Backlog...... 48 7.5.3 Summary...... 48 7.6 Milestone 5...... 49 7.6.1 Status...... 49 7.6.2 Milestone Backlog...... 50 7.6.3 Summary...... 51 7.7 Milestone 6...... 52 7.7.1 Status...... 52 7.7.2 Milestone Backlog...... 53 7.7.3 Summary...... 53 7.8 Milestone 7...... 55 7.8.1 Status...... 55 7.8.2 Milestone Backlog...... 57 7.8.3 Summary...... 58 7.9 Milestone 8...... 59 7.9.1 Status...... 59 7.9.2 Milestone Backlog...... 61 7.9.3 Summary...... 61
8 Project Summary 63
9 Future 64
10 Special Thanks 65
11 Appendix 67 11.1 Google Calendar...... 67
5 QuizUp Single Player Web
1 Introduction
Plain Vanilla Games is an Icelandic Software company, best known for the trivia game QuizUp which was released in November 2013. The company headquarters are located in Reykjavík, Iceland. The QuizUp game was released for iOS in November 2013 and for Android in March 2014 followed by Windows Phone in June 2015. The game has evolved over the years and changed from being a multiplayer trivia game to a social media network where users share their interests. The game has been translated to 7 different languages and total number of users are over 70 million. In the the fall of 2015, NBC announced that they were working in co-operation with QuizUp to release a TV series based on the game. The premiere date has not been officially revealed. Recently QuizUp released a single player game mode, based on the multiplayer version, for Android and iOS. The goal of our project is to develop the single player game mode as a web application. This report is structured as follows. In section 2 we discuss the scope of the project, how the game is played and the development environment. In section 3 we discuss our work methodology. In section 4 we discuss time management and backlog planning. In section 5 we review risk analysis which was updated throughout the project. In section 6 we emphasize on the architecture of the project and take a look at the most important screens of the game. In section 7 we discuss the progress over the whole project. Section 8 is a short summary of the project and section 9 follows up with our future vision for this project.
6 QuizUp Single Player Web
2 Product Description
Our final project was to create a single player QuizUp web application. It was developed in collaboration with Plain Vanilla Games, the creators of QuizUp. The game is a standalone application and follows QuizUp’s style that can be found on their Brandisty1 page.
2.1 The Project
The final product is a running web application and a backend for the game. It is user friendly and the design is similar to the current QuizUp game, using the same fonts and color schemes. It allows a user to play QuizUp in single player mode at his own pace, which is currently not available in the browser based version. All of the code we wrote is property of Plain Vanilla Games according to a contract signed by each individual team member. The company provided us with accommodation for the duration of the project. We had our own work space at the QuizUp offices at Laugarvegur 77, 101 Reykjavík.
1brandisty.com/quizup
7 QuizUp Single Player Web
2.2 Development Environment
We did the project on our own computers. For the development of the project we used various frameworks and libraries. The following are the most prominent tools that we used, this is not an exhaustive list:
Frontend
• React – A JavaScript library for building user interfaces. ◦ Redux – A predictable state container. • NodeJS – An asynchronous event driven framework.
Backend
• NodeJS ◦ Mongoose – elegant mongodb object modeling for node.js.
Data structures
• Redis – An in-memory data structure store. • MongoDB – A NoSQL cross-platform document-oriented database.
Facebook API – Various user interactions.
Mocha – Used to unit test both frontend and backend.
ESLint – Syntax rules to enforce a certain style of coding.
A more detailed description of these tools can be found in section6.
8 QuizUp Single Player Web
3 Work Procedure
This chapter presents the basic work procedures of the team. A short explanation of the Kanban methodology and use of Git for source code management. Our schedule and work flow. Our adaptation of Kanban and how we used it to organize ourselves. Our Kanban board setup and how we categorized tasks along with various degrees of how long a task should, based on estimates, take to fully complete.
3.1 Kanban
In our first few meetings we discussed which methodology team members wanted to use. We decided to use the Kanban methodology over Scrum, for couple of reasons. The first being that QuizUp uses it. The latter being that we wanted more flexibility during planning. However, we also used some of the methods from Scrum and mixed them with Kanban. Kanban is a lean approach to agile software development and is supposed to be more adaptive than other methods used in the past as it has less of an overhead compared to Scrum. The main benefit of Kanban is that bottlenecks become visible in real-time. Scrum has many benefits which we looked into, like the time-boxed iterations. In later chapters we will describe these milestones (called sprints in Scrum) to the reader. Roles are not traditionally prescribed in Kanban. However, the team decided to inherit some Scrum methods with minor alterations and we will be using the roles: Product Manager (Product Owner) and Kanban Manager (Scrum Master).
3.2 Repositories
For source code management we will be using Git and GitHub. The company provided us with two private GitHub repositories to work on. One for the backend and one for the frontend. Our repositories are not connected to any of QuizUps existing services and will be developed as a standalone application.
9 QuizUp Single Player Web
3.3 Work Hours
To accommodate other school obligations we defined our project hours as such:
Team Member Monday Tuesday Wednesday Thursday Friday Week
Gunnar Optional 9:30 - 16:00 9:30 - 16:00 9:30 - 15:00 9:30 - 15:00 24
Kristinn Optional 9:30 - 16:00 9:30 - 16:00 9:30 - 15:00 9:30 - 15:00 24
Sonja Optional 9:30 - 16:00 9:30 - 16:00 9:30 - 15:00 12:00 - 15:00 21.5
Steinar Day off 9:30 - 16:00 9:30 - 16:00 9:30 - 15:00 9:30 - 15:00 24
Total (Hours) 92
We decided that Mondays were an optional day to be able to attend to other coursework. We expected all team members to follow this schedule and be present at QuizUp. This did not reflect actual work hours.
10 QuizUp Single Player Web
3.4 Kanban Board
To boost our knowledge of Kanban we had a meeting with the in-house agile coach, Kristinn Árni Lár Hróbjartsson. He gave us a good idea of how to set up our Kanban board and some useful recommendation on how to plan the milestones. He suggested that we start by distinguishing the main functionality of the product to get a good overview of the flow through one round of the game, and try to make it as raw as possible. After that we wrote down the main stories, created a story tree from those stories where each child in the tree was a small task to be implemented for either the frontend or backend of the application. When all the tasks were written down we prioritized them for future milestones.
Figure 1: Kanban board
11 QuizUp Single Player Web
The Kanban board from figure1 has four main columns. Story, Todo, Development (On- going & Review) and Done.
Story – A large functionality that includes many smaller tasks
Todo – A task to be implemented for a story
Development
• Ongoing – A task that a team member(s) is currently working on • Review – When a task has been implemented, tested and reviewed by another team member
Done – A task that is fully implemented, tested, reviewed and merged.
Everything on our Kanban board is assigned a color depending on what it entails.
Story – Green colored A-8 paper
Frontend task – Orange colored post-it sticker
Backend task – Lime colored post-it sticker
Other2 – Yellow colored post-it sticker
Reports – Hot-pink colored post-it sticker
Tasks were assigned time frames. Small, medium and large were mainly for tasks while extra large was for reports.
Small – Estimated 2 hours of work for an individual
Medium – Estimated 4 hours of work for an individual
Large – Estimated 8 hours of work for an individual
Extra Large – Estimated 16 hours of work for an individual
2Suggestions and/or changes to be discussed in detail later on in the project
12 QuizUp Single Player Web
During the first milestone we limited our work-in-progress (WIP) rule to have a maximum of three tasks under development but we quickly realized that this did not suit us and our work flow. In the following milestone we changed it so our WIP rule was that a maximum of eight tasks could be under development. We defined the rule as such:
Work-In-Progress
• Reviews should be prioritized. • Each team member can only have 2 tasks under development at once. • If a team member already has 2 tasks under development he/she should pair up with someone else instead of starting a new task, or review someone else’s task.
To visualize the work flow, we had pictures of everyone on our Kanban board and placed them by the tasks we were working on. Initials were put on the task and after it was done the time it took and date finished.
Figure 2: Milestone board
The goal at the end of each iteration was to show that there was more value in the product than in the one before. On the milestone board in figure2 we defined the first two iterations. Below there are stories that were for latter iterations. This way we had a general idea of what was coming up next.
13 QuizUp Single Player Web
3.5 Backlog
The product backlog was decided by using information present in the original project description, input from the Arnaldur, our product manager, and from our interpretation of it. We were encouraged to not explicitly follow the way the recently released single player mobile application worked while not deviating from what the product is. Our backlog in figure3 consisted of multiple stories. A story is a general way of interaction within our application. An example of this would be the log in or game over screen. These stories then consist of multiple tasks which make up the functionality of the story. A task is a very small part of the functionality, such as authenticating the user.
3.6 Milestone
We decided that milestones should be a two week schedule in which we setup various tasks and a general flow that we expected to be completed by the end of the milestone. The goal of our first milestone was to have a fully functional, yet raw implementation of the application, a demo. Where the flow should have been somewhat complete to allow for us to play a single game with a single question and be able to see a game over screen. To accomplish this we prioritized certain tasks into the first milestone, implementing the bare minimum in each story category. A lot of the early implementation was hard coded and in later milestones we worked on improving those tasks. At any given time we only planned two milestones ahead. This was done to easily allow us to change milestones based on progress. This allowed us to react quickly to changes.
3.6.1 Milestone Planning
At the start of a new milestone we had to check if there were any tasks leftover in the previous milestone. If so, we added it to the milestone we were about to begin. After that we could re-arrange other tasks so that we did not have a milestone with too many tasks.
14 QuizUp Single Player Web
We also planned the following milestone based on the state of the application at that time and what we wanted to accomplish in the following milestone. A milestone is two weeks. Always starting on a Monday and finishing on a Friday the following week.
3.6.2 Milestone Review
During and after each milestone we had a meeting to determine how the milestone pro- gressed. On the first Friday of a milestone we met up at the end of the day to review the preceding week. We did that to see if there was something that could be improved and if we were behind or ahead of schedule. The purpose of these meetings was to resolve any problems we had come across. At the end of the milestone, we tried to get an in-house employee to try our application’s demo. This way we got informal feedback from a different perspective which was useful. At the end of the milestone, the team members also did a full review, to decide our next objective. During review meetings each team member talked about how the milestone went, any problems that occurred and what could have been done differently.
3.6.3 Milestone Schedule
At the beginning of the semester we sat down and discussed how we wanted to setup our milestones. We decided to have a total of nine milestones. The first milestone on the list was spent finding a final project and setting up at the company. This involved finding available space inside the company and getting to know some of the people around us.
Milestone #0 – 11. January to 22. January Milestone #1 – 25. January to 5. February Milestone #2 – 8. February to 19. February
15 QuizUp Single Player Web
Milestone #3 – 22. February to 4. March
Milestone #4 – 7. March to 18. March
Milestone #5 – 21. March to 1. April
Milestone #6 – 4. April to 15. April
Milestone #7 – 18. April to 29. April
Milestone #8 – 2. May to 13. May
3.7 Meetings
Daily stand-up meetings were held all days when at least two team members were present. The main characteristics of these meetings were to keep everyone on the team up to date on current tasks and progress. These meetings never exceeded 10 - 15 minutes. If any major problems surfaced a meeting had to be scheduled to resolve them.
16 QuizUp Single Player Web
4 Project Structure
4.1 Time management
For general overview of the project we decided to use Google Drive. Each team member was responsible of tracking their own work hours on the shared document on our Drive. This helped to keep track of how many hours we spent on tasks and whether we were behind or ahead of schedule. For visualization of this data see any of the milestone reviews in section7. Our work hours were split into four different categories. Programming, design, reports and untracked3. To efficiently track hours spent programming, design and reports we decided to use a combination of Trello4 and Toggl5. We initially tried using this combo at the end of milestone 2 and it seemed to work nicely together. We decided to use it for the remainder of the project.
4.2 Calendar
The team agreed on using a shared Google Calendar for due dates and reminders for meet- ings and lectures. This way every team member could visualize deadlines. See appendix 11.1.
3If it doesn’t belong in the other categories it is put here, anything like lunch, meetings, demos etc. 4trello.com 5toggl.com
17 QuizUp Single Player Web
4.3 Backlog
At the beginning of the project we wrote down a list of tasks that formed our backlog. We knew that this list would change throughout the project. After each completed task we wrote down the actual time it took to complete it.
Figure 3: Screenshot of initial backlog
18 QuizUp Single Player Web
5 Risk Analysis
During a project such as this various events could unfold that would potentially affect it. Here we will discuss some of these events, the chances of them happening, their impact and how we can prepare and resolve them. In the following chapter we will breakdown the occurrences of said risks (if applicable), their reason, the consequences and impact on our project will be briefly explained. We listed the risks for our project below and updated them continuously throughout the project. When events not previously thought of occurred we added that risk and incident to the list.
No. Event Odds Impact Risk6 1 Code merge causes issues 3 4 12 2 Task evaluation wrong 3 4 12 3 Code blockage 3 3 9 4 Milestone evaluation wrong 3 3 9 5 A poorly implemented feature 2 4 8 6 Tasks/stories not detailed enough 2 4 8 7 Issues with remote server 4 2 8 8 Communication issues with company 2 3 6 9 Internal company changes 2 3 6 10 Communication issues within team 2 2 4
Scale Odds Impact 1 Highly unlikely None 2 Unlikely Minor 3 Likely Moderate 4 Very likely High
6Odds of occurrence * Impact of event
19 QuizUp Single Player Web
5.1 Managing Events
Event 1 – Code merge causes issues A merge with master could cause some unwanted behavior or completely break the application.
• Precautions – Make sure all unit tests still run and that someone has reviewed the pull request before accepting it onto the master branch. • Reaction – Revert back to the last functional master branch commit and re- evaluate the merged code. • Consequences – Slows down progress. • Team member responsible – Steinar
Fortunately we managed to avoid code merge issues. This was prevented by following our precaution rule and using branching with git. Our reason for having this risk at the top of our risk evaluation is that we have all been a part of a project where merges with git have caused major issues that took time to resolve. Having a guideline step-by-step process for working on a task has been a key factor in making sure merging has not been an issue, which we are very happy with.
Event 2 – Task evaluation wrong We either commit too much or too little time to a specific task that does not reflect what we had estimated.
• Precautions – Review and base evaluations on previously completed tasks. • Reaction – Take note of what went wrong, review in retrospective and compare it to other tasks to see how to improve. • Consequences – Inaccurate expectations. • Team member responsible – Gunnar • Occurrences ◦ When – Milestone #1. Reason – Some tasks took longer than estimated. Consequence – Some tasks were moved back to the backlog. Impact – We had to re-evaluate the backlog at the start of the following milestone and move tasks accordingly.
◦ When – Milestone #2. Reason – A few tasks were underestimated.
20 QuizUp Single Player Web
Consequence – Three tasks moved to next milestone. Impact – Minor, nothing to be worried about.
◦ When – Milestone #3. Reason – Underestimated tasks. Consequence – Tasks took longer to implement. Impact – Slowed down progress, unfinished tasks at end of milestone.
◦ When – Milestone #4. Reason – Underestimation of tasks. Consequence – Only one task was finished and merged. Impact – Milestone was a failure (task wise), everything was moved for- ward.
◦ When – Milestone #5. Reason – A few tasks were underestimated. Consequence – Three tasks moved to next milestone. Impact – Minor, nothing to be worried about.
◦ When – Milestone #7. Reason – Underestimation of tasks. Consequence – Minor, still managed to finish all the tasks we wanted and more. Impact – Minor, milestone was successful.
Event 3 – Code blockage When you are stuck during your task and have not had any real progress for a set amount of time.
• Precautions – Take a short break from coding, stand up, stretch and think about it, ask for input/help. • Reaction – Ask team members or a contact at the company for help. • Consequences – Halts progress. • Team member responsible – Kristinn
Never happened to an extent that halted progress. Everybody occasionally ran into small obstacles but those were easily resolved either with input from team members or company contacts.
21 QuizUp Single Player Web
Event 4 – Milestone evaluation wrong When we put too much or too little into the milestone, meaning we would be either ahead or behind schedule.
• Precautions – Review past milestones when setting new ones. • Reaction – Re-evaluate our overall schedule too see how we are doing, improve the next milestone to avoid this from happening again. • Consequences – Our expectations might not be accurate. • Team member responsible – Gunnar • Occurrences ◦ When – Milestone #1. Reason – Underestimated the time for reports. Had too many tasks. Consequence – We could not finish all tasks. Impact – The next milestone has to be fully re-planned.
◦ When – Milestone #3. Reason – Task evaluations were wrong. Consequence – Not all tasks finished at the end of milestone. Impact – Tasks moved to next milestone.
◦ When – Milestone #4. Reason – A task was underestimated and the review meeting took more time to prepare for than we initially thought it would. Consequence – Only one of the tasks for this milestone was completely finished (although we had started some of the others). Impact – Wildcard logic moved to the next milestone.
◦ When – Milestone #6. Reason – Exams and in-house preparations took more time than we thought. Consequence – Could not finish as many tasks as we would have liked. Impact – Only half of the tasks were finished, had to be done in the next milestone.
Event 5 – A poorly implemented feature A feature we have already implemented turns out to have been done so poorly.
• Precautions – Make sure reviews spot poorly implemented features. • Reaction – Refactor/rewrite the feature.
22 QuizUp Single Player Web
• Consequences – Code becomes harder to maintain and understand. • Team member responsible – Steinar • Occurrences ◦ When – Milestone #3. Reason – We were using Immutable incorrectly. Consequence – Had to devote time to fixing the code that relied on correct immutability. Impact – Time lost, had to re-evaluate a lot of code.
◦ When – Milestone #5. Reason – Backend re-factoring, fixing dependency injection and cleaning up unit tests. Consequence – A lot of minor changes had to be made across various files. Impact – Some time lost but well worth it.
◦ When – Milestone #5. Reason – Some components had to be re-factored. Consequence – Both .css and .jsx files had to be improved. Impact – Time lost, had to re-evaluate a lot of code.
◦ When – Milestone #7. Reason – Unit tests we are not running as we expected them to. Consequence – Had to devote time to setup unit tests again so that they behaved as we originally wanted. Impact – Time lost, had to re-evaluate a lot of code.
Event 6 – Tasks/stories not detailed enough Details might surface that have not been thought of or explored enough. Definitions not defined fully.
• Precautions – Review and update them frequently. • Reaction – Emergency meetings, must be resolved as soon as possible. • Consequences – Delays in project if missing crucial components of application. • Team member responsible – Steinar • Occurrences ◦ When – Milestone #1. Reason – Unclear task definitions/explanations.
23 QuizUp Single Player Web
Consequence – We were not sure how to proceed with the tasks. Impact – Moved to backlog for further definition. Following the first occurrence of this risk we changed the way we defined our tasks on our Kanban board. If the task name sounded ambiguous we wrote down a small description with it, either a short summary or notes about what it should do.
Event 7 – Issues with remote server The remote server gets shut down, crashes or experiences other issues.
• Precautions – Do not rely on the server solely. • Reaction – Use local databases. • Consequences – Might ruin something while we are working on it. • Team member responsible – Kristinn • Occurrences ◦ When – Milestone #7. Reason – Server got hacked. Consequence – Had to take it down and use local databases. Impact – Minor inconvenience. After this incident we decided not to host our databases on the web. We also identified another risk, which was that our databases contain data from QuizUp which might be compromised.
Event 8 – Communication issues with company Hard to get a hold of our company contacts or get help from someone else within the company.
• Precautions – Set up a good way of communication, get to know the employees. • Reaction – Reach out to see if there is anyone that could help. • Consequences – The possibility of getting stuck on something that the com- pany might have already dealt with and could relay useful information to solve said problem. • Team member responsible – Sonja
This was never an issue for the duration of the project. At one point our company contacts had to leave the country for work. Yet we were still able to communicate with them over Slack and had other company contacts that were present for help if we needed it.
24 QuizUp Single Player Web
Event 9 – Internal company changes A major change within the company that directly affects us.
• Precautions – Have other workplaces available (A team members home for example). • Reaction – Work with the company to minimize consequences. • Consequences – Could ruin our schedule if we were not well prepared. • Occurrences ◦ When – 29/01/2016. Reason – Glu Mobile Inc invested in QuizUp, re-organization within the company. Consequence – We had to move our work space to another floor. Impact – Minor inconvenience. Had to spend time moving our Kanban wall and set it up again.
Event 10 – Communication issues between team members Unexpected differences/problems might occur.
• Precautions – Keep a light and friendly atmosphere. Everyone should be able to express themselves without judgment from others. • Reaction – Resolve our differences/problems. • Consequences – Results in bad moral within the team which affects the work. • Team member responsible – Sonja and Kristinn • Occurrences ◦ When – Milestone #1 Reason – Information was not getting to everybody on the team. Consequence – A team member got left out of the loop and was not able to get into it. Impact – Loss of manpower, less work accomplished than might have been.
We did not have any further occurrences of this risk during the project.
25 QuizUp Single Player Web
6 Architecture
In this chapter we will emphasize on the architecture of our project. Figure4 shows an overview of our system and how each individual component communicates with each other. The web application was developed in ReactJS with the Redux data model, this was a requirement from by QuizUp. The only external service we use is the Facebook API. QuizUp did not provide us with any of their services. The user logs in with his Facebook account which gets authenticated on our backend. Following this the user can choose a topic to play through. QuizUp provided us with a boilerplate code for the frontend of the application. It included a setup of React and Redux with CSS Modules, Webpack, Babel, Mocha and a Node proxy server. An ESLint configuration was also provided. All of our code is written in ES6.
Figure 4: System Overview
26 QuizUp Single Player Web
6.1 Components
6.1.1 Frontend
The web application was developed in ReactJS7 which is a JavaScript library created by Facebook for building user interfaces. It also uses Redux8 which is a framework inspired by Flux that is used to maintain application state. ReactJS and Redux work exceptionally well together since ReactJS is focused on the user interface while Redux focuses on the data that the view then renders. In Redux you can only change the application state inside ’reducers’. The ’reducers’ are unit tested to make sure that the state changes as expected. We use NodeJS9 in the frontend as a proxy server to funnel requests to the backend. This is done to avoid CORS10 because it is not allowed by default and if enabled it poses a security risk.
6.1.2 Backend
Our backend is a NodeJS server that uses ExpressJS11, which is a minimalist web framework for NodeJS that provides a robust set of features to develop web and mobile applications. To define the database schema we used MongooseJS12, which is a library that provides MongoDB object mapping. Unit tests were done with Mocha13 using Expect14, which is an assertion library. Data is stored in MongoDB15, which is a NoSQL data storage, and Redis16, which is an in-memory data structure store.
7facebook.github.io/react 8redux.js.org/index.html 9nodejs.org/en/about 10en.wikipedia.org/wiki/Cross-origin_resource_sharing 11expressjs.com 12mongoosejs.com 13npmjs.com/package/mocha 14npmjs.com/package/expect 15docs.mongodb.org/manual 16redis.io
27 QuizUp Single Player Web
6.1.3 REST URI
A more detailed documentation about our backend can be found in our REST URI guide.
Method URI Description
POST /api/v1/login/ Log in user GET /api/v1/topics/ Retrieve topics POST /api/v1/topics/slug/answer/ Validates answer GET /api/v1/topics/slug/questions/ Retrieves questions GET /api/v1/topics/slug/wildcard/topics Retrieves three topics GET /api/v1/topics/slug/wildcard/question/ Retrieves random question GET /api/v1/topics/slug/ Retrieves topic GET /api/v1/users/ Retrieves user information PUT /api/v1/users/ Updates user information POST /api/v1/users/favorite/slug Adds a favorite topic DELETE /api/v1/users/favorite/slug Removes a favorite topic POST /api/v1/games/ Add/update played topic
28 QuizUp Single Player Web
6.2 QuizUp Single Player
In this chapter we will describe the general flow in our web application. Among these are the home screen, topic screen, questions screen, game screen and game over screen.
6.2.1 Home Screen
In figure5 we see the home screen which appears after logging in. The first row displays favorite topics, the second row displays random topics and the last row displays most recently played topics. The navigation bar displays the QuizUp logo and allows the user to navigate to ’All Topics’ and toggle the menu side bar.
Figure 5: Home screen
29 QuizUp Single Player Web
6.2.2 Topic Screen
In figure6 we see the topic screen for a specific topic. Here we can view more information about the topic, description and leaderboards. On this screen the user can add or remove the topic from his favorites list and start playing. The leaderboard can be filtered by Facebook friends so that the user can see how he stands against them.
Figure 6: Topic screen
30 QuizUp Single Player Web
6.2.3 Question Screen
In figure7 we see the question screen. On the left side we have a tubemap which displays the current round. On top of the page we have the score and on the right side we have the timer animation which displays the time left to answer.
Figure 7: Question screen
31 QuizUp Single Player Web
6.2.4 Continue Screen
In figure8 we can see the continue screen which is prompted in-between rounds once a question has been answered correctly. The tubemap now displays the current round and upcoming round. The comical quote is randomly chosen between rounds. The ’X’ button in top right corner gives the user option to quit the current game and return to the topic screen.
Figure 8: Continue screen
32 QuizUp Single Player Web
6.2.5 Wildcard Screen
Figure9 displays before every fifth question where a user is prompted to choose from three random wildcard topics. After choosing a topic, a random question is served from that topic.
Figure 9: Wildcard selection screen
33 QuizUp Single Player Web
6.2.6 Game Over Screen
Figure 10 shows the game over screen. When a new personal high score is achieved it rains confetti. Similar to figure6, the leaderboards are also shown. If a user has reached certain milestones he will obtain a new titles, which can be applied immediately or later in the settings menu. He can also choose to play the topic again, share it to Facebook or leave the current topic.
Figure 10: Game over screen
34 QuizUp Single Player Web
7 Milestones
In this chapter we will reflect on each milestone. We have written down some noteworthy points about each milestone; what we did, what went well and what we could have done better.
7.1 Milestone 0
11. January - 22. January. Our goals for this milestone were to visualize and organize the project and setting up all required software. We started looking at the boilerplate code that the company provided and each team member spent time looking at React and Redux tutorials. This sprint was actually very exciting as it went on. We met up with the company rep- resentatives, our technical contacts, product owner, agile coach and got acquainted to the CEO of Plain Vanilla. After we designed wireframes for the flow of the application we made relevant user stories and converted tasks to GitHub issues. We then organized milestone 1 and made a rough plan for milestone 2.
35 QuizUp Single Player Web
7.2 Milestone 1
25. January - 5. February. Our goal for this milestone was to implement a game from beginning to end with minimum functionality. That is, the user could log in with Facebook, click a button to play the game, answer a single question and get the game over screen.
7.2.1 Status
We finished roughly half of our tasks so we were running a bit behind schedule. We underestimated the time it took to write reports and the learning curve of the boilerplate. This explains the vertical line from 25. January - 5. February in figure 11.
Figure 11: Burndown chart for milestone 1
The talking points from the retrospective meeting after milestone 1 are as follows:
What went well
36 QuizUp Single Player Web
• The communication between us and the company was very good. We got almost instant technical help when needed. • To get familiar to the React and Redux frameworks we used pair programming.
What did not go well
• We miscalculated the hours that we needed for writing all the reports which lead to us over estimating the tasks we chose to work on along side the reports. • Task descriptions not detailed enough. • We were not doing our daily standup. • One team member felt left out of the loop at times.
What we have learned
• Pair programming can be very useful when the learning curve is steep. • If some team member is unsure of what he should be doing or feels left out he should tell the other team members. Communication is key to solving this. By doing nothing we would be losing valuable manpower. • At Daily stand up meetings each team member must be focused so these meet- ings do not loose their mark. • Put fewer tasks in each milestone. We would rather add tasks than leave them open • WIP rule changed.
7.2.2 Milestone Backlog
Below is an overview of the status of the backlog for this milestone. ’Open’ tasks were not finished, ’Removed’ tasks were removed from the project and ’Closed’ are completed tasks that have been merged.
37 QuizUp Single Player Web
Frontend/Backend Story Task Scale Status Front Facebook Login Button component L Closed Front Facebook Login Post to our backend M Closed Front Facebook Login Route user M Closed Back Facebook Login Basic user database schema M Closed Back Facebook Login Verify access token L Open Back Facebook Login Create user M Closed Back Facebook Login Get user S Closed Back Facebook Login Return user S Removed Front Home Get topic name from backend S Open Front Home Show topic S Closed Front Home Select topic S Open Back Home Create topic database schema S Open Back Home Return topic S Open Front TopicX Display play button M Closed Front TopicX Get topic from backend S Open Back TopicX Get topic by ID S Open Back TopicX Hard coded database topic S Removed Front Question Display question M Open Front Question Display answers S Open Front Question Select answer S Open Back Question Get question and answers S Open Front Game Over Game over text S Open
7.2.3 Summary
We learned that communication is key if this project was going to be a success. Planning and organizing was something we would get better at with time. The tasks we did not complete were moved to the next milestone.
Figure 12: Work hours
38 QuizUp Single Player Web
7.3 Milestone 2
8. February - 19. February Our goals were to improve the application flow and layout. The backend had to be re- factored before we could unit test the functions. We tried out Toggl to help us with time tracking for each task. At the end of the milestone a team member discovered that Toggl could be used directly with Trello.
7.3.1 Status
During planning we deliberately left some hours aside because we were not sure how to prioritize tasks. Which explains the added tasks in figure 13. Our application was in good shape after this milestone considering how much time we had left.
Figure 13: Burndown chart for milestone 2
The talking points from the retrospective meeting after milestone 2 are as follows:
39 QuizUp Single Player Web
What went well
• We are more confident in React. • Communication within the group is going very well. • Toggl and Trello are working well together and tasks are more precisely time tracked as well as actual working hours.
What did not go well
• We were not doing well enough when describing tasks, i.e. two tasks might have been on a separate post-it when they should have been on one and vice versa. • Syncing the backlog to the Kanban board is lacking.
What we have learned
• We are getting better in estimating each task. • We need to start unit testing. • Put fewer tasks into milestone then add more as we go along. • Use and drop. Do not hesitate to drop tools that are not working and try others. In this milestone we did not have our tasks on GitHub but used time tracking with Toggl and than later Trello.
40 QuizUp Single Player Web
7.3.2 Milestone Backlog
Frontend/Backend Story Task Scale Status Front Home Select and display topic L Closed Front Home Return multiple topics S Closed Front Home Get topic name from backend M Closed Front Home Layout M Closed Back Home Create database topic schema L Closed Back TopicX Get topic by slug S Closed Front TopicX Game overlay component M Closed Back TopicX Case insensitive topic creation M Closed Front TopicX Back button S Removed Front TopicX Unit test implementation S Closed Back TopicX Topic schema slug S Closed Back Question Return multiple questions M Closed Front Question Select answer S Closed Front Question Display question M Closed Front Question Validate answer to question S Closed Front Question CSS questions M Closed Front Question CSS questions, text and buttons M Closed Front Question Continue screen S Closed Front Question Continue button S Closed Front Question Quit game button S Closed Back Question Limitation characters questions and answers S Closed Back Question Get correct answer to question S Closed Front Question Questions database schema S Removed Front Game Over Back button S Closed Front Game Over Game over text S Closed Front Game Over Play gain button S Closed Front Game Over Go back to topic button S Closed Back Game Over Eslint configuration S Closed Back Other Documentation implementation M Closed
7.3.3 Summary
Time management was better using Toggl and we learned that actual working hours do not reflect the hours spent in house. Tasks were better defined but we still have room for improvement.
41 QuizUp Single Player Web
Figure 14: Work hours
42 QuizUp Single Player Web
7.4 Milestone 3
22. February - 4. March. Our goals were to improve our application flow, make it user friendly and adding game logic. The user could at this point search for topics, choose a topic and play a game.
7.4.1 Status
In figure 15 the guideline was 82 hours of programming work and we completed 78. During this milestone we added 30 hours worth of tasks and moved 32 to the next milestone. The reason for adding tasks is that we discovered that some needed to be completed before others could be started.
Figure 15: Burndown chart for milestone 3
What went well
43 QuizUp Single Player Web
• User interface programming went very well.
What did not go well
• Team members did not update their project journals.
What we have learned
• We learned how to implement Redis • All objects and variables that are stored in the Redux state should be immutable. • Toggl and Trello board works well together.
44 QuizUp Single Player Web
7.4.2 Milestone Backlog
Frontend/Backend Story Task Scale Status Front Facebook Login Log in button delay M Closed Back Facebook Login Generate cookie M Open Back Facebook Login Verify access token M Closed Back Facebook Login Advanced user database schema M Closed Back Facebook Login Unit test user model S Closed Back Home Initialize icons S Closed Front Home Topic rows layout M Closed Front Home Topic display icons S Removed Back Home Return user info S Closed Front Home Get user info S Closed Front TopicX Basic layout setup M Closed Front TopicX Create /topics page M Closed Back TopicX Unit test topic model S Closed Front Topics Search for topic L Closed Back Question No duplicate questions L Open Front Question Show score during game L Closed Front Question Question round M Closed Front Question Color validate answer M Closed Front Question Continue screen layout S Closed Front Question Start game screen layout S Closed Front Wildcard Select wildcard screen L Open Back Wildcard Get random topics for wildcard M Open Front Wildcard Get question from wildcard topic S Open Front Wildcard Show wildcard question M Open Front Wildcard Validate wildcard answer S Open Back Other Implement backend unit tests L Closed Back Other Implement Redis S Closed Front Game Over Layout S Closed Front Game Over Show score S Closed
7.4.3 Summary
Our time management through Toggl helped logging actual programming time which is displayed in figure 15 and we will continue using both Toggl and Trello board in the forth- coming weeks.
45 QuizUp Single Player Web
Figure 16: Work hours
46 QuizUp Single Player Web
7.5 Milestone 4
7. March - 18. March. Our goals were to implement the Wildcard functionality and prepare for the project review meeting with our instructor and examiner.
7.5.1 Status
Due to the workload in other courses and the time it took to prepare for the review meeting, we were not able to be as productive as we would have wanted.
Figure 17: Burndown chart for milestone 4
What went well
• Preparation for the meeting. • The meeting went well.
What did not go well
47 QuizUp Single Player Web
• Planning.
What we have learned
• Redis in-memory database.
7.5.2 Milestone Backlog
Frontend/Backend Story Task Scale Status Back Facebook Login Generate cookie M Open Back Questions Make sure no duplicate questions L Closed Front Questions Timer L Open Front Questions Tubemap L Open Back Wildcard Get Random topics for wildcard M Open Back Wildcard Get question from wildcard topic S Open Front Wildcard Select wildcard screen L Open Front Wildcard Show wildcard question M Open Back Wildcard Validate wildcard answer S Open Front Wildcard Increment score after wildcard M Open Back Wildcard Unit test redis functions L Open
7.5.3 Summary
We were satisfied with the review meeting. However, we were not happy about our planning since we only finished one task. The only task we managed to complete took us a grand total of 25.75 hours in pair programming. We implemented Redis in the previous milestone but we ran into some problems while working with Redis in this milestone.
Figure 18: Work hours
48 QuizUp Single Player Web
7.6 Milestone 5
21. March - 3. April. Our goals were to implement timer, image questions and side bar component to name a few tasks. Due to Easter break there were fewer working days than usual.
7.6.1 Status
Our productivity went up after the Easter break which explains the vertical line in figure 19. We managed to finish most of our tasks but underestimated some of them.
Figure 19: Burndown chart of our progress
What went well
• More productive than previous milestone. • Planning.
What did not go well
49 QuizUp Single Player Web
• Keeping reports up to date.
What we have learned
• Redux thunk.17 • Time is running out.
7.6.2 Milestone Backlog
Frontend/Backend Story Task Scale Status Front Home CSS components cleanup S Closed Back Home Remove favorite topic S Closed Front Home Get favorite topic S Closed Front Home Hamburger component M Closed Back Home Post favorite topic M Closed Back Home Add titles S Closed Back Home Re-factor M Closed Front Home Re-factor components L Closed Back Home Generate cookie M Removed Back Home Get favorite topics S Removed Back Home Update user S Open Back Questions Get questions from wildcard M Closed Front Questions Image questions S Closed Front Questions Make reducer immutable L Closed Back Questions Payload image questions S Closed Front Questions Timer L Closed Front Questions Unit test game reducer S Closed Front Questions Unit game result reducer S Closed Back Questions Unit test redis functions L Closed Front Questions Unit test topic reducer S Closed Front TopicX Add favorite topic S Closed Back Wildcard Get question from wildcard S Closed Back Wildcard Get random topics from wildcard M Closed Front Wildcard Get select wildcard screen L Closed Front Wildcard Show wildcard questions M Closed Back Wildcard Validate wildcard answer S Closed Front Wildcard Increment score wildcard S Open Back Game Over Topic leader board schema M Open
17npmjs.com/package/redux-thunk
50 QuizUp Single Player Web
7.6.3 Summary
A lot of tasks were finished in this milestone, which might have something to do with team members being rested and refreshed after a short but much needed Easter break.
Figure 20: Work hours
51 QuizUp Single Player Web
7.7 Milestone 6
4. April - 17. April. Our plan for this milestone was to accomplish as much as we could in the first week. Unfortunately things did not go as planned due to final exams in other courses. Another reason was an informal in-house demo where we showed our progress to the developers at QuizUp.
7.7.1 Status
Most of the tasks were moved to the next milestone due to insufficient time. As shown in figure 21 we had exams from the 9th - 17th of April.
Figure 21: Burndown chart for milestone 6
What went well
• Demo at QuizUp.
52 QuizUp Single Player Web
What did not go well
• Planning.
What we have learned
• Our user interface needs an upgrade.
7.7.2 Milestone Backlog
Frontend/Backend Story Task Scale Status Front Home Content to sidebar M Closed Front Home Favicon S Closed Back Home Get recent topics M Open Front Home Get recent topics S Open Front Home Home logo component M Closed Front Home Log out S Open Front TopicX Remove favorite topic S Closed Front Questions End game after X minutes S Open Back Questions Flush redis wrong answer S Closed Front Questions Quit game confirmation S Open Front Game Over Display leaderboard M Open Back Game Over Get leaderboard S Open Back Game Over Post add played topic S Closed Back Game Over Post leaderboard S Closed Front Game Over Post stats M Open Back Game Over Put update user topic M Removed Front Game Over Share to Facebook M Open Back Game Over Topic leaderboard schema M Open
7.7.3 Summary
We spent two days getting ready for the in-house demo, to do this we went briefly off schedule to accommodate certain features that we felt were mission critical.
53 QuizUp Single Player Web
Figure 22: Work hours
54 QuizUp Single Player Web
7.8 Milestone 7
18. April - 1. May. This was the last milestone before the feature freeze. The main focus was to upgrade the user interface in a manner that we would be proud of. The flow of the game at this point was good as finished.
7.8.1 Status
We managed to complete all of the tasks planned along with others added. We removed tasks that we deemed unnecessary and unrealistic due to the time left.
Figure 23: Burndown chart for milestone 7
What went well
• Productive milestone. • Good Communication.
55 QuizUp Single Player Web
• Tasks well prioritized.
What did not go well
• We thought we were almost done, we were wrong.
What we have learned
• Planning matters.
56 QuizUp Single Player Web
7.8.2 Milestone Backlog
Frontend/Backend Story Task Scale Status Front Game Over CSS leaderboard scroll S Closed Front Game Over CSS title notification S Closed Front Game Over Detect title unlocked M Closed Back Game Over Detect tile unlocked M Closed Front Game Over Display leaderboard S Closed Front Game Over Fix re-render issue S Closed Front Game Over Leaderboard CSS M Closed Back Game Over Post addPlayedTopic M Closed Front Game Over Post stats to database M Closed Front Game Over Share after game to Facebook M Closed Back Game Over Update user on GameOver M Removed Front Home Delay topic animation S Closed Front Home Get recent topics S Closed Front Home Loading animation S Closed Front Home Log out S Closed Front Home Sidebar CSS M Closed Front Home Background S Closed Front Home Loading message S Closed Front Home Prettify S Closed Front Questions CSS image questions S Closed Front Questions Punchlines S Closed Front Questions Quit game confirmation S Closed Front Questions Reducer unit tests M Closed Front Questions Timer CSS M Closed Front Questions Tubemap L Closed Front Questions Tubemap CSS L Closed Front Questions Settings page CSS L Closed Front Questions Settings to update info M Closed Back Topics Add more titles to payload S Closed Front Topics CSS containers M Closed Front Topics Shortcut S Closed Back TopicX Add titles to payload S Closed Front TopicX Display topic leaderboard S Closed Front TopicX Presentation topic S Closed Front TopicX Leaderboard national flags M Removed
57 QuizUp Single Player Web
7.8.3 Summary
We were pleased how we managed progress in this milestone. Prioritizing tasks was impor- tant as we needed certain functionality to be completed before we could start improving the user interface.
Figure 24: Work hours
58 QuizUp Single Player Web
7.9 Milestone 8
2. May - 13. May. We were in feature freeze which means we only improve our user interface before our final review meeting and final presentation.
7.9.1 Status
We managed to complete all of the tasks before the milestone was finished. Tasks that were in our backlog and we could not complete due to time constraints were removed from the project as shown in figure 25.
Figure 25: Burndown chart for milestone 8
What went well
• Final review meeting. • Improving the user interface.
59 QuizUp Single Player Web
What did not go well
• Nothing notable.
What we have learned
• Prioritizing is important.
60 QuizUp Single Player Web
7.9.2 Milestone Backlog
Frontend/Backend Story Task Scale Status Front Facebook Login Log in failure message M Removed Front Facebook Login Help button M Removed Front Facebook Login Help button CSS M Removed Front Home Fix favicon logo S Closed Front Home Homepage CSS S Closed Front Home Button CSS M Closed Back Home API documentation L Closed Front Home Display score CSS M Closed Front Home Sidebar CSS M Closed Front Home Welcome on-boarding S Closed Front Home Icons CSS S Closed Front Home On-boarding S Closed Front Home Fix production build L Closed Back Home User aggregate score schema M Removed Front Home New 404 page L Removed Front Home New user message M Removed Front Topics Re-ordering after search M Removed Front TopicX Facebook leaderboard CSS L Closed Front Question Quit prompt CSS S Closed Front Question Delay clickable S Closed Back Question New personal best score check M Closed Front Question Answer question CSS S Closed Front Question Timer CSS M Closed Front Game Over Add display name to leaderboard S Closed Front Game Over Confetti component L Closed Front Game Over Re-render problem fix L Closed Front Game Over Share to Facebook CSS S Closed Front Settings Settings CSS L Closed Front User Carousel stats L Removed Front User User page S Removed
7.9.3 Summary
At the end of the milestone we removed the tasks that were left in the backlog due to time constraints.
61 QuizUp Single Player Web
Figure 26: Work hours
62 QuizUp Single Player Web
8 Project Summary
Overall we are pleased with the outcome of the project even though we would have loved to achieve more. When we handed in the project we had completed all of the requirements defined by QuizUp. The team as a whole has enjoyed this project although it has been a challenging endeavor. The learning curve of the frontend boilerplate code we received was steeper than we initially thought it would be, even at the end of the project. While working on the backend and our data structures we realized that the task at hand was greater than we initially concluded from the project description. During our milestone planning throughout the project we underestimated a few stories and could perhaps have broken some tasks down better. This caused certain features to either be pushed to the next milestone or put on hold until features with a higher priority were completed. Thanks to Kanban flexibility we always managed to re-organize quickly and get back on track.
Figure 27: Project burndown
63 QuizUp Single Player Web
9 Future
When we handed in the project at the end of our time at QuizUp the web application and backend where fully developed and ready for production. However, due to the need of scaleability in applications like these where thousands, if not millions of requests needed to be handled in a short period of time an NodeJS backend would scale poorly. The reason we chose NodeJS was that none of the group members had developed a backend in Java or other environments that are not asynchronous. The group had a many ideas on how we would like to enhance the product and make it different from the QuizUp game we know today. Due to time constraint we were only able to squeeze in a few before we handed in the project. If we had a few more months to work on the project we would do the following. First, we would like to conduct usability testing. This would provide us with more understanding of the users needs, decrease future cost in development and provide future users more satisfaction when playing the game. Secondly, we would add more game modes. The ideas the group had in mind was a Wildcard mode, where the user would only get wildcard questions. Trifecta game mode was another one where the user would start a game, choose three topics to play from with no wildcard questions. Last but not least, we would try to monetize the product. Instead of flooding users with ads, the users could unlock topics for a small fee. Other ideas would be to allow the user to buy back into the game on wrong answer.
64 QuizUp Single Player Web
10 Special Thanks
We would like to thank everyone at Plain Vanilla Games for their collaboration and giving us the opportunity to work on this project. The company provided us with fantastic facilities and a motivating working environment. Our special thanks go to Kristinn Árni Lár Hróbjarstsson the Agile coach, Pétur Jóhannes Óskarsson for introducing us to Friday feelings, Vigdís Hlíf for in-house management, Hlynur Sigurþórsson and Steinn Steinsen for valuable pointers, and the whole Web Tools team for technology assistance, Arnar Þór Sveinsson, Sölvi Logason, Tryggvi Gylfason, Kristján Oddsson and Arnaldur Grétarsson. Finally we would like to thank our instructor Stefán Freyr Stefánsson and our examiner Lóa Jóhannsdóttir for advices and valuable pointers for the future ahead.
65 QuizUp Single Player Web
May 12, 2016
Gunnar Marteinsson Kristinn Júlíusson 260983-5209 150893-2409
Sonja Jónsdóttir Steinar Þór Árnason 180292-3499 240493-2259
66 QuizUp Single Player Web
11 Appendix
11.1 Google Calendar
Figure 28: Screenshot from January Google Calendar
67 QuizUp Single Player Web
Figure 29: Screenshot from February Google Calendar
Figure 30: Screenshot from March Google Calendar
68 QuizUp Single Player Web
Figure 31: Screenshot from April Google Calendar
Figure 32: Screenshot from May Google Calendar
69