In my time at Brandeis University, I spent 3 years working hard for the Brandeis Student Union. Over those three years, we had three different computer science students as “web-master”, and three politicos as “communications director”. The problem was that each “web-master” would build a beautiful website that was never able to be updated because the communications director never had the technical expertiese to update the HTML or use the static site generator.
As college was coming to an end, I was frusturated because my time with the board of trustees had not been as productive as I had originally hoped. Looking for a place I could have a lasting legacy and impact, I found it in the Student Union’s website.
At its heart, the problem is one of distributed data management and editing. Students within the union should have different access to edit different data, but the site should be rendered in a way that does not reflect this mutliple authorship - components should be rigid enough that an author’s style does not bleed into a unifying presence. In addition, a distributed ownership model for content needed to be (A) version controlled (B) auditable © completely non-technical.
The end product is pretty sweet, and uses some smart optimizations to minimize hosting costs and maximize page load. I took advantage of Github’s “pages” platform to serve the static HTML renedered by the site. A change in one of the underlying sets of data would trigger a re-render of the HTML generated by the data, and then would be written out to github pages. This had two main benefits - github automatically maintains version control history, which enabled auditing of who wrote what and when, and github stores its HTML files in pages in a blazing fast CDN. This meant that lookups to the webpage were infinitely scalable and cheap (from my perspective), and meant that there were not “read” server costs.
The server that processed writes was built on app engine, using JSTL templating over datastore objects to render the HTML to write to github pages. More exciting than that was the group strucuture that I made so that sub-groups of the Student Union could have access to different sets of permissions for editing. This formed the basis of Committee pages, and organization pages, which were only editible by their members.
Additionally, the data was reused between pages for commen elements (for example, all committees should have the names and bios of their members, even if each member is in 10 committees).
On the front end, I used a “Medium”-esque visual markdown editor to enable the construction of HTML elements from a given set of supported ones (which I provided a cohesive design language for on the rendering side).
The result is gorgeous, and far more importantly, meets the needs of the Union. I left Brandeis two years ago (writing this from 2018), and it has been used effectivley by three Student Unions since. I do occaisional performance upgrades and feature requests, but I’ve seen the site updated by dozens of Union Members without any technical knowledge.
I’m quite proud of this project because it stands solidly at the intersection of technical simplicity and client needs. I have confidence that the Union will be using this product long after anyone remembers me at Brandeis.