Workplan :
Site Infrastructure
Dubbed “Framework”, the application I’m about to outline is a based on the concept of a logical structure in which a website is defined. This can be thought of as a sitemap of sorts, but by maintaining the structure in a dynamic system, with a comprehensive database backend, we can overlay functionality, provide service for multiple sites and allow for independent or semi-independent “modules” to be hung off the framework where needed.
It’s first important for me to outline how encompassing the application will be. The design starts above the websites, viewing a single administrator as the top position. This person has the option to create as many websites as needed. A website in this case is defined as: a set of hierarchal html pages that respond under a specific domain name and have a similar or unified interface.
The system allows for one additional step in diversity, and this is the ability to react to a third level domain part and create a new site based on that part name. This has two ramifications. One, that newjersey.domain.com will be perceived as different from newyork.domain.com and thus can contain two distinct (or semi-distinct) websites. Two, that those two websites will be able to draw from the same information base and utilize the same administrators based on the fact that ‘domain.com’ is similar between them. In this way, we can add domain2.com to the framework without jeopardizing our security model based on political or geographical subdivisions.
By creating a powerful framework such as this, we open ourselves to saving a considerable amount of time in the long run on several points: One, generation of the original applications, such as the article editor, page editor, permissions system, login system, administrative screens and others will be a one-shot deal. Although all these applications will have a somewhat heightened awareness of what site they are currently working for, overall all sites will benefit from more robust tools. Two, a compound database will be designed to accommodate all framework information. This new database will be independent of previous work, and well eventually contain all other current database structures with the notable exception of the Bonner WBRS 2.0 system. Three, Overall maintenance, debugging, and feature expansion will also be a one-shot deal. Once any modification is made to the framework, all sites within will benefit immediately. Four, hosting will be a less complex scenario. While each site will maintain its own usage logs, the framework as a whole can be thought of as one large system and with that, there are less things to go wrong.
There’s really nothing new, except for the overall framework itself. I’ve strived to reduce the costs and complexity of the system while still providing the features I think are necessary to long term success.
Below I outline the major areas of function in the framework itself.
Navigational System (or Sitemap)
This covers the central database structure and administrative screens that provide the description of each site. This is where pages are created, attached to the site where they belong, and filled with static or dynamic content. This system also maintains the geographical or political subdivisions, if needed. Estimated construction cost: $3,000.
Single Point System
There are two ways in which the system will be considered single-point, one in the fact that all web pages will be viewed with a nearly identical URL, meaning that rather than defining multitudes of pages or applications, we’ll use a simple system of displaying page content from the framework by using a single retrieval application. Also, whenever a user wishes to or needs to login, a single point login function will take care of this need. In fact, all sites within the framework system will utilize the same user database, vastly cutting down on redundancy. Estimated construction cost: $2,200
Page Builder
Since the framework is basically designed to hold web pages, it’s sensible that a convenient page builder needs to be included. In some cases, the page builder will simply accept the name of an external html file or application to display. In other cases, html maybe be simply clipped into the database from another source, such as Dreamweaver. A final option will be to use some predefined templates, specific to each site, to create a simple page. Any time that html or page content in saved directly into the database, the page builder will also provide the means by which to maintain and modify this data. Estimated construction cost: $500; plus $200-$400 per template.
Article Builder
Moved almost intact from the CORPSnet project, this article builder will provide the foundation for creation of any textual entity in the database. This will be especially useful for items that require collaborative creation. Such entities are: News articles, Calendar items, Reports, Profiles, and Feature Stories. Keep in mind that once constructed, this module will not need to be recreated for COPRSnet and it’s primarily positioned in the framework due to its central importance to that site. Estimated construction cost: $4,500
Spell Checker
This is a simple integrated addition that I think is important enough to include wherever possible. Both Builders above will clearly benefit from a simple but effective spell checking system. Estimated construction cost: $1,000
Help
Throughout the system, literally on every page, a unified help system will be supplied to cover the needs of all users, administrative and public. Although not something that’s often given much thought, a help system can be invaluable to both a user and a visitor. Estimated construction cost: $800