Where this all started

During college, I volunteered to maintain my fraternity's "family tree:" a hierarchy showing the pairings of little bros & big bros. Everybody has one big bro; a big bro may have one, multiple, or even zero little bros. We also gave names to our families, originally dividing into two main groups named the Saints and the Regulators. Over time guys decided to spin off their own families (ex. the Liberators spun out from the Saints).

I originally maintained the family tree using flowchart software (Microsoft Office Visio). This worked in the beginning, but as the families grew in size it was no longer manageable to fit everyone on one page. After graduation, I decided to build a website for the family tree and automate the work of arranging everybody. Thus, the Framily Tree website was born!

Computer Science background

In computer science terminology, we call this a Tree data structure. This data structure is defined by nodes which will each have zero or more child nodes. This concept maps nicely to what we're trying to track: each fraternity member is represented by a node, and their little bros (if they have any) are represented by child nodes. Each of the different families (ex. Saints, Regulators, etc.) are represented as their own tree graph.

Design

The main design parameters for this project were:

1. Easy to maintain/update
2. Easy to share
3. Interactive
4. Free to host the family tree website

This led to a few key pieces of technology:

1. Google Sheets to keep track of the big bro/little bro data
2. Needs to be a website for easiest shareability
3. Use Vis JS for an interactive graph
4. Use GitHub Pages for free hosting

Design consequences and trade-offs

Although GitHub Pages is free for hosting, this only hosts the "frontend" of the site. To keep this totally free, the Framily Tree project has to work without a need for the backend. Normally a backend would be used to facilitate communication between the frontend (the web page) and the data storage (our Google Spreadsheet); since we don't have a backend, the workaround is: after updating the spreadsheet, I use a commandline tool to pull down the Google Sheet data, parse it, save the data as a JSON file which is bundled directly into the website, and publish the changes to the website. This gets the job done, but it would be nice to have the option to skip the intermediate step and let the website pull directly from the spreadsheet (see issue #1).