Case Study

The idea came from when I was watching a playthrough of Scarlet and Violet and thought "Man, Altaria's been used by a lot of trainers." So I stopped and thought, "Is that really the case or do I just notice it more often than others?"

Normally I would just check how many times Altaria's been used, but around that time there were Reddit posts floating around like "Obscure Pokemon Trivia" that were quite popular, so I knew there was a demand for information. So I thought it'd be fun to build the page for anyone to use!

All of the relevant information is being stored in the database, and primarily being accessed via a linking table. Each trainer and each Pokemon line have their own ID, so when I make the API Call to the database via a Lumen route, I'm specifically searching for that Pokemon line's ID to return the results. Since I had connected the trainers table and the species line table to the linking table in the code, I'm able to return any information from those tables I want to display, such as the trainers name. From there, it's just a matter of converting those results into json and populating the page with those trainer names.

I wanted to get a little fancy too and wrote some code to help spice up the page, like some code that displays that length of that json to say how many times that Pokemon line had been used. If there's 4 members of that array, then it'll say that Pokemon line has been used 4 times. And I'm also using that Pokemon line's ID to display an icon on the page.

One thing that was a roadblock for this page was mobile users. Frankly, the desktop setup I had wasn't exactly the most mobile-friendly. Lots of scrolling and white space. So I thought the best solution was to create a Select List for mobile users and let the browser's native settings do all of the work for easier UX/UI. After all, why reinvent the wheel?

The problem with that was ensuring the code still functioned properly, so I began familiarizing myself with OR statements in Javascript, aka ||. Since the information was the same but being selected in two different ways, I felt it was the best way to display that information without writing the function twice. The code I have checks for either what the current target is, or what the value of the mobile version's select list is, and creates the API Call from that information.

The biggest issue I had with this was satisfaction. Having lots of information can be a good thing, but I had to find a line between interesting & relevant information and redundant & unneeded information. Not everyone may care about Lady Daphne or Team Rocket Grunt 16. That's what led me to create special modes for this page. These modes function the same, but give different results. Sometimes people just might want to see how many times a Pokemon is used in main fights before the credits roll, some might want the instances after. People are fans of Colosseum and XD as well so those trainers might be noteworthy. All of these modes are just new linking tables, with imported data from the other linking table and new information. Just because Gardenia upgraded her Turtwig into a Torterra at the Battlegrounds doesn't take away that she uses the line after all!

For better user interaction as well, I created a variable check when a user switches modes, so that the function is activated and updates the results, rather than having the user to click off of the line and then click back on. That's what the savedVariable is in my OR statement; to ensure that if the mode is changed, the Pokemon doesn't and the user gets relevant results right away.

One day I hope to add an NPC trainer mode as well for those fans of Lady Daphne and Team Rocket Grunt 16. For right now, this felt like the best and satisfying compromise between myself as a dev, and for the users of the site.