While prepping an orienteering trail, we needed to compare GPS track and photographs alongside an existing map that might be out of date with the current park trails. That was the delivery problem for the Grant Park review tool: put the material together so it could be examined, layers compared, and photos of interesting features traced back to their locations.
I developed an ad-hoc viewer for that work, which I talked about back in an earlier post. Its delivery format was a single HTML file, with the maps, photographs, and interactive code embedded. A browser provided the interface; the design didn’t require a hosted application to supply the material during review. The file was about 90 MB. (“Single file” and “small file” are different promises.)
That size bought something useful. The map and photographs traveled with the viewer, instead of depending on a collection of links that the recipient also had to be able to reach. The package included original data and exports for further work, so the viewer wasn’t the only way to use the material. Someone who wanted to inspect photographs had an interface for that; someone who wanted to work with the geographic data had separate files.
A hosted version would have introduced another responsibility: keeping the application available for the person reviewing the map. Hosting can be worth that responsibility, but the need to inspect a particular set of material doesn’t automatically create a need to operate a service. For an occasional handoff, a file might be fit for purpose.
The work doesn’t disappear when you remove the server, it just moves. A large file has to reach the recipient, and the recipient’s browser has to handle it. The viewer was designed for offline use, but I didn’t check compatibility with every browser or operating system. A useful acceptance check is to open the delivered copy without a connection, inspect its photographs, make an adjustment, save it, and reopen the result. File size alone says nothing about whether that sequence is comfortable or even successful on the intended machine.
Updates also become a handoff problem. Replacing a hosted application can give everyone the revised version on their next visit, but sending a new file leaves the old copy wherever the recipient saved it. Clear revision names and instructions matter, especially if the recipient has already made adjustments. “Use the latest one” isn’t much help when both copies are called final.
And don’t put revision names or dates in filenames in the first place. Use a revision control system if you need to control revisions! I just shared the file on a cloud drive and overwrote it when needed; there was no need for the previous version when a new version was available.
Keeping the source data alongside the viewer helps here, too. The Grant Park package preserves the original GPS coordinates separately from the display adjustments, so a recipient could carry those observations into another tool without treating a visually adjusted overlay as a new measurement. That’s useful whether the interface arrives as a file or through a website.
I’d reconsider hosting if the job changed to frequent updates, several people editing shared work, or access that needed to be managed centrally; those requirements give a service something specific to do. Before choosing the delivery format, ask who will use the result, what they need to change, and who will look after it when the original work is finished.
—jhunterj