Interaktionsspel På Spotifys App-Plattform Martin Jönsson

LiU-ITN-TEK-A-13/055-SE

Interaktionsspel på Spotifys app-plattform Martin Jönsson

2013-10-25

Department of Science and Technology Institutionen för teknik och naturvetenskap Linköping University Linköpings universitet nedewS ,gnipökrroN 47 106-ES 47 ,gnipökrroN nedewS 106 47 gnipökrroN LiU-ITN-TEK-A-13/055-SE

Interaktionsspel på Spotifys app-plattform Examensarbete utfört i Medieteknik vid Tekniska högskolan vid Linköpings universitet Martin Jönsson

Handledare Pierangelo DellAcqua Examinator Pierangelo Dell'Acqua

Norrköping 2013-10-25 Upphovsrätt

Detta dokument hålls tillgängligt på Internet – eller dess framtida ersättare – under en längre tid från publiceringsdatum under förutsättning att inga extra- ordinära omständigheter uppstår. Tillgång till dokumentet innebär tillstånd för var och en att läsa, ladda ner, skriva ut enstaka kopior för enskilt bruk och att använda det oförändrat för ickekommersiell forskning och för undervisning. Överföring av upphovsrätten vid en senare tidpunkt kan inte upphäva detta tillstånd. All annan användning av dokumentet kräver upphovsmannens medgivande. För att garantera äktheten, säkerheten och tillgängligheten finns det lösningar av teknisk och administrativ art. Upphovsmannens ideella rätt innefattar rätt att bli nämnd som upphovsman i den omfattning som god sed kräver vid användning av dokumentet på ovan beskrivna sätt samt skydd mot att dokumentet ändras eller presenteras i sådan form eller i sådant sammanhang som är kränkande för upphovsmannens litterära eller konstnärliga anseende eller egenart. För ytterligare information om Linköping University Electronic Press se förlagets hemsida http://www.ep.liu.se/

The publishers will keep this document online on the Internet - or its possible replacement - for a considerable time from the date of publication barring exceptional circumstances. The online availability of the document implies a permanent permission for anyone to read, to download, to print out single copies for your own use and to use it unchanged for any non-commercial research and educational purpose. Subsequent transfers of copyright cannot revoke this permission. All other uses of the document are conditional on the consent of the copyright owner. The publisher has taken technical and administrative measures to assure authenticity, security and accessibility. According to intellectual property law the author has the right to be mentioned when his/her work is accessed as described above and to be protected against infringement. For additional information about the Linköping University Electronic Press and its procedures for publication and for assurance of document integrity, please refer to its WWW home page: http://www.ep.liu.se/

© Martin Jönsson Abstract Spotify wants to explore the possibilities of social gaming within their desktop client. Thanks to their Spotify Apps API it is possible to build applications that integrate with the Spotify library while using modern web technologies. This thesis work consists of exploring what is possible using the Spotify App API and the most modern web technologies available. The main theme and goal of the Spotify App is to engage users in a social context. Creating a quiz application, which users can play along with using their smartphones, does this. This is targeted towards people being in the same room, sharing the experience. There is also a focus on usability and both group discussions and think-aloud interviews have been conducted regarding the development and design of the product.

1 Acknowledgements

I am very grateful to Spotify for this opportunity, thanks to all the people there for making me feel at home. Many thanks to Pierangelo Dell’Acqua and Camilla Forsell for help and advice at the university. A big thank you to all my friends who helped out with this thesis work in one way or another, be that testing it, proofreading or buying me a beer when I have had a rough day. Thanks to my family for all their support, kind words and encouragement. Most of all, my utmost thanks and love to my wonderful Johanna.

2 Table of Contents 1 Introduction 5 1.1 About Spotify ...... 5 1.2 Background...... 5 1.3 Purpose ...... 5 1.4 Sources ...... 6 1.5 Thesisoutline...... 6 1.6 Limitations ...... 6 2 Theoretical background 7 2.1 What is a Spotify application? ...... 7 2.2 Social application in Spotify ...... 7 2.3 Social games outside Spotify ...... 8 2.4 Social gaming ...... 8 2.5 Current technology ...... 9 2.6 Usability...... 9 2.7 Lo-Fi prototype ...... 10 2.8 Usability at Spotify ...... 10 2.9 Think-aloud Interviews ...... 11 2.10 Group discussions ...... 12 3 Technical background 13 3.1 Real-time communication ...... 13 3.1.1 HTTP long polling ...... 13 3.1.2 HTTP streaming ...... 13 3.2 HTML5 WebSockets ...... 14 3.2.1 A comparison between HTTP long polling and WebSockets 15 3.3 JavaScript...... 16 3.4 Node.js ...... 17 3.5 HyperText Markup Language ...... 17 3.6 Cascading Style Sheets (CSS) ...... 17 3.7 JavaScript Object Notation ...... 18 3.8 MongoDB ...... 18 3.9 Chromium Embedded Framework ...... 19 4 Implementation 20 4.1 Generaloverview ...... 20 4.2 Theserver...... 20 4.2.1 Game logics ...... 21 4.2.2 MongoDB ...... 22 4.3 The web application for smartphones ...... 22 4.3.1 CSS ...... 22 4.3.2 JavaScript ...... 23 4.3.3 Socket.IO ...... 23 4.3.4 Facebook Authentication ...... 23 4.4 The Spotify application ...... 24 4.4.1 CSS ...... 27 4.4.2 JavaScript ...... 28 4.5 Usability ...... 28 4.5.1 Lo-Fi prototype ...... 28 4.5.2 Think-aloud Interviews ...... 29 4.5.3 Group discussion ...... 30 5 Conclusion and Discussion 31 6 Future work 33

3 Acronyms An alphabetical list of the acronyms used in the report: • API Application Programming Interface • BSON Binary JavaScript Object Notation • CEF Chromium Embedded Framework • CSS Cascading Style Sheets • DRY Don’t Repeat Yourself • HTML HyperText Markup Language • JSON JavaScript Object Notation • PaaS Platform as a Service • RDBMS Relational Database Management Systems • SMACSS Scalable and Modular Architecture for CSS • W3C The World Wide Web Consortium • WHATWG The Web Hypertext Application Technology Working Group

4 1 Introduction This thesis describes a master’s thesis project carried out at Spotify and the Department of Technology and Science at Link¨oping University. The aim of the project is to develop an application within the Spotify desktop client that encourages social gaming and focus on usability within the application. This chapter presents background about Spotify and the thesis work itself, why it was done and what kind of limitations was put on it. The outline of the thesis will also be presented.

1.1 About Spotify This is how Spotify describes its service. ”Spotify is an award-winning music service oﬀering a legal and su- perior quality alternative to music piracy. Spotify provides instant access to whatever music you want, whenever and wherever you want it, through a simple, clean and quick to use platform via an ad-supported, free-to-the-user service and a paid subscription service. With access to millions of songs through your computer, on your mobile and beyond, Spotify makes it easier than ever to play and share music legally.” [1]

1.2 Background Spotify launched their application platform in late 2011 and are looking into the possibilities of social gaming through the client. The concept of social gaming is when people play a game together in a group, may that be together in a room or online. In this thesis work, the aspect of social gaming that will be discussed refers to when people gather in a room to play a video game. What kind of social game should be created that ﬁts this purpose? How has other solved it? A huge advantage of the new application platform is the new web technologies that are bundled within the client, such as Geolocation, WebGL and WebSockets. An important aspect of games in a social context is that a lot of people should have the possibility to be engaged in the game, even if it is only for a short while at a time. A good example is the popular video game Sing Star. Only two people can play each time, but every song is around three minutes or less, which makes it easy for a crowd of people to switch around so that everyone can play. Using the Spotify application platform as a service to a game is very beneﬁ- cial since you get access to a huge library of music. It also has support for very modern web technologies, which can be used to create very functional and impressive applications.

1.3 Purpose The purpose of this master thesis is to investigate how Spotify can integrate a social game into their client. Furthermore, to implement a social game of choice. The game will be chosen together with the supervisor at Spotify, while going through different ideas and deciding on the one that best fits the task. It is important it fulfills its purpose both in a technical aspect as well as it engages users in playing. Therefore there will be a large focus on usability and on finding

5 best practices for user ﬂows. There will also be continuous usability-tests during the entire process.

1.4 Sources Most of the technical sources used are from The World Wide Web Consortium (W3C), which is an international community where member organizations, a full-time staﬀ and the public work together to develop Web Standards. The mission of W3C is to lead the Web to its full potential. They work together with The Web Hypertext Application Technology Working Group (WHATWG), which was founded by individuals from Apple, the Mozilla Foundation and Opera Software. It is a similar community, which is interested in evolving HTML. Both these sources are very trustworthy since they are the ones, which deﬁne the Web. Other sources are articles or books, either from universities or online but all with recognized authors.

1.5 Thesis outline Chapter 1 includes background and purpose of the thesis work. In chapter 2, the preparatory work that was done before the actual implementation will be discussed. All technologies used will be explained to the reader in chapter 3. In chapter 4, the method and how the implementation was made will be presented. At last, in chapter 5, a result will be presented and discussed.

1.6 Limitations The only limitation in place is that the part of the game that will be in the Spotify client, must be written with JavaScript, HTML and CSS. This is because the Spotify client only supports JavaScript and the API, which will be used, is in JavaScript. In regard to real-time communication, this thesis work will focus on getting a working product and not so much looking into eventual scaling issues the game will face in the future if a large amount of users are to play it at the same time, causing a lot of simultaneous connections.

6 2 Theoretical background This chapter goes through the preparatory studies conducted in the thesis work. There is discussion about how Spotify applications work, thoughts about other kinds of similar games to the one that will be created and what makes them special. An analysis of what kind of usability features should be looked at and how interaction will be done in the application. Also, a walk-through of the technology that exists today that makes the game possible to do.

2.1 What is a Spotify application? A Spotify application is a small program that can be run inside the desktop client. An application has access to a certain set of features in the Spotify client. To name a few, it has access to all the music in Spotify, the library of the current user and the ability to create, share and edit playlists. Spotify currently has a lot of diﬀerent applications within the client, most of them are created by other companies. One of the most popular is an application called TuneWiki, which can be seen in ﬁgure 1. In this application the user can see and follow along with the lyrics of the current playing track.

Figure 1: The TuneWiki application in Spotify.

Having a lot of diﬀerent interfaces of many applications makes the overall usability of the Spotify desktop quite diﬃcult. Because of this Spotify has created Integration Guidelines [2] and Design Guidelines [3]. This means the application that will be created in this thesis must follow these guidelines. This will be a big part of the design process and motivate a lot of the decisions.

2.2 Social application in Spotify There are some social applications in Spotify and it is interesting to look at what kind of social interaction appears in them. The most popular social application in Spotify today is without a doubt an application called Soundrop, which can be seen in ﬁgure 2. This application lets users join diﬀerent rooms and listen to the same tracks at the same time, while chatting about them. The users can also recommend new tracks to be added to the list. Then the other users can vote on these tracks if they want to hear them next in the playlist, which is a very social experience.

7 Figure 2: The Soundrop application in Spotify.

2.3 Social games outside Spotify Some of the more popular games that are usually played with a group of people are Guitar Hero and Sing Star. In Guitar Hero, the players have plastic instruments which acts as controllers. The purpose of the game is to tap on the instrument at the same time as the track displays on the screen, generating the feeling that the player is actually playing along with the track. In Sing Star the players have a similar game controller, instead of an instrument the players use microphones and sing along with tracks. Based on how they sing, the players receive points. Both of these games include some kind of controller. Almost every other gaming platform utilizes some kind of physical controller. For example, to play Wii tennis, the player uses the Wii Remote as a racket, which is intuitive for the player. It is the same intuitiveness that makes Guitar Hero and Sing Star popular. These games however have a very speciﬁc theme. If a game were to be developed with a very speciﬁc theme, the best control would be something created for its purpose. If one would want to engage a bigger amount of users at the same time, an interesting approach can be found in Design Guidelines for Classroom Multiplayer Presential Games [4]. This article discusses design guidelines for engaging a whole class in a learning game. In their game they use a host computer pro- jecting a game on a big screen, then each pupil have a controller in form of a mouse. With Spotify, the users are able to use the desktop client or the mobile client. This is a very big advantage since a lot of people already are very comfortable with using their smartphones and the mobile client. It is a natural step to use it as a controller.

2.4 Social gaming When it comes to social gaming, it can be described in multiple ways. The difficulty lies in defining what social means. Stenros et al defines social as a sliding scale based on the amount of social interaction that is possible while playing. According to Stenros et al it comes down to the number of players

8 that can participate at the same time, where the game might take place or who the spectators to the game are. At one end of the scale there is the single-player game that is played by the person who created it, therefore no-one else knows about the game and the creator is all alone playing it. On the other end there is a huge multiplayer game that everyone know about and participate in. Of course two extreme opposites. Stenros et al then continues to compare different games to each other, single-, two-, and multi-player games. Stenros et al conclude that to be able to define the sociability around a game, the games must be separated into these blocks. This is to be able to analytically study them and to deal with pitfalls such as politicking in multiplayer games. Stenros et al also found that single-player games are more social than they are given credit for and that massively multiplayer and social games are built on a feeling of co-existance even when the players are not interacting with each other.[5] Social games can of course take many different forms, everything from co- operative games that are shared on one screen to single-player games that are played online in large multiplayer universes. As Stenros et al concluded, these must be analyzed differently. In this thesis, the sociability part in social gaming will be defined by how users of the application interact with each other, while being in the same physical space.

2.5 Current technology There is some software allowing the user to use their smartphone as a game controller together with their computer [7]. However this forces the user to install separate software on the computer and the player have to be on the same network as the host computer. In multiplayer games over the Internet an important factor is speed. It is always important in any user-centered design, [6] but especially in games since actions need to mirror the behavior of the user. Therefore the communication between user and computer must be quite instantaneous for it to work properly. The modern technique, HTML5 WebSockets [10], is supported in the Spotify platform and allows for real-time communication between the user’s smartphone and the Spotify desktop client with very minimal bandwidth usage. HTML5 WebSockets was derived because of the need of bi-directional communication in the web browser. There are several old technologies to achieve the same eﬀect but they are more costly. These technologies will be discussed more in depth later on in this report.

2.6 Usability Usability is best explained according to ISO (International Organization for Standardization). ”ISO 9241-11 explains the benefits of measuring usability in terms of user performance and satisfaction. These are measured by the extent to which the intended goals of use are achieved, the resources that have to be expended to achieve the intended goals, and the extent to which the user finds the use of the product acceptable.” [11] ISO 9241-11 is a part of a bigger standard called ISO 9241 - ergonomic requirements for office work with visual display terminals (VDTs) The key values in part 11 are the key words, effectiveness, efficiency, and satisfaction. The key words are explained in the following way:

9 • Effectiveness Accuracy and completeness with which users achieve spec- ified goals. • Efficiency Resources expended in relation to the accuracy and completeness with which users achieve goals. • Satisfaction Freedom from discomfort, and positive attitudes towards the use of the product. ISO 9241-11 emphasizes that visual display terminal usability is dependent on the situation of use and that the level of usability achieved will depend on the specific situation in which a product is being used. When measuring different aspects of usability, they should be based on data, which reflect the results of users interacting with the product. It is possible to gather data by objective means, such as the measurement of output, of speed of working or of the occurrence of particular events. The data can also be collected from the subjective responses of the users expressing feelings, beliefs, attitudes or preferences [11]. The subjective data is very important when it comes to games, and users’ feelings connected to the game especially. Objective measures give direct indications of effectiveness and efficiency while subjective measures can be linked directly with satisfaction. Satisfaction in games can be measured by rating on scales such as discomfort experienced, liking for the product, satisfaction with produce use, or acceptabil- ity of the workload when carrying out different tasks, or the extent to which particular usability objectives have been met. Another way to measure satisfaction is to discuss the number of positive and negative comments recorded during use [11].

2.7 Lo-Fi prototype Lo-Fi prototyping is when the designer creates a very basic prototype often using only paper and pencils. This enables the designer to initiate user testing very early in the process. Even though it appears to be a simple type of prototyping this can actually provide a lot of useful feedback, which will result in a better end result. Another great beneﬁt with Lo-Fi prototyping is that it is very cheap and can save a lot of money in the later run. It also enables both designers and developers to easily exchange ideas very early in the development process so that they have the same understanding of the product they are developing.

2.8 Usability at Spotify These are comments from an interview together with Daniel Källbom, designer at Spotify. At Spotify there is no real design process for a product. It differs quite a lot depending on the scope of the product. With a larger scope such as the iPad application, which was released in the spring of 2012 (2012-05-02), there were extensive user testing. This is mainly because it was a brand new product that was very requested. This meant that the product needed to be of very high quality and well tested before release. With the Spotify iPad application, external people were taken in to test the application. During these meetings, the users were presented with different sce- narios or flows from Spotify, which the users had to go through. These tests and the users were video-recorded for future reference. There was also documenta- tion created to support decisions made throughout the design process.

10 During the beginning of a design process, it is mostly up to the designer in charge on how to begin. Some Spotify designers feel comfortable with paper and pen while others use software, such as Adobe Photoshop to create quick wireframes or sketches. Complete Lo-Fi prototypes are rarely created mainly because of the difficulties in getting relevant answers from test users. The design team at Spotify is quite small but is growing. In August 2011, there were only two designers and the design process was somewhat limited. Now, they are five designers and are able to keep most of the guidelines within the group. However, with the growing number of employees, the designers have started to create an UX/UI-library, which will help to keep the UX/UI consistent across all different platforms.

2.9 Think-aloud Interviews This type of cognitive interview comes from the psychological procedures described by Ericsson and Simon [19]. The term ”think-aloud” is used to describe this special type of interview in which the subjects are instructed to ”think aloud” as they answer questions. The interviewer asks a question and then takes notes about how the subject reaches an answer. The interviewer should not really intervene except with question such as ”Tell me what you are thinking”, when the subject pauses. A typical example of a think-aloud interview: INTERVIEWER (reading survey question to be tested): How many times have you talked to a doctor in the last 12 months?

SUBJECT: I guess that depends on what you mean when you say ”talked.” I talk to my neighbor, who is a doctor, but you probably don’t mean that. I go to my doctor about once a year, for a general check- up, so I would count that one. I’ve also probably been to some type of specialist a couple of more times in the past year - once to get a bad knee diagnosed, and I also saw an ENT about a chronic coughing thing, which I’m pretty sure was in the past year, although I wouldn’t swear to it. I’ve also talked to doctors several times when I brought my kids in to the pediatrician - I might assume that you don’t want that included, although I really can’t be sure. Also, I saw a chiropractor, but I don’t know if you’d consider that to be a doctor in the sense you mean. So, what I’m saying, overall, is that I guess I’m not sure what number to give you, mostly because I don’t know what you want. An important aspect to ”think-aloud” interviews is to prepare the subject in a good way. This generally involves careful training in the beginning of the interview. This training generally consists of a set of questions designed to let the subject answer in a way where they must think at the same time. An example of such a question: ”Try to visualize the place where you live, and think about how many windows there are in that place. As you count up the windows, tell me what you are seeing and thinking about.” There are certain advantages and disadvantages to this approach, which must be taken into account when conducting these types of interviews.

11 Advantages: • Freedom from interviewer-imposed bias: Because of the minimal contribution from the interviewer the risk of having the subject biased is minimal. • Minimal interviewer training requirements: The interviewer only needs little training or special expertise since he or she mainly reads survey questions and listens to the respondent talk. • Open-ended format: Because of the minimal interaction with the subject, they might provide information that is not anticipated by the interviewer. This information can then be used in the research. This works best if the subject is very outgoing and has experience on the topic discussed. Disadvantages: • Need for subject training: Since thinking aloud is very unusual for most people, the subject needs to be trained before undergoing the interview. • Subject resistance: Even though the subject undergoes training some people are not fit for think aloud interviews and are not capable of elab- orating their actions. • Tendency for the subject to stray from the task: Since the subject controls the discussion of the interview it is easy for a ”free associating” subject to stray from the task and spend time on irrelevant areas. This is difficult for the interviewer because they have to struggle to get the subject back into the task. • Bias in subject information processing: Some subjects may invest a large amount of mental effort into the questions since the think aloud process forces them to think. This might contaminate the actual answer to the question. If the subject can simply answer ”Yes”, ”No” or ”I agree” there is minimal contamination. This issue is however open to debate as there is no direct physiological measures, from either the cognitive interview or the usual survey interview [20].

2.10 Group discussions Individuals and groups behave differently when analyzing and reaching con- clusions, this has been shown in research within the fields of psychology and organization studies. Følstad [21] conducted a pilot study to see, given these differences, what the effect of group discussions would be. According to the study, a significant aspect of group discussions managed to identify new usability issues, but more importantly it managed to qualify the set of usability issues already identified by individuals. This kind of qualification through group discussion may be very valuable, especially if the system is in a development context with limited resources for redesign. Because of group discussions, low- importance problems can be removed and focus can be switched to what is really important. [21]

12 3 Technical background In the following chapter all the technical background that is relevant for this thesis work are described. This is to familiarize the reader with all the technologies used, why they are being used and a brief history on each technology.

3.1 Real-time communication As mentioned earlier, one of the most important aspects of a multiplayer game is to have a responsive and fast user interface. This means having interactions sent with enough speed that it appears to be in real-time. During the last couple of years there have been diﬀerent attempts mimicking real-time communication within the browser. In the standard HTTP model, a server cannot start a connection with a client or send an unrequested HTTP response to a client; therefore the server cannot push events to the clients. This is a problem, which is usually solved by let- ting the client request (poll) the server for new content. This is however not very bandwidth-friendly and it may reduce the responsiveness of the application [8]. As an attempt to make this situation friendlier, a few server-push programming mechanisms have been developed in the recent years, which are often grouped under the term ”Comet”-technologies. These mechanics allows the web server to send updates to the client without waiting for a poll request. This means that the server can send events to the client in a more timely manner without the pains of loosing responsiveness while the client opens and closes connections due to polling for updates. There are two server-push mechanisms that are the most common, these are HTTP long polling and HTTP streaming.

3.1.1 HTTP long polling The server keeps a request open for each event from the client, but only re- sponding when there are events to send. This way there is always a request to which the server can respond. When the server has ﬁnished sending an event, the client sends a new request, which will stay open until next time an event is sent. Worth noticing is that when it comes to a large message volume, long polling does not provide a signiﬁcant performance improvement over normal polling. It could also be worse, because long polling can spin out of control into a continuous loop of immediate polls [9].

3.1.2 HTTP streaming With HTTP streaming the server keeps an open connection all the time. Firstly, the client makes a request to the server and waits for a response. Then the server keeps the connection open and when an update is available it will push out the data to the client. The request never gets terminated. This technique is made possible by the fact that the server can send several pieces of data in the same response, without closing the connection in between. There are issues with HTTP streaming as well. The HTTP protocol allows for proxies, gateways etc. to be involved in the transmission between client and server, there is a possibility that these intermediaries will buﬀer responses

13 before actually sending it to the client. If there is some kind of intermediary, HTTP streaming will not work. On a perfect network the maximal latency of HTTP streaming is one network transit. However, the techniques used with HTTP streaming often involve JavaScript and DOM elements being filled with content for each message received. Therefore these elements must be cleared occasionally not to initiate memory problems within the browser, this forces the client to make a new request after a transmission has been closed, adding time to the maximal latency. There can also be issues with clients buffering data. If the response chunk contains JavaScript, there is no requirement in the browser to run the code before the whole response is received. A solution to this problem can be sending blocks of white space to achieve a buffer overflow, which will trigger the code [8].

3.2 HTML5 WebSockets Due to the desire for a bidirectional communication between server and client, the WebSocket Protocol and the WebSocket API were introduced and have been implemented in various browsers. The idea is to have a single TCP connection for traffic in both directions, instead of abusing the HTTP protocol. Conceptu- ally, WebSocket is a layer on top of TCP with some added features. The protocol consists of two parts: a handshake and the data transfer. The handshake means that the client sends a request to start a data transfer and the server answers with a confirmation. Algorithm 1 shows the first part of the handshake, from the client. Algorithm 2 shows the answer from the server, which confirms the handshake. After this is done, the data can be transferred freely between the client and the server.

Algorithm 1 The handshake from the client GET /chat HTTP/1.1 Host: server.example.com Upgrade: websocket Connection: Upgrade Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== Origin: http://example.com Sec-WebSocket-Protocol: chat, superchat Sec-WebSocket-Version: 13

Algorithm 2 The handshake from the server HTTP/1.1 101 Switching Protocols Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= Sec-WebSocket-Protocol: chat

When the handshake is successful, a two-way communication channel is opened where both sides, independently from each other, can send data. The data is sent in units referred to as ”messages”, where each is ”message” is composed of one or more frames. Each frame has a speciﬁc type, for example, there are types for textual data, binary data and control frames. The current WebSocket protocol [10], published in December 2011, deﬁnes six frame types and leaves ten reserved.

14 3.2.1 A comparison between HTTP long polling and WebSockets Header overhead is a big issue with long polling since every request and response is a complete HTTP message. This means that a full set of HTTP headers is being sent every time. This can have a huge impact on bandwidth if a large amount of messages are being sent. To understand how much better WebSockets are when it comes to saving bandwidth a comparison was made by Peter Lubbers and Frank Greco at Kaazing Corporation [8]. They created a JavaScript stock ticker web application and the server is polled for changes every second. In their example they used normal short polling since long polling would just result in a series of continuous polls. The HTTP headers (3 and 4) being sent are the same so it does not matter when it comes to measuring network throughput. With each request and response a total of 871 bytes were used. This is data that will never be used; it does not contain any interesting data for the application.

Algorithm 3 HTTP request header GET /PollingStock//PollingStock HTTP/1.1 Host: localhost:8080 User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.5) \\Gecko/20091102 Firefox/3.5.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-us Accept-Encoding: gzip,deflate Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7 Keep-Alive: 300 Connection: keep-alive Referer: http://www.example.com/PollingStock/ Cookie: showInheritedConstant=false; showInheritedProtectedConstant=false; showInheritedProperty=false; showInheritedProtectedProperty=false; showInheritedMethod=false; showInheritedProtectedMethod=false; showInheritedEvent=false; showInheritedStyle=false; showInheritedEffect=false

Algorithm 4 HTTP response header HTTP/1.x 200 OK X-Powered-By: Servlet/2.5 Server: Sun Java System Application Server 9.1_02 Content-Type: text/html;charset=UTF-8 Content-Length: 21 Date: Sat, 07 Nov 2009 00:32:46 GMT

To compare, three use cases were created and the network throughput was calculated on every case. The following is the network throughput for the polling. • Use case A: 1 000 clients polling every second: Network throughput is (871 · 1 000) = 871 000 bytes = 6 968 000 bits per second ( 6,6 Mbps) • Use case B: 10 000 clients polling every second: Network throughput is (871 · 10 000) = 8 710 000 bytes = 69 680 000 bits per second ( 66 Mbps) • Use case C: 100 000 clients polling every second: Network throughput is (871 · 100 000) = 87 100 000 bytes = 696 800 000 bits per second ( 665 Mbps) This is large amount of unnecessary network throughput. Each WebSocket

15 message has two bytes of overhead instead of 871 bytes, which gives the following result. • Use case A: 1 000 clients polling every second: Network throughput is (2 · 1 000) = 2 000 bytes = 16 000 bits per second ( 0.015 Mbps) • Use case B: 10 000 clients polling every second: Network throughput is (2 · 10 000) = 20 000 bytes = 160 000 bits per second ( 0.153 Mbps) • Use case C: 100 000 clients polling every second: Network throughput is (2 · 100 000) = 200 000 bytes = 1 600 000 bits per second ( 1.526 Mbps) This is a huge difference in network throughput and it is illustrated in figure 3. Worth noting is that figure 3 is only a comparison of the network throughput; issues with long polling also include maximal latency, resources being allocated and degradation in performance [8].

Figure 3: Comparison of the network throughput [9].

3.3 JavaScript JavaScript is the programming language of the web browser, it is supported in all major browsers; Chrome, Firefox and Internet Explorer to name a few. Because of its association with the browser it is one of the most popular programming languages in the world. But at the same time it is also one of the most despised programming languages. This is primarily because of unfair blame. The API of the browser, the DOM is quite awful and would be painful to work with in any language. The great thing about JavaScript is that it is possible to get work without knowing much about it, or even programming in general. The programmer does not need any server or setting up a special environment. All that is needed is an editor and a browser. This means that the startup time is minimal. JavaScript is even better when the user knows what to do and has an enor- mous expressive power. Worth noticing is also that the standard that deﬁnes JavaScript is The ECMAScript Programming Language [12].

16 3.4 Node.js Node.js is a way of running JavaScript outside the web browser, particularly on web servers. There are several great features about Node.js that make this interesting. Node is a wrapper around the high-performance V8 JavaScript runtime from the Google Chrome browser. Node tunes V8 to be better in contexts other than in the browser, mostly by providing additional APIs that are optimized for speciﬁc use cases. For example, manipulation of binary data in a server context is often necessary, JavaScript and V8 however poorly support this. Hence, Node has a class called Buﬀer that provides easy manipulation of binary data. Supporting JavaScript on the server is a powerful feature, especially since you can share code between server and browser. Also due to the increasing com- plexity of web applications, the more code that can be shared means that the costs of creating these complex applications can be reduced [13].

3.5 HyperText Markup Language HTML is the World Wide Web’s markup language. It was originally designed as a language for semantically describing scientiﬁc documents but has since developed into describe a number of other types of documents as well.

Algorithm 5 A basic HTML document. Sample page

Sample page

This is a simple sample.

HTML documents consists of a tree of elements and texts. A start tag and an end tag denote each element in the source. There are also some elements that only require a start tag. Elements can have attributes which control how they work, for example, a hyperlink has an attribute of href, which describes which link the hyperlink should go to. The newest version of HTML, HTML5, features a lot of new modern technologies, such as WebSockets, but also things like Canvas, which allows the user to render dynamic graphics on the ﬂy or media elements like video and audio which means the user can watch and listen to media directly in the browser without support of third-party plugins such as Adobe Flash [14].

3.6 Cascading Style Sheets (CSS) Whilst HTML structure the document and gives semantic meaning to each element, CSS gives the browser instructions on how to display elements. This involves size, coloring and position etc. This is done following a system of rules; these rules tell which speciﬁc elements should have styling.

17 Algorithm 6 A basic CSS rule. h1 { color: #000; font-size: 24px; }

The example above tells the browser to ﬁnd all h1-elements in the HTML, set their color to #000 (the hexadecimal color code for black) and set the size of the font to 24 pixels. CSS is not a programming language like JavaScript or a markup language such as HTML, there is actually nothing else that it can be compared to. CSS was invented to separate the presentation and structure in web development. Because the web environment changes so often it is more beneﬁcial to have it separated [15]. The newest version of CSS, CSS3, features some styling possibilities that have been requested for a long time, for instance, the possibility to have rounded corners or a drop shadow on elements. It also allows more advance styling, such as animations and transformations in a 3D space.

3.7 JavaScript Object Notation JSON is a data-interchange format, which is very lightweight. It is very human- friendly and very easy to read and write. It is also very easy for machines to parse and generate. The format is based on a subset of the JavaScript programming language. It is built on two structures, ﬁrstly, a collection of name/value pairs, in various languages this is referred to as an object. Secondly, an ordered list of values, in most languages this is referred to as an array, vector, list or sequence. Since these are universal data structures, virtually all programming languages support them and it makes sense having a data format that is interchangeable between languages [16].

3.8 MongoDB MongoDB (derived from the word humongous) is a different kind of database in comparison with Relational Database Management Systems (RDBMS), which is the most popular form of database. In mongoDB there are no concepts of tables, schemas, SQL or rows. MongoDB is created from the idea that one size does not fit all which is generally the biggest trouble in RDBMS, especially when there is data that varies, or data types that varies. Instead of creating a database that tries to do everything for everyone the mongoDB team decided to create a database that worked with documents instead of rows, is blazingly fast, massively scalable and easy to use. It is however, as most databases, differently good in different situations. For example, it lacks transaction support, which means you probably would not use it for banking systems. However, it is perfect for applications in which you need to store complex data, access data fast and scale easily. It is quite popular to create a hybrid solution with an RDBMS and mongoDB. In addition to being easy to work with it, mongoDB can also run nearly anywhere you want it. It features downloads for Linux, Mac, Windows and Solaris. It also has various unofficial versions that enable you to install it on Fedora or CentOS, among other platforms.

18 An RDBMS is very structured, with several tables that store individual pieces. MongoDB, on the other hand, keeps everything in a single document. It is like JSON in that sense and this provides a rich and expressive way of storing data. At ﬁrst glance, one would probably assume that mongoDB uses JSON for its data, but it actually uses BSON (Binary-JSON), which adds a couple of features, including the ability to add types for handling binary data. Improving performance with a relational database is pretty straightforward; you buy a bigger and faster server. This works quite nicely until the day when there is no longer a bigger nor faster server. When you reach this point, the only solution is to spread out over several servers, and this is when an RDBMS stumbles. For example, with MySQL or PostgresSQL, two of the most popular RDBMSs it is not possible to run a single database on two servers, where both servers can both read and write data. When you query your database, it has to ﬁnd all necessary data and link it all together. RDBMS solutions are very clever and have clever ways of improving performance, but it relies on having the complete picture of data available. This is why it stumbles when half your data is on another server. If you are having a small database that gets a lot of requests and you need to share the workload you also get another problem. You need to ensure that all data written to one server is available on the other one. It gets especially tricky when updates occur on two separate masters simultaneously. MongoDB solves these problems in a very easy way, it avoids them completely. Since the data is stored in BSON documents, the data is self-contained. Al- though similar documents are stored together, each document is not made up of relationships, this means that all you need is in one place. Because queries in mongoDB look for keys and values in a document, this data can easily be spread across several servers [17].

3.9 Chromium Embedded Framework The Chromium Embedded Framework is an open source project founded by Marshall Greenblatt in 2008. The purpose is to develop a Web browser control based on the Google Chromium project. It supports a range of programming languages and operating systems and can easily be integrated into applications. The host application can control resource loading, navigation, context menus and more, while taking advantage of the same performance and HTML5 technologies available in the Google Chrome Web browser [18]. This is what the Spotify desktop client uses to provide the API functionality to its third party developers. This also allows Spotify to more quickly develop features across diﬀerent teams in the company. It is also a great help when programming the user interface since developers can use a language speciﬁcally designed for layout.

19 4 Implementation In this chapter everything related to the implementation of the Spotify application will be discussed. Firstly, what kind of social game the application will be, then how it will be implemented technically.

4.1 General overview The game idea is that users can start a music-quiz from a quiz library, which is user-generated. The idea is to have the Spotify application on a big screen (TV or projector) in front of a crowd of people, then each participant will sit in front of it and interact with each question. With the quiz being user-generated, it means that a user can create a speciﬁc quiz for a special occasion which other can later also play. When the user has chosen a quiz from the library, the Spotify application presents a waiting room. This is the stage before the quiz starts. Now, the users who want to join will have to use their smartphones to join the waiting room. When enough participants have joined it is up to initiator of the quiz to start. The game is called Quiz Jitsu. The reason behind choosing a music-quiz game was because it is a way to engage many users at the same time. Each question is maximum 30 seconds, which leads to quick interaction, and users do not get bored. The solution with people using their smartphone as a controller really promotes social gaming since people can sit next to each other, talk about the question and at the same time see the results on the big screen. It also presented a technical diﬃcult problem when it comes to communicating between smartphone and computer. The game that was implemented features three key elements which all have different problems and important aspects to look at. Firstly, there is the server, which holds all the game logic and functions like a mediator between the other two elements, the desktop Spotify application and the smartphone web application. All the communication between the smartphone and the Spotify application goes through the server. An example, when the user answers a question in the web application, the answer is sent to the server for answer evaluation, point setting and then a message gets sent to the Spotify application noting that the user answered a question. All communication is being done through HTML5 WebSockets, where available, if not, the Socket.IO framework will fall back to using older technologies. This only happens when older smartphones that do not support WebSockets are used. Spotify however, will always support it.

4.2 The server The server is written using Node.js and consists of one HTTP server that serves the web application to the client. Attached to that is a Socket.IO-server. A mongodb database is also running on the server. The web development framework is Express, which is a high performance framework and also one of the most popular frameworks for Node.js [22]. The reason behind choosing Express is that it has been properly battle-tested and is a very popular among Node.js- developers. It currently (2012-05-14) has 6218 watchers and 615 forks on github [23]. Express has the ability for the developer to configure different settings for development and production, which is very nifty. For instance, in this application, while in development mode, the log levels are detailed and nothing is minified. In production, log levels are set to minimum and JavaScript and CSS is con-

20 catenated and minified. In this project a CSS preprocessor is being used and Express allows middleware that will compile and do alterations to the code. A good example is that the middleware can base64-encode images into the CSS document, minimizing the number of requests to the server, creating a faster load time for the user. Development was made locally, which meant running the server locally and not being able to access it from the outside. When the application needed testing it had to be deployed to an external server. During the first portion of the thesis work a Platform as a Service (PaaS) called Nodejitsu was used. This is a really great service, which allows the developer to deploy an application without having to think about setting up a server and production environment. The developer never has to connect to the server but can instead deploy from the command line, locally. Nodejitsu is very new and are currently in beta. An invitation was received after explaining the situation to the people behind the service; the people were very friendly and supportive. There is however limitations to this service currently. The biggest one in aspect to this project is that they currently only have servers in the US. This is quite critical when it comes to real-time communication. The delay is very obvious while using the application. It worked for easy testing but not running in production. Because of the notable delay, a normal server was bought and configured. The hosting company Linode was chosen because of good recommendations from people at Spotify. The server is now hosted in London, which was a great improvement in latency. The server runs Ubuntu 12.04 and is configured in such a way that the developer can easily deploy code locally. All source code is hosted at a private repository at bitbucket.org. A specific user was created on the server called deploy with only access to pull down the repository and start, restart and stop node processes. When the developer chooses to deploy, a script is run locally which will ssh onto the server with the deploy user and do the following actions. It will start with pulling down the latest version of the repository, moving the current running application into a history folder (keeping it for emergency reverts), deploying the latest version, install any new Node.js packages, run a few tests to make sure the server can start properly and after those tests pass it will start the server gracefully which means the downtime is almost non-existent.

4.2.1 Game logics All the game logics are on the server. This means that the client and the Spotify application can reconnect to a quiz if they happen to disconnect. This is mainly a decision made based on the fact that the communication technologies can fail and the ability to preserve a game involving a large amount of people should be in place. A Player class makes up each player, a Host class makes up each Spotify application host. Each quiz game is made up of a Quiz class, which in turn contains one Host and x Players and acts as a mediator. On top of this there is a Game class that holds all the active quizzes and make sure they do not conﬂict. In the Host and Player classes, the conﬁgurations for the connected sockets are established. All available events are taken care of and routed to do the correct action.

21 4.2.2 MongoDB To be able to store all the quizzes a database is used, in this case mongoDB. It is very fast and easy to set up, especially if you are already working in JavaScript. The data you deal with is basically identical to JSON and that is a known syntax for any JavaScript-developer.

4.3 The web application for smartphones When the user starts the web application, they get presented with a welcome screen and invitation to login using Facebook. Once the user logs in, the application checks the Facebook status, gets the user’s data and presents a list of the available rooms to join. If there are no available rooms that will be the message to the user. The whole procedure can be seen in ﬁgure 4.

Figure 4: The login procedure on the smartphone.

4.3.1 CSS When developing for smartphones the developer needs to take in account a large amount of different browsers and support for properties will be very different. In order to streamline this development; the CSS preprocessor Stylus is used in this application [24]. This, along with nib, which are extensions for Stylus, allow the developer to ignore browser-specific issues, like prefixing new properties. New CSS properties are often implemented in test-mode while the official standard is being formed. This means that several browsers need to implement their own version of the property and these might not behave the same way until the standard is finished. Therefore properties are prefixed to enable developers to activate new properties before the standard is done. This causes a bit of a problem because forming the standard often takes much longer than expected and so the browsers have support for new properties a long time but cannot use an official property name. An example of prefixing properties when using CSS3 transitions can be seen in algorithm 7. To be able to skip all this repeating code and to keep everything DRY (Don’t Repeat Yourself), the developer can use a preprocessor. Then, the developer only has to write the standard form in CSS and then the preprocessor parses the code and generates the snippet above.

22 Algorithm 7 CSS3 property preﬁxed to enable support in several browsers. -webkit-transition: all; -moz-transition: all; -ms-transition: all; -o-transition: all; transition: all;

4.3.2 JavaScript At first, jQuery was used in this project to ensure compatibility over several smartphone platforms. This is a safe bet since jQuery is heavily battle-tested and is known to work on a lot of different platforms. The biggest drawback with using jQuery is the large overhead, which is really bad when it comes to mobile surfing, since speed is rather limited. This causes a situation where jQuery is both loved and hated. In this project, just to give an example, accessing data- attributes in pure JavaScript returned an error on the Android device used in testing, but using the data support in jQuery made it work. When most of the client-side code was finished, optimization and page speed was the main focus of interest. Analyzing this, the overhead that jQuery had, was very large in comparison. After looking into possible cross browser problems, the client-side code was rewritten into pure JavaScript, saving 92 KB in loaded resources. The entire client-side currently loads in at 81 KB, which meant by removing jQuery over half of the loaded resources were removed. The JavaScript itself went down from 100 KB to 10 KB.

4.3.3 Socket.IO During development there was a bug occurring when authenticating with Face- book, this caused Mobile Safari on iPhone to crash. This did not happen every time but enough times to be annoying. The problem seemed to appear when the end user authenticated with Facebook without having a cookie set, however, not every time, which was very strange. Later on, there were some ideas about Mobile Safari having troubles with WebSockets, which was quite correct. The issue occurred for other people about a year ago (May, 2011), but no solution could be found until two months ago (March, 2012). Mobile Safari together with Socket.IO appeared to have a problem maintaining an open socket while navigating to a diﬀerent tab for authenticating, creating a crash when returning to the original tab [25]. Disconnecting the websocket connection when the user went to the Facebook authentication and reconnecting once the user was back to the application solved the bug.

4.3.4 Facebook Authentication The decision to use Facebook authentication in the client web application was taken quite early in the development process. This feature was discussed quite heavily. The pros of having Facebook authentication are several. Firstly, it allows the quiz to display images of the participants which allows the users to connect to the game in a diﬀerent way than if the quiz were to use comical avatars or something similar. It is also beneﬁcial in a business point of view since all the users that will ever play the game will be added to the Facebook application. It can also add features to the game, for instance, befriend people through Facebook that you met while playing the game.

23 The biggest drawback to using Facebook authentication is that it adds additional steps to the process of starting to play. The user is required to log in and install the application. Facebook has created a very streamline process for this so it goes pretty quickly. This is also only necessary the ﬁrst time the user wants to play because after that, all the necessary information get stored to quickly log them in again in case of a disconnect. In the end it was decided to go with Facebook authentication because of the major improvements it adds to the game and also the fact that it opens up for features in the future.

4.4 The Spotify application The application is written in HTML, CSS and JavaScript. Thanks to Chromium Embedded Framework (CEF), it can utilize the latest technologies within these languages. One of the advantages with this is that CSS3 animations and transitions can be used heavily. All animations within the app are pure CSS3, which in normal web development for browsers, would never work across all major browsers. CEF is also the reason that HTML5 WebSockets can be used in the Spotify client.

Figure 5: The ﬁrst view of the game.

24 When the user starts the quiz, a menu made out of the current quizzes in the database is presented which can be seen in ﬁgure 6. The user can also choose to create an own quiz.

Figure 6: The menu within the game.

Once the user chooses a quiz, the user actually initiate a game and a waiting room appears which can be seen in ﬁgure 7. Now it is time for the participants to join the room (which gets a randomized four letter name) by following the instructions on the screen.

Figure 7: The waiting room with players connected.

When the host starts the quiz, the first question appears. At the same time, the available answers get sent to all the participants, this can be seen in figure 8. When the users have answered the question, their avatars appear at the timeline in the order they answered, the timeline is decreasing as the track plays. The answers have different colours, this was not the case on one of the first iterations of the game. It was quickly pointed out that it was difficult to connect what the user read on the big screen to the smartphone, therefore colours were added as a mean of identifying the answer more quickly on the smartphone.

25 Figure 8: Question in the Spotify application and on the smartphone.

Once the timeline is empty, the correct answer gets presented and the users get points based on if they were correct and how fast they were when answering, this can be seen in ﬁgure 9.

Figure 9: Points dealt on a question.

When the round is over the score gets presented both in the Spotify application and on each of the users’ smartphones, which can be seen in ﬁgure 10.

Figure 10: The ﬁnal score when the round is over.

26 If the user wants to create their own quiz, there is an option in the menu that allows them to do that. Once inside, the user gets presented with an input to fill out the theme of the quiz. Then the user has to add questions to the quiz. In each question the user has to figure out a question and find a track to go with that question (which can be seen in figure 11). Once the user has found a track they can start listening to it and fill out the correct answer (and some false ones). This procedure can be seen in figure 12.

Figure 11: When a user searches for a track while creating a quiz.

Figure 12: When a user has ﬁlled in a question while creating a quiz.

4.4.1 CSS Because of diﬀerent views and UI elements in the Spotify application compared to the smartphone application, a method of structuring the CSS was implemented. This method is called SMACSS, which mean Scalable and Modular Architecture for CSS. It is a style guide on how to write CSS in projects to have it scale easily and keeping components modular. This reasoning is applied in this project and helps a lot in developing future features.

27 This is a better way of working with CSS, especially in projects that are large and will grow. However, it works equally well for smaller projects. At the core of SMACSS is categorization, by categorizing CSS rules; patterns appear which in turn defines better practices around each of them. In SMACSS there are five different types of categories. 1. Base 2. Layout 3. Module 4. State 5. Theme Each category has certain guidelines that should be applied to it, and the purpose of categorizing in this way is to find patterns and code them, to avoid repetition. Less repetition makes the code easier to maintain and there is a greater consistency in the user experience [26].

4.4.2 JavaScript The JavaScript takes advantage of the Spotify App API, when manipulating playback, searching for tracks or displaying artwork. Thanks to the API, a developer can get access to the entire Spotify library and do actions, which were before only available internally for Spotify. Between the services that transfer or modify the data and the API there is a bridge. This bridge makes sure the correct services sends and receives commands from the API. The application uses the template engine slab to render templates. Slab is a templating engine for JavaScript, written by Mark Obcena, an employee at Spotify [27]. This allows the developer to separate views from logics. This makes developing much easier, especially when it comes to building views based on data that can only be achieved via JavaScript. Spotify has their own set of utility functions that are available to third party developers. These are functions that are used quite commonly and therefore they are gathered in a utility-framework, these functions involve easy access to elements or array-speciﬁc functions.

4.5 Usability Throughout the entire thesis there was a large focus on usability, therefore the application was tested continuously using think-aloud interviews and group discussions. This was to create an understanding of the different user flows within the application and to fix things that were broken from a usability point of view.

4.5.1 Lo-Fi prototype In the beginning of this project Lo-Fi prototypes were created. It started with quite a lot of sketching with different layouts, to be able to find a direction to go with. An early Lo-Fi prototype, which can be seen in figure 13, was created for the smartphone. At this stage the game idea was not related to quizzes. The photo features different kind of dialogs and views.

28 Figure 13: Early Lo-Fi prototypes.

A great benefit of the Lo-Fi prototype is that the application could evolve from comparing different sketches and dialogs, whilst figuring out which ones would work best.

4.5.2 Think-aloud Interviews Interviews were also conducted with a focus in a specific section of the application, the quiz creation part. Five different users where interviewed and were given the task of creating a quiz that had one question in it. Instructions were given to the users to speak their mind and try to explain all thoughts they had. The users were quite tech-savvy which was not ideal for testing purposes, but it still gave some very valid points. After the task was completed the users were asked questions to follow up on the task. Firstly they were asked to name three good things about the process, this often resulted in quite similar answers. Secondly, they were asked to name three bad things, this resulted in more diverse answers. They were also instructed to give three examples of ways to improve the application. During all interviews the audio was recorded for later analysis. Notes were also taken throughout the process to document what the interviewee said and if there were any physical notations that the audio could not pick up. At first the interface of the application in the interviews were very basic, not much effort were put on design at this stage, which most of the interviewees mentioned. This was a conscious choice. This motivated how to design further down the line. For example, in the beginning there were two buttons next to each other, ”Play” and ”Create”. This caused a lot of confusion among the interviewees so the choice was made to incorporate the create button as a command within the application. A good example of how the application changed after an interview is how the saved questions were presented. To quote an interviewee: The only kind of evidence of the question that I’ve done, is this little kind of icon there and it just took me like a second to be like right, ok, yeah my question is saved, I assume, because I can see the cover art of the song I chose. It just took a bit of time and I was like ”Where’s my question?” At first the only indication of a saved question was the cover of the associated track. The interviewees did not understand that this was clickable or at first

29 even, what it was for. After a few iterations the questions became very clearly shown, they became more clickable and easier to interact with. This is a problem that one could have solved in numerous ways, but because of the interviews a more conscious iteration on this could be made. Throughout all the interviews one of the key aspect, which was important, was the matter of speed. Especially when it came to searching for tracks, almost all interviewees felt that the experience went quickly and they got what they needed fast.

4.5.3 Group discussion During the process of developing this application, the application was tested in large groups of users. It was tested three times with the entire web developer guild, which was around 15 users at the time. It was also tested in another environment, with friends that were less knowledgeable in the technology. In these sessions the amount of users were from three users to five users depending on the session. In all sessions, the environment in which the game was played in was very similar to its actual future environment. There were different aspects of the application that got discussed and iterated. For example, in one of the first versions of the application, the big screen only showed the scoring of the participants in the game. This was a big mistake since everyone playing the game just kept looking down on his or her smartphones, making the social aspect of the game very bad. As a first attempt to solve this issue, the question and answers were added to the big screen. However, this turned out not to help, since the participants still had the option to look down on the smartphone, read the question and answer there, which most did. Hence, the solution was to only show answers on the smartphone, forcing people to look up at the big screen. This increased the activity between participants and the focus was lifted off away from the smartphone. Another part of the application that was iterated after group discussions was how to present the score and the rank in a good way. At first it was made as a list, which between each question re-ordered the participants in regard to points. This was quite effectful and a nice feature, but made a lot of the participants appear beneath the fold, making their experience very bad. This was solved by turning the list view into a grid view, removing the names of the players also saved a lot of space. An addition that increased social behavior was the addition of a timeline on which the avatars of the players appeared in their answering order. This created a race-feeling, which resulted in a lot of laughs and conversation. This proved to be a very efficient way of testing since the amount of input was very vast, and discussion occurred on how one could improve functionality and the application in general. Especially when it came to prioritization of usability issues, which goes hand in hand with Følstad’s study [21]. In conclusion, a lot of major usability issues, but also minor, got caught and could be evaluated because of group discussions. In my opinion, and in regards that the purpose of the application was to have a social game, the group discussions helped immensely.

30 5 Conclusion and Discussion The result of the project is a fully functional Spotify application, which allows users to come together around Spotify in a social way. The purpose of this thesis was to investigate how Spotify could integrate a social game in their client and implement a social game of choice. It was also important that the game fulfills its purpose both in a technical aspect as well as it engages users in playing. This goal has been achieved by creating an application, which has been iterated over numerous time with the help of group discussions and think-aloud interviews. The technical solution is very modern and works well since it enables a large audience to play together, making it a very social game. It ties very nicely with Spotify’s app platform, utilizing the latest web technologies. The game also iterated into something that for each iteration increased the social engagement between the people playing, by them interacting and talking with each other more. In regards to the scope of this thesis, one could have focused more intensely on usability, which would have rendered an application with less features, perhaps not even playable. One could have also gone the other way creating a big complex application with community features and much more (but with perhaps bad usability). I believe the created application landed somewhere in between. There are many difficult technical problem that were solved and compared to the first versions, it has greatly improved when it comes to usability. It was very interesting to start at a clean slate, and iterate quickly to see where one would land. In retrospect there are some features that did not need the time they took. For instance, creating all animations in CSS is a technically difficult problem, but quite irrelevant to the finished product, this is nothing a user of the system will know or even care about (unless they are a CSS developer). A better approach would be to make animations as easy as possible and then improve in the end. In regards to usability a good approach would be to have reoccuring interviews with set goals, to work on a certain aspect one week, interview in regards to it and then iterate. I think the development would have gone faster and it would have been a good way to focus on set tasks instead of many at the same time. This thesis work is seen as a proof-of-concept application, which lets Spotify discover how people could interact with the client in different ways than earlier. Spotify does not get that much attention in a social context, it is often only used to play music in the background. This application enables people to gather around Spotify and have fun with music. From this thesis work also came a server, which was fully set up and it is very fast and has support for a large number of users. Discovering when it breaks is out of the scope for this thesis work but it is an interesting topic, especially when it comes to dealing with the amount of parallel connections and the amount of messages sent during peak hours. This is noted in the ”Future Work”-section. The application is the result of having different people test the application, both in a group context but also in a single person context. The use of think- aloud interviews proved very important in iterating the design-process. The group sessions also helped the application tremendously, both in suggestions but foremost in testing game mechanics with a lot of different people at one time.

31 For Spotify, this application is an interesting approach to a social situation and can also be used to show third-party developers what is possible with the platform and hopefully inspire real business to implement modern technologies such as WebSockets in their applications. Throughout this entire project a lot of resources came from the web community and has really helped this project in so many small ways that are often over- looked or not visible from the outside. One of the best learning experiences is translating plugins using jQuery to pure JavaScript. This enables you to get an understanding of how the language works and what differs between using and not using a library. Since there was no real specification the functionality was very much up to the author, adjusting for this might also have been the most difficult task since the functionality changed quite a bit depending on what kind of feedback people had. There were fair amounts of re-doing development or changing code around to make it work in a new context. Thinking about what capabilities that Spotify offers today it is definitely one of the best technical solutions when it comes to social gaming. For me, the best proof that it works as intended is when people try it out, have fun and laugh together while using it.

32 6 Future work This project will be worked on continuously on the author’s free time. There are a lot of features that could be added, but all these are mostly game-play related. When the game is played in a group of users there is almost always someone with an idea on how to improve the game-play, for instance adding abilities to interfere with other players’ answering capabilities and such. This was actually thought about quite early in the development. An idea was to implement the brand-new vibration API so you could make the other people phones vibrate to disturb them while they were answering. The support for this is however non-existent, but will perhaps be implemented once it is in place. The biggest concern regarding the future is what kind of scalability issues the application might run into. The Socket.IO-framework has been benchmarked to manage thousands of connections at the same time but with the user base that Spotify has it is very diﬃcult to know how many it will be during peaks. Therefore it is crucial to make the application scale well with multiple instances, so that when the pressure becomes too big it is easy to start up new instances. For Spotify, this thesis was a good example of what could be created on the platform. It was also used in discussions with third party developers on what is possible to do from a technical point of view. Spotify as a company will not continue working on this application, that is up to the author.

33 References [1] Spotify Ltd https://developer.spotify.com/technologies/apps/guidelines/ integration/ (2012-05-01) [2] Integration Guidelines http://www.spotify.com/se/about-us/press/background-info/ (2012-12-01) [3] App Design Guidelines https://developer.spotify.com/technologies/apps/guidelines/ design/ (2012-12-01) [4] Design guidelines for Classroom Multiplayer Presential Games M. Villalta, I. Gajardo, M. Nussbauma, J.J. Andreu, A. Echeverr´ıa, J.L. Plass Computers and Education, volume 57, pages 2039-2053 [5] The Many Faces of Sociability and Social Play in Games Jaakko Stenros, Janne Paavilainen and Frans Mäyrä Proceedings of the 13th International Mindtrek Conference: Everyday Life in the Ubiquitous Era, pages 82-89 [6] Jakob Nielsen Website Response Times http://www.useit.com/alertbox/response-times.html (2012-05-01) [7] WanderPlayer ”WanderPlayer is a console right in your phone” http://www.wanderplayer.com/ (2012-05-01) [8] Internet Engineering Task Force (IETF) Known Issues and Best Practices for the Use of Long Polling and Streaming in Bidirectional HTTP, page 3-9 http://tools.ietf.org/html/rfc6202 (2012-04-01) [9] Peter Lubbers and Frank Greco HTML5 Web Sockets: A Quantum Leap in Scalability for the Web http://www.websocket.org/quantum.html (2012-04-01) [10] Internet Engineering Task Force (IETF) The WebSocket Protocol http://tools.ietf.org/html/rfc6455 (2012-04-01) [11] ISO 9241-11 Ergonomic requirements for office work with visual display terminals (VDTs) - Part 11: Guidance on usability International Organization for Standardization [12] Douglas Crockford JavaScript: The Good Parts O’Reilly Media, 2008 [13] Tom Hughes-Croucher and Mike Wilson Node: Up and Running O’Reilly Media, 2012 [14] Editor: Ian Hickson, Google, Inc. HTML5

34 A vocabulary and associated APIs for HTML and XHTML http://www.w3.org/TR/html5/ (2012-05-01) [15] CSS basics http://www.w3.org/wiki/CSS_basics (2012-06-01) [16] Introducing JSON http://www.json.org/ (2012-06-01) [17] Eelco Plugge, Peter Membrey and Tim Hawkins The Deﬁnitive Guide to MongoDB: The NoSQL Database for Cloud and Desktop Computing http://bit.ly/IDjjF4 (2012-05-01) [18] Marshall Greenblatt The Chromium Embedded Framework http://code.google.com/p/chromiumembedded/ (2012-04-01) [19] K. Anders Ericsson and Herbert A. Simon Verbal reports as data Psychological Review, volume 87, pages 215-250 [20] Gordon B. Willis, Research Triangle Institute Cognitive Interviewing http://fog.its.uiowa.edu/~c07b209/interview.pdf (2012-04-01) [21] Asbjørn Følstad, SINTEF ICT The Eﬀect of Group Discussions in Usability Inspection: A Pilot Study http://dl.acm.org/citation.cfm?doid=1463160.1463221 (2013-02-01) [22] TJ Holowaychuk Express, web application framework for node http://expressjs.com/ (2012-03-01) [23] TJ Holowaychuk Github repository https://github.com/visionmedia/express (2012-03-01) [24] LearnBoost Stylus, expressive, dynamic, robust CSS http://learnboost.github.com/stylus/ (2012-03-01) [25] Safari (Mac Only) crashes when using websocket https://github.com/LearnBoost/socket.io/issues/193 (2012-05-01) [26] Jonathan Snook Scalable and Modular Architecture for CSS https://smacss.com/ (2012-04-01) [27] Mark Obcena Slab is a templating engine for JavaScript. https://github.com/keeto/slab (2012-04-01)