Case Study

This project was based on one of the assignments I did during my time at Fanshawe College. That project was a Dungeons and Dragons puzzle, where you had to diagnose the issues, then solve them to make a functional puzzle. The puzzle primarily focused on drag and drop events, which I found to be cool. Just after that assignment was finished, I got inspired to build something similar, but with Pokemon instead.

Aside from objectives, what differs between the Pokedex Maker and the DnD Puzzle is that, there's no singular correct place for the Pokemon to go. You could make Bulbasaur the first Pokemon in your Pokedex, or the 100th. That's why, in the code, I defined a variable that searches for the closest element with the class of pokedex-box. This way, the code and image know exactly where you want the Pokemon to go, rather than starting from the top.

There were two major challenges I encountered while creating this page. One of them being, what if the user doesn't want that Pokemon anymore? Or wants to put the Pokemon back for now and use it later? The original code had the Pokemon go anywhere, but that didn't seem like a good solution. If you put Clefairy in Iron Valiant's spot and want to use Clefairy later, it's going to be a little rough to find it again. So I had to figure out a solution to ensure that a Pokemon returned to its original position for better user experience.

The solution I came up with was "What if I gave the original div and the image a timestamp, and the code looks for a matching timestamp and returns the image to the div with that timestamp." which worked 100% exactly as expected. The timestamps are unique identifiers, so there's an extremely low chance two divs will ever have the same identifier.

The other issue I came across was mobile interaction. Dragging and dropping events aren't functional on mobile, which are replaced with touch events instead. Now, I could refactor the code for touch events as well, but I'll be honest, if you're building a modern 400 entry Pokedex, I don't think you want to constantly be scrolling the page for that interaction. Doing a 400 entry on desktop, while fun, is also exhausting. So I had to think of an alternative for mobile users for a better experience for them.

When I was developing the mobile functionality, I was becoming acquainted with manipulation and creation of select lists. So I thought "What if I just used a select list for that?" Thus, I created a new column in my database to differentiate alternate forms and standard forms, and created a new route via Lumen that brings all of the Pokemon from the database that aren't alternate forms and populates each box that the user creates with a select list with each Pokemon. This way it stays consistent with the drag and drop version.

Admittedly, scrolling through 1025+ Pokemon can be a little cumbersome, but thanks to the mobile browser's innate functionality and the numbering system Pokemon has established, I was able to take away as much pain in the process as I could. A consideration I do have is to maybe order them alphabetically rather than numerically, as opposed to the consistency, but that's a consideration for a potential upgrade down the line. If users are satisfied with this system, then why fix what's not broken?