The Beginnings: App Foundations

📅 2020.11.01 - 👤 Borbély Viktor

important to define basic components in the case of app foundations too

It is difficult to build a lasting castle on loose ground. Good foundations are needed in our everyday lives that we can build on. Such stable positions that can withstand unforeseen loads. This is no different in producing digital products. App foundations are also like this. They are easier to modify than their physical counterparts because they are not works carved in stone. Nevertheless, their creators must proceed just as precisely from the beginning as with a skyscraper.

With the parallel mentioned in the introduction, I conveyed that indeed, the software developer who spends time on elaborating details spares themselves many wasted work hours.

Continuing after the Trivia Game quiz mobile app foundations presented in the previous article, I present how I usually start determining the details.

Delimiting functionality

It’s important that a mobile application solves one task, but knows how to do it well. This is a clichéd statement. This is true for the initial times. Why? Because our first users will learn from this the message we want to convey. That precisely what our app will solve for them. This must be well recognizable and unambiguous. This belongs to the UX (User eXperience) area.

Trivia Game is a quiz game application that shows everyday questions, but the answers are far from unambiguous.

After the foundations, further definition can come: multiple people can play it; in the form of challenges; it works without internet; it motivates the player in the meantime, etc.

The smallest unit

From these, it’s easy to see that the smallest unit is a question (trivia). Such a small data structure around which the product can be organized.

I consider it important to think in structures. This is like carrying a box around. What’s in the box won’t be interesting to the postman. Only at the end to whoever looks. I can take out, put in things (data) anytime later. I present this, the game’s elementary unit, through a quiz “puzzle”.

For a quiz “puzzle” I store the following details:

  • question’s unique system identifier (1)
  • question title (2)
  • the puzzle text itself to be solved, or an image (3)
  • how many points it’s worth (4)
  • what its difficulty level is (5)
  • what topics it may belong to (tag) (6)
  • what the correct solution is (7)
  • marking of different languages (8)

These were not determined at first, not all at once, but based on operation, which I explain in the next chapter.

What is the operating mechanism?

The game’s progress is that somehow the set of puzzles gets onto the phone. Pre-installed, or at first start, the game downloads it from the internet. These can be identified (1).

The player can set for themselves in what topic (6), at what difficulty level (5) they play.

The program then starts throwing up questions (2, 3) on a display surface. It immediately evaluates answers based on the score (4) and solution key (7). From this, the score achieved in the game is assembled, and the player can level up. Or get a badge. Or whatever we designed in.

So that the game isn’t boring, previously played questions are not, or only very rarely drawn again. This can be taken care of by noting the quiz identifier (1).

How to proceed after MVP?

Simple operation can later be taken in many directions. It’s not a problem if the game is slightly over-designed. (At least I like to over-design.) What’s good is if I can use the same data in 2-3-4 different ways. This is the concept of “derived data”. Preferably, let’s keep track of something from which several things can be decided, and we don’t have to modify it together with other data. This is quite a foggy formulation, I’ll show an example.

If we store a list of quizzes in a database, and there’s a field for whether it has been played, it’s better if we don’t note yes/no about it there. Instead, it’s luckier if we write a date of when they played it, otherwise it’s empty. With 1 data we already got more info:

  • was it played already?
  • when was it played?
  • in what order was it played by someone?
  • if we make a competition out of it and compare it with other players’, then an order can be established, and so on.

Here’s a good advice:

Let’s round off the concept as soon as possible and resist adding further functions. This will only further complicate the solution and delay the first presentable version’s date.

Let documentation be our help

Requirements coming from the client are described by the specification document. In this, we mainly get an answer to the question: “WHAT? do they want to create”. Processing this, chewed by an organizer (architect), ideas emerge for the ” HOW?” in the form of a design document.

It’s essential that it contains the necessary basic info. Let’s not write a short novel, but give sufficient guideposts to those who arrive later and join the development. Let it be understandable and to the point. If it’s too long and no one ever reads it, then it was useless to wear out the keyboard. (On the topic, I’ve already written on the pages of DigitalHungary.hu.)

I hope you found my methods useful, in which I described what I pay attention to when creating app foundations. If you liked it, stay with me for the next part. Then I’ll report on interface design and solutions.

Cover image: Icons8 Team / Unsplash.com