As the core content of the site was ported from archive, the styling, content, and layout is antiquated at best and spaghetti code in general. It is recommended that the entire site be refactored to match a modern and updatable new standard.
A first option is to manually refactor. This is a traditional refactoring. This would include a refactoring of all HTML content that was not already accounted for in the creation of new header/footer content. Each HTML component should be evaluated for purpose, usage, and location, then subsequently assigned an appropriate formatting convention and its code updated appropriately. The ultimate goal would be to arrive at a streamlined set of pages and CSS, with no unused components and minimal leftover code (deprecated, commented-out, etc..).
A second option would be to refactor using a templating engine like Jekyll. A similar outcome of streamlined and pruned code is desired. Jekyll requires more initial investment of developer time and education, but allows for easier future updates with a more modular design (eg. support for blog posts with minimal developer investment) due to its integration with GitHub Pages. At the time of this writing, the showcased sites built with Jekyll are impressive, with several featuring a similar overall style to our current manually-created state, making a transition relatively painless.
Both of these options should be considered. It is also possible (and my recommendation) to pursue option 1 in order to fulfill a public-facing stable resource in shorter time, then attempt a migration to option 2 for longterm stability and additional features.
As the core content of the site was ported from archive, the styling, content, and layout is antiquated at best and spaghetti code in general. It is recommended that the entire site be refactored to match a modern and updatable new standard.
A first option is to manually refactor. This is a traditional refactoring. This would include a refactoring of all HTML content that was not already accounted for in the creation of new header/footer content. Each HTML component should be evaluated for purpose, usage, and location, then subsequently assigned an appropriate formatting convention and its code updated appropriately. The ultimate goal would be to arrive at a streamlined set of pages and CSS, with no unused components and minimal leftover code (deprecated, commented-out, etc..).
A second option would be to refactor using a templating engine like Jekyll. A similar outcome of streamlined and pruned code is desired. Jekyll requires more initial investment of developer time and education, but allows for easier future updates with a more modular design (eg. support for blog posts with minimal developer investment) due to its integration with GitHub Pages. At the time of this writing, the showcased sites built with Jekyll are impressive, with several featuring a similar overall style to our current manually-created state, making a transition relatively painless.
Both of these options should be considered. It is also possible (and my recommendation) to pursue option 1 in order to fulfill a public-facing stable resource in shorter time, then attempt a migration to option 2 for longterm stability and additional features.