Scribbly

the story behind this website

The idea for this website randomly arose one day, when I was playing a game of Skribbl.io with my friends and something bothered me. Specifically I didn't like how it's kind of annoying that your custom word list doesn't get saved in browser, so you need to save it manually not to lose it.

On an unrelated note, not long before I was trying to make a game that would include a multiplayer element. Whilst browsing for ways to incorporate it, I found WebRTC.

So when I was thinking about things I would add to Skribbl.io I remembered about this WebRTC thing and figured it would be a good practise to try to remake the fun drawing game in my own style.

Why I never finish projects

So starting this fine endeavour, I asked around a bit if anyone has tried to do this or something similar. You know, to get some tips on how to best approach this. While noone in my close friends group ever made a similar project, almost everyone advised to use some sort of CSS framework. I'm not kidding, literally everyone.

Of course, as per usual, I said to myself "alright, lets make a vanilla CSS mockup and then we'll see". And this was the start of my demise.

Lucky strike with finding learning resources

First things first. If I want to even come close to making a Skribbl.io clone I'd need to make a very basic drawing application. And so the Googling journey begins.

Surprisingly enough, the first result had everything I needed. I quickly copied over learned about how to make a basic drawing app. A few modifications and BAM! Drawing part done.

There's more than one way to browse the web

Different people have different needs. That's an undisputable fact that should always be included into website development (among other things, of course). And by that I don't just mean people with disabilities, but also mean to point out that different people can have different preferences when it comes to browsing the internet.

I'm no expert when it comes to accessibility, but I learned that there is a point to links having underlines and different colours and buttons changing visually when hovered over. The point is general recognition. People are more likely to notice that something is clickable if it looks like clickable things on other websites.

There are also other things, as having a familiar layout of navigation elements and navigation through the clickable things with the tab key. Another important one is knowing when to use a specific HTML element as they usually have a semantic meaning along with the functional one. And if you are ready to go the extra mile, there's ARIA.

Fun with CSS

So I have a love/hate relationship with CSS. I find its capabilities amazing and there's always something new "made with only CSS" that is just mind bending. When they added CSS Grids and Flexbox I felt like I can make any layout in the world.

But then there's practical side. While I learned all my CSS from just fooling around with it and have accumulated knowledge for more years than I care to admit, there's always that one little thing that catches you off guard, something that doesn't quite work as it seems. If you ever written any, you know exactly what I'm talking about.

What this boils down to is me, sitting behind a computer at 4am, thinking about how to make a box keep its darn aspect ratio when everything around it is responsive. And this leads to rewriting the whole CSS file, from ground up, for the 5th time... and the aspect ratio is still not fixed... and I just need sleep at this point.

Things take a weird turn

So at weird hours come weird ideas. After a few days of minimal sleep and a sleeping schedule of a vampire, I need a break. And what better way to relax than to listen to some chill music. And that, at least for me, would be old jazz.

While searching for the right playlist I came across online jazz radios. Interesting. And jazz can be pretty old some times. Okay. Connect the two together and you find old public domain online jazz radio station. Fun.

And because of sleep depravation and sudden spike of jazz appreciation, I get the bright idea to try and add this radio station onto my website. Lo and behold, it's pretty simple and 10 minutes later, we have a nice button at the top right that toggles the playback of the online radio station. Cool.

But this arises a question. While usage of public domain material is fair game (most of the time), what about this specific radio station. The short and the long answer is "I don't know". If you, the reader, know more about this, please contact me via service you can find on the author page.

Actually thinking through CSS

After a crushing defeat at the battle of CSS I finally came to my senses and decided to plan things out. I sat down in front of a blank piece of paper and drawn a phone, tablet and monitor.

In reality, they were just different sized squares and I planned out a desired look for this webpage. A few iterations later I had something that made sense and started to rework the entire CSS file for the n-th time. But this time I had a plan.

First things first, I decided to pursuit a mobile first approach. This made things significantly easier and I have no idea why I never start like this. There's just something in the paper that makes me remember about this. But tl;dr: you should always plan first, before starting to write CSS files to oblivion and back.

Blissful ignorance

This should also be the time to plan the positioning of HTML attributes and think about general accessiblity. And to a degree, I did all that. But it's really easy to slip and think things through with a "design first, accessibility second" kind of approach and this is almost always a bad idea. But sometimes you just forget certain things. Good thing websites are not set in stone after you publish them.

the CSS gods show mercy

Usually when you don't know how to do something, you google it. But when you don't even know how to pose a question, you ask your developer friends (the only people willing to listen to your idea long enough to understand it).

Funny thing is that some times (dare I say most of the time), after you explain your problem to a person, you gain some clarity about it yourself. So it even helps if you explain things to peolpe who don't necessarily know how to code just for that reason.

Skip forward and after who knows how many iterations of CSS, I finally got it to play somewhat nicely. That mainly means nothing gets magically hidden or grows out of control at certain screen sizes. This is the time to try to open your website on every device you own and not forget about screen orientation.

oh hey, i can use this

I'm studying informatics and that brings about a certain amount of work. This time around we got an assignment to make a website. Immediately I thought of this little project. Great, let's combine hobby and study, what a great idea, I'm sure nothing bad is gonna happen.

Let me start by saying this, to be fair, this project is a bit more advanced than what the assignment was requesting, but I just couldn't help myself. At first it seemed like a good idea for a while, but as time passed it became abundantly clear that I overscaled the project and am not going to have enough time to finish everything by the due date.

But my luck was found in the detail. As I previously mentioned, the project is more advanced than the assignment and there we go. I can only make the parts of it that are important for the assignment and finish the whole thing later. Now that sounds doable.

saving time by not doing the required work

So the assignment has two parts, the project and a report. The project is this website, but a report can't just be an afterthought. As I was running out of time I remembered the professor telling us that we can include the report in our website. So instead of writing and formatting a Word document, I figured I'd do this page instead.

The idea was good, but the reality of it is that it has taken around 3h to write to this point and I'm still not done, with the project as a whole or writing out this page (let alone finished with revising this massive wall of text).

CSS corrections - final edition

about mydevice.io and landscape media query and learning about aspect ration media queries

Alright, let's go back to square C, meaning of course the CSS. As expected we're not nearly done with the style part of this website and things continue not to work in one way or another. The biggest problem of all still being how the drawing app still doesn't look good on mobile or tablet. The biggest problem is the landscape orientation where we want the canvas area to take up as much of the screen as possible while still keeping the 4:3 aspect ratio.

But let's examine the problem from a distance. Why am I having such a big problem styling it the way I want it to look. I mean PC is in landscape too, why is it so much trouble on smaller devices? Well the thing is that the phone is much smaller than a monitor and that your browsers address bar etc takes much of the vertical space. So we really want to maximise the height of the canvas element as much as possible because after all, you can't really draw anything if the canvas is only about two thumbs high.

We can't really keep the same layout of the elements as in portrait orientation, mainly because the tools area take up much of the precious vertical space, so the only way is to position them on the side, where we have extra space since phones are pretty long these days.

new game features

So while I was watching people use the drawing page, I noticed they were always searching for something that wasn't there. Now the specific things they were searching for were different brushes, undo button and even a load button so they could continue from where they left. But there was always one thing that everyone was missing. An eraser.

And from all of the requests, this one was the easiest to implement so there was really no excuse not to.

Another thing I noticed was that while choosing colours, people forgot which colour they selected or didn't know if they hit or missed the button. So I added a function that colours all the circles of brush size selection to the currently selected colour.

one page is not like the others

So nothing on this website is super complex, be it layout or content. It's pretty simple to reorganise the layout to work in mobile portrait, desktop landscape or anything in between. But that's not really the case for the drawing page where we really need the canvas to take as much space as possible and always keep its aspect ratio.

So this is the first time that I actually need to think not just about width but also about screen orientation when defining media queries. Because there is a big difference if you try to draw with a tablet in portrait or a mobile phone in landscape.

The solution here is moving the tools bar from the top of canvas to the side when a device that is smaller than desktop is used. This immediately helps a lot, but I realise that moving the canvas besides the normal flow of the webpage would be even better, though maybe that wouldn't look as nice. I might revisit this in the future.

This is also the point where I noticed that my previous CSS solutions for holding the aspect ratio of the canvas were more of a hack than a real solution, which became painfully obvious when canvas deformed while viewing the website on a tablet in landscape orientation.

but this works on my device

After dealing with the canvas aspect ratio problem I realised that my media query breakpoints were all over the place by now. While it does help to set them based on content rather than trying to cater for every device, having a solid base breakpoints is much more useful. This article along with a website that shows your devices screen metrics helped me immensly with setting sensible base breakpoints that should be quite future-proof.

I also realised that it's unrealistic to try to draw on a mobile device in landscape orientation and that's why I also added a message that asks you to rotate your device in this case. There's just no nice way to display canvas in that specific case with my website layout as it is right now.

calm before the storm

Okay... now "everything seems to work", says every developer before everything breaks. But seriously, things are pretty functional at this point and I can't find any problems across my devices. Things are finally good.

This means that I can finally start tackling the main goal of this whole project, learning and implementing WebRTC for multiplayer functionality. (but we're not really done yet, are we...)

okay, just one more thing

One of the most important things to do before you can consider a project "usable" is to ask people to try it out and see what bugs, edge cases, ... they can find that you didn't encounter yourself. Which is easy enough if you have a super popular project that thousands or even millions of users are eagerly anticipating the release of. But that's not the case here.

As I might have previously mentioned, it's kind of hard to persuade your friends to continuously test your broken project because it gets boring real quick. And if I'm honest, everyone has something better/more important to do than test my broken app. But if you make enough changes and first test them out yourself, you can still manage to make the changes interesting enough for people to at least want to try it out briefly again.

I also added more pictures to the gallery page. It loads quick enough because they're all optimised but I know this won't be enough in the long run. So for that reason I also implemented the loading="lazy" attribute that should help in the future.

forgetting to finish this

I can already see myself panicking about how I forgot to finish this great wall of text after submitting the project. But that's just how life is from time to time I guess and as they say "it's no use crying over spilled milk".

To whom it may concern, if you find this documentation about the process of building this website lacking, please kindly check the source code for potential updates before lowering the grade of the assignment. Thank you in advance.

future plans

this is a floating title meaning it will move downward as the project continues