Categories
Startup World Wide Web

Eukles: Marketing Automation done DIY

For the past couple of years I have been playing around with the idea of a hard divide between outgoing communication (transactional emails, push notifications, newsletter contact list synchronization, marketing automation, slack notifications, etc) and the business logic of my applications.

It never made sense to me that a backend system that manages ticket sales for an should would also implement a mailer queue; but also it doesn’t make sense that the copywriter who wants to change the content of an email would have to talk to a developer to do so.

In 2017 I started working on removing all logic for these kind of actions from my websites and replace them with a single event driven microservice that would handle anything related to outgoing communication for all projects I build.

My goals where to:

  • Be vendor independent: Services like Mailchimp, Moosend, Sendpulse etc have basically already built what I wanted to have, but given my DIY nature I wanted to stay independent from them.
  • Base all actions from a stream of events sent by the business logic.
  • Manage all GDPR related permissions and preferences from a central location.
  • Cut all links between the app domain and this microservice: no accessing data that has not been provided. Push only.
  • Be able to synchronize lists of users (= segments) according to relationships and synchronize these to newsletter services. (ie: automatically make an email list of all registered users who are attending a certain quiz).
  • Provide a management panel where non coders could change the content and the logic of the outgoing notifications.

That is what I started building. I even setup a website to ask feedback from smarter people to make sure I wasn’t reinventing a square wheel, but in the end I kept building nevertheless: Eukles was born.

The Slack notification

I started with our ticking website CatLab Events, and my first goal was pretty modest: send a slack notification to our channel every time someone bought a ticket for one of our quizzes. I setup a MySQL database (probably not the best fit, but as I wanted quick results I stayed with the tools I knew best) and a Laravel/Charon REST API and also created a separate API client package for PHP to easily implement in existing projects. A few days later I registered my first event:

/**
 * @param OrderConfirmed $e
 * @throws \GuzzleHttp\Exception\GuzzleException
 */
public function onOrderConfirmed(OrderConfirmed $e)
{
    $order = $e->order;

    $attributes = [
        'event' => $order->event,
        'order' => $order,
        'ticketCategory' => $order->ticketCategory
    ];

    if ($order->group) {
        $attributes['group'] = $order->group;
        $attributes['subject'] = $order->group;
    } else {
        $attributes['subject'] = $order->user;
    }

    // Track on ze eukles.
    $euklesEvent = \Eukles::createEvent(
        'event.order.confirmed',
        $attributes
    );

    $euklesEvent->unlink($order->user, 'registering', $order->event);

    if ($order->group) {
        $euklesEvent->link($order->group, 'attends', $order->event);
        foreach ($order->group->members as $member) {
            if ($member->user) {
                $euklesEvent->setObject('member', $member->user);
            }
        }
    }

    \Eukles::trackEvent($euklesEvent);
}

To break it down: what I wanted to communicate to Eukles was:

  • An event.order.confirmed event has happened
  • This event has some related properties (event, order, ticketCategory, group and subject (which can be user or group, depending on the event type).
  • Unlink the ‘registering’ relationship between the active user and the event (= the user is not registering anymore, as the registration is already done). The idea is that these relationship actions could be defined either in the business logic or triggers on Eukles itself.
  • Link the ‘attends’ relationships between the group and the event. This would allow us to create a segments of all groups that attend a specific event and synchronize that to Mailchimp later.
  • Add all members of the group as properties of the event (= when a group has 4 members, send an email to every single one of them)

(Note that all models used as properties would have to implement an ‘EuklesModel’ interface that included methods to serialize the content that is send to Eukles.)

The content of the event properties is stored in two places:

  • As part of the event, so that we always know the state of a model at the time of the event creation.
  • (If a unique identifier is provided) the model it is also synchronized with a centralized project-model database that contains the relationships between project-models and always contains the last known properties. Every time an event is sent, the content of these models get updated.

Now I just had to add a SlackService, store authentication details for these services in the database and setup a few Action and Trigger models that would listen for the event and cary out actions. And using the Jobs queue in Laravel everything was handled without impacting the user flow.

Internal use only (for now). Everything is manageable from a REST API with the goal to build an angular frontend in a later stage.
Humble beginnings.

To keep things simple I used Laravels Mustache syntax to parse the arguments that were used by the service clients.

GDPR consents

As Eukles would become responsible for all outgoing communication, I found it fitting to store communication preferences and consents on Eukles instead of in the business logic. Eukles doesn’t really have the concept of a ‘user’, as user project models are sent in events and follow the same logic as any other event property. So I created an API endpoint that would show me all consents in a given project by a given project model. By adding this call to my registration process I was able to ask all users that logged in (existing or new) to give the required and optional consents.

By adding these as filters to segments and actions, I was able to block communications to users who opted out of these messages.

Segments

The goal of Segments was to make dynamic or static lists of project models and synchronize those lists with newsletter services like Mailchimp. For example: by defining segment rules and setting a parent model in the segment schema, Eukles is able to create a segment for each ‘event’ projectmodel, containing all ‘user’ projectmodels that have the ‘attending’ relationship set to it AND have given consent to receive newsletters.

Once every hour these segments are then synchronized with Moosend or Mailchimp, and whoever is in charge of sending out the newsletters can rely on those lists being up to date at all times.

This synchronization also checks for users who are marked as ‘unsubscribed’ in Mailchimp, and the applicable consent is removed from those specific users, resulting in remove them from that segment.

Templates

As all emails in QuizWitz use the same basic template, I have added the ability to define mustache-like ‘templates’ for each project. Anywhere parameters are parsed, these templates can be used (but they only really make sense in html-like contexts)

The email that is sent whenever a player starts a QuizWitz PRO game uses the standard ’email’ template.

Wait 1 hour. if !subject.hasLicense(event.license): then: send email.

And that is pretty much where the project stayed for a few years. My simple event -> trigger -> action model worked fine for sending transactions emails, notify us about certain events and even sending tweets with giphies based on event attributes (implementing services is trivial since the base architecture for defining actions and storing credentials is already provided).

All was well in Eukles world… until I found myself with a bit of time on my hands and I decided to implement some dark design patterns to try to raise the conversion rates in QuizWitz: when someone initalizes a license purchase but in the end decides not to complete the purchase, send them an email asking for feedback.

A perfect use-case for Eukles, where it not that I had gone for the quick event -> trigger -> actions design instead of a fully fledged ‘workflow’ state machine. So that is what I started building.

Instead of triggering an action, all events now check for ‘workflow triggers’ that initializes states in the workflow machine. Depending on the trigger configuration, Eukles also checks for duplicates to make sure that recurring events don’t cause too much triggers. A state then follows the configurable steps in the workflow and triggers actions that are defined in steps. Each trigger also has the ability to set one of the event properties as ‘subject’ that can be used anywhere in the workflow, to reduce the dependency on the initial event.

A simple shunting yard algorithm offers me the ability to define conditions in string format and makes it possible to setup decision trees in the workflow, while a special ‘wait’ step adds a delay to the state machine processing. The whole thing is using Laravel Job queues, so it was all fairly trivial to setup.

The table based interface is obviously a horrible choice for setting up workflows like this, but as for the moment I am the only one using this, it will do. No need to pour more hours in things that only marginally improve my life 😉

And that basically is the current state of the Eukles project. My goal is to clean it up and release it under a GPL license in the future, but in order to do that I first want to improve the admin panel interface and write down some documentation. If that ever happens, I’ll definitely post it here.

Categories
Uncategorized

QuizWitz / Quizfabriek ecosystem

Hello, I am Thijs and I have a problem: I keep buildings things. Silly things. Things that I am sure nobody else will ever use. And yet I keep building them (and release the source code). Why? Because I love it so much. Because I keep thinking of cool use-cases for linking things together.

My story starts in the summer of 2013. I wanted to found a game studio and I had a brand new, original idea for an amazing game: Kahoot. Or… well… our version was called ‘Quizted’ and was aimed towards gamers instead of educators, but the main premise was the same: an audience participation game around quizzing. (Let me spare you the googling: Kahoot beta was released later that year).

I managed to secure some money from the Flanders Audiovisual Fund (VAF) and in the summer of 2014 I hired 3 of the worlds best programming… students. Two software developers (Katia & Yannick) and one marketing student (Ken). Second years students, looking for a summer job. I also hired a consultant from Portugal who would be working on the quiz editor.

By the end of summer, we had a pretty basic proof of concept: we had systems in place to create quizzes, play these quizzes with up to around a hundred people, and I had even developed a rudimentary licensing system to accept online payments. Ken had been working on a crowdfunding campaign and we organised a few ‘quizwitz viewing parties’ where we would play the game with a group of people. I hacked together a QuizWitz mod that allowed a ‘quizmaster’ to control the pace of the game and added a jury mod that allowed manual correction of open ended questions… and our QuizWitz Live events were born. And thus we started our transformation from a gaming studio to an event organiser.

I split up the organisation and moved the event management side into a separate entity (Bektoe vzw, more commonly known as De Quizfabriek). More people joined and we started disrupting the Flemish quiz space with our digital quiz experience™. I would be in charge of the quiz software (through my own company), the content would be provided by our fellow members.

It’s all fun and games … until someone has a new idea. And there were ideas. Tons of ideas. Initially we sold ticket through an online form and quizteams had to pay their entrance fee at the door. Due to a whole bunch of no-shows, I replaced that with an online registration system: CatLab Events was born (source code on github). And since we wanted to support the UitPAS program, obviously that had to be integrated as well.

In 2019 our events started to grow unwieldingly large and we started having trouble with handling the bar. It’s not a great expience if you need to wave for ten minutes until a server notices you and then has to disturb the people around you by taking your order. So I wrote a very simple QuizWitz mod that would allow players to order drinks from their table. CatLab Drinks was born (source code available on github).

Everything ran smoothly from their on… until I wanted to experiment with digital drink vouchers. Up until then we had been working with the traditional paper drink vouchers had to be purchased at a central cash registry, but that all felt a bit backdated. So I extended CatLab Drinks to be able to connect to a Raspberry Pi (over websocket) to a service that provided NFC reader/writer capabilities. One of the bigger challenges was that I wanted to store the user credit on the cards themselves, so I would be able to read (and change) the balance even if the central system would go down.

We started a few phased release tests but ultimately started using the system for all our events. I also extended the app even more to allow players to popup their cards using a QR code on the back (resulting in a whole bunch of synchronization challenges that had to be handled every time a card was read or written) and instant payment of remote orders so that servers could just rely on the system instead of manually scanning the cards. Challenge completed. Next!

At one of our themed quizzes we wanted to add a photobooth where players could take a team picture (source code available on github). Taking the pictures was easy, but keeping track of who was on the picture provided to be a challenge. But a solution was at hand! Since every team already had an NFC card, it would be trivial to make a small Raspberry PI based system where players would scan their NFC card and a picture is taken automagically.

Manual picture (people in picture unknown)
Automatic picture: ‘Quizfabriek team’. I must admit that I’ve never figured out how to make the camera focus properly, but that was out of my tech savy scope 😉

But a new problem popped up: the NFC cards were basically anonymous and some teams even used the same card for multiple events. So I had to extend CatLab Drinks even more, to be able to check players in and connect their card to their name and email address. Then I just had to provide an API for the photobooth application, connect the whole bunch up to Eukles (my marketing automation system that also handles all communication from QuizWitz and the ticketing system) and bam, photos were automatically emailed to the players.

Oh, and also all assets, photos, video fragments, etc are stored in a central storage system that makes sure that no duplicate data is stored (source code available on github).

Oh, and I also have a laptop that listen to a datastream (websocket) and emits MiDI signals on certain game events to a digital lighting console to control the theater lights over DMX. But that is not included in the overview.

This is when I learned that an introduction can be too long.

And that is basically what our system looks like. From registering for our events, over checking in and playing, to checking your score on our website when the game is done… An ecosystem of overengineererd madness… But so much fun to build. I’m trying to cut back on new ideas and perhaps properly document what has already been created. Maybe someone on GitHub can see some use of projects after all…

But what if, instead of a quiz, we would gather with 160 players to play a digital escape game…

Categories
English Startup

My 2021 in numbers

Happy 2022! May the omikron-variant (and the corona-virus in general) die a quick death. No other wishes… just that.

As I’ve been tracking my worky-worky time for the last two years, I continued doing that in 2021. This years report is probably less interesting than previous years, but I’m writing it for good measure.

So first, the data:

ProjectHoursRevenueHourly
Work for hire1563.99121,070.3977.41
QuizWitz546.918,483.0133.80
Quizfabriek247.253,479.9014.07
Dolumar627.774.63
Papyri58.50.000.00
Quizproject X570.000.00
Administratie15.50.000.00
Varia70.000.00
Eukles2.50.000.00
Same as last year I’ve only counted revenue and excluded all cost except for personnel cost that was directly related to the event (so when I needed an extra pair of hands to work on a QuizWitz event, the cost of those hands are not included in this revenue list). Servers, transport, equipment and other external labour are ignored (= left included) and all amounts are excluding VAT.

I’ve logged a total of 2504,64 hours which amount to an average of about 52,18 hours a week (at 48 weeks / year, so holidays excluded). This is about the same as last year.

An overview

Work for hire

Work for hire still is the big one. I’ve been lucky to be working on an interesting and challenging project for the last two years. While in previous years I sometimes saw these clients jobs as a necessary evil in order to reach true goals, this has lately shifted somewhat. These days I describe my other projects as ‘hobbies’, as they never seem to get out of that stage anyway. Not meant to be bitter, but labeling them as hobbies gives me more peace of mind.

QuizWitz

Revenue from QuizWitz is down 35% since last year, and this while I’ve spend a considerable amount of money and time in improving the communication around our product. Of the €21.962,91 generated revenue (note that I include the Quizfabriek ‘revenue‘ in here as well), only €9.950 came from the online platform (was €16.727 last year). The rest came from support at events etc.

At the same time I’ve spend about €14.500 on various freelancers to improve the communication and marketing around our product, so the bottom line is that QuizWitz resulted in a net revenue of about €7000 in 2021. Whether these investments in clearer communication will result in continueing return remains to be seen.

Quizfabriek

This number is a bit unreliable as revenue from this non-profit is actually license fees for using QuizWitz at their events. De Quizfabriek has been doing pretty well the last two years and Wietse and Mathias managed to setup a pretty decent B2B sidetrack.

The tracked hours here are mostly spent on Quizfabrieks B2C events and thus aren’t really related to the revenue that is noted here.

Other projects

Not much to say about these. There are a few projects that just require maintenace to keep online but don’t really return any revenue. Sane people would probably take them offline, but I feel they still have some value.

  • Dolumar is a browser based game I made when I was studying. There is one guy still playing it every day. This makes me very proud.
  • Papyri is a project in the document management space that I’m still working on as a side-hustle.
  • Eukles still handles all outgoing mails, slack notifications and other messages that are sent out by QuizWitz and some other projects.

One day these projects will probably suddenly appear under an open source license.

Technology

Not that much really. I guess I could label this year as ‘maintenance of older projects’.

  • In accordance to our privacy policy I started automatically removing inactive user data from our servers, which resulted in some interesting edge cases in my SSO system and a huge amount of bounced emails (not doing that again!)
  • I’ve automated the whole invoice flow for QuizWitz so that professional users can now request invoices without me having to hack away at the payment gateway.
  • Tired of manually switching scenes during livestreams, I’ve hacked together a control panel for our Atem mini that listens for midi-notes from our QuizWitz midi generator (that we already used for controlling the light fixtures in the venue over DMX) and switches between game view and camera view at appropriate events.
  • For a Quizfabriek quiz I’ve implemented a greenscreen imagick script in our Photobooth. Nothing fancy, but the end result was pretty neat.
Photobooth with greenscreen (that is hardly visible due to too many people in the frame).

Next up

While in 2021 I’ve spend quite some effort in re-launching QuizWitz, I feel like I’m finally done with that. Not that I will drop the project completly, there’s still an amazing bunch of people who still regularly use our software. But I’m done with trying to push to the masses. I don’t have the skills to do that, so I better just focus on what I can do: try to make sure that our existing users have the best experience possible (without hurting myself too much).

My main focus for 2022 is going to be the project I’m working on for hire. Sure, there will be QuizWitz events and other projects that just suddenly turn up, but I don’t really feel like prioritizing those anymore.

I guess I’m getting old.

Categories
English Startup

My 2020 in numbers

Happy 2021! May all your pharmacy stock pay off and may your hodling enhance your riches!

What a crazy year it was. Covid-19 forced everyone to work from home and online conferencing tools almost brought down the internet… and (spoilers ahead) introduced the mass market to online streaming quiz games.

Last year I started extensive timetracking on anything work related and this year I did the same. Slightly less hobby projects this year, as QuizWitz took a bit of a jump and caused some gear shifting on our side. So only 9 projects this year (excluding the 3 projects I worked on under ‘Work for hire’).

ProjectHoursRevenueHourly
Quizkalender0,00€ 73,24€ 73,24
Work for hire1.523,33€ 102.970,72€ 67,60
QuizWitz748,00€ 32.958,94€ 44,06
Dolumar4,00€ 22,56€ 5,64
Quizfabriek218,50€ 1.000,00€ 4,58
Photobooth53,00€ 0,00€ 0,00
Eukles18,50€ 0,00€ 0,00
Administratie15,50€ 0,00€ 0,00
CatLab Drinks4,50€ 0,00€ 0,00
Same as last year I’ve only counted revenue and excluded all cost except for personnel cost that was directly related to the event (so when I needed an extra pair of hands to work on a QuizWitz event, the cost of those hands are not included in this revenue list). Servers, transport, equipment and other external labour are ignored (= left included) and all amounts are excluding VAT.

I’ve logged a total of 2585,33 hours which amounts to an average of about 53,86 hours a week (at 48 weeks / year, so holidays excluded). A fair bit more than the 44 hours I logged last year.

An overview

Isn’t it great when a project generates revenue without having to work on it? That’s how a silly website as www.quizkalender.com managed to jump to the top of my project list at €73,24 (google ads) revenue for 0 hours of work. That is an infinitive amount of revenue per hour! If only I had spent slightly more time on it…

Secondly, same message as last year: don’t quit your dayjob just yet. Working for the man still pays the bills. When comparing the numbers to last year, I must admit that I’m a little annoyed with myself for trading a 15% price cut for the convenience of working close to home, especially at a time when working from home is the default. No rights to complain ofcourse, but bills were paid 15% faster last year 😉

Thirdly, the big one. QuizWitz. Suddenly teleconferencing became huge and people had to be entertained. I managed to quickly adapt the software to take the streaming delay of YouTube and Twitch into account without affecting the gameplay too much and together with de Quizfabriek we started replaying old live-quizzes on YouTube. A few additional changes soon followed and we fairly quickly gained a bit of an online following.

After testing on a small scale, QuizWitz grabbed the attention of a few bigger players and after some nerve-wracking meetings, tests and experiments we supported a whole series of quizzes at www.huiskamerquiz.be with hosts like (start <namedropping>) Belpop Bonanza (Jan Delvaux & DJ Bobby Ewing), Nerdland (Lieven Scheire & Bart Van Peer), Bahamontes, Sofie Engelen, Xander De Rycke. Not to mention a whole bunch of these livestreams were filmed on the old Studio Mussle location where Mosselen om half twee was recorded for a while. (end </namedropping>)

Meeting your heroes whilst stressing out over the stability of your software and servers: big check! (Having your servers crash on one of these events and working through the night to fix them by next evening: also check.) We’ve also worked with Sitting Bull and Roularta to organise livestream quizzes.

Meanwhile de Quizfabriek started doing their own teambuilding activities. It’s awesome to see that something you helped setting up suddenly kicks into gear and starts accelerating without you pushing it forward.

While the events were ofcourse a strong push for QuizWitz, another thing started happening in april: online sales of the regular platform jumped to heights we had never seen. As soon as the surge started I started concentrating on usability and compatibility of the game and the platform (at this point it was mostly tested on google Chrome only, as this was the platform used at the events). We also wrote a manual on how to use the software in various situations and this seemed to help the sales as well.

QuizWitz made €10.358,82 in work (support at events, excluding extra hands) and €23.600,12 in licenses (including €1.445,01 on Airconsole). Of those licenses, €16.727,17 was made through online sales and €6.872,95 was made through livestream license fees.

As I try to conduct business in an open and transparant fashion (and maybe also because I hope one day an investor will cold call me) I’ve started sharing the QuizWitz key metrics in a publicly available online dashboard. It takes a while to load so be patient.

So yes, QuizWitz took a fairly big part of the year again.

Fourthly Dolumar. Hardly did any work, hardly made any money. Not much to talk about. There’s still a few people playing it, and that games is now 13 years old. Yay me.

Fifthly, we’ve already talked about Quizfabriek in the QuizWitz section. The €1.000,00 revenue I took for licensing is already included in the QuizWitz calculations above (that’s why the total license income doesn’t match the column at the top). While I am taking a little distance from the non-profit organisation, I’m still putting in a quite a few hours 🙂

Technology

And finally, the fun (open source) projects. The CatLab Photobooth project was a rather silly attempt to combine the NFC scanners (that we use at de Quizfabriek for digital drink vouchers) with a remote controller DSLR camera to generate a photobooth that was aware of who it was taking a picture of.

We’ve used it for the Harry Potter quiz to make sure we had a picture of each individual quiz team. It then uploads these pictures to an Amazon S3 bucket and we then used those to generate a little memento of the quiz and mail it to the players. The photobooth project only took care of taking and uploading the pictures, the rest was done by Mathias (from de Quizfabriek) in Python.

I also spent some time on Eukles, a project that currently doesn’t do much more than gathering events from various websites, send emails and send Slack notifications. But hey, at least QuizWitz users now finally receive a receipt when making a purchase.

The CatLab Drinks project also need(ed/s) some fixes. We’ve used it extensively (and by third party bar people) on the Harry Potter quiz and it is … almost stable. We still have some trouble with people moving the card away from the scanner too soon … but it is mostly safe.

Oh, and Tine and I bought a house.

Next up

Honestly, I don’t know. I’ve started talking to a few people on how to keep the QuizWitz ball roling. I poured a lot of hours in the project again and every release it feels slightly more production ready. Getting the damn thing to the market keeps being the real problem and I’m realising it’s not one I can fix alone. The end of the covid crisis will likely result in a drop of the salesnumbers as well, so getting some kind of marketing ball rolling will likely be very important.

I should probably look into getting that Work for hire average back to 2019 level. Even though I’m quite happy with the projects I’m doing at the moment, knowing that there are more lucrative deals out there sometimes stings a bit.

And, as soon as these vaccines are finally rolled out globaly, go on a long holiday and enjoy life a little more. That should probably be a little higher on this list 🙂

Thanks for reading and take care! See you in 12 months.

Categories
English Startup

My 2019 in numbers

Happy 2020! May all your companies turn into unicorns and all your projects be bought by Facebook!

I have a tendency to blindly jump into new projects, lose interest along the way and then abandon them. It’s been a constant in my carreer, so in january 2019 I decided to do something about that. I started doing timetracking on my just-for-fun projects.

Turns out I worked on 16 projects this year, some of them as little as half an hour. I have also kept note of any income generated by the projects, and calculated an hourly income. Note that I’m ignoring any costs involved (servers, transport, equipment and external labour), and all amounts are VAT excluded.

ProjectHoursRevenueHourly
Work for hire1.013,76€ 77.897,38€ 76,84
QuizWitz388,75€ 8.547,76€ 21,99
Dolumar10,25€ 78,67€ 7,68
Quizfabriek336,00€ 925,00€ 2,75
Quizkalender33,00€ 13,78€ 0,42
CatLab Drinks167,00€ 0,00€ 0,00
Kitten Race55,00€ 0,00€ 0,00
Werewolves34,00€ 0,00€ 0,00
Escape game21,00€ 0,00€ 0,00
Research project13,00€ 0,00€ 0,00
Administratie11,00€ 0,00€ 0,00
Word game11,00€ 0,00€ 0,00
Eukles8,00€ 0,00€ 0,00
Dolumar TCG6,00€ 0,00€ 0,00
Trading game2,00€ 0,00€ 0,00
Wittegeit0,50€ 0,00€ 0,00

Since this is the first year I’m doing time tracking, I don’t have running totals of the projects. The bulk of QuizWitz development has happened over the past few years, and a quick estimation shows at least 5000 hours have been put in before (by various people). However, to not completely lose my mind, I have decided to only measure this years activity.

In total, I’ve logged 2110,26 working hours, which is about 44 hours a week (at 48 weeks / year, holidays excluded).

An overview

Don’t quit your dayjob just yet is probably the lesson to learn here. I deciced to turn down a lucrative project in May, in order to take some time off and take on projects a little closer to home. It took a cut out of the hourly rate, but at least I don’t have to drive for two hours every day. But even then, pet projects don’t even come close to working for the man.

Next up: the big one. QuizWitz has been my main project for the past few years, so I’m happy to see at least some revenue coming in. Quizfabriek, a little lower on the list, should actually be added to QuizWitz as well, as any income from Quizfabriek comes in the form of license fees for QuizWitz. That brings QuizWitz to €9472,76 in revenue, or €24,36 hourly. (I’m not counting the 336 hours worked as a volunteer, since none of the other volunteers get paid either.)

The bulk of the QuizWitz revenue comes from offering support at live events and renting out equipment (so basically me doing actual work) totalling €6544,50. That means QuizWitz generated €2928,26 in software sales (including Airconsole).

Related, but not exactly the same: Quizfabriek, our now 10-headed non profit that tries to revolutionise the traditional pub quiz. As stated above, all revenue that is listed here comes out of QuizWitz license fees. All hours put in should be considered ‘unpaid voluntary work’, but just for funsies I split them up anyway.

I’m not sure what happened, but for some reason Dolumar also generated some sales this year. Not enough to keep the server running, but since this game was my first proper try to build a strategy browser game, I can’t bring myself to shutting it down. And obviously thousands of hours have sunk into the Dolumar project, so the hourly revenue is way off. Thanks for the support though!

The last project that generated any revenue was Quizkalender. This project was built to give to provide some free advertising space for our Quizfabriek quizzes. It uses data from various sites to compile the most complete overview of the Flemish quiz scene. When we’re not advertising our own quizzes, we’re using the space to show paid ads, resulting in a tiny bit of extra beer money.

On to another big time-waster, but one that has had a significant impact on the way we organise our quizzes at Quizfabriek. CatLab Drinks is a very rudimentary web based cash register system with support for NFC topup cards. It can be integrated in the QuizWitz quiz software, which allows players to order drinks from the bar during the game. When the NFC topup system is used, players can topup their card and all payments are done behind the scene, so that bartenders don’t have to worry about anything. I’ve released the code under GPLv3.

That leaves us with the projects that have had no value whatsoever. Kitten race was an attempt on an educational ‘classroom game’, but ended up being a refactor of our ‘CatLab Remote’ engine. That same refactored engine was then used to create a party game implementation of the game Werewolves (also known as Maffia in some parts of the world). Both games are still sitting on a shelf and might be released on Airconsole or Steam at some point in the future.

With Escape Game I wanted to see if the CatLab Remote engine could be used for a mass escape game, where tens to hundreds of people would try to solve a mystery or avoid a disaster, but I didn’t get much further than a few sketches.

Finally there’s a bunch of projects where I only spent a few hours on; prototypes that I still want to explore at a later stage. I even have a rough draft of a Dolumar themed card game, but it hasn’t come to the playtesting stage yet.

Technology

Overall, I’ve had a fun year. Not always productive, but I’ve played around with fun ideas and tinkered with lots of things I hardly knew anything about.

I’ve used DMX and WebMidi to automate moving lights and led pars at our quizzes. I’ve used WebRTC to stream QuizWitz to raspberry pi’s connected to displays (to avoid having to use HDMI splitters and unhandly cables).

I’ve played with NTAG213 NFC tags and readers to implement a cashless topup system and used html offline features to make sure the system runs even when internet connection fails.

I’ve made my old libraries compatible with npm and typescript, to make the game development less painful.

Oh, and I’ve also bought a new car!

Next up

I don’t think 2020 will be much different from 2019. I’ll probably try to put in some more work-for-hire hours, as you can’t spend every summer sitting on your arse, but I don’t think I’ll stop starting silly projects and giving up on them. It’s just too much fun.

I should look into more ways to get QuizWitz into the hands of event planners and quiz organisers. Everyone who’s used the software is enthousiastic and our very first client still calls us for every quiz they organise. I feel like I’m leaving a lot of potential on the table. I’m just not very confident reaching out and doing sales. Improving my business skills is pretty high on my list of new year resolutions. Or finding a cofounder who can handle that part.

Finally, I should finish renovating my tiny little house. I haven’t really done any construction work in 2019, and renovating a house of this size shouldn’t take 5 years to finish. 🙂

Categories
English

5 months of QuizWitz on Airconsole

Airconsole is an awesome project by Swiss startup ‘N-Dream’. It offers a ‘game console in the cloud‘ where the games are played on a smart tv / laptop / … and the players use smartphones to as controllers. Most games are party games, so there is an obvious match with QuizWitz.

QuizWitz has been available on Airconsole since july, and since there is very little information on how games on Airconsole generally fare (and there are no NDAs that prevent me from sharing), I’ve decided to share the results of publishing QuizWitz on the Airconsole network.

Statistics: QuizWitz is the 23th most popular game on the network, yay! I should note that the ranking changes frequently and violently, QuizWitz has been jumping between 40 and 20 for the past few weeks.
Revenue since July 2019. Lets not quit that dayjob just yet.

Airconsole has recently raised $3 million in a series A funding round, so I’m pretty excited to see where the platform is going from here.

Categories
Uncategorized

Project digital drink vouchers – part 3

After a bit of a break, I turned back to the digital drink voucher project. Most of the functionality described in the earlier blogs have been implemented, and I have decided to release the whole thing under the GPLv3 license. I have also setup a rudimentary website at drinks.catlab.eu. Feel free to use our hosted instance, just don’t rely on it too much 🙂

I’ve also removed the vendor specific authentication mechanics from the open source project, so you can now just set it up with the traditional laravel authentication forms.

I’ve also started writing some documentation, but for now it’s limited to describing how I’ve designed the NFC topup cards. Please give it a read and let me know if there is any scenario that might still be causing problems (other than the ones I’ve already described in the file).

Next week we’re using the NFC cards ‘in the wild’ for the first time. An earlier test with 3 teams at the first quiz resulted in a few bugfixes, but now I’m confident that the system should work as expected.

Hopefully…

Categories
Uncategorized

Project digital drink vouchers – part 2

Raspberry pi

After driving for 20 minutes to buy a microsd card, I opened the raspberry pi box to discover that a microsd card was included in the box. Yay me.

I started out by installing Ubuntu Core on the Pi, since I thought it would be easy to create a snap from the nodejs application that would talk to the pcscd service. This proved a little more difficult, so after about half a day trying I ended up installing Ubuntu Server on the Pi. Installation of the required services and nodejs environment went without issue.

Talking to the NFC tags in nodejs was pretty easy; I used a nodejs package that already handles most of the conversation between pcscd daemon and the nodejs environment, and the repository included examples on how to passport protect NTAG213s, so that jumpstarted development.

The NTAG2x password protection only allows you to set a 4-byte password, so you can’t really call it a security measure. I decided I would use the 4-byte password to discourage users overwriting the tag, but the true authentication would lay in using an SHA-256 HMAC on the content I would write. The 32 byte signature already takes quite a big bite on the 144 byte total available memory, but given the offline requirements this seems like a fair tradeoff. The password also only enforces write protection, I decided to keep all data on the card readable; since I’m planning to open-source the whole project it doesn’t seem logical to disallow users to read their won tag.

In our current ‘CatLab Drinks’ application, an organisation can organise multiple events. Our own organisation is active in multiple locations, so it makes sense to have a separate pricelist for each location. Early on we have decided that credit bought at one event would be transferable to other events, so each nfc card is linked to the organisation, not the event. So I gave each organisation their own ‘nfc secret’ which is used to calculate both the NTAG213 password and the HMAC.

Since we’re planning to allow users to topup their credit with their cellphone, I decided to encode all data in the NDEF format. This way I was able to write one NDEF record with the user specific URL for topup, while the signed wallet data would be stored in a second NDEF record. There is a very, very small overhead, but giving users with an NFC-ready phone the ability to scan their card and topup straight from their phone, seems worth it.

Signed data

It took me some sleepless nights to figure out what to actually store on the NFC tags. ‘Current balance’ is an obvious one, but the requirement that not all POSs need to be online at all times makes the whole thing a little more difficult. In the end I decided to take a practical approach that – according to our sale statistics – would work out fine:

  • balance
  • transaction count
  • timestamp last transaction
  • 5x last transaction amount

All data is stored in 32bit signed integer. I briefly thought about storing the timestamp in 64bit, but it would be silly to think this format would survive another 19 years (and also I couldn’t figure out how to write 64 bit signed integer).

There are only 2 vital elements of this content: ‘balance’ and ‘transaction count’. Balance is obviously required, since otherwise it would be impossible to check if a user has enough credits to buy a drink. Transaction count, however, is also of vital importance. For starters it avoids people rewriting old data to the card. If they would do so, the POS would notice that the last seen transaction count is lower than the new transaction count, and can then dismiss the card.

(There is still a situation where an offline bar could not be in the possibility to transmit the new ‘transaction count’ to the other bars, and a user who decides to go to an online bar would be able to double-spend, but honestly this situation seems too uncommon to take into account. Also, when the offline bar would finally come online, it would upload all its transactions and the card would be charged into negative values.)

The 5 last transactions are not really required, they are just used for online POSs that don’t know about offline transactions. An online POS will always upload the card state to the server, and the last 5 transactions could then be used to fill in the gaps between the last known transaction and the current transactions. If the amount of transactions would exceed 5, a 6th ‘unreliable’ transaction would be constructed that holds the difference between the Nth and the 5th transaction.

Finally, the timestamp is not used at all. I’m not sure if it is usefull for salting purposes, but even if it’s not it might be a nice-to-have for the future.

Mirroring

I took some time checking the security requirements and I talking to some people about the format; it seems a reasonably secure system. So I got started and tried to write the data to the NFC cards.

One of my main concerns was writing to the tags. Writes can be interrupted at any time, and since the data I’m writing is rather long there isn’t any tear-protection available. I briefly thought about writing the balance data twice, so that there is always one record to recover from, but the space limitations of NTAG213 finally forced me to abandon the idea.

In the end I just went for storing the latest known (valid) data in the browser localstorage of the POS terminal, and throwing a big warning message whenever a write fails. This way, a user that presents their card and interrupts the write, will be asked to scan its card again. If a user would at this point walk away, he would end up with an invalid card. It will be up to my UX design to make sure that the bartenders handle this situation correctly and ask the user to scan their card again.

I also improved the NFC nodejs service to only write data that has changed since the last write, lowering the risk of tearing. Since the first NDEF message (with the topup url) will always stay the same, there is no reason to write that on every transaction.

Topup & spending

With the write-procedure implemented in a reasonably reliable way, it was now time to implement the POS side of things: allowing our own staff to topup cards and allow bartenders to sell beers… More about that in a next blog.

Categories
Uncategorized

Project digital drink vouchers

Since I am a huge fan of starting projects and never finishing/polishing them, I decided to give ‘nfc based digital drank vouchers’ a try. I am part of an organisation that regularly organises quizzes using our own QuizWitz software, and I am constantly trying to improve and optimize the way we organise our events.

At these events we sell drinks and snacks, and since I recently got interested in NFC I decided to see if I could introduce some cashless system that would replace our current foolproof ‘paper vouchers’ system. There are ofcourse loads of existing solutions on the market, but since we have absolutely no budget for that I decided to see if I could do something DIYish.

Last year I already implemented a simple webbased cashier system that allowed us to track what drinks were sold and also allowed players to order drinks straight from there table. We would then bring the drinks to their table and demand the required amount of ‘paper vouchers’. Some people would come straight to the bar and order drinks there, but both situations were handled by a very simple web based cashier system. And now I want to play with NFC cards, so … let’s get going.

The Goals

Our players have to register before they can join the quiz, so we already have the players grouped in teams of 4 (or less). My goal is to give each team a single NFC card that they can topup and use to buy drinks. At the same time, the ‘remote orders’ also still have to be possible, and I don’t want bartenders to walk around with NFC readers (since I only have 1 and it is not exactly portable). Additionally, since there is no budget, I try to keep hardware costs as low as possible and try to reuse parts I still have laying around.

  • Each competing team should receive 1 NFC card that can be used to topup and buy drinks.
  • Teams should be able to order drink through the existing app, so the team should be linked to the NFC card. Payment for a remote order is done at the time of the order, not at the time of drink delivery (so bartenders don’t have to walk around with nfc readers)
  • Players should be able to topup their credit online (through an online payment gateway). Players should also be able to topup in cash at the entrance.
  • The topup station must be connected to the internet.
  • It should be possible to have multiple POS (point of sales = bars) and, while the bars should try to maintain a connection to the internet, such connection should not be required.
  • The topup station at the entrance must always be connected to the internet.
  • We have an android tablet that we use at the bar, and we intend to keep using that.
  • I have a raspberry pi and 2 NFC card readers (ACR122U) that I intend to use. I also have 80-ish NTAG213 stickers that I want to use for this.
  • The user interface must run in the browser.

Having the requirements set, it is clear that the available credit must be stored on the NFC cards, which poses.

Babysteps

Since I have no experience with NFC I decided to start with trying to get that working. Since I don’t want to bother with trying to get android to play nice with the external NFC readers, I decided to connect the NFC reader to a raspberry pi 3 and install a socket.io server on the pi. All NFC communication will thus go over the network trough the rasperry pi. So I bought a microsd card and connected everything up… Wish me luck.

Categories
Reis

Mind the gap 1

Daar gaan we weer: met het halve gezin voor twaalf dagen op pad. Ierland, ditmaal, met een aantal tussenstops in Engeland. Geen idee waar we eigenlijk precies heen gaan. De laatste weken waren zodanig chaotisch dat ik de hele planning niet helemaal gevolgd heb. Elke dag een nieuw verrassing, dus. Maar dat is ook leuk.

Vandaag ging de reis naar Cambridge. Cambridge is een stad in Engeland. Cambridge heeft een universiteit. En Cambridge wordt al jarenland verkeerd geschreven. Het is namelijk Camebridge. Of zo wordt het althans door de plaatselijke bevolking geschreven.

Camebridge – ik probeer de juiste schrijfwijze te verspreiden – ligt op ongeveer een uur treinen van Londen. Londen is de hoofdstad van Engeland en is bereikbaar vanuit Brussel, per trein, via de kanaaltunnel. Op minder dan twee uur sta je vanuit Brussel in Londen. De wonderen van de technologie, meneer.

Je kan echter ook per boot gaan. Dan ben je een beetje langer onderweg. Als je, ter illustratie, om kwart voor negen (in de ochtend) in Merelbeke om een trein stapt, dan ben je rond middernacht (niet meer in de ochtend) in Camebridge.

Op de zeven uur durende boottocht (van Hoek van Holland tot Harwich – geschreven als sandwich maar dan met een H) heb je echter de mogelijkheid om: naar buiten te kijken, tergend traag satelliet internet te testen, te roken in een acht beaufort westendwind, een hamburger met extra bacon te eten, boonanaza te spelen, tot tweemaal toe te plassen, nog maar naar buiten te wachten tot alle camions van de boot zijn gereden omdat “de voetgangsbrug kapot is en je daarom via het ruim naar buiten moet”.

Oh, en je kan er ook naar de cinema gaan. Als je betaalt, tenminste. Dan kan je er helemaal alleen naar “The Theory of Everything” kijken en hopen dat je zelf nooit vast komt te zitten in je eigen lichaam.

Van Harwich naar Ipswich met de trein en van Ipswich naar Cambridge. Dat is, als ze een trein vinden om je mee te vervoeren. Ipswich leek niet zijn beste dag te hebben vandaag want, hoewel de geautomatiseerde stem het steeds over een trein had die binnenkort zou komen, bleef een omroepster van vlees en bloed ons mededelen dat ze eigenlijk nog steeds geen trein gevonden hadden.

En toen zo’n trein er uiteindelijk kwam, moesten de deuren niet enkel met de hand open gedaan worden; er zat niet eens een klink aan de binnenkant waardoor de uitstappende reizigers hun arm door een raampje moesten steken om de deur te kunnen openen. Gelukkig hingen er aan elke daeddeur instructies over hoe dat precies in z’n werk ging.

Om middernacht (elf uur plaatselijke tijd) dan toch Camebridge binnen gereden. Ingescheckt in de jeugdherberg. De bar in de herberg net gesloten en geen pub in de buurt te bekennen. Dus maar meteen het bed in en schrijvend overdrijven over wat eens mens op zo’n treinreis zoal beleeft.