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 third post in a series of posts about this. Here our Designer Viktor talks about adding artwork to the app.
Post nr 1: Making the server side…
Post nr 2: The making of …
Post nr 3: This post…
So, first things first, we did not have much to go on when the design process started. Or let me rephrase that, we had A LOT to go on, but it was a 30 page long mood board for the stage design of Robyns tour, which was also put together by a whole range of different people. I took some parts of it (the left half of the image below, which turned out to be the wrong half) that felt like they would merge together quite well and got to work on creating a look that could support the simple UI elements and the overall secretive feeling we wanted the app to convey.
(not the actual moodboard)
This is the first game board version, this is just a personal process but I like the idea of making the first draft of something as much as it can be and then scale down/remove stuff rather than the opposite way of adding stuff as you go along. The trade board was originally supposed to act like a radar so you could turn your phone and easily find people to swap with. Turns out (golfclap) almost no phones have the ability to do this in a good way, their favorite thing in the world is to to mindlessly spin around and point out west as north and so on. In retrospect this would neither have been needed since the players where awesome at organizing swap-meets!
A very early version of the achievement tab, it is always folded down over the current view so I wanted to experiment with a cut-out effect since video would be playing in the background.
I don’t know if this a broadly used terminology but in my experience it’s well worth spending a couple of hours on. Let me explain: one big challenge in this project was that we needed to test a lot of technical stuff as well as performance at the same time. What this means is that we had to have graphics from the get go that would change as little as possible. ‘Change as little as possible’ meant that we decided to render the app in 3 layers (simplified) one big animated background, one layer for ui elements, such as buttons, positions, well almost everything and last but not least, achievements as the third layer.
We also decided that we would use transparent pngs for all elements except text and backgrounds (video and or animated gifs) and that the transparent bounding boxes of the pngs would act as margins for layout purposes. This enabled us to update the entire look of the app without rewriting code each time. I set up all the assets as linked PSDs and arranged them in a couple of master files, one for each view in the app. So when feedback arrived I did not even had to work in any of the master files, I could update each asset on an individual basis and only really open master files for when the overall design was to be reviewed. I could also just replace files and they would almost automatically arrive in the app and update the whole look.
This might sound as small details but it enabled me to detach myself from developer deadlines and it made sure that the developers would not have to fear design feedback or changes, and we knew that we would have to make a lot of versions of the graphics since Robyn was working on artwork for both the first single, the album and the set design at the same time as we where building the app. All in all it made design a less stressful experience for all of us involved.
Robyns team got closer and closer to finished album artwork and the stage design so we finally had something to align the app against. So the first step was to tone down the crazy colors and achieve a more subtle feeling.
First draft of the game board was too much full on Miami 80s and the achievement notification REALLY went full on 80s! The third view of the game board is where we locked almost all elements and more or less only played with the colors up to the final version.
We got the final color scheme in the form of 5, 2 part color combinations and I thought: “wow those are some bold color combinations for an app, let’s do this, 100% throttle” and the result was, well let’s say it looked bold…
Game board & Achievements in extreme colors.
The symbols had a rather organic evolution, they started out in an asian calligraphy world, loosely tied to the name of Robyns label, Konichiwa, they however never felt right. They then went into something best described as computer OS icons, then to retro game, then to impossible stone shapes. When they where shown to Robyn she came up with a list of artifacts she felt would represent her and the album. In that moment they also changed name from pieces to artifacts. So in order of birth, here they are:
Evolution of the trade & unlock symbols.
First selection of artifacts to the final codes!
Initially each and every single view of the app was supposed to have an animated background. We wanted to have this because the UI itself has little or no animation or visual feedback (you click a button on the home screen and go to another screen) and it would be the most effective way to bring the app to life and give it a sense of flow and dynamic. We hung on to the idea a long time but in the end it was too much of a risk performance wise to have anything interfere with the swap view. If the experience of swapping was slow the whole core and integrity of the app would be in jeopardy and we really, really wanted people to share artifacts with each other!
Thank you Red Bull and Robyn for making this really fun and rewarding, I’ll repeat what the previous post about this project concluded: If you ever get the chance to make something for Robyn’s fans, take it.
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/
Sommarpyssel för dig och din unge.
Det låter kanske kul men det är ett litet helvete. Fast jo, också kul.
Roblox är en spelplattform med en egen utvecklingsmiljö för publicering av egna spel. Det har funnits sedan 2006 men på senaste tiden har det ökat snabbt i popularitet och är enormt stort i den yngre målgruppen med 65 miljoner aktiva spelare varje månad.
Todo:
Till dom första två stegen använder jag Blender och lite Photoshop men det går ju bra med valfri 3D-programvara och eventuell bildbehandlingsprogram.
👆 Här gör jag själva 3D-modellen i Blender.
Roblox har en gräns på 5000 polygoner per mesh. Detta är ju en rätt simpel form men håll modellen så enkel som möjligt.
Gör man modellen 3 enheter stor i Blender och sätter scale till 0.01 när man exporterar som fbx så blir det en rimlig storlek när man tar in den i Roblox Studio.
👆 Texturen skissade jag upp med Texture Paint i Blender och snyggade till i Photoshop.
Det här kan man ju göra på lite olika sätt. Jag valde att snitta upp min pippi på det här viset. Hur man markerar sömmar och ritar textur i Blender tycker jag den här videon förklarar bra.
Spara ut den som en png och ladda upp den under Create > Decals på Roblox.com. Då får du ett ID-nummer i urlen som du behöver klistra in som TextureId i Roblox Studio. Den måste inte vara modererad av Roblox för att använda i Studio. Dom är dock rätt snabba på att godkänna uppladdat material.
Om du testar spelet nu (F5 eller playknappen) så kan du inte greppa flamingon. I Roblox behöver man ett skapa ett objekt som heter Handle och placera det där karaktären ska greppa objektet. Man gör de två objekten till children av objektet Tool som finns beskrivet här. Tool är alltså till för redskap eller vapen egentligen. Jag följde den här beskrivningen för att få det att typ funka.
Tweaks
Genom att överdimensionera flamingon, placera handtaget på sniskan så att det ser ut som att man typ sitter på den istället för att hålla i den samt ändra fysikvärdena lyckades jag få den att agera som en användbar badring.
👆 YEEHAAW!
Roblox Studio är en lite frustrerande miljö och det är väldigt mycket testande fram och tillbaka. Men fan alltså, det är roligt och leder till nästan lika många skratt som sammanbrott. 10 av 10.
Hej då.
/Andreas
👆Nu var jag ute efter en handtextad känsla så jag började med att skriva alla bokstäver med en fet Faber Castell Brush pen och kalkerade av dom i Illustrator. Jag är så van med Illustrator att jag hellre styr upp ankarpunkterna där och kopierar över till Glyphs.
👆Övriga lager, i det här fallet highlights och skugga+outlines designade jag direkt datan genom att utgå från baslagret. Totalt 3 lager alltså.
👆 Här är alla tre lager importerade i Glyphs. Väldigt tillfredsställande när man kan testa sina bokstäver med tangentbordet.
👆 Här är ett litet fulkodat exempel att kika på.
Vad ska man med detta till då. Halvbra fråga. Fel använt skulle ju detta få internet att bli riktigt jävla fult. Men i rätt doser och kombinationer i rätt sammanhang är det fan fint alltså. I det kontextet hoppas jag på att få se mer av detta.
Detta var enkelt beskrivet. Att skapa ett typsnitt med bara ett lager är rätt tidskrävande och sällan försvarbart ekonomiskt för separata projekt. Men ändå. Det finns ju färdiga som sagt och det kanske inte alltid behövs ett helt typsnitt. Jaja.
👇 Den här är ju förresten baserad på en variant av exemplet ovan men med lite andra lager.
Hej då.
/Andreas