Photo Gallery Part 2: My Requirements

Before I start trying out photo gallery software, I would like to outline my requirements. Different software may be appropriate for different use cases, so an explicit description of my requirements can help clarify what I am looking for. If others searching for photo gallery find this blog, they can compare their requirements to mine to help determine how well our priorities align.

My use case is sharing private photos and small videos with family. I will likely continue to update these requirements as I learn more about this type of software.

User Interface

Not all family members speak English. It would be preferable to use a photo gallery that supports both English and Japanese. This is not absolutely necessary, however, if the user interface is sufficiently intuitive.

Administration

Currently, my wife handles the administration of photo galleries without needing assistance. She currently uploads and manages photos and small videos in batch, generally at the end of every month. We would like to find photo gallery software that allows her to continue administration without help, though I can help her if necessary.

This is a significant constraint because my wife is “non-technical.” She currently uploads photos/videos to Google Photos by dragging-and-dropping them from iPhoto (on an old computer) to a Google Photos gallery in her web browser. Preview images let her easily see which media she has already uploaded.

It would be nice to use photo gallery software that allows my wife to upload media in the same way. I initially only considered such software, but thanks to discussion with Chris Horn, a friend who recently investigated photo gallery software for use on his website, I have decided to consider filesystem-based software as well. Perhaps file browser previews would be sufficient.

Dealing with many filenames, not to mention command-line administration, is definitely not viable.

Viewing and Downloading

Family members need to be able to view and download photos and videos. Some family members are extremely non-technical, so the user interface for doing so must be very easy to use. Downloading is required for saving as well as printing favorites.

Currently, family members are notified of a new gallery via email, which includes a link to the gallery. Clicking on the link opens the gallery. Some family members browse the gallery on a computer use the web interface, while other family members browse the gallery on an Android tablet or phone using the Google Photos app. Both user interfaces are intuitive, and family members have no problems navigating galleries.

One nice aspect of Google Photos is that family members tend to already be authenticated. Clicking on the link opens the gallery directly! Perhaps some photo gallery applications use OAuth to provide this capability. Separate authentication is not desirable, but it may not be avoidable. In this case, a login UI is preferred over basic authentication.

The gallery UI must be easy to use on computers, tablets, and phones. This covers a wide range of screen sizes, and it must work well with a mouse as well as a touchscreen.

The gallery needs to be usable even with slow/poor internet access. The UI should therefore not require huge downloads. For example, consider the case of wanting to view a specific photo on a really slow connection. The UI should load and display thumbnails without downloading too much, allowing the viewer to “quickly” locate the target photo.

Security

The family galleries are all private, and all of the users are trusted. Since the site will not be public, the threat of vulnerabilities is not too significant. I do not trust PHP at all, but I will consider using photo gallery software implemented in PHP in this case, using containers to at least provide some separation.

Another nice aspect of Google Photos authentication is that it helps prevent people from sharing access with others, by accidentally forwarding a link or sharing authentication credentials. My wife and I are able to specify who has access to the galleries. If we are unable to use OAuth to continue using Google for authentication, we will have to make due with lower security.

Photo galleries could be shared by including a secret token in the URL. Anybody who has the secret URL would be able to access the content. We do not want to do this.

If we use credentials specific to the site, there is a risk that somebody may share their credentials in order to share access to the photos. (The value of using Google for authentication is that people would have to share access to their whole account, including email, which they would not want to do.) We can of course tell users to not share access. They can let us know if they would like to give access to somebody, and we can create a new account if we think it is appropriate.

I prefer to host the software within a subdirectory. For example, the software could be served under a https://www.example.com/family-gallery URL. There are two reasons for doing this. Most importantly, the URL to the login screen can be kept private, which greatly reduces the amount of hacking attempts. Another benefit is that it allows a single sub-domain to be used for more than one service. The web server (Nginx) can terminate the TLS and reverse-proxy to each application based on the path prefix.

Features

Support for various image an video formats is important, but my wife and I do not use many formats. We require support for JPEG images and MP4 as well as MOV videos. Transcoding is fine when necessary.

We do not need tagging functionality or face detection, as family users would not use it even if it is supported. Bounding boxes around faces would just be an annoyance.

We do not require comment functionality. It could be nice for my wife and I to add a quick explanation about a photo or video, however, so it would be nice to have. Family members generally comment on photos via email, chat, or in person, not in a photo gallery.

Resource Usage

I would like to keep the costs down. For the server, I am currently thinking about using a $5.00 USD shared CPU plan at Linode, which only provides 1GB of RAM. Such specs will likely be too modest for some of the software that I will try out. The service will be private and have few users, however, so software that is not resource-hungry may work fine. I am particularly concerned with database requirements, so I am interested in software that does not require a database or supports SQLite.

Thanks to discussion with Chris, I am going to consider static options. Serving static content should be no problem with even modest server specs.

A few other friends suggested using a VPN to provide access to a local service. I currently do not have any always-on computers/servers in my home, though I could put such a service in a router, using external storage for storing the photos and videos. Such a solution introduces more points of failure, but downtime is not a significant issue for the service. I do not know if I will have time to explore this option.

As for storage, we do need to store the full history of photos and videos. It is acceptable to only store recent months/years and remove older media to make room for newer media. Family members can download photos that they want to keep, and we can regularly print photo books anyway.

Time

I do not have a lot of time to dedicate to this project. I am therefore not considering writing my own software or using software that requires a lot of time to setup or maintain.