December 29, 2020
By: John Tomblin, Solutions Architect
A recent call from a prospective customer led to a question we hear regularly. What is the difference between a website and a web application? My response was "A website is to the backyard pool as a web application is to an ocean". Maybe a bit overstated, but you get the idea. The differences are night and day given that web applications are dynamic database systems with millions of possibilities. Conversely, websites are, fundamentally, very nice electronic brochures.
This article was written for the small business owner who's stuck somewhere between having a website or web application, knowing they need more and are trying to decide whether a web application can offer-up the tools to control their business from the cloud, remotely, from anywhere.
If your Phoenix business is looking to develop a web application, read on. This is part 1 of a 2 part article on what small business owners need to consider when developing a web application, and I am providing this quick reference guide with questions you need to consider as you begin down the path.
Who is your audience?
Answering this question will have a significant impact in deciding what type of web application you should develop for your Phoenix business. Consider the following. If you owned a company that sells cotton candy, and you wanted to exhibit at a trade show, you wouldn't buy a booth at a steel manufacturing convention. The same concept applies to web applications. If the application's intended use is your company employees and management, then the number of browser types and/or mobile platforms become less complex. When limited to only your company employees and staff, you have the added freedom of using vernacular specific to your industry. Conversely, if your web application is being accessed by employees, customers, vendors, and non-defined visitors, then your audience is much broader, and as a consequence, more factors must be considered. Browser software (Chrome, Firefox, Safari, etc.) versions and backward browser compatibility are a few of the questions that must be considered near the beginning of the process, otherwise, you might find yourself redefining your audience, and paying the programming price to make the change.
What are the General Standards?
General Standards include your application's functionality, style, layout, metadata, content consistency, and ease of access to component controls. The end solution must be easy to understand and it must operate in a functional manner consistent with other types of applications in the industry. If for a specific industry, the application must be careful to use the correct vernacular. Also, spelling, capitalization, and punctuation must be consistent across all screens and content, and tooltips and error messages need to be descriptive and not only explain what the error is, but what to do next. Also, applications should be consistent in the use of notations for any PDF, PPT, or DOC files that might become part of the platform. Another overlooked aspect is not paying attention to the layout and spacing of objects and elements on a screen page. Lastly, if you are expecting the major search engines to "crawl" your application for indexing, then your site must have descriptive metadata titles and descriptions, the first steps of an effective SEO campaign. To learn more about SEO, be sure to read some of our other articles explaining the role it plays in your application's lifecycle.
In what language will your application be developed?
Which Browser Standards with your web application use?
In case you did not know, Google's Chrome (as of December 2020) is in version 87.0. That means the software has been completely revised 87 times since it's inception. It also means you will have to decide how much backward browser compatibility you consider to be "safe". For most of our customers, being compatible with two versions back typically works well, but we have had customers request backward compatibility 3, 4, and even 5 versions back. The problem with backward compatibility is that the further back you go, the more diminishing returns you will see, especially when you consider that 80% of Chrome users are already on the most current version of the software and another 15% on the version prior. That means that only 5% of Chrome users are using an older version, which begs the question of whether it is worth all the work, costs, and testing time to ensure backward compatibility, and for such a small audience. Of course, you cannot forget about Microsoft Edge and Firefox. According to Kinsta.com, Chrome dominates with a whopping 63% market share, followed by Safari, Edge, Firefox, and Opera. Global Stats Counter concurs, showing Chrome clearly out in front with 68% market share, but that leaves somewhere between 32% and 37% market share to be divvied up between the remaining browser software companies. So, it is not just about developing the web application, but also deciding how much backward compatibility will be required - and how much it will cost you to provide it.
How much testing is enough? How much testing is too much?
Testing software is a double-edged sword. On one hand, you want to make sure to test all functionality, but if your testing plan becomes excessive, your software will never reach the marketplace. Testing is the single greatest factor most small business owners overlook when starting a project. Stakeholders should create a "Validation Team", made up of employees. Why? Because it is the employees, not the stakeholders, who own the process and know best what works and what doesn't. It is the employees who possess the tribal knowledge, and at Phoenix Bizz, we already know this. For that reason, employees, not the software firm, are the best jurists in deciding if the software meets the business requirements of the company. This is also why we provide a reasonable mix of both Quality Assurance (QA) and User Acceptance Testing (UAT), employees, with every web application project.
What about design?
They say beauty is in the eye of the beholder, but when it comes to web development and design, we respectfully disagree. Every project, regardless of size, should have some level of UX/UI (User Experience/User Interface) design, with the end goal to create a consistent user experience that matches or beats the market's best UX/UI design standards. At Phoenix Bizz, we take a commonsense approach to achieve this goal. We keep the color palette simple, with only a few colors, then one or two accent colors for fine detail. Tables, tabs, navigation elements, and components are designed to ensure easy navigation while staying easy on the eyes. One project of note was developed for a client who mandated the entire site be developed using only grey tones. The final site was gorgeous.
That is all for now. Check back again next week when I will post part 2 of this article addressing domains, navigation, component wireframing, deployment, and stabilization. Until then, go small business!