It may be worth investigating if things look better if the pledge class colors 🎨 are closer together (or perhaps even making this distance adjustable).

Right now, two generations of pledge classes jump from blue to dark purple to magenta. This means that it only takes a few hops to get to yellow, though, which isn't very aesthetically appealing.

Here are some ideas:

1. Make all pledge classes the same color, but with varying intensities (i.e. start at a dark blue and work toward a light blue)
   • This has the added benefit that the user could customize the color palette (blue, red, purple, green, etc.) to match Fraternity colors, while also getting the desired contrast
   • This has issues with color text (black vs. white)
2. Start at something like a purple and gradually get lighter, then switching to light blue and moving toward a darker blue. This could snake over to dark green ➡️ light green ➡️ light yellow ➡️ dark yellow, etc.
   • This shouldn't be much harder to manage
   • I'm concerned about the contrast between things like light green and light yellow
3. Do the same thing I'm doing now, but make the delta a bit smaller
   • Close pledge classes may be difficult to distinguish
   • Far apart pledge classes will be closer to the same color palette, but will still likely fall into the same issue

Whatever solution I go with should work well for ~20 generations (that's the current 14 generations, plus 2 more year's worth). It should also be more aesthetically appealing with the chosen background image (and sufficiently easy to switch palettes given a different background image).

If this works well for the pledge class colors, it should be trivial to switch this implementation to the family colors for an awesome effect.

I messed up the background image in this commit: 5d48572.

That commit works for the local deploy, but not when deployed on github pages (because "framily-tree" is the root of the path, not "/").

We have special code to disable zooming on mobile:

However, apple decided to disregard this on iOS 10.

It looks like this issue was fixed upstream in almende/vis#2123, so we should update the dependency and see if it fixes the issue. After that, we should see if we can remove the user-scalable stuff.

Data might be in an unexpected format (e.g., someone might lack both a "big bro" and a "family started" due to data entry mistakes). This is something we can easily handle in the code.

We could either add these guys to a separate family (named "UNKNOWN") or output warnings/errors in the console.

Sometimes the network appears zoomed out after the page loads (this is before user interaction). The desired behavior is for the network to be the full size of the Theta Chi flag area.

I can't repro on Android but can occasionally repro on the mobile mode in Chrome devtools. I can also repro on my iPhone (safari and chrome). It usually only repros on the first load after a navigation: subsequent reloads always display correctly.

I think this might only repro when inside the iframe. I can't repro when I load a locally-served file within the iframe, but I can sometimes repro if I serve a local file which points its iframe at https://nfischer.github.io/framily-tree/.

Problem:

• Typing in a query that matches multiple brothers will only return one result based on first match of nodes.find()

Proposed solution:

• Populate list of all matches within nodes using nodes.filter()
• Show indicator of multiple matches near search box
• Add Next button or hit Enter to cycle through all results

I pretty much only tested this for iOS safari and desktop Chrome. It'd be great if I got around to testing this on the following combos:

• Mobile iOS Safari
• Mobile iOS Chrome
• Mobile iOS whatever-webview-they-have
  • Ok, I don't know much about iOS apps, but I think they have UIWebView (deprecated) and WKWebView (the iOS 8+ hotness), and there might be a WebView that's also sometimes used
  • This would have the same benefits as listed below for Android WebView
• Mobile Android Chrome
• Mobile Android WebView
  • This covers the users following links from Facebook
  • Also, it means this could be easily turned into a simple mobile app (if anyone wants to take that up)
• Desktop Linux Chrome
• Desktop Mac Chrome
• Desktop Linux Firefox
• Desktop Mac Safari

Problem:

• Content update requires manual execution of scripts due to static nature of GH pages

Proposed solution:

• Leverage AWS Lambda and some sort of CI pipeline

It'd be cool if the web app remembers the user's last selection of map color coding. This isn't a big feature enhancement, but it'd be cool to get used to local storage technology.

Move the hardcoded data out of the repo and use the Google Sheets API instead to pull the data on page load.

Also, update all the instructions once this is changed.