Client: Whidbey Telecom
Ferrycams was designed and built for my friends at Whidbey Telecom (who provide those of us out here on Whidbey with phone, internet and other essential services). Travel back to civilization for islanders involves catching a ferry. There are cameras at the various terminals, and everyone who has to sail wants answers to all of “the Ws”: When, Where, What, and, if things are jammed up, Why?
Though a website and not an “app”, Ferrycams is very much aimed at mobile users.
All of the content is “live”, pulling data from a combination of private webcams, the Department of Transportation’s (DOT) cams, and various DOT apis. There are idiosyncrasies unique to each player–and I wanted to be a good user of those services and hence there is a fair amount of caching involved–so the project wasn’t as easy as it might seem. The caching works: the number of hits any web cam added to this site experiences, no matter how many actual users are viewing, is at most one or two every minute–not per user, that’s the overall traffic!
The site runs on WordPress. I wrote plugins to handle the API interactions and the administration of the various pieces, while the theme adds styling and a couple of simple templates. (The plugins do not have any native styles of their own, so while you could switch themes and everything would still work, it’s unlikely that it would be pretty without adding some custom styles. )
Nothing is hard-coded or assumed, and the tools could just as easily gather DOT highway cams from the Cascade passes. Cams (both still image and video-based) are the backbone the site is designed around. Tools provided allow site admins to gather their cams into “locations”, and those locations can then be grouped into “routes” (or perhaps “regions”?). Looking at the screenshots, “The Clinton Ferry Dock” is a cam, “Clinton” is a location, and “Clinton/Mukilteo” is a route.
The number of items of any type is not limited–you could have 17 cams assigned to a location and ten locations assigned to a region and the site should work just fine. That said, the navigation experience on a small mobile device would need some help! (We can only do so much within the budget, and that kind of overload was not in the cards.)
Desktop users get a scaled-up version of the mobile experience. (All of the CSS is written to use “scaling” units, rather than hard-coded pixel values.) The site is optimized for typical “largish” smart phones, but works reasonably on smaller early iPhones…though I make no promises about (shudder) outdated Safari.
I designed the site using Adobe XD, a first, and it was a fairly reasonable experience. I use JetBrains products for my actual code-writing, while source control is via Github.
If I can help you with a similar project, please drop me a line!