Software programs are like food and clothing. They come in all shapes and sizes. There are billions of programs. But all of them can be classified in a few categories. This post informs you about the different categories of software programs, what can be achieved with each, where they fall short and how you can decide which one you should build, or assemble a team for.
The topic seems very basic, but I feel that companies today are churning out too much code and too many variants of the same program for their own good. As a company, it is worth pausing and asking yourself what you really want to achieve for the users.
Let’s see the different categories of software programs with the help of a story.
‘Stock Up Your Money’ is a fictious financial services company in our story. Their intention is to make a software solution for customers to give them recommendations on what stocks to buy and what stocks to sell everyday. The company cares only about people who trade once a day. They do not care about the traders who sit in front of a computer all day, jumping from one trade to another.
Using various formulae for calculating which stock is trending and which stock is failing, they want to give recommendations on whether you should buy a stock, sell it or leave it alone on a given day.
“There is an app for that”: An app with a user interface
Let’s assume that ‘Stock Up Your Money’ is one of the millions of typical companies that decides to build an app with an icon on the home screen, that a user can click to open. The user typically goes to the website of a company and downloads a file that he can use to install the app. Or he goes to his manufacturer’s application store.
Clicking on the home screen icon usually opens a user interface through which the user can interact with the program. Once inside the program, the app’s home page loads today’s recommendations. The user can click on each stock to see its chart and indicators. He/she can fiddle with the stats from every angle before reaching a decision on whether to buy, sell or keep. Examples of such applications are apps on Windows desktop, Mac OS, iPhone, Android and Linux desktop, e.g. Ubuntu.
Examples: Microsoft Office, Adobe Photoshop, Instagram, Uber
Advantages: Be it Windows desktop, iPhone or Android, there is a proven process for building apps and making it available to users. Usually, Windows goes with its familiar setup.exe installer file, whereas Mac OS, iPhone and Android users turn to their respective manufacturer’s apps store. The development process for each of these platforms, along with which programming language to use are well documented. Several courses can teach how to program for all these platforms. Installing an app and clicking on its app is a very familiar experience for the users on these platforms. Native apps also have the option of accessing the full range of a device’s hardware. So you can use everything from the front camera to the tiny gyroscopes.
Disadvantages: An app created for one platform does not run on another platform. If you target Windows desktop, iPhone and Android users, then you need to create three different apps, each capable of running only on the device for which it is made. What’s more? All the apps may need to be created in different programming languages, e.g. C# for Windows, Swift for iPhone and Java / Kotlin for Android. To roll out native apps in each platform needs different skill sets, that many teams to be hired and that many app stores / markets to distribute the app to.
Personal opinion: There was a time when native apps were the only option. In fact, the process of building an application with a UI meant that you must make an app native to a platform. But the next two headings will look at more elegant and all-platform compatible solutions. For me, the era of mandatory native apps is long dead and as a freelancer, I usually reject such projects. Today, the only reason to resort to a native app is if the app is going to run on a custom device fitted with a screen, running its own operating system that doesn’t support a web browser, e.g. Arduino. You’ll also need a native app if you will access special hardware not yet supported by other all-platform solutions such as the web applications.
“Let’s surf the app”… with a browser
What if ‘Stock Up Your Money’ took a step back and decided to create their application as a website? Google has been doing it for years now, with GMail that doesn’t require Outlook Express, with Google Drive that doesn’t require Microsoft Word / Excel. Heck, they even have Google Maps running on the browser. This practice has also been successful for Amazon and e-Bay with their online markets, for Dropbox with their cloud storage and for Facebook with their social network.
All you need is a browser and a URL. When you hit the URL, the server at the other end gives you everything necessary to run the app. The browser’s internals are responsible for converting files written in HTML and CSS into the UI that you see on the screen.
Modern browsers have come up with support for saving a website as an icon on the desktop screen. So clicking on the icon opens the browser directly to the website. Feels just like a native app. What’s more? Browsers these days support GPS, camera and even bluetooth. No need to make a native app even to access these hardware features.
Examples: GMail, Google Drive, Amazon, Facebook, Twitter, Dropbox
There is no release process, i.e. you do not have to upload an app’s finished product to some market place like an app store, so that people get to download and install the app. You just need to publish the URL some place where everyone can see it. A single click on a hyperlink is all that a user needs to launch your app.
Disadvantages: Most full-featured web applications depend on cookies to maintain sessions. If a user has disabled cookies, then the web apps won’t run. An outdated browser is incapable of running web applications properly. Plus, there are usually problems making Internet Explorer run properly.
A web application is also insufficient if you are accessing special hardware. By design, a web application does not allow you to build components that can access your hardware directly. Only a few categories of hardware, such as GPS, bluetooth and front camera are supported.
Personal opinion: Web apps are second on my list of go-to options to develop solutions. It is rare for me to write apps that support special hardware and it is easy to write a web app that runs reliably on different platforms. There is no release process, i.e. publishing the app to an app market. You just need to upload files to your own web server and distribute the hyperlink to everyone you care about.
But why are web apps only second on my list? What takes the #1 spot?
“I don’t see or hear it, but it works, just like God!”… in the background
What if Stock Up Your Money’s core business simply depends on their calculations and recommendations? What if that’s all the user pays for? Why should the company build an app or a website at all? What if they simply calculate recommendations and simply send those recommendations to the user by email?
“But what if the user wants to analyse the stock, look at its graph and indicators?”, you ask. Sure, but does it necessarily have to be Stock Up Your Money’s work? Inside the recommendations email, can they link to the stock’s page on Google Finance, Yahoo Finance, StockCharts or one of the hundreds of free services which already do that? The user wants to see charts, the user has got it. Does it really matter to Stock Up Your Money’s ‘brand’, where the chart comes from. As I see it, the company should be branding themselves as experts at recommendation and not at building UIs.
In his book, ‘The Best Interface is No Interface’ (Amazon India | Amazon.com), the author who calls himself ‘Golden Krishna’, writes about why your first instinct should be to eliminate user interface all together. Curiously, Golden Krishna is a UI designer by profession and conventionally used to earn more per app by making as many screens as possible. But his new approach is to understand the user requirements to such as point that he recommends automation and eliminates screens. Companies save so much money on all the UI that he discards that now they call him to eliminate screens. And he earns more by recommending and doing less work.
Apps running in the background with no UI are my favourite category of apps and I usually snap up any chance I get to work on such apps. Most server software fall in this category. The server contains all the code for business logic and then simply passes on HTML to the browser. It then becomes the responsibility of the programmer working on the browser side (category 2 in our post) to ensure that the UI is smooth. If the system is designed to have no UI, then the server can simply shoot an email to the user as a summary, using third party services to give the user more information.
Examples: Alexa, Google Home, Web servers, Messaging servers, Programs that build a report from data and mail that as a PDF, programs that curate articles from around the web and then send the user an email with links and descriptions.
Advantages: Cutting down on designing UI drastically reduces the development time. It also means that you don’t have to hire a team for design and UI development until absolutely needed. If the user only requires you to provide information and not a full-fledged user interface, then a background program that emails or messages the user is ideal. Even if a UI is required, then the solution may seek third-party services.
Disadvantages: Even with programs happily chugging along in the background, the user may want to control a few things. E.g. what if the user has preferences and does not want recommendations on alcohol stocks? What if he wants to block certain companies because he / she doesn’t like their ethics even if the stock price paints a rosy picture. Background apps do not have a UI, so we usually need to pair it with another app that does have a UI, e.g. a web app where the recommendation preferences can be set. You cannot usually build a background app standalone, without building a support app with UI.
Personal opinion: My favourite activity is to build a number of small apps that run in the background and do useful things without the user having to intervene. But somewhere, the user needs to be able to set preferences. I recommend attaching a small web server inside the background app itself, so that the user can open the settings via a browser and change the app’s settings even while it is running.
“Help me speak to this machine” … Device drivers / Apps which control hardware
So far, we have been talking about apps that solve business problems. But those problems are not solvable until the underlying hardware works perfectly. This is the job of the people who write software that speaks to the hardware to get things done.
You want to get stock recommendations from Stock Up Your Money? Well, someone wrote the device driver that enables your WiFi card / 3G connection to use the Internet to receive recommendation mails? Do you see the recommendations on the screen? Well, someone made it possible for your monitor / LCD screen to light up and show the recommendations. Do you want to print the recommendations on a sheet of A4 paper? You bet. Someone made it possible for your computer / phone to speak to your printer. Someone even made Alexa and Google Home possible. Because ‘Stock Up Your Money’ made apps for those platforms. The apps in turn activate software that make these tiny devices use their speakers to announce the day’s recommendations to you.
I am not delving into the advantages or disadvantages of device drivers, because they are absolutely necessary. Without properly functioning hardware, there is no software.
As you can see, we have covered three broad categories of applications: those which have a user interface, those that run in the background and perform business logic and those that make hardware function correctly. Among the apps with UI, we can see native apps that run on a specific device and web apps that are capable of running on all devices. This wraps up our discussion of the category of apps we see around us. Next time you fire up your favourite app, think about all the categories of software that makes the app run and thank the people who made them possible.