Making o(m)g:image Part I: Design Iterations
I blogged about my recent project omgimg.jim-nielsen.com and I figured Iâd write more details about my process behind making it.
When the idea first struck, I jumped into Figma and started working out the idea. I had a pretty good idea of what I wanted: a quiz-like website that showed one question per page.
Once you answered it gave you the result and prompted you to continue to the next question. Pretty basic stuff. In no time, I had something in Figma that fit the bill.
From there I was anxious to jump into the code, so I built the Figma mockup in code. (I built it using Web Origami, more technical details later.)
I am hosting the site on Netlify, which has atomic builds for each commit. That means I am lucky enough to go back through my deploy history and view the site at different commit iterations, so I nabbed some screenshots for this post.
The first version was pretty close to the Figma mock.
Side note: Figma, for me, is a tool for settling on the direction of a websiteâs design and structure, not a âimplement this screenshot pixel-for-pixelâ tool, so I knew things were going to change and evolve as I built the site in the browser. Building the site is part of the design process.
That worked, but I didnât love it. The relationships between elements didnât quite feel right, so I started playing with layout and other small things.
From there, I started clicking around and going through each question. This gave me a feel for the experience of answering questions, seeing the result, and moving on to the next question.
I had figured out (in my mindâs eye) how this would work in Figma, but only once I had a working prototyping in a web browser could I really get a feel for how the Figma design held up. This gave me a chance to say to myself, âOh well that doesnât work, and Iâll have to change this, and this thing over here...â
That's how I ended up on another iteration where I tweaked element positioning to try and better the experience of: seeing a question, answering it, then viewing the result.
After I got the navigational elements to a place that felt better (and indicating your progress through the quiz), I went back to layout and played with the overall positioning of elements. I also continued to refine and tweak the elements that helped you navigate through the questions of the game (and their corresponding answer pages).
At this point I ended up taking a detour on the navigation front.
I kept waffling between the idea of minimal representation of the number of questions in the game (e.g. â1/10 questionsâ) and something more robust that would let you jump to any question at any point. So I built a version to test out that idea.
Then I ended up on a side quest of multi-page view transitions, because it was cool to be able to design the navigation in such a way that I could have multiple HTML pages that transitioned visually when navigating between them.
But I ended up deciding I didnât want to go in that direction, so I went back to a minimal representation of question status/progress. I also changed the layout (yet again). These were all decisions I made after repeated usage of the game, just clicking through things over and over and over until I found an experience that felt seamless and fast.
I also decided that, rather than have all questions laid out in the navigation for every single question, I would have a single page with all the questions represented on it. As an enhancement, people with JavaScript would see their progress on that page including the correctness of their answer for each question.
That felt good to me, so I shipped it and thatâs the state of the site at the time of this writing.
Itâll probably change in the future because every time I use it I think, âOh I could tweak this, and move that...â
Thatâs the curse of building these things yourself.