Labs – internet experiments by Earth People
For this year’s Stupid Hackathon we made a fun little thing called Laff track.
Many TV series we know and love wouldn’t be the same without added laughter. There’s a great episode of 99% Invisible about all of this.
Our project Laff track is a plugin to Chrome, which adds this craziness to all Youtube videos. It simply detects when people are not talking, and adds in a bit of laughter.
Download it here and give it a try!
/Peder & Hjalle
So we made a game for Robyn and Red Bull Music. This is the second post in a series of posts about this. Here our UX Designer Nana talks about designing a competition for the compassionate, and the secret ingredient to a sticky game.
Post nr 1: Making the server side…
Post nr 2: This post…
Post nr 3: The design of…
If you ever get the chance to make something for Robyn’s fans, take it.
This year Robyn released her first album in eight years, and the only way to get tickets was to play a game. We were asked to make this high stakes competition while encouraging collaboration and generosity. On top of that we were tasked to force the players to interact face-to-face with strangers and make it enjoyable.
As a Stockholmian that enjoys the comfort behind my screen and noise cancelling head phones I had to wonder, what does that even look like?
Photo: Johanna Sjöstrand
This totally looks like a staged PR-pic, but it’s just a couple of Malmö swappers trying to charm Red Bull into giving them a rare artifact.
Spoilers! Before we get to that, we wanted to share some behind the scenes of making the game. It has been an absolute blast, and we are so grateful we got to make something for Robyn’s wonderful fans. Game mechanics and design can only nudge players so far, what they chose to do with it was the real magic.
So here is a peek into the work that went into bringing this game to life! I can talk about this game for hours, but to keep it short (hah!) let’s focus on three goals I as a game designer had my eyes set on:
Red Bull and Robyn knew they wanted a board with pieces. Each day the players would get a new piece and they would have to meet up with other players IRL to trade copies of their pieces in order to fill their board. There were also rare pieces that could only be unlocked with a code. (If you’ve played the game you might notice we didn’t call it “artifacts” or “swapping” yet)
As a UX Designer for a super secret project that can’t be user tested on a big scale it was my job to try and predict what the players would do with the game mechanics we gave them. It was a tough case to crack considering we had no idea if we would have 500 or 10 000 players.
© OpenStreetMap contributors (openstreetmap.org)
Heatmap timeline of 20 000+ players meeting up 320 000+ times and unlocking 50 000+ artifacts during the game’s three weeks. I was so young and naive.
If it was only a race to collect the most artifacts there would be no incentive to help each other out (except for the kind nature of your heart). So we decided to center the scoring system around four main metrics:
Going into this we knew there was a risk of opportunistic players in big cities joining on the last day. We added achievements and scored them in a way that rewarded dedication and being an early adopter. Having a 14 day streak was worth more than meeting 30 people. In the end, 95% of the top 500 players joined the first week of the game. The top 5 Swedish players all joined within the first 4 hours.
We didn’t let the users know exactly how we scored their progress, we hoped it would encourage players to compare and collaborate. But they had a statusbar that let them know if they were on track for a ticket or star treatment.
It was a close race to the ticket level. In the end the difference between number 450 and 550 was the equivalent of meeting 40 people and sharing 70 artifacts. But there was a nice spread in the top 500. The top player met 923 people, shared 2 200 artifacts and earned 70 060 points. Player number 500 sat on 13 440 points.
One way we nudged players to collaborate and reach out to each other was making them think of the game bigger than the app. That meant we didn’t want the app to be too comfortable to stay in.
At first there was talk about missions in the app that would unlock rare artifacts (one I fondly remember was Robyn’s idea to stand quietly in the woods for 10 minutes) but for multiple reasons we decided that the rare artifacts would be unlocked with codes that could appear unexpectedly in the physical or digital world.
Another example of how we did this is how we designed the swap-radar where players could choose who to swap with. If we wanted to make the app comfortable, we might have gone this route:
Early swap-radar sketch.
If nearby players were always visible on a map and the player could zoom in, out and pan around it would be pretty easy to stay in the app and keep an eye on when players were nearby, and how to get to them. Instead, we wanted the players to hit each other up outside the app, so we didn’t want to let them get a too good idea of their surroundings. Here is our journey from wireframes to the finished look:
I think the first thought that comes to most people’s minds when they think of a trading system in a game is pretty simple: Player A sees Player B in the game and sends a request to trade. Player B accepts, and they automatically trade pieces. But that just ain’t gonna cut it when we’re trying to force them out from behind their comfortable screens. (Sorry!)
We explored different swapping systems. QR-codes, bluetooth, bumping. But we were falling into the trap of letting technology make the connection for us.
The solution was kind of simple. One player gets a code if they are standing close enough, and the other player has to enter it on their screen.
It’s not a huge task, but I think it had a pretty big effect. When I went undercover and attended my first swap meet it was really nice seeing everyone working together and given a reason to talk to each other, telling each other which symbols to press.
Speaking of symbols. They’ve been on a journey to reach the look and feel they had in the game:
“Collaboration gets you further in the game! (And in life!)”
– Robyn
All of these choices could have backfired or fallen flat. I’m used to designing products that help the user every step of the way. Usually, UX design is about making things easier, not mythical and difficult to understand. There is no rage like not understanding an app.
And even though there were frustrations and my heart goes out to players that fell through the cracks (I wish we had balanced it better for players in smaller cities for example) I was not prepared for the perfect match the values of the game aligned with the players. They took their kindness and went above and beyond.
Like all the winners who decided to give their +1 ticket to players they never met:
Or the players that shared codes to the rare artifacts to help other out:
This describes the experience very well (in Swedish), giving a shout out to all the kind swappers she met:
Thank you for the opportunity to be a part of this experience, Red Bull Music, Robyn and all of her fans <3
So we made a game for Robyn and Red Bull. This is the first in a series of posts about this. Here we focus on the server side and outline some of the challenges we had.
Post nr 1: This post.
Post nr 2: The making of…
Post nr 3: The design of…
While the game itself was a success, we did struggle with something we usually never struggle with – the server side. The nature of the campaign meant that we had huge traffic spikes, which in all honesty we were not prepared for.
Early in the project we decided to write the server side in NodeJS. We’d be hosting this at DigitalOcean, using their load balancer to spread the load round robin among n app servers. Since the campaign period only was ~3 weeks we decided to have a big single database server, running MongoDB.
DigitalOcean
DigitalOcean performed great. Their API’s and GUI’s for taking snapshots of app servers, and creating new droplets is easy and we could easily take servers in and out of rotation using their tag system. Even when they were doing network maintenance we just noted a tiny bit of latency. Something that could have become an issue was the internal network speed on the network. 1Gbps is not that much, and we we’re dangerously close (~800Mbps…) a few times. We would we have had to shard the database if the campaign had stretched for another week.
NodeJS
We ran our node processes via final-pm, and could run as many processes as we had cores on the appservers. This worked pretty great. All app servers sent their logs to Loggly, so we could follow everything in near real time.
Workers
All heavy lifting was offloaded to a couple of worker servers. They were running Agenda and handled achivements, sending push messages and calculate user score. They worked really hard every now and then, which is great, but we started adding some interval between queue jobs to give MongoDB some breathing room.
MongoDB
This is where we had some challenges.
First, we didn’t log slow queries on our production database. As the collections grew, response time went up. As there were no logs of this, we didn’t realize this as fast as we hoped. When enabled, the logs showed us that we were missing a few indexes, and when adding these the query time become much more stable.
Secondly, using an ORM is a very convenient way to make too many heavy queries and not seeing exactly what queries generates locks… after looking at the raw queries we were able to optimise these.
Thirdly, we did not stress test the API with the same kind of requests as the app did. Since the app updated user position every couple of seconds we had a lot of writes going on at the same time, generating locks.
Key learnings:
As always, it feels sad taking down the cluster just when it performs at it’s peak. Which is now. Good bye cluster. You were great, at the end at least.
Jo, men för ett år sedan skrev vi överlag rätt dåliga commit-meddelanden. “Fix” och “Stuff” var inte helt ovanligt att läsa i historiken. Problemet med sådana meddelanden är att de inte ger nånting; att komma in som ny utvecklare i ett projekt fullt av “Fix” är minst sagt lite knepigt.
För att få alla att kollektivt skärpa sig skrev jag en liten slackbot som, på eftermiddagen varje dag, går igenom dagens aktivitet i våra aktiva projekt. Boten postar sedan ett av de meddelanden som är av perfekt längd till vår #kod-kanal.
Detta har fått oss att skriva mycket bättre commit-meddelanden på väldigt kort tid. Som nån sa: “det hjälper att man har ögonen på sig faktiskt”.
Koden ger inget att dela, vi kör ju CI-plattformen Buddy, och detta i princip bara en liten curlsnurra runt deras API. Att göra detta på GitHub eller BitBucket borde inte vara mer än några rader kod i valfritt språk.
/Peder
Vid utveckling av webbplatser gillar vi att få en visuell historik över sajtens utveckling. Allt från en första vit blank sida till en färdig sajt med logotyp, menu, content och (ibland) andra färger än vitt.
För att få denna historik har vi utvecklat ett eget verktyg vid namn 📸 PushSnapper.
Det hela är väldigt enkelt: varje gång en ny version av en sajt pushas ut så tas en skärmdump av sajten. Alla skärmdumpar sparas i en mapp på en server och när som helst kan vi plocka fram valfri skärmdump eller skapa en film av alla skärmdumpar. Det är kul att titta på, det är ett bra sätt att följa en sajts utveckling, och det kan säkerställa att inget oväntat skett på sajten. Så när någon frågor “när och hur och varför blev logotypen dubbelt så stor?!” så kan vi lätt se vilken dag och tidpunkt detta inträffade.
Såhär kan verktyget visa utvecklingen av en sajt. I detta fall har vi skärmdumpat hur sajten ser ut på en mindre skärm, typ en mobil:
Slår man ihop alla bilder ovan till en video blir det ungefär såhär (du måste kanske musa över videon och klicka play):
Jo på Earth People använder vi ofta verktyget Buddy för att deploya kod. Buddy har en fiffig funktion vid namn Pipelines som gör att man kan utföra olika saker i olika steg vid en deploy. Sist bland dessa steg har vi lagt in vårt eget verktyg PushSnapper, en liten enkel node-snurra som i sin tur använder sig av Puppeteer.
Så varje gång en ny version av sajten läggs ut så tas en eller flera skärmdumpar. När man väl aktiverat skärmdumpningen så behöver man inte bry sig om att den sker. Förhoppningsvis glömmer man det och kommer på det sist i projektet när man vill ha en fin animation – eller när något går riktigt snett och man undrar exakt när det hände!
Det finns garanterat flera liknande verktyg – men det här är vårt eget verktyg skapat för våra behov. Och än så länge funkar det 💯.
/Pär
Vi är ett antal individer på det här bygget som släppt ifrån oss musik i olika former. Jag själv började trevande med cdr-släpp med hemgjorda omslag, la ut musik i låg bitrate när MySpace-eran nådde zenit, för att gå vidare till “riktiga” cd-skivor, vinyler och de streamingtjänster som vid det här laget känns som de funnits för evigt.
Då det mest hela tiden skett på punknivå så har jag plockat på mig små bitar av oklar kunskap kring musikdistribution. Sådant det finns internationella standarder kring och professionella ägnar sig åt hela dagarna. Min icke-metod har lett till att mina tidigaste släpp gjorts under oklara former, där ingen av de inblandade vetat riktigt vad de hållit på med.
Med den inledningen ska jag komma till saken: Jag ska återutge en av mina första skivor, som från början gavs ut på cdr, och sedan släpptes digitalt. Den gavs ut av två olika skivbolag i nanostorlek, som båda somnat in sedan länge. För att kunna behålla de antal spelningar som skivan samlat på sig på Spotify behöver jag få fatt på de ISRC-koder som hänger ihop med låtarna.
Om jag gjort allt enligt konstens alla regler när det begav sig hade det varit EN kod prydligt kopplad till EN låt. Och allt hade registrerats hos IFPI i deras stora och lättillgängliga databas.
Men skivan släpptes utan koll på läget. Tur då att uppgifter om ISRC-koder finns tillgängliga i Spotifys API. Jag fick hjälp av Peder som byggde en enkel webbtjänst där man genom att klistra in länken till ett Spotify-album får fram all metadata som finns om låten, inklusive ISRC-koderna. Så nu har jag, förutom själva ISRC-koderna, fått reda på att låtarna visst råkat få dubbla uppsättningar av koder. Därför måste jag nu reda ut hur detta ska städas upp. En massa felstavad metadata är det också. Suck. Kan inte allt bara funka.
/Henrik
En kanske gillar en del program på Sveriges Radio och en del musikbloggar. Dessa har massor med fina låtar listade, en och en, på sina websidor. Fantastiska playlists, förutom att de inte är just playlists utan bara låtlänkar. En vill inte sitta och klicka play låt efter låt utan ha detta i playlists istället.
Märkligt att det fortfarande saknades en enkel tjänst för detta. Så jag gjorde en snabb liten sajt som hjälper iallafall mig i min vardag. Använd om den passar ditt liv också.
Alla låtarnas interna Spotifylänkar presenteras, rakt upp och ner, i ett litet textfält. En illa dokumenterad feature i Spotifys desktopapp är att dessa kan pejstas rakt in i en playlist. Sjukt ju.
Inte så märkvärdigt, men känns bra att ha täppt igen det här glappet på Internet.
https://earthpeople.club/~peder/url2spotify/
Vi jobbar ju i en del projekt där faktiskt nedlagda timmar ska faktureras. Men det är ju så roligt att jobba och så himla svårt att komma ihåg att tidrapportera, även om man som vi gör det direkt i Slack.
Men samtidigt dumt att bjuda på timmar som glöms. Så jag hackade ihop en liten slackbot som hämtade ut alla dagens commits ur vårt byggsystem Buddy och jämför det med dagens inrapporterade timmar. Det är lite trubbigt (än så länge) men boten känner iallafall igen ifall någon varit inne och programmerat i nåt projekt och glömt rapportera det.
Alltid nåt.
/Peder
Alltså oklart varför, vi är ju ingen eventbyrå. Men i mars ordnade vi ändå en skofri releasefest i dansens tecken, för Jenny Wilsons nya skiva Excorsism. För att:
1) det är så sjukt kul att ordna fester.
2) så himla fint att sammanföra massa bra folk från vårt nätverk som kan bidra med sina specialiteter.
(Video: Ola Lewitschnik / Gabriel Leigh)
Jenny har tidigare spelat på Webbklubben, och vi har tidigiare gjort nån slags “interaktiv upplevelse” för hennes singel/video: http://www.rapin.run
Bonusmaterial: “TV-kanalen” med tematiska giffar som Katarina kodade ihop och projicerade under festen (OBS: Enorm laddtid pga preload):
https://earthpeople.club/~katta/gif/
/Peder
Jag kom på nu att vi ju kört rätt fina afterworks hos oss i gamla stan, i flera år, och glömt berätta om dessa. Om du känner oss sedan tidigare kanske du varit här, annars är du välkommen i framtiden. I sin enkelhet bjuder vi på öl och bokar en artist vi lyssnat på. Det är alltid astrevligt, och en rätt härlig mix av webbtroll, goda bekanta, snälla grannar och löst folk från gatan.
Mer bilder från alla webbklubbar på Instagram.
Artister som spelat senaste åren:
Den 24:e maj är det dags igen. Då spelar det helt färska bandet FLORA något som, om man får tro första singeln, låter som en perfekt kombination av Yung Lean och Autechre.
Det blir nog stämning. Kom då!
/Peder