If you haven't heard of #DJD and it's 'quackathons', I recently participated in a fun web development hackathon. It's a great way for professionals to meet and work with others while learning either new development technologies or techniques.
The design prompt for that weekend was to build an educational app that would teach some aspect of CSS3 Flexbox. What follows now is a retrospective on what happened that weekend for the team, the things that went well, the things that didn't, and a quick bit on what actions I believe could immediately improve the development process moving forward. If you're interested in trying a hackathon yourself, the 'quackathon' takes place on the #DearJuniorDev discord, recently started by this wonderful advocate for junior devs. Check it out!
When we started talking about ways of teaching flexbox, we threw around a few great examples we had seen online, like flexbox zombies, or flexbox froggy, but definitely noted that we didn't have the time to come up with something as in-depth as any of our inspiration did. What they did do was give us the basis for the concept, which was to have the user try different flexbox settings to help boats navigate a river with obstacles.
As you can see in the screenshot, a number of boats sit at the top of a vertically oriented river, and a series of rocks sit at the bottom. Once the level starts, the boats begin to drop to the bottom of the river, and the user has to type in the correct answer to prevent the boats from crashing into the rocks.
The challenges we found during development were fourfold:
Our option for making objects move around for this app were to animate objects on a canvas element, CSS transitions, use a library, or come up with something else on our own. We chose to come up with something else on our own. We decided it would be fun to try to figure out how to make a boat look like it was moving down a river just programmatically swapping out different styling (positioning), via the HTML class attributes. We could just cycle through a set of different stylings using the web API setInterval() to do it once ever 1 or 2 seconds.
To move the boat down the 'river' using just CSS, we figured we would have to keep the height and width ratio of the game display static - aka a fixed aspect ratio - otherwise any change in the ratio (essentially, any device screen size with a different H x W ratio) would result in the boats either overshooting or undershooting the bottom of the river, or various other odd-looking issues. This also required a little CSS magic.
The React programming model doesn't play nice with web API like setInterval() or setTimeout() in this problem. The callback that setInterval() or setTimeout() will call after a re-render of the component is outdated. We needed a custom hook.
The last challenge was more of an issue with coming together as a team for the first time on such short notice, and not so much an issue of oversight or miscommunication. Using git and github together was new for some members, and since it was such a small scale project, there were only really 2 or 3 files to work on, so it made it a challenge timing when one teammate could introduce their additions to the work without causing merge conflicts.
My team and I had several personal and work related items that pulled us away from the time-constrained development sprint, so when the submission deadline hit, we had the underlying logic and structure completed, but failed to have the necessary CSS to make the application fully responsive for desktop and mobile.
We didn't even have any media queries, so it looked pretty broken outside of the one desktop screen size, even though we had a working version before adding some layout changes for the rest of the interface. As it is right now, an hour or two of fiddling could get it to being minimally useable for both desktop and mobile devices, but I wanted to post this retrospective first and let it sit for a few days before I got the chance to fix all the unresolved issues and publish it for others to see.
Given this was the teams first sprint together, what went especially well was communication. Compared to the teams previous participation in hackathons, we felt like the brainstorming session was a quick process. We passed around ideas, kept the scope limited to just the 'justify-content' Flexbox property so we wouldn't have to build out too many features, and then made some improvements on how the design could be broken down into chunks and stages so we could avoid working on the same structure at the same time. It still ended up being a challenge since we all came and went throughout the day, but the preparation and forethought definitely increased our calm about it.
A bottleneck - I suspect this is one of the more common things that goes poorly in engineering - one problem took longer than we suspected it would, and we didn't organize enough resources to resolve it before we lost valuable time we could have spent addressing other problems. It was the custom React hook solution. After some fiddling, some putting together of heads, some research (see: googling), we finally found this which swiftly resolved the entire issue, and even provided some great reading material on Reacts programming model with respect to setInterval() and setTimeout(). Thanks, @dan_abramov!
Once the timer worked, we were able to start testing the cycling through of classes and styling, but it's what ended up stealing a larger chunk of time that we expected to spend on the styling of the whole app, which I suspect ended up being why the project wasn't finished on time.
Aside from the basic styling to make the app responsive to most mobile and desktop screens, I would say that if I had a fresh start and the same amount of time, I might have just chosen to build the mechanics with a canvas element instead. Not because it proved too difficult to accomplish with the timer, the React model, etc, but because -- while it was a fun challenge to see if it was doable, based on my experience, it doesn't appear to be a solution that could be extended as far, as easily, and with as much detail and flexibility as one using a canvas element. Great fun, though!
Given that this was the first time working with this specific set of teammates, my only thought is that a tiny bit more logical planning or testing first thing may have avoided the bottleneck related to the custom hook. We might have either realized the component re-rendering issue sooner and allocated more team focus to creating a custom react hook, or just pivoted to design the mechanics using a canvas element instead.
For example, after resolving to use setInterval() to trigger the cycle through classes on the boat elements, it could have paid off more in the long run to just do some research for a few minutes on if other projects made use of setInterval() in react, and, if so, how they did it. Also, just knowing to ask for help when the problem isn't solved within a healthy timeframe and getting colleagues to work on it together could have moved the project forward more quickly, even at the expense of several teammates' time away from their tasks.
The whole reason I'm even doing a retrospective is just to get better at the whole process, so I hope you enjoyed getting to see how we got from idea to deployed app, and what it really looks like to participate in a hackathon, even if you don't feel the project is polished.
I'd also like to open myself up to suggestions for improvement of my contributions to the project by providing a link to the github repository here. I'm collectivenectar on github, so feel free to reach out for any comments or connection!