Messianic Fellowships

A visual directory of Messianic congregations, covering who they are, and where they meet, and when they meet, and what they are affiliated with. The problem it solved is the problem that every scattered community has, which is that the information exists but it exists only in people's heads and on a hundred separate websites.

It is the earliest web app that I built for myself, and it runs to around 2,500 lines of PHP.

The data model

The whole design is legible from one table:

CREATE TABLE fellowships (
  id          varchar(30) primary key,
  name        varchar(200),
  address     varchar(400),
  email       varchar(50),
  timestamp   int(11) unsigned not null,
  leader      varchar(50),
  phone       varchar(15),
  website     varchar(50),
  affiliations varchar(200),
  latitude    varchar(10),
  longitude   varchar(10),
  services    varchar(400)
);

The latitude and longitude columns are the interesting ones. The directory was not a list that you scrolled through, because it was a map that you stood on. Geocoding each congregation at the point of entry, rather than at the point of search, is what made "near me" cheap to ask for.

Geolocation, in 2012

Finding the user was the hard part, because navigator.geolocation could not yet be assumed to exist. The app shipped a shim that detected whether the browser had native geolocation, and when it did not have it, the shim fell back to Google Gears, and that included a special case for the build of Gears that ran on Windows Mobile.

That is a dead technology stack solving a problem that is now one line of JavaScript, and it is a fair snapshot of what web development felt like at the time, because every capability you wanted was a feature test and 2 fallbacks behind it.

Layout was handled in the same way, with the 960 grid system for the structure and adapt.js to swap the stylesheets by viewport width. This was responsive design in the window after people had accepted that phones mattered and before media queries were something you could simply rely on.

The rest of it

There is a hand-rolled framework under fls-include, which holds the configuration, and a database layer, and form handling, and a mailer, and a session layer that runs to 634 lines on its own. On top of that sit the things that any directory needs, which are login, and forgot-password, and user profile editing, and the add and edit flows for the fellowships themselves, with an admin tier sitting above the ordinary users.

The user profile table carried headline, and location, and about, and topics, and websites, and feerange, which is not what a congregation directory needs at all, because it is what a speaker profile needs. The same backend was powering Supply The Pulpit, which was built alongside it in that same year.