coloured shapes

Meet Logike 🔵🔺🔶

This fall, I started building a puzzle app called Logike. It’s a game that focuses on building logic skills, and from a programming and design perspective, it’s also the most challenging project I’ve ever brought to fruition. There’s a lot to talk about, so I broke it down into a few parts 😉

TLDR: If you just want to try Logike, you can here!

The story

With few exceptions, most of the memories from when I was very young are faint at best. One such exception relates to when I was in Kindergarten. We had a lot of “free play” time, as you do when you’re 5 years old, and during that time we could chose from a whole bunch of different activities. Actual examples include: making necklaces with beads, taking apart old broken motherboards using pliers and hammers, or in the more educational department, puzzle games to develop logic skills.

My favourite game involved placing coloured shapes on a grid in order to satisfy a logical conditions on the supplied cards. They’d start out really easy and get progressively more difficult, to the point where they were no longer feasible for the average 5 year old. It was a lot like Sudoku, but the difference was that this game mixed and matched and layered many different and nuanced types of logic. Sudoku games can be solved with the same algorithm each time, whereas the one to solve this game was far more complex and varied.

child playing with legos

Here’s a picture of a kid playing with legos, which will be replaced with a picture of ME playing with legos, once my mom finds it 😂  
photo by Kelly Sikkema

Fast forward twenty years and I’m looking for a project idea to help me learn front-end. I don’t remember what made me think of the puzzle game I played as a kid, but it popped into my mind and I went with it! No-one seemed to have digitized the game, and I realized that through code there were ways to take it even further.

What it looks like

There are two major things that the app lets you do: solve puzzles, and build them. Lets start with the part where the fun happens!

Solving Puzzles
an easy puzzle

Logike’s tutorial puzzle.

Solving puzzles is pretty straightforward: each puzzle consists of a set of logical conditions, and it’s up to you to move coloured blocks onto the board so that all of the conditions will be true.

However, the conditions can become quite complex

The logical conditions for a moderately difficult puzzle.

The logical conditions for a moderately difficult puzzle.

Or downright difficult, like this one…

The logical conditions for a difficult puzzle

The logical conditions for a difficult puzzle

Instead of telling you where specific entities (the coloured shapes in this case) need to be, this difficult puzzle only tells you about entity properties (colours, shapes) that could apply to a slew of different entities!

For now, the logical conditions are:

  • Some entity or property is here.
  • Some entity or property is not here.
  • Some entity or property could be here.
  • Some entity or property is/isn’t/could be here relative to some other entity or property.

Additionally, the grids for the logical conditions can also be smaller than the puzzle board itself, meaning that a 2×2 condition could theoretically apply to one of 4 places of a 3×3 board.

Building Puzzles

As for the puzzle builder, it’s a lot less mature than the rest of Logike, but functionally it does what it needs to. Initially, I wrote all the puzzles by hand in one massive JavaScript class. It was great for prototyping, but it wasn’t ideal for production, so I refactored all of the puzzles into JSON files. This is what one logical condition looks like in JSON now:

one logical condition, in JSON

one logical condition, in JSON

Imagine writing dozens of chunks of code like this by hand, and trying to visualize a puzzle with them. It just isn’t pleasant, so I made a GUI (Graphical User Interface) that writes the JSON for you! 🎉

The builder puzzle

The puzzle builder.

I talked about entities and properties a bit earlier, but it’s really in the builder that they start to shine! By abstracting the different parts of the puzzles above, I realized that the code I was writing could be applied to far more than just coloured shapes.

In the first part of the builder, you can chose a different set of entities than the classic shapes, and you get to chose the size of the puzzle as well! Technically, there’s no maximum size for the puzzle, but it’s currently limited to a 5×5 grid until I smooth out the design to accommodate larger ones.

The logical condition builder.

The logical condition builder, being used with the “animals” entity set.

The most important part of the builder is the part that writes the logical conditions. Each one is comprised of a selector (the entity or property you’re referring to in the logical condition) and a grid filled with conditions. The tool lets you visually build each grid, and see the puzzle as it will appear when someone’s trying to solve it.

When you’re done building a puzzle, it’s time to name it and download it!

When you’re done, you come up with a clever name, rank the difficulty of the puzzle, and the download the resulting JSON. There’s currently no user accounts, or database to deal with storing user-generated puzzles, but this is a good first step. A teacher could technically build a bunch of puzzles and send them to their students, who can load them up on the puzzle selection screen.

Under the hood

In the past, I would go into a programming project head-first, and start coding immediately. While this would be great for my short term motivation (features being built, and fast), in the long run it led to depressingly messy code, and made for unsustainable projects. Logike was the first project where I actually took some time to work on the architecture, and boy did that pay off!

Part of the architecture for Logike.

Part of the architecture for Logike.

This planning allowed me to build the app in the most efficient way possible, given my current skill level. It also made it possible to shrink my puzzle files down to sizes measurable in bytes!

The whole thing is built in React, so it’s a mix of HTML, CSS, and JavaScript. Additionally, anything that isn’t part of the core application logic is JSON. All of this lives on a free Heroku server, at least for now.

As far as technologies go, there’s not much fancy programming witchcraft going on, but that doesn’t mean that the project itself is simple. There were a bunch of technical challenges that had very little to do with the tech used, the biggest one was making the code sufficiently generic.

I could have taken a bunch of shortcuts and just hard-coded everything based on the coloured shapes and left it at that, but then I’d be missing out on the chance to make a much more powerful too. So I ended up with a bunch of classes like this one:

// an Entity is the main element that is manipulated in the puzzle.
// it has properties, a name based on the properties,
// a common name which may differ from the name, and an image
// ex: red square, potato, JK Rowling

class Entity {
    constructor(commonName, properties, img) {
        this.properties = properties; // an array;
        this.name = Object.values(properties.map((property) => {
                return property.name
            }
        )).join("-");
        this.commonName = commonName; // for display purposes ONLY
        this.img = img;
    }
}

export default Entity;

With all this abstraction, consistent and meaningful naming becomes super important, and at a certain point collisions can occur between your app’s logic and the programming language’s reserved keywords and pattern names.

  • Entities could have been called objects, but Object is a pretty important keyword that’s part of JavaScript.
  • Properties could have been called parameters, or attributes, but parameters are found in JavaScript functions, and attributes are found in HTML tags. Technically, in React, props stands for properties, but no-one writes it out the long way, even in their code, so this was the safer option.
  • Selectors are used in CSS, but at least they behave the exact same way in Logike’s logical conditions, and it wasn’t a reserved keyword.

The second biggest challenge was validating the pure logic found in the puzzles.

This is a bit of code that validates whether an individual logic cell in the logical condition is being respected.

// returns false if the selector is found in a place it's not supposed to be. Otherwise returns true
    const validateLogicCell = (selector, ansCell, logicCell) => {

        var matchesSelector = false;
        // checks to see if the answer matches the selector
        if (selector === ansCell) {
            matchesSelector = true;
        } else if (selectorIsPartial(selector, entities)
            &&
            ansCell.includes(selector)
        ) {
            matchesSelector = true;
        }

        var selectorCanBeHere = false;
        if (logicCell == null || logicCell === "empty") {
            selectorCanBeHere = true;
        }
        var selectorIsHere = false;
        if (logicCell === true) {
            selectorIsHere = true;
        }

        if ((matchesSelector
                &&
                (selectorCanBeHere || selectorIsHere))
            // matches selector in specific cell, therefore the cell needs to contain true or null
            ||
            (!matchesSelector
                &&
                (!selectorIsHere || typeof logicCell === "string")))
        // doesn't match selector, therefore the cell must contain false or another selector
        {
            return true;
        }
        else {
            return false;
        }
    };

Does your head hurt? 😂

Validating that a blue circle is in the top-right cell is easy. Validating that and every other thing I’ve mentioned is a whole other story, and likely makes a terrifying looking flowchart!

How to try it

The puzzle app lives at logike.confusedretriever.com and eventually at logike.app once I figure out how SSL works.

It works on desktop or mobile, though there’s some features that are restricted in the puzzle builder on iOS for the moment.

Let me know what you think, and if you make some cool puzzles be sure to share them with me! 😄

What’s next

What I’ve made so far is just the tip of the iceberg. I see a lot of potential with Logike, so I’d like to keep developing it.

Here’s the current to-do list, more or less in order:

  • Puzzle Builder design improvements
  • enable editing logical conditions
  • enable reordering logical conditions
  • Persistent save state after end of browser session (accounts + database?, Cookie?)
  • Ability to share puzzles without downloading/uploading.
  • JSON V2 (remove ALL duplicate data and add IDs to entities and properties instead)
  • more robust entity validation (unique names that aren’t based on properties)
  • Creating new puzzles
  • Tweaking old puzzles
  • improving entity set images
  • Fixing nasty iOS bugs
  • Fixing toast jitters
  • Improve test suite
  • Validation improvements (duplicate entities, more robust property selection)
  • Puzzle builder validation (to give feedback preventing impossible puzzles)
  • Ghost images to fix sizing issues
  • Design improvements to support large puzzles
  • Shuffle-able logical conditions
  • Onboarding flow
  • Entity set builder
  • URLs that lead to specific parts of the app (builder, specific puzzles, etc)
  • logike.app SSL

For now I’m taking a bit of a break from the puzzle app to work on Compass, but I plan on alternating between the two projects until I feel like Logike is pretty mature.

Phew! 😌 That was a lot!

Thanks for taking the time to give this a read, and I’ll keep posting updates here whenever I start chipping away at the next next Logike release 😊

Until then, keep being awesome! 🌠

Image

🔒

So I was trying to add SSL to logike.app, because you need to use SSL to make the new .app domains work, and I accidentally added SSL to the blog! 

Hurray, I guess! 🎉

#IHaveNoIdeaWhatImDoing

Web dev 1.0 – The Process 🌱✨👨🏼‍💻✨🌱

For the last 3 years or so, I’ve been immersed in the world of code. What started as a simple workshop to help me build an MVP for an app turned into a full fledged rabbit hole, and before I knew it, I was working for a kick-ass EdTech company and spending my weekends sipping and writing Java. I’ve learned a ton, but the journey definitely hasn’t been linear.

Learning to code during evenings and weekends is great, and got me a working prototype of my Android app, but it has it’s limits. No amount of passion or drive can replace putting in the time, and I wanted to find a way to learn more, faster, without necessarily going back to school.

It just so happened that at the same time that I was feeling this urge, Les Pitonneux, a non profit that helps people learn to code, had a new cohort for their Lab12 program that was about to start. I’d already done a series of Android workshops with them, and I’d gotten a lot out of it, so I figured it was worth a shot.

Lab12 is twelve week “un-bootcamp” for self learners. There are no classrooms, no lectures, and certainly no fixed curriculums. You start out with a goal, usually a specific project, and with the help of mentors and your peers you work towards it for the duration of the program. It’s good to have a sizeable amount of time to dedicate to learning each week as well.

In my case, I wanted to make an interactive logic puzzle, while using modern web development tools that are similar to what’s being used where I work. The puzzle is something that could be integrated into Netmath, but more importantly, the whole process would help me become more familiar with the possibilities and constraints that come with building web apps. Design that’s informed by development is more robust, so I asked to be able to dedicate some time in my usual work-week to learning JavaScript and React.

A mural near Notman House that I like. It’s kind of chaotic, just like that front-end programming landscape!

Lab12 was divided into 3 parts for me: ideation, knowledge acquisition, and building. First I needed to figure out what exactly I wanted to do. Yes, I wanted to build a puzzle app, mais encore? I needed to scope the project into something that was achievable in 12 weeks, and also map out how all of it would be organized and what technologies I needed to learn.

The learning part is tricky, because I found that this is where motivation can take a bit of a dip. Optimal learning happens when you build onto prior knowledge bit by bit, applying what you learn as you go along, but it can be tempting to just go out on a limb and keep learning a bunch of things that you aren’t going to use right away.

One of the resources I was using, Eloquent JavaScript, had some particularly thorny bits that, while fascinating, were utterly useless for the first development phase of my project. I read on a bit further than I had to, and during that week where the puzzle app wasn’t moving forward I felt a big dip in my energy. It’s a tricky dance to balance learning and progress, but when you get the mix right it feels almost magical!

Dance magic dance!✨🕺✨👨🏻‍🎤✨💃✨

I spent a little over a month learning quite intensely, then came the building phase. There isn’t a ton to say about it other than the fact that it’s one of the most rewarding phase of any project. It’s when your planning and learning finally come to fruition, and you prove to yourself that you can do more than just follow along with a tutorial or copy/paste Stack Overflow. This is where I usually show off what I can do on Twitter. 😂

(By the way does anyone know the proper punctuation of emoji in a sentence? Do they replace the period, or go before/after it?)

At the end of the 12 weeks, I had a working prototype that was actually pretty fun to use. There were a few bugs in it, as is the case with most software, but nothing particularly worrisome. Setting aside the extra time to code made a huge difference and gave me a nice boost of momentum for my learning goals. I’ve taken the puzzle app even further as well, by making a puzzle builder, but that’s a whole story in itself!

I guess the takeaway is that if you feel like you’re in a bit of a rut or you’ve hit a plateau, there’s probably a way to fix that and take your game to the next level. In the immortal words of Enrique Iglesias, Baillamos! 💃

Status

Something wonderful has begun 🚀

After a few months making puzzles, I’ve officially started working on Compass again! This time however, I decided to do things right and actually plan a bit before I code! 😅

post-its mapping out the inner workings of compass

Mapping out the inner workings of my app.

When I was building the puzzle app, having a clear map🗺 was invaluable. Instead of wasting time questioning my architecture, I was coding it, and checking off boxes in my diagrams as I went along.

I could also show others how my app worked, without diving into the code itself and being like “see this function? It does X… that class lets you talk to Y… what do you mean you don’t understand?! THERE ARE COMMENTS!

the architecture of the Logike app, mapped out with sticky notes

The architecture behind the Logike app

I currently have a love/hate relationship with code architecture. On one hand, I just want to hunker down, learn Typescript, and spit out my gem💎 in the making! On the other, it feels a lot like a game of Risk or Ticket to Ride, and I love a good strategy game.

By mapping out your project, you can be very strategic about the code you write and avoid going back and changing the same lines every couple weeks. Obviously no path is perfect, but it feels really cool to be able to make and educated guess about which one is best, something I definitely wasn’t able to do a year ago! 🎉

My first hackathon: do_action_montreal 👨🏼‍💻

A few months ago I attended my first hackathon. For those who are unfamiliar with the term, a hackathon is an event where people who may not know eachother get together and build something for a common cause. They’re pretty popular in the tech community, and typically last a few days at most (though there are exceptions). The hacking is more of a reference to putting together something quickly than of breaking into the mainframe, or at least that’s my understanding of it.

I’d been a bit hesitant to go to this kind of event in the past, mostly because I was still learning the ropes and I was afraid to slow my team down. Imposter syndrome is real.

One day, I see a post in the Pitonneux Slack for something called do_action_mtl. What stood out with this particular event was that they were specifically looking for designers, and since my foundations are in design, I signed up.

The goal of do_action_mtl was to make a WordPress site for non-profits with limited technical knowledge. The non profit that my team was paired with was called Beigne Oui, which is French for Donuts Yes, and also a pun. 🍩

Donuts? YES!

The day started way too early for my liking (Saturdays are made for sleeping in), but there was plenty of free coffee to compensate. We met our teammates, and got started as soon as we were sufficiently awake. We had a full day to make a site powered by WordPress, populate the content, and make sure everything looks polished.

It quickly became clear that when faced with exacting time constraints, being able to think on one’s feet is far more important than technical prowess. As the designer on the team, I had to make sure that everyone had specs early on so as to not waste time. But that proved to be quite challenging.

Usually, when I design something for a client, I like to spend a bit more time up front to really figure out their needs. In this case, Corin from Beigne Oui was there, but we couldn’t afford to let the rest of the team just sit around, so a lot of stuff was improvised on the spot. I found a good compromise was to sit next to her while I worked, that way I’d get instant feedback along the way.

I also typically build WordPress sites from scratch, using Pinegrow. That gives me incredible control of my design compared to doing something based off an existing theme, and I can split my page elements into components that can be used across different projects. This is perfect for the one man show I’m used to when building sites, but it’s not the most well adapted to a hackathon. Not to mention the fact that most people don’t even make WordPress sites like that. In the end we chose a free theme that was being given by one of the event sponsors, and we just tweaked it as needed.

Once we knew which direction we were headed in, things went relatively smoothly. The entire afternoon part of the day was a big rush of making final designs, building them, and polishing. Near the end when my designs were done I got my hands dirty with some of the CSS too, to speed things up a bit.

In the end this is the site we delivered, which is not bad for a chaotic day’s work volunteering!

Our team for do_action_mtl

Our team for do_action_mtl … Not my best selfie 🙃

Would I do it again? Yes!

Would I change anything? Oh yeah!

Had I done something like this before, I would have started designing something basic before the hackathon itself. Nothing major, but I would have gotten all of the info ready and made a few sketches so I could hit the ground running on the day of the event.

I also would have put some more thought into how to divide some of the work. I’m used to building what I design, but not necessarily passing those designs to a developer. Since the hackathon this is actually something that I’m doing a lot more at my job, and I’ve definitely improved.

Hackathons have tons of transformative potential, both for the participants and the causes they support. I’d recommend them to anyone! 😊

I made my first React Component! ⚛️

I created a Grid Component.

It accepts an array of arrays in order to structure the cells inside of it, and it automatically resizes to be as big or as small as I need it to be. The cells can contain anything, even other grids!

This is what using the grid looks like in React:

<Grid cells={THE_ARRAY_OF_CELLS_GOES_HERE}/>

It outputs a table, which is great because coding what you see below by hand in HTML is the very definition of hell 🔥.

a react component that consists of a 3 by 3 grid that cointains other 3 by 3 grids and random content like text and emoji(yes it’s hideous 😉 … there’s no CSS in it yet!)

UPDATE:

This was awful to style because tables kind of suck, so I stopped trying and came up with something else.
I made another version of it using divs and Flexbox in the end, and it’s actually beautiful!