January 05, 2021
By: John Tomblin, Senior Solutions Architect
PhoenixBizz, a division of Sofvue, LLC
In last week's article discussing web application development, I talked about audience, general standards, design, programming languages, browser standards, and testing. This week we are going to discuss domains, navigation design, component wireframing, deployment, and stabilization.
What about domains?
Two more points regarding domains. First, if you do not already have your domain name, and you are scouring the web to find the perfect fit, spending $1,000 or $2,000 is a drop in the bucket for a decent domain name, especially when we see our customers spend up to $15,000 for a good, but not great, domain name. We were recently stunned to find one of our clients find and purchase a seven-character domain name using two whole words, and with only two syllables, and did so for only $100. So, can you occasionally get lucky and find the perfect domain for a few hundred dollars? Yes, but these are extremely rare cases. Second, syllables count. Phoenix Bizz is three syllables, and our parent company, Sofvue, is two syllables, and both by design. A lot of work and investment is made into purchasing and managing the right domain names because we have seen customers build great solutions yet fail because of a horrible domain that cannot be branded well.
What about the application navigation design?
Simply put, navigation design is the art of providing your users with the best possible experience while using your application. Is a hamburger menu the best way to drive navigation or should you use tab controls? Is it better to use pop-up elements or expand/collapse controls? Should you use vertical or horizontal navigation, and based on that decision, how will the text, or graphics be presented for the navigation? The answers to these and many other questions are based on your application's audience. If the application is only being used by employees, and you can use tooltips and text explanations to get your point across, great, but if your audience is both employees and customers, how are they different from one another, and how and when will your application deliver and manage their user experience?
Component wireframing. What is it and why does it matter?
Web application component wireframing is to software as blueprints are to a custom-designed home, and if you have ever heard the statement "A picture is worth a thousand words", then you will understand why. Not only do wireframes create important visuals and design elements, but they also provide stakeholders, programmers, and testers an incredible roadmap of the application's functionality and workflow. For startups, component wireframes not only create an ability to create video use-case scenarios but allow potential investors to view the total application as a Minimum Viable Product (MVP). Having component wireframes also saves considerable time and forces answers to questions at the beginning of the process instead of mid-way through development. We once had to create a "User Management" component for a client that, because of specific business requirements, resulted in the collection of seventeen pieces of information about each member, despite the fact that the client had told us repeatedly they only had eight, and it was not until we wireframed that component that the stakeholders quickly realized their error, and did, in fact, have to collect more information. Wireframes force functionality to be completely unraveled, which in turn, ensures all the elements for each business and programming requirement are completely flushed-out, long before any coding begins.
What about deployment?
Deployment is much more than just flipping the hosting switch. It is about making sure that once all the testing is complete that the application is launched to both a production environment (where user and customers interface with the application), and to a staging environment, as well. Having the staging platform allows for new functionality to be added, testing and validation to run seamlessly, and all of this before moving new component functionality to a production environment. Yes, it adds some additional management and versioning requirements, but it pays huge dividends in the end.
Just like athletes at relay races at the Olympics, web applications, once released, need time to settle down or "stabilize". If you find yourself constantly adding new functionality to your application, within what appears to be minutes since the last source code upload, it means that the development deployment schedule was wrong. You should allow released software to operate across the enterprise for a minimum of 30-60 days before adding additional functionality. This also bods well with employees and customers, otherwise, you may find yourself continually criticized for having software that is constantly changing.
I hope this quick reference guide provides some insight on what to consider as you start thinking about whether a web application is in your company's future. Be sure to ask us about our case studies and how they can help you decide the best options moving forward.