Getting your mobile app out, part II — Prepare for the development

The only article of this guide that you should read before going into the development itself. Prepare all the groundwork for having your development organized, knowing what hill you have to climb on and have most of it defined thanks to following these simple steps. You will learn how and why to prepare your flow charts, wireframes, design, git, API blueprint and development tasks. All that is needed to start building the app itself.

Photo by Yancy Min on Unsplash

Our mock app

To help me visualise my point and to provide you with a specific example, we will be following the development of a small part of a fake single app. Specifically our app will consist only of the following views and functionality:

• Splash screen
• Welcome screen (showed on the first open only)
• Disambiguation screen
• Login screen
• Register screen

Setting these borders means that this will most likely be an app that also has a server part and will use some type of a remote database.

The scope outside of these few screens is completely up to your imagination. I don’t want to steer you in a direction that might not be fitting for your specific case. Those few screens will help to get my point through just fine without making this a too specific example.

Flow chart(s)

What are they and why do we need them

You might remember flow charts from your UML diagrams classes. But don’t worry, we won’t be this strict. For our purposes, just a simple diagram of boxes with arrows between them will suffice. We will visualize this way how a user can move within all the parts of our app and how they will interact with it just fine.

Why define the flow within our app? Well, I’m sure you have it all figured out in your head. But do you really? Did you really not forget any screen? Any mechanism or functionality?

Putting the whole flow through the app down will help you organize and scope your development. You will see it all laid out in front of you and you will be able to easily extrapolate how many individual screens you need, what controllers will there be, what data you will need to store and so on. This is the most important reason — you will want to use these data to guide your development.

Additionally, you will be able to look at the flow, think about it, revise it and in the future revisit it. If you would happen to need to share your app idea with someone else, you will also have a great visual tool for them to help you explain it. And if this will be a success and you will turn this from a hobby to a startup, you are just now laying the groundwork for a propper documentation.

Which tool to use

While if you were working for some big corporation you might use Microsoft Visio to design the flow, we are operating on a non-existent budget so we will look for a free to use tool. From my own experience, diagrams.net (formerly draw.io) is a tool that will handle most of your diagramming needs just fine. So we will use that.

Designing your app’s flow

What I like to do is to sketch the flow on a paper or a whiteboard first. But no matter if you decide to follow the suite or to start digitally right away, once you are ready to start, open this link.

You will be greeted by the UI of the application and prompted to select where to store your diagram. Choose whatever works for you the best, just one advice though — storing the diagram locally is the worst option of those given. Whenever you will decide to save your progress, a new diagram will be downloaded to your device. So if you are paranoid like me, you will soon end up having dozens of diagrams that pretty much don’t differ at all. Choosing Google Drive for example, will on the other hand keep just one copy updated on your drive. I usually opt out for that option and all that is required is to authorize the sign in. Do whatever you find the most useful for you and lets continue.

Select create a new diagram in the next step. Whenever you will want to work on your diagram in the future, you will be selecting “chose an existing one” instead. Now pick a fitting name and make sure that the file has an extension “.drawio”. As for the template — we want to chose a “blank diagram”. Pick a root folder or any other one where you want to store the diagram and we are all set now.

You are now welcomed by a screen like this:

Feel free to play around with the tool to get some idea of all its capabilities. When you ready, lets start with the flow.

Start by expanding the “UML” section of the left side bar and place the “start” symbol anywhere on the canvas by holding the left mouse button and dragging it.

This will indicate where our user will start interacting with the application.

Another step would be dragging the rectangle symbol from the “general” section in the very same way. Once you have it placed near the “start” symbol, drag the arrow to the rectangle so they connect.

Click twice with your mouse on the rectangle and it will allow you to put text in it. Type “Splash screen” to the rectangle.

You might have noticed a couple of things while doing that — if you connect the arrow of the previous object to the next one, when you drag any of those interconnected objects, the connection will remain. Additionally, whenever you move something, guidelines appear to help you align various objects in reference to each other.

Lets now put the first logic part to the diagram. Drag the diamond shape from the general section to the canvas and place it below the “splash screen” rectangle, double click the diamond and enter “is this the first open?” into it. Next put two additional rectangles to the canvas with titles “disambiguation” and “welcome screen”. Drag an arrow object to the canvas from the general section and connect “splash screen” to the diamond and the diamond with both rectangles using two arrows. Then connect the “welcome screen” with the “disambiguation” with another arrow. Finally double click the arrow from the diamond to the “disambiguation” and type “no”, then do the same for the remaining arrow and type “yes”. You will end up with something like this:

Congratulations! You have visualised your first condition in the flow chart. So far we have described that the user opening our app will be first taken to the splash screen, then the app will determine whether they are opening the app for the first time ever. If yes, they will be taken to a welcome screen, which then leads to the disambiguation screen. If this is not the first open though, they will be taken directly to the disambiguation.

Lets add our two remaining screens to the diagram — the login and register screens. By adding a thin rectangle to the canvas and linking to it with a single arrow from the “disambiguation” and with two arrows to two additional rectangles “login” and “register”, we are displaying two equal options that the user has. This way we can add forks and joins to the mix. Replicate the image below:

This is all of the screens we have set to design, so I will now let you continue on your own. Continue by adding all screens and actions to your app in this fashion until your app is completely covered by the diagram.

Getting the important stuff out of the flow chart

Now that you have the whole flow designed and provided you are satisfied with it, break it down in the following:

• Screens
• Logic
• Data

Have this on hand as we will be using all of these in the next steps.

Wireframes

What is it and why we need it

It’s time to take our list of screens that we have defined in the previous step and make wireframes out of them now. Why? Well we want to know what screens we will going to be eventually designing, what elements will they have and how will they interact with each other.

What will we use

There are three main tools used today for wireframing and rapid prototyping. Zeplin, Adobe XD and Figma. We will be using Figma, since it is not only free but also easy to use and will allow us to make the full designs in it as well.

Lets get to it

Go to figma.com and create a free account. If you have used Google account for the flow charts, feel free to sign up here with the same account as well. Skip naming the team for now.

Once you sign up, you will be welcomed with a blank project. Notice at the top center, there is “First project / Untitled”. Jump out of the project by clicking on the hamburger icon in the top left corner and chosing “back to files”. Delete the “untitled” file, we won’t be needing it:

Put this link to the browser in the same window and you will land on a free mobile wireframing kit. Click “duplicate” on the top right corner. You will be now taken to the newly duplicated file that will be saved in your drafts folder.

Click on the name of the file “Mobile UI kit (Community)” and select “move to project”. Then move it to your project folder. By clicking the name of the file itself, you can rename it.

What you now have, is a bunch of assets to make your wireframes out of. To keep things organized, click on the “+” plus sign next to the word “Pages” in the left side bar. Create a page titled “Wireframes” (or anything else you would like to name it).

Once that is done, click on the “frame icon” — the third icon from the left on the top navigation bar (highlighted in blue on the image below).

Notice that once the frame tool is active, the right side bar now contains a list of various screen options. If you now click any of the devices on the right, a canvas in the size of their screen will appear. I will be selecting “iPhone 11 Pro / X” as my device format.

You can add any number of screens. For our test project, we know that we need five of them. Add them to the canvas. Once they are in place, rename them to the corresponding screen names by double clicking the titles of the screens in the left side bar.

Until now, we have been using the “layers” part of the file. Click on “assets” on the top of the left side bar. Explore what individual items are there.

Once you have seen all that is available to you, go to “iOS status bar” layer, click on “iOS status bar black” item and press ctrl+c (cmd+c).

Go back to “layers”, select “wireframes” page and click on the first screen. Press ctrl+v and the status bar will be placed on that screen. By copying it to the rest of the screens, you will end up with something like this:

Why did we do it this way? By copying an asset? Using assets will allow us to redesign them, modify them just once and see the results on every instance of the asset. Now if you would want to change any aspect of the status bar we have just created, you would go back to assets, change it there and it would apply on all those screens where we have placed it.

The makers of this template conveniently put all of those assets in to the “components” page, so we don’t have to go to assets all the time. They have also created a couple of screens on the “mobile UI kit” page too, lets see if we can leverage that.

There are for example the whole login and sign up screens. Lets use them. The rest we will create with the individual assets. Eventually we will end up with something like this:

Now lets take this a step further and make this into a prototype. Notice the right side bar — all this time we have had the “design” option selected. Switch to the prototype mode now and then click on the “loading” text of the first screen. The selection will now be highlighted and on its right side a plus sign will appear. Drag it to the last screen and you will end up with this:

Leave the interaction settings as they are or toy with them a bit. The main point now is, that if we were to enter a presentation mode, we would be able to click on the “loading” text on the first screen and it would take us to the “first open” screen.

Create the rest of the interactions and this is what you end up with:

Click on the “play” icon on the top right corner and you are now able to interact with your wireframed app.

Design

Building on the wireframes, you can finish the whole design in the Figma as well. I won’t be going into that here, since you would be using all that you have learned in the previous section. So if you will be designing your app yourself, replicate the steps above and instead of using the template, make your own components from scratch.

Once you have this, Figma allows you to easily export your assets to use in development. Here is an example of how to export the play button for various screen resolutions.

First select the icon and make sure you have the “design” right side bar active. Scroll down on the right side bar and click on “export”.

Notice that the export has several options — size (half, 1x, 2x etc.), suffix and format. If you click on the export button now, it will export a PNG file with the name of the component (Play.png) in the same size/pixel density as it is and with no suffix. However if you change this to 2x, with a suffix @2x and then press the export button, it will automatically rescale to a double sized image named Play@2x.png. Pretty useful, huh?

Versioning

Choosing our Git

How many of you are old enough to remember CVN? Or the still running subversion? Fortunatelly there are now tools that are much better to use than that. For example GitHub, which we will be using. I imagine you do have experience with Git, maybe even with GitHub, so I will focus only on setting up an organization where we will be storing our repositories. This kind of set up will allow for an easy automation and development task tracking.

How to set it up

Go to github.com and login or sign up. Once you are signed in, click on the plus icon on the top right corner and select “create new organization”.

You will be prompted to select a plan, chose the free one.

In the next step, name the organization, fill out an e-mail, indicate you as the owner, select an individual type and solve their riddle.

The most important part in the next step is to indicate if you already have an existing repo. If yes, it will allow you to transfer it under this organization. The rest of the fields can be set up however you feel. After that, you will have a new organization with its own unique url.

Now lets create a project belonging to the organization. Go to the “projects” tab, select “create new” and fill out the details about your project. This is where you will hold the repos for your app and maybe for your backend if you have one.

Most importantly — link any existing repos if you have any. Otherwise fill in the details and set the project visibility to private.

That’s it. We know have our project. Feel free to create repos in here the way you are used to.

And why have we done this? Why haven’t we just created a repo under our personal account? Well our project now has a board. We can keep track of our development tasks by putting them as issues on the board and we will always know what lies ahead and what we have already accomplished.

API first

What and why

If your application will have a server backend, you need a layer through which those two parts will make contact. If your app however doesn’t have a server part, feel free to skip this step. Otherwise lets take an API first approach.

Designing the API first will provide you with a huge advantage — you will be able to safely develop the backend and frontend independently, since both will be targeted against specifications that are already known during the development.

And if we select the right tool, such as Apiary, we will also have the ability to mock our API and test the BE or FE without the counterpart being developed yet.

Lets get to it

So lets make a free account on Apiary now. We can even sign up using our GitHub account that we have created in the previous step. Pretty neat, huh?

Name your first API during the sign up process. It will then have a public URL with that name. You are then taken into the editor view right away:

Using a simple notation, you are able to define the API URL, the endpoints, their expectations and responses:

Using the flow chart created in the first step of this article, pull out all actions required to happen on the server side and create the documentation. The outcome will look similarily to their sample documentation.

You can now run requests against it or use it as a guide for your development.

Making it all fit together

Thanks to making the flow chart in the begining, we were able to create the wireframes and the designs. Therefore we have covered what screens we will need to use, how will they look like and we also have all our assets ready to go.

The flow charts also defined what logic elements, what programming will be needed for the application and the data which we will need to store and create operations with.

Since we have designed our API already, we also know how our backend and frontend will be interacting with each other.

We have set up our Github organization, its project and consequently a board in it.

And all of this was for one purpose — you can now prepare all the development tasks and fill in your Github board.

Go ahead and do it, you will then have your project set up for the development.

My personal weapons of choice

I have promised you that I will at least mention what technologies I am building my own app with. So to keep on my promise, the stack is as follows:

• React Native — Get started guide
• Expo.io — Get started guide
• Symfony — Get started guide
• MySQL (with Symfony)— Get started guide

Of course you might have a completely different stack and that is perfectly all right. This series will most likely be aplicable for whatever architecture you have chosen.

And that’s it! You can start the development now! All the other articles will be covering subjects that can be done during or after the development. So feel free to jump into writing some code finally.

Notice that we have done some quite professional preparation for our development at no cost at all.

In any case, good luck with the development and I will catch up with you next week when we will be covering the set up of the rest of our ecosystem.

Next article: Will be published on March 29th.

Series introduction: Getting your mobile app out, part I — Series Introduction