A one-man site redesign, and nostalgia
Despite how I look, I’m the kind kind of person that loves to play old video games. (Full disclosure: I look exactly like the kind of person that loves to play old video games).
Accordingly, one of my favorite discoveries of the online age was a site dedicated to reworking, re-translating, and relocalizing those games of yore, ROMhacking.net.
Here, the denizens of the internet collaborate to make completely new NES Super Mario games, fix the nagging two-player glitch on the Clinger Winger level in Battletoads, and re-work the Breath of Fire II translation into something much closer to actual English.
But as content rich as the site is, and as much as it’s a masterclass in data management (holy sorting options, Batman!), it does have one particularly glaring design flaw.
If there were a UX police department, ROMhacking.net would be written up for at least five violations of Hick’s Law. Menus top, left, and right; side menu’s duplicating top menus; menus with 6, 8, or even 10 items — all crowding the screen for your attention.
Even when you consider this site is intended for the type of person who pours over online forums for hours looking for that one piece of information they need to fix a convergence issue on their CRT TV, that’s a lot of options to get lost in.
So the primary objective of a potential redesign of this internet gem has to center here: apply a little simplicity, and maybe just a bit more polish to the efficient but otherwise spartan UI. But before jumping in with both feet on VSCode, I needed a few things to base my code on:
- an overview of what things the original design did and didn’t do well;
- a basic inventory of what is actually on ROMhacking.net, and;
- some wireframes to work out how to display it.
Overview: the good, the bad, and the menu-y
While the negatives of the site jump right out at you from the landing page, there actually were some good design queues from which to take notes.
Yes, the menus cause claustrophobia, but the presentation of the data in individual hack / translation entries is clean and well-presented. Not just one big table, but a well-proportioned and divided layout that displays a whole lot of data. This is the kind of thing that could be kept.
There’s also nothing wrong with the basic color scheme, and if we’re going to keep the logo (which, why not, it works great) that should be maintained.
What it lacks is perhaps a certain pizazz, and a touch of modern design. Instead of only tiny screenshot images, bigger and more emphasized hero images would look nice. Instead of opting for the classic shadow-box-floating-bubble-two-tone layout, something flatter and simpler could spruce it up.
Inventory: let there be content
Uh…. woah.
To say that ROMhacking.net has a lot of content is nearly is the same as saying the Atlantic is “a lot of ocean”. Sure, there may be bigger in the wide world, but golly if it didn’t take thousands of years of technological advancement to safely cross it.
Thousands of documented games, dozens of utilities, thousands of hacks and translations, each with authors, categories, platforms, readmes, screenshots, download files — and that isn’t even touching the “About” page, forums, and instructional guides.
It’s a big site.
Representing a redesign of the site in its entirety would be outside the scope of this project. But if we’re talking combining a few pages (like About and Help) and representing a few example hack/translation entries… now that is doable. The point is to give an idea of how the redesign could look, not recrunch the Mt. Kilimanjaro of data it contains.
The usual frame-up job
If history has taught us anything, it’s that styles you made fun of in pictures of your parents will be popular again for your kids, and that good web design should begin with some sort of wireframe. If you’re in it for the real money, probably multiple iterations of wireframes of the whole site, with research and user testing to back it up.
Yes, well, this project wasn’t quite on that level. So basic wireframes for a few of the pages, for mobile and desktop, probably will do.
Now, with the preliminaries done, it’s time to spring to life a basic coded-prototype.
Let the code slinging begin
There is, as usual, a sort of gap between what a site looks like in its wireframe, and what eventually gets spelled out in tags, classes, and functions.
This is often because along the way, you might figure out something that works even better than your original plan, and just as often because part of that plan turns out to be, functionally, a bad idea.
Have a nice, restrained image slider? No, go BIG, baby! Make that image go wall to wall on all screen sizes! Spelling out every hack entry in simple HTML and CSS? You wouldn’t have enough lifetimes for a site of this size, so instead of typing a bunch of new material for each entry page, and copy-pasting left and right, make a fetch to a JSON, and have JavaScript populate the whole thing for every entry page!
The one minor wrinkle to work out for this info-getting was how to call the right data from the JSON for each page.
I tried a few variations (an onload in the body that passes a parameter? finding a piece of text in the DOM?) but found that setting up a bit of hidden input, and getting its value from its ID turned the trick. So with a change of one value on a page, an otherwise identical copy can have completely different content according to the corresponding JSON entry. Huzzah!
Now on to an “About” page, and a “Contribute” form, and loads of styling, and… yes, there was still plenty to do.
Thus it was done
So, how did this little redesign turn out?
Well, not bad. Surely it could use some review and additional research. But for its scope, I think it addressed the issues at hand.
Navigation bars were reduced to one, with five links and a search bar, and one sub menu. Add to that some slapping-good game art in a slider, and an overlay-style mobile nav, and the laws of both Hick and slick are appeased.
Three example entries are present, each programmatically generated using the aforementioned JavaScript that fetched from a JSON like a good little doggie. Each entry takes a lot of the good design cues from the original, and adds a flatter, modern touch. Adding more pages would be as simple as tacking on more JSON entries and a few pictures. Then presto copy past-o, more hacks, utilities, and translations.
To finish it off, I fill the site out with a basic form page and an About with some clip-path shapes (because why not?). Those pages that I didn’t remaster, I link to the original site to open in a new tab, so you can still sort of act like it’s a complete site.
It isn’t perfect, but I think it sets up well so that any nerd with a heart in his Genesis can easily get his mitts on some remastered nostalgia.
Full disclosure: I downloaded and patched in four game hacks in the course of this redesign. And I think I showed an excellent amount of restraint.
Adam Andreason is a student in the Digital Media program at Utah Valley University, Orem Utah, studying Web & App Development. The previous article relates to the Capstone project in the DGM2740 class, and is representative of the skills learned.
