It’s very easy, especially for an “evolving” web application, to end up with a user interface that is buggy and difficult to maintain, particularly if you are incrementally making changes to an outdated app, without a full redesign. This is a challenge that I’ve faced on many occasions, as I have often worked on applications that were built using an outdated software paradigm or have subsequently failed to keep up with the advances in software technology and methodology. This is not uncommon at all, in fact most, if not all, software engineers have had to deal with this on many occasions during their career.
Working through these challenges has taught me a great deal about the evolution of software applications. It’s something that I’ve had to learn, while balancing the day-to-day demands for the support/upkeep of an existing codebase. This process can teach a developer a great deal, as they research best practices and gain experience; but most importantly, it can teach developers what not to do, as you see how the process unfolds over time.
10 Principles of Front-End Web Application Design
The principles outlined here are those that have worked best for me. Given the situations and experiences I’ve had to deal with. Hopefully they will be useful for your project too. I’d be interested in hearing your suggestions and criticisms, so these principles can be improved.
Avoid using tables in the HTML layout.
Tables were first used, because they were a way to create layouts that couldn’t be created with the standard HTML tags in early browsers. Tables are, however, a terrible way to organize your layouts for a variety of reasons. Many better methods have been implemented since the table heyday in the 1990’s, still many developers haven’t gotten the memo and continue to use tables, which severely constrains the flexibility and the stability of their layouts. If part of your front-end uses tables, take the time to implement a better layout.
Use naming conventions
At the very least, when you’re writing a module, keep the naming consistent and meaningful throughout the module, Ideally this should be done throughout the application as well. Make the names so understandable that someone who isn’t even familiar with the code can see the pattern and understand the meaning, without even needing to read comments or documentation.
Comment the code
If you learn a better way of doing something, set aside some time to apply it to existing code where feasible.
Inevitably, as you grow in your understanding and incorporate the latest methodologies and software technologies, you are going to have some modules become out of date. It’s important to put in the time to keep things up-to-date on a regular basis. It will make your application look/behave more consistently and will eliminate the kinds of nightmares that can happen if parts of your application become severely out of date.
Re-evaluate your technologies and methodologies on a regular basis, to find areas to improve
If you regularly improve, your technique and the technology which supports your technique, will continue to improve; your system will stay in good shape and remain adaptable. On the other hand, if you become locked in your ways and unchanging, you will eventually find that what you are doing, while it may still technically work, is obsolete and can be done better and more efficiently in another way. Then you’ll be forced to take more risk by having to potentially rewrite your application, if it becomes too far out of date.
Be scientific in your evaluation of potential new technologies and methodologies.
When you’re making decisions about the future of your application, don’t make them based on whim or hearsay. Do extensive research, utilizing several different sources. Encourage your team to do research as well and share the results. If you spend a few hours up-front making the best decision, in a scientific and rigorous way, you will save yourself a great deal of time down the road. If you ignore this advice, don’t be surprised if you have to rewrite your application again.
Be decisive and follow through.
Once you have applied the principles and made informed decisions, follow through with it until you have a good reason not to. It’s often tempting to want to try new things or change conventions and methodologies; but if you change your mind too much your project will have no direction, time will be wasted and the quality of your application will suffer. If you’ve made a good decision with all of the available information in the first place, you should have no reason to change your mind. If however, you are changing your mind frequently, it likely indicates that you are making decisions hastily, without considering the available information. Those who follow through write better products which are more professional, lower maintenance and more appealing to users.