BUSINESS MOBILE APP DESIGN & MONETIZATION

 

conceptualizing a business mobile app

Time to develop your first mobile app without programming. Normally it would be time to take your imagination, storyboard sketches, and make them more tangible by wireframing. Wireframing is the process of making a prototype of your mobile app. We'll get to wireframing later. Instead, this is less of a prototype and more of a process examination: basically some things to consider when you're conceptualizing your business mobile application.

The mobile app you're developing is going to teach children the alphabet, and eventually teach them how to read. You've just run into your first challenge: defining the scope of your mobile app. What is the app really going to do, just teach the alphabet or is it really going to teach reading skills, or both?

The best approach is to not bite off more than you can chew and start small: so let's just teach the alphabet for now. This doesn't mean your plans to teach the world how to read aren't going to happen; they just need to go on hold for a while. The reason is that an alphabet app is way easier to code than a reading app. However, an alphabet app can eventually be evolved into a reading app. As a matter of fact, an alphabet app can be completed, tested, and launched into a marketplace where it can start making money. As the alphabet app makes money through its monetization methods, the original mobile app can evolve into a reading app and updated into the marketplace, and perhaps sold as an upgrade. It's best to start simple and evolve mobile apps.

For now, in your head, the concept of your mobile app looks somewhat like the graphic above. Your images are crisp and have a nice layout and an interesting, easy-to-use navigation system. Keep in mind that this app is for children, so it has to be simple. You also want an older person helping the child so they can identify the images together. The idea is that an image, in this case an apple is displayed when the user navigates to the letter "A." Seems simple enough. Keep in mind that you're assuming a child knows what an apple is, and further, that this is an English-speaking child, but we'll get to that soon enough. You want the child to easily navigate to "B," then "C," and so on. By the way, if you're thinking a mobile app like this has no potential to be monetized and make money, think again. Children's mobile apps are an enormous market segment. Educational mobile apps are a massive market segment as well. Both market segments are often underserved. Remember, this is a business, and a broad definition of business is to make a profit.

Component Inventory

 

At this point, it doesn't matter how the mobile app will be programmed, or even in what language. Let's look at the component elements that make up your conceptual alphabet mobile app depicted in the following image.

Figure 2.3: (A) Combined (B) Sound Icon (C) Arrows (D) Letter Graphics (E) Alphabet Navigation Bar (F) Background Images

Sound icon (Figure 2.3 B): What does it do? The intention is that the user touches the sound icon and a sound file might say, "L is for leaf!" This suggests you will need 26 sound files, one for every letter in the alphabet. One of the more common audio files is called a Waveform Audio File Format (WAV). Does the sound icon sit on top of the apple, fish, or zipper graphic, or is it embedded in every graphic? The answer is that there should only be one sound icon that gets repurposed every time the user changes to a new letter. However, you will need 26 WAV files for your mobile app. At this point, it will be a really good idea to name your WAV files numerically like 1.wav for "A," or 5.wav for "E." Each number in the WAV file name corresponds to the letter's order in the alphabet.​ Sound File Inventory (27 total files): 1.wav, 2.wav, 3.wav, 4.wav, 5.wav, 6.wav, 7.wav, 8.wav, 9.wav, 10.wav, 11.wav, 12.wav, 13.wav, 14.wav, 15.wav, 16.wav, 17.wav, 18.wav, 19.wav, 20.wav, 21.wav, 22.wav, 23.wav, 24.wav, 25.wav, 26.wav, soundIcon.png

 

Letter Graphics (Figure 2.3 D): A more important question is to ask whether the "L" or any other letter is a PNG graphic or is it's text generated by the mobile app? The answer is that all 26 letters are PNGs with a strict naming convention. For instance, to represent "L," there is a file called 12_letter.png, for the twelfth letter in the alphabet.​ Letter File Inventory (26 total files): 1_letter.png, 2_letter.png, 3_letter.png, 4_letter.png, 5_letter.png, 6_letter.png, 7_letter.png, 8_letter.png, 9_letter.png, 10_letter.png, 11_letter.png, 12_letter.png, 13_letter.png, 14_letter.png, 15_letter.png, 16_letter.png, 17_letter.png, 18_letter.png, 19_letter.png, 20_letter.png, 21_letter.png, 22_letter.png, 23_letter.png, 24_letter.png, 25_letter.png, 26_letter.png

Arrows (Figure 2.3 C): On the top, right, two navigation arrows, presumably to advance to the next letter or reverse to the previous letter. This suggests that this type of navigation is linear, meaning you can only get to “G” if you advance from “F” or reverse from “H.” There is nothing wrong with this type of common navigation, but your user may find it limiting. Once again, the arrow elements should not be a part of the background image and instead be an independent left arrow and right arrow. Although it seems like there are only two arrows, there are actually four because the left arrow when on the letter “A” needs to be programmed not to reverse back and be grey instead of black (out of context), and the right arrow should be grey and not advance when the user is on “Z.” Maybe the arrows should always be in context (only two black arrows) and “A” can reverse to “Z”, and “Z” follows through back to “A.” This is a decision to make before programming! Arrow File Inventory (4 total files): rightArrowBlack.png, leftArrowBlack.png, rightArrowGrey.png, leftArrowGrey.png

 

Alphabet Navigation Bar (Figure 2.3 E): Another important question is how does this "Alphabet" navigation bar (alphabetNavBar.png) actually work? If you look closely, you'll see that when the user presses a letter on the alphabetNavBar.png overlay, they will navigate to the appropriate letter of the alphabet with the expectation that the letter they pressed will darken on the "Alphabet" navigation bar. That seems really redundant given the fact that the screen will already show the letter they've chosen. It also seems like a lot of extra programming for something that may be superfluous. Alphabet Navigation Bar File Inventory (1 total file): alphabetNavBar.png

 

Background Images (Figure 2.3 F): Is the leaf an independent image on top of a white background? The answer again is yes, but for a few different reasons. Like the other overlay images, they afford versatility and the ability to switch them in and out for different versions. You may have noticed that every image so far in the Alphabet mobile app has a white background although they are very disparate subject matter (apples, goldfish, zippers, etc.) The reason for a white background is to have continuity throughout the mobile app. In simple terms, it looks really nice and every image seems to be part of a whole. This is not to say your "leaf" can't have its own background if that's what you think your user would prefer. Background File Inventory (26 total files): 1_background.png, 2_background.png, 3_background.png, 4_background.png, 5_background.png, 6_background.png, 7_background.png, 8_background.png, 9_background.png, 10_background.png, 11_background.png, 12_background.png, 13_background.png, 14_background.png, 15_background.png, 16_background.png, 17_background.png, 18_background.png, 19_background.png, 20_background.png, 21_background.png, 22_background.png, 23_background.png, 24_background.png, 25_background.png, 26_background.png

Another reason to have "overlay" images is that the mobile app shown is always in a vertical user interface. Will you let your user turn the mobile device horizontally, which will make the app look markedly different? To avoid this scenario, many mobile app developers "lock" their apps to either vertical only or horizontal only.

Once you understand that many images can layer on top of each other, its important to know what kind of image files to use. In general, its best to use a Portable Network Graphics (PNG) file. PNGs were created as an open format to replace Graphical Image Files (GIF) because one company owned the patent for GIF and no one wanted to pay licensing fees. It also has a full range of colors and better compression. PNGs are ideal for mobile apps because they support transparent backgrounds that make them ideal for image layering.

To further define the inventory of images, many times referred to as objects, it's time to give them file names. Figure 2.4 shows all 26 Portable Network Graphics (PNG) files, each of which will be displayed when their appropriate letter comes up. It's time to think ahead, way ahead. It would be tempting to name the files apple.png, banana.png, carrots.png, etc. These file names would work in a programming environment, but somewhat awkwardly. What if you wanted to do another version of the Alphabet Mobile App with a new theme, like sports?

The idea is to code once (program once) and only switch in a new set of images. If your programming referred to an object called "truck.png," you would have to switch it for instance to a file called "tennis.png." Banana.png becomes baseball.png; fish.png becomes football.png, and so on. What if all the images were named with numbers? For instance, apple.png was renamed to 1_background.png; banana.png was renamed to 2_background.png, etc. Now when your mobile app wants to show jellybeans on the screen, it retrieves 10_background.png, the 10th letter of the alphabet. If the 26 new PNGs that make up the sports theme had the same nomenclature, all that needs to be done is replace the original images in their image folder. What about all the Waveform Audio File Format (WAV) files? Should they use the same naming conventions? The answer is yes! Now programming one mobile app with countless themes becomes possible, and likely.

Computer File Naming Conventions

 

Before you go any further, it's time to step back and consider a few things about coding an app. Have you been keeping count of how many computer files make up the Alphabet Mobile App Game? There are 87, all using homogenous names with a very particular nomenclature. Notice that the computer files describe what they are, like mainBackground.png. This type of computer file nomenclature is called Camel Case, which is the practice of writing compound words so that each word in the middle of the phrase begins with a capital letter, with no spaces or punctuation.

Once you start coding, you will appreciate the time and thoughtfulness that went into your particular nomenclature. Computer file names within your programming will be much more obvious to identify. Although computer files are digital, they are literally your inventory, no different than a hardware store. Tools are a well labeled and generally kept together in the same area of the store, as is lumber or flower seeds. Your mobile app should be the same. It cannot be overstated how important it is to have a well organized filing system for mobile apps.

Developing mobile apps is a business, pure and simple. Businesses with poor inventory systems fail, the same way a mobile app will fail with disorganized and poorly labeled files. It's not enough to have great file names; they must be stored in well-labeled folders as well. For instance, the Alphabet Mobile App Game should have a separate folder for the 26 WAV files. Although there are many PNG files, it would be a good idea to have a separate folder for the 26 Background Files.

What was one of the bigger points of homogenous file names in the first place? The answer is "Program once, deploy many times." Let's say the Alphabet Mobile App Game's code is written and it is deployed into the Google Play Store and generally flowing about $50/month in royalties, or $600/year. Let's also say the programming of the Alphabet Mobile App Game took about 50 hours to complete, and developing the WAVs and PNGs took about 5 hours. Instead of spending another 55 hours to make another $600/year for a new app, imagine only spending 5. You already know your coding is solid and filled with homogenous file names. Now spend just 5 hours developing new "themes" with the original computer file names and simply switch them in to the original coding. The program doesn't differentiate that 3_background.png represents carrots in the case of the Alphabet Mobile App Game, or a Chevrolet in let's say, your new Racecar Mobile App Game. After just five hours, deploy the Racecar Mobile App Game into the Google Play Store and perhaps double your revenue. While you're at it, why not program once and deploy ten times for perhaps $6,000/year.

Originally, you intended to make one children's mobile app that you could monetize by distributing it in the bigger Marketplaces like iTunes or Google Play. Now employing a numeric and homogeneous nomenclature for file names has allowed you to deploy countless mobile apps with the same programming, which potentially increases your business profits exponentially.

Making Your App Work

Let's get back to the Alphabet Mobile App Game. What happens when your user presses an icon to start the game and it is first loaded to a mobile device? What does it look like? Is it obvious what to do? (Mobile apps don't usually come with a lot of instructions, so simplicity makes a difference.)Start Screen File Inventory (3 total files): mainBackground.png, titleTextGraphic.png, startButton.png

Figure 2.5: What makes up the "splashscreen"?

The Graphic above shows an elementary starting screen (sometimes called a splashscreen) on the right with a not-so-subtle "go!" button. The obvious question is, go where? Do you code the mobile app to start at "A" every time, or do you code it to arrive at a random letter like "D" which might make the game more interesting, but possibly more confusing at the same time. It also might make your programming more complicated.

Since this is a non-programming example, let's simply have the "go!" button (1. Starting the App)arrive at a blank screen (2. Blank), then initialize (3. Initialize), and then load the letter "A" and all of its components (4. Active Controls.) This all happen in the blink of an eye, and the user will only perceive that they arrived at "A."

1. Starting the App (1)

Remember, you are not programming this app quite yet; you are not even storyboarding or wireframing, you are simply thinking about what is going to happen when the Alphabet Mobile App Game is in the user's hands. The first question to ask is about the "Start" screen (1). What are the names of the background images, title, and "go!" button? As you may have already guessed, they should be homogeneous. The "start" screen for the Alphabet Mobile App Game has a xylophone graphic. However, when the app is eventually redeployed as a new alphabet app for farm animals for instance, you'll appreciate that the background file is called "mainBackground.png" and not "xylophone.png." Although the "go!" button implies starting the game, a good file name might be "startButton.png".

The title, "Alphabet Mobile App Game" may not be a graphic but rather text generated by the program itself. If you were to let your mobile app generate a text title for the name of the app (in this case, Alphabet Mobile App Game) with the expectation that the user's mobile device supports a specific font, it may not work. You may have designated the "Curly Cue" font at a specific size for the title text that looks great when you tested it, because your phone has the "Curly Cue" font onboard. What does the Alphabet Mobile App Game look like on a different mobile device that doesn't support "Curly Cue"? Very likely it will switch to a default font and not look anything like what you intended. For these reasons, the title typically is a graphic and could be named "titleTextGraphic.png".

The Start Screen is made up of three distinct graphics. Once again, it is important to note that your original mobile app can easily morph into countless games with no reprogramming because of generic file names.

2. Blank (2)

Before we can get to the alphabet and it's graphics, we need to set the tools and components in place that will make the mobile app work. In reality, there is no "blank" screen, at least not what the user sees, but it does point out what needs to be done before the Alphabet Mobile App Game can commence. (This is actually where a "Splashscreen" goes, but we'll get to that later.)

3. Initialize (3)

Every screen regardless of the letter displayed is going to need objects like the sound icon (soundIcon.png), a left arrow (leftArrow.png), a right arrow (rightArrow.png), an image of the letter to be displayed, (1_background.png which is the "A") and the alphabet navigation bar (navBar.png) before anything else happens. In the case of the Alphabet Mobile App Game, we only want to process this once, (not every time the user switches to a new letter) and moreover, do it before anything else happens. Generally, in coding, this is called initialization. After initialization, the program only needs to load the appropriate background image and letter.

Consider if soundIcon.png, leftArrow.png, rightArrow.png, and navBar.png were all 25 Kilobytes apiece in files size for a total of 100 Kilobytes. Now consider that all 26 of the "alphabet picture" background images are 25 Kilobytes in file size apiece. Without initialization, all five of these images would have to be loaded for a total of 125 Kilobytes every time. With initialization, four objects totaling 100 Kilobytes are loaded only once. Now when the user navigates from letter to letter, only the 25 Kilobyte background is loaded, saving an enormous amount of computer processing. Initialization also makes programming a lot less complicated, a lot more compartmentalized, and once it's complete, you can focus on how the mobile app works.

One suggestion when considering what needs to be initialized is to look at your mobile app and take an inventory of everything that appears on the screen all the time. In the case of Alphabet Mobile App Game, soundIcon.png, leftArrow.png, rightArrow.png, and navBar.png always have to be present for the app to work.

4. Active Controls (4)

At the end of the initialization process, you need to decide what the user sees first; in the case of the Alphabet Mobile App Game, the letter "A" shows up as well as a background image of an apple. (Remember the apple image is named 1_background.png for the first letter of the alphabet and future version considerations.)

Now the numeric naming convention will really come in handy. Keep in mind there are many ways to code, and this example is just one of them. What actually happens when the user presses the right arrow? Your expectation is that the app would advance from the letter "A" to the letter "B." Rather than having some awkward and non-reusable coding say to switch out 1_background.png for 2_background.png when the right arrow is pressed, let's try something a little cleverer.

In all coding languages, it is common to define variables. A variable is just a placeholder for a value, sometimes numeric, text, etc. For instance, if "x" = 1, then "x" + 4 = 5. Instead of referring to 1_background.png, can't we just say that "x"= 1 and x_background.png = 1_background.png? Now when the user presses the right arrow, it's programming simply says "x" = "x" + 1. That means if "x" = 1, then "x" + 1 = 2, and x_background.png is now 2_background.png. All the programming really has to do is display x_background.png every time and simply change the value of the variable "x." Just like computer file names, variables should have solid and understandable nomenclature as well.

In the previous example, the variable "x" works, but isn't definitive. Instead of defining a variable called "x", do the same thing with a variable called "backgroundNum". For instance, backgroundNum = 1, so backgroundNum_background.png represents 1_background.png.

Now we can see that all the right and left arrow simply has to do is redefine a variable (backgroundNum) and the user sees the alphabet advancing or going back. Are you starting to see what can go wrong? What happens when the user gets to "Z", or 26_background.png? At "Z", backgroundNum already equals 26. If so, then backgroundNum = backgroundNum + 1, or 27? There is no 27_background.png. Now what? Programming logic to the rescue.

 

Even though we are still not programming, it is good to think ahead about constraints particular to your mobile app. You knew your user would eventually get to "Z," the 26th letter of the alphabet. The whole time you were redefining the variable backgroundNum by adding or subtracting 1, you were checking if it's value was 26. If backgroundNum's value wasn't 26, then simply add 1. However, if backgroundNum does get to 26, then redefine backgroundNum back to 1 so the app displays 1_background.png and the user sees they rolled through the end of the alphabet and back to "A". The same logic applies if the user presses the left arrow that subtracts 1 from backgroundNum. If backgroundNum = 1, and left arrow says backgroundNum = backgroundNum – 1, then backgroundNum = 0, and there is no 0_background.png. In this case, if backgroundNum = 1, and the user presses left arrow, reset backgroundNum to 26, and the user sees the letter "Z."

Time for another decision: Do you want to use the grey right and left arrow PNGs? Generally, when a control item like the arrows are grey, it informs the user that they are out of context, and are disabled. Originally, there was grey arrow PNGs for context-sensitive controls. "Context-sensitive"in computing means, "depending on the circumstances". In the previous example, we avoided an error by anticipating that the user will get to "Z" and let them roll back through to "A", and vice versa with only the use of the right and left black arrows. Instead of rolling through from "Z" to "A", you could code the app to simply display a grey arrow that does nothing. Basically, if backgroundNum = 26, tell your programming logic to switch the black right arrow for the grey right arrow, and to stop adding one to backgroundNum, and vice versa for "A." The programming really isn't any more difficult or complicated to include the context-sensitive grey arrow, but is it worth it? Does it enhance the mobile app? Does it confuse your user, in this case a child learning the alphabet? The answer may be revealed in your testing phase. If you handed the Alphabet Mobile App Game to an independent user, would they complain that the alphabet doesn't actually roll through infinitely, or would they appreciate the ease in which the alphabet starts over? In this case, we'll continue to let the user roll through.

You might imagine that the WAV sound files are going to work like the PNGs since they have the same computer file nomenclature. Can we repurpose backgroundNum and use it with the WAVs? The answer is absolutely yes. As a matter of fact, it is the best possible solution! However, it does point out that backgroundNum may have been misnamed in the first place because it was originally supposed to only control background files like 7_background.png. Maybe a more appropriate variable name for backgroundNum would be alphabetLetterNum, which will control both background PNGs and WAVs. Remember that the large letter displayed in the upper left on the screen is actually a PNG as well, like 7_letter.png. Should alphabetLetterNum control the letter to be displayed as well? Absolutely! Because one variable like alphabetLetterNum controls three display items, we are guaranteeing that they are all in sync with each other and never have to worry that the letter "R" is displaying with an orange in the background. If alphabetLetterNum = 4, then the associated items to display are 4_background.png, 4_letter.png, and 4.wav.

Now on to the Alphabet Navigation Bar (alphabetNavBar.png.) Before you decide if it's worth it or redundant, consider how it will be programmed. All that's really going to happen is that when a user touches a particular part of the Alphabet Navigation Bar, say "B," the programming simply says that alphabetLetterNum = 2, and all of the appropriate "2," or "B" files are displayed and activated. That wasn't so hard or complicated at all, but questions still remain. Is it worth keeping the Alphabet Navigation Bar just because it's easy to include? The answer is that it doesn't matter whether it was hard or easy to code, it only matters what the user experiences. Users don't purchase games based on whether they are hard or easy to program. The real decision is whether the Alphabet Navigation Bar enhances or detracts from the mobile app. Once again, this is something you may discover in testing.

Is there something missing from the Alphabet Mobile App Game? Should there be an "End" button that lets the user exit the game when they are done? The answer is "maybe." Perhaps the user simply exits the game by using their mobile device's controls, as many apps do. When the user returns to the game, do you want it to restart at "A," by setting alphabetLetterNum back to "1"? Do you make sure alphabetLetterNum retains its numeric value when the user exits the game? If the user exits and alphabetLetterNum was set at "3," that means the game will restart at "C," where the user left off. Would a child know that the alphabet doesn't start at the letter "C.?" Once again, usability testing may reveal these answers.

Without touching a key or doing any programming with an SDK, you've just completed your first mobile app. A lot of thought went into Alphabet Mobile App Game, as it does with all mobile app development, especially in business when it really counts. There was a lot to keep track of. That's where storyboarding and wireframing come in. Having an imagination in mobile app development is a good thing, but organizing that imagination is even better.