Migratory Habits of Highly Effective Websites
No system on the web lasts forever. Web sites often start out as static HTML, grow to become interactive through the use of scripts, then grow larger still until they require the use of complex content management systems and multiple servers to deliver information to the visitor.
Migration is an exercise in pain management for both the development staff and the users. Data and business logic get tweaked to live happily in the new environment, but the old way of accessing that information is often obliterated once the new system is in place. If the internet is going to be at all meaningful as a repository of information, access to that information must remain static. The location of that information should not change without leaving a forwarding address.
Think of university grad students or doctoral candidates who cite supporting material from a web site. At the time of publishing, that address may be valid. Is the address going to be valid a month later? A year? Five years? If that location is like most on the Internet, the outlook isn’t so good. If you start designing your next web-based application with an eye toward the future, you can ease the pain, and save time and money when you switch to a new method of delivery. There are several ways you can design for the future, all of them involve two key terms: Separation and Abstraction.
Separation of Church and State
For application development, the best thing a programmer can do is separate presentation logic from business logic, and separate logic from data. When migrating to a new system, your data isn’t going to change, and neither is your presentation (assuming you aren’t also re-designing it). If you have your data mixed in with your business logic, or your presentation mixed with your application logic, you will have a difficult time extricating the parts that need to change from the parts that don’t. This can result in errors in your data, and countless hours of needless debugging.
Content that is free from logic and presentation is more easily repurposed. Want to use an article you wrote for the company intranet for the annual report? Just drop the raw content into your layout application. There is no need to make the designer de-crud the information. If you want work smarter and not harder, create a script that will retrieve the data from your repository and place it into your application of choice.
Le Petit Déjeuner sur l’Herbe
Abstraction is also important. When you originally designed your application, it didn’t need a lot of functionality, so you used a low-end database in order to get up and running quickly. Now things are different. The project has changed, more functionality is required, and the existing database won’t be able to handle the new features. With proper abstraction, the application doesn’t need to know that the database is now a fully ACID-compliant, enterprise-level database located in another country.
The easiest way to achieve this is to abstract queries to the database. The application always asks the same questions, and it is up to a separate module to map those questions to external database queries. This is much easier to maintain as all the queries to the database are in a single location and nothing is changed within the application logic itself.
Web addresses are the single most often mangled piece of content when migrating to a new system. They are also the most important part of a web page. If you care enough about the page to publish it, you should also care about visitors being able to find it. Imagine your old website was created using hand-coded HTML, but now your site is PHP-based. The bookmarks that your users have saved ages ago will fail. Your users will become frustrated, as the address they went to is no longer valid. You can prevent this by abstracting your links.
Let the server route all page requests to a script that uses the URL as an argument passed to the application. That will obviate the need for a visitor to request a physical file. The URL would look like this http://yourwebsite.com/articles/new/ In this case, the arguments would tell the application to retrieve “articles” that are “new” from the database and present them to the visitor. If you created a good hierarchical file structure when your site was hand-coded HTML, the old bookmarks will still be valid, and longtime visitors to your site won’t need to change their bookmarks. However, it is more likely that you didn’t create a good hierarchical structure when building your website. What to do?
The solution to this is simpler than you think. There is no need to create an application to map old addresses to new ones. Your web server has this capability already. By using the standard HTTP 301 (address permanently moved) and 302 (address temporarily moved) errors, you can have old links forwarded to their new locations. Many modern browsers will even update the bookmark automatically, no user intervention required. Visitors won’t even see an error page. The requested page appears as if it were still available via the deprecated address. Consider this a “get out of jail free” card.
Thinking about how a system is going to be used in the future will save you many hours of frustration when it comes time to migrate to a new platform. It takes time to design an application for future growth, but the time spent up front is far shorter than the time it will take to add new functionality into an application not designed for it.