Practical Advice for Developing Web Software Applications
- Web Apps Stuck in the Past
- Guidelines, Rules, and Web Standards
- Microsoft ASP.NET Framework
- Content Management
- How To Approach Web Apps
This chapter is from the book
This chapter is from the book
This chapter is from the book
Professional Web teams build Web sites not only to serve static content but also to serve dynamic applications and sites from Content Management Systems (CMS). These should employ user interface (UI)-layer code, further subdivided into markup, CSS, and JavaScript. The importance of this is magnified the larger the Web site or the longer the duration between major site overhauls. Why not reduce dependence on backend programmers or CMS experts, when the UI coders could largely manage UI changes themselves?
Add the challenge of integration with third parties and older and newer Web properties from across a Web enterprise, and you'll see there are endless aspects that can benefit from Web standards. In fact, anything within end-user interface has code that should be implemented using Web standards-based techniques.
Web Apps Stuck in the Past
Many Web application developers learned HTML in the 1990s and haven't updated their coding techniques to incorporate lessons learned since then. It can be an interesting experience to share new levels of separation and strict adherence to a standard or specification with an application developer who's grown tired of the tag soup of yesteryear. Modern standards-based approaches are much cleaner, more efficient and logical, and tend to appeal to software engineers' sense of "either it works or it doesn't"—often reviving their interest in front-end development.
By definition, standards-compliant Web sites strive for strict adherence wherever possible. When Web-based software intersects with or even produces UI layer code, the same levels of discipline should be expected. This benefits the site and the application in the long run by reducing the risks that come with a number of software modifications. Web standards-based approaches increase compatibility and accessibility, and reduce resources and efforts required to change the UI of the application or the static portions of a site alike.
The problem is that there is a huge amount of archaic, undisciplined, or just downright old-school code being implemented where Web software is concerned. We need to take a comprehensive look at custom-developed, in-house software and commercial product implementations to evaluate how and when sites' software can benefit from Web standards.
Software Quality and Inventory Analysis
In order to determine the nature of the situation, each and every piece of Web software employed in a project should be inventoried, cataloged, and evaluated for compliance (or noncompliance) with Web standards.
Web Application Development Problems
From a Web standards perspective, the trouble usually surfaces where the application developers need to create their UI layer—in the areas of maintenance, redesigns, subtle design tweaks, and of course accessibility and browser compatibility.
Typically, a Web programmer is either dropping code into templates provided by a design team or attempting to match a look and feel demonstrated in static representations of their application. There are also software packages that generate UI code with different levels of customization available. And, of course, application programmers writing their own front-end code will achieve varying degrees of standards compliance—some are quite successful and adept; others are not.
A multifaceted problem, of course, but the point is that application frameworks, education materials, generated code, and tools are seriously lacking in best-practices demonstrations. Many developers rely on some form of integrated development environment (IDE), code libraries, or copied code that may or may not follow any sort of best practices.
The results are backend code that produces ugly markup with inline presentation, table-based layouts, extra unnecessary markup, and front-end scripts that conflict, are browser specific, or don't take into account other front-end scripts. Design changes become a real problem—and they don't need to be.
The UI layer is either generated by human effort or it's generated by software (with little effort) and blindly accepted by humans.
But how much effort? Since today's application engineers, server platforms, and tools don't typically create standards-based front-end code by default, the quality is all over the board. It takes a certain amount of effort to achieve standards-compliance on the front end of applications and content management. By establishing a set of best practices for the UI code in server-side software applications, we have something against which software can be evaluated for improvement.
It's important to acknowledge that there is a real tradeoff between solving a problem that will eliminate issues later and simply trying to get the product out the door. Striving for Web standards-based UIs will, in the long run, reduce risk by pulling apart the layers of application logic, presentation, and UI. However, sometimes it takes time to get there.
Evaluation Criteria
For each document within an application, a series of questions or evaluation criteria should be considered:
- Where does the UI layer come from?
- How is the front-end code structured?
- Does it use valid HTML or XHTML?
- Is there a DOCTYPE declaration and is the document rendered in standards or quirks mode?
- How are presentation aspects declared?
- Do the application developers understand the UI code?
- Do the UI programmers understand the backend code?
- How many staff members understand how the UI and the backend are integrated?
- How is markup generated?
- Does the software reference any current presentation code, such as CSS files? If so, which files? Are those files changing in a redesign?
- How tied to the backend business logic, if at all, is the front-end code?
- Is there any way to abstract the UI code from application code?
- If the application generates front-end code, is there any way to control how?
- If users have the ability to generate content or code, is there a way to lock down what they can do?
- What is the level of effort involved in UI layer modifications?
- What is the risk to the application of UI layer modifications?
- What are the potential hazards or drawbacks of not redesigning the application?
- What are the limitations of how third-party software may need to be customized?
Clearly, there is an enormous amount of information to be collected, evaluated, and weighed.
Can Applications Be Updated?
In the end, aspects of some software may be beyond help. There may simply be no way to bring them up to date with the latest Web standards front-end code, either due to architectural issues or unacceptable risk. In these cases, the efforts become an exercise in compromise. Either there needs to be a long-term plan to resolve the issues or both the users and the business will just have to suffer through painful update processes.
This is essentially a tradeoff between short-term effort and risk, and long-term effort and risk. Some partial solutions include either an implementation of some styles (even extracts from or specific CSS files) or a superficial re-creation of the look and feel for a given application. In the long run, though, the organization suffers because it will become more difficult to apply changes to applications that become special cases and need to be evaluated every time a change is made. The critical turning point varies by organization.