Wireframing The Unquote Game
Along this Android and Java journey, you will build a game. Each project will bring you one step closer to completing a working trivia game we’re calling, Unquote.
In Unquote, players must correct Internet misinformation—in our case, the kind that comes in the form of picture-quotes.
If you’re unfamiliar with fake quotes on the Internet, go and use the Internet, then come back to this page when you’re ready! And if you still haven’t seen one, they look like this:
Hint: Marilyn Monroe never said that, but the Internet remains unconvinced!
Over the course of several projects, you will build an Android game that presents fake quotes to the user and tasks them with identifying the true author of each quote, e.g. who actually said, “Do or do not, there is no try.” The answer, in this case, is Yoda, post-baby Yoda to be precise.
In this first project, you practice your wireframing skills to design Unquote’s one and only screen: the game screen.
If you get stuck during this project take a look at the project walk-through video.
1. Grab some paper and a pen, ideally 4 sheets of graph or dot-grid style paper.
If you don’t have a graph/dot-grid paper or a printer, plain paper and a ruler can do the trick! But if the year is 2065, “papers” were flat rectangular surfaces made of tree pulp. And “trees” were…
2. Define the game screen somewhere on your sheet
The top-left corner will do just fine.
In wireframing, we divide our application into ‘screens,’ unique experiences that serve one or more purposes within our application.
To begin, each screen requires a title.
3. List the purposes served by the game screen below its definition
We at Codecademy already know what this application does, but for the purpose of this exercise, imagine how this game works and define its behaviors.
Remember, Unquote is a trivia game that presents users with quotes (most of them fake) and asks them to identify the true sources of their wisdom!
As the one and only screen in Unquote, it will serve the following purposes:
4. Draw your first box to represent the game screen wireframe
Being a mobile application, we want the wireframe box taller than wide (candy bar-shaped) and large enough that we can write complete, hand-written sentences within the box if needed.
5. Draw device decorations
Android screens often come loaded with a few common screen-consuming elements, its best we include them in our wireframes to remind us that the full height of the screen is generally unavailable.
Most Android devices have two top bars: a status bar (battery, clock, notifications) and an ActionBar (app title, icon, menu buttons). Together, they consume approximately 8-10% of the screen.
And most Android devices also feature an on-screen navigation bar at the bottom (home, back, and task manager buttons) which consumes about 5% of the screen’s height.
Draw a narrow box at the bottom of your frame, and a slightly taller box at the top to identify these screen portions as ‘unavailable.’
6. Choose a purpose, and illustrate that purpose in your wireframe
A good place to start is any purpose that likely consumes a large portion of the screen (presenting an image or a set of buttons).
Go back to Step 3 and look over the purposes served by the game screen.
For example, ‘present the number of remaining questions’ — how might we present that information to the user? As a percentage? As a whole number? In the bottom-right corner? Top-left? Dead center?
Don’t worry about getting it right, only about getting it on the screen. Wireframing never provides the final solution, but with practice, it offers a great starting point.
7. Repeat step 6
Repeat step 6 until your first wireframe satisfies every purpose listed below the game screen.
If you run out of space or forget to include something, start over! Sometimes it helps to think of every purpose your screen serves as part of a greater whole.
You can begin with a big-picture idea, such as dividing the screen into fourths or thirds, then honing in one portion at a time, choosing how each section may satisfy one or more purposes.
8. Repeat steps 4, 5, 6, and 7
Repeat those step to create a second wireframe that satisfies all requirements for the game screen.
If you’re stuck, try making small modifications to your first wireframe (swapping the position of two or more elements). This is enough variation to satisfy this step and the following step.
9. Repeat steps 4, 5, 6, and 7 (again)
Repeat these steps again to create a third wireframe that satisfies all requirements for the game screen.
By completing this step, you likely have three wireframes that strongly resemble each other—that’s okay! This process forces us to think outside of the box, and soon your original concept will run out of steam.
10. Repeat steps 4, 5, 6, and 7 (again, again)
Repeat these steps again to create a fourth wireframe that satisfies all requirements for the game screen.
In this attempt, challenge your assumptions of what an application should look like. It’s easy to copy popular apps (after all, their success in part is due to their design), but it’s far more fun to draw outside the lines.
Think of one common element, an Image perhaps, and imagine what happens when you rotate, shrink, or obscure it behind another element. Don’t force yourself to do the right thing, but guide your hand in the direction of fun or bizarre.
11. Repeat steps 4, 5, 6, and 7 (again x3)
In this repetition, look at the elements you’ve made most prominent in your wireframes so far and those which you’ve placed as secondary.
For your fifth wireframe, swap the emphasis placed on two or more of these elements. The importance of one goes up, and the other goes down.
In all likelihood, your designs feature prominently the quote image, and deemphasize, for example, the remaining number of questions.
What would happen to your design if you granted far more importance to the number of remaining questions than you did the image? Explore that idea in this step.
12. For the last time (we promise), repeat steps 4, 5, 6, and 7
In this last repetition, let yourself loose creatively because now there’s nothing to lose (there never was anything to lose, but that’s beside the point).
Here again, a slight alteration of a previous design is enough to satisfy this step. Look at your fifth wireframe and see what, if anything, you can change by making a small modification.
13. Wait one day. 24-hours. 1440 minutes… you get it
After a good night’s rest, your mind is better prepared to look at your wireframes objectively. After the Earth has given us all one good spin, check off this box.
To speed this process along, Codecademy recommends Time-Travel™, available everywhere fine Science™ is sold.
14. Discard any wireframes that fail to satisfy your aesthetic
Ultimately this is a design project, and beauty is in the eye of the beholder (you). After this step, you should have a maximum of 3 wireframes remaining.
If you like all of your wireframes, rank them from best to 5th-best, and remove the bottom 3. Sorry bottom 3, you 👏 gots 👏 ta 👏 go.
15. Consolidate your remaining wireframes into a single design
Merge the common and favored elements remaining in your top 3 designs to create a new, unified design that features every element you love.
This is your final wireframe. As an example, here is the final wireframe we will follow for the remaining Unquote projects:
If you struggle to merge the designs, proceed with your favorite among the 3—remember, this is not about getting it right, but about finding a great place to start.
16. Prepare yourself for feedback
Wireframing is a shot in the dark. Until we expose our ideas to the light, to our end-users, we won’t know which elements were missing, which needed tweaking, or which demanded complete expulsion.
For these reasons and more, we limit this portion of the software product design cycle because otherwise, we get stuck wireframing while producing only marginally superior designs (if even that).
We only arrive at our best design by incorporating user feedback and satisfying the user’s needs, and that means we need to build it.