Technical

The Ideas

October 16, 2026: I started writing down a whole list of ideas here, and then (as I always do) went straight into implementing. I’ve now iterated up to version 0.10.0 which has a mostly functional photo app, at least for displaying photos. I will now re-write the idea list to document the changes that have happened and consilidate / elaborate on the ideas that are still to come.

Done

  • Infinite scroll has been implemented. The “Latest” and “Search” functions support a potentially infinate scroll, although there is no releasing of memory yet.
    • New database field addedDateTime was introduced to provide the ability to display all the photos in the archive, latest first.
  • Getting away from the 3:2 aspect ratio has been implemented. A new thumbnail format, called s150, has been added to the “custom” sizes (rendered by default) for the thumbnails.
    • New database fields for the original and edited width and height are introduced and populated to know the exact aspect ratio of the photo.
  • Introduced the concept of “group” and “folder” to the user interface, in the Browse function. Groups are the top-level grouping of the photos: by year, or by special category. Folders correspond to the existing sets, it's jut a new name for it. Groups and folders are intended to become the fundamental top-down hierarchy of the photo archive.
  • Display a splash page while the app starts up.

Still to do as part of the initial release

  • Separating access from filtering. Access is who is allowed to see what. Filtering is who wants to see what. There is a fundamental difference.
    • Introduce a status to define access. There are three statuses:
      • NEW: initial status when photo is added to the archive; only administrators have access to review and categorize the photos.
      • AVAILABLE: regular status for photos in the archive. Everyone can see these photos.
      • RESTRICTED: photo has been categorized but access is restricted. Guests don’t see these photos; user must be logged in to determine whether they can see the photo or not.
    • In the future, it may be possible to define that different logged in users can see different restricted photos. Initially, the restricted photos function as the “private” category in the old database.
    • The NEW status is corresponds with the “new” category in the old database.
    • All categories other than new and private correspond with the AVAILABLE status.
    • Updating the status from NEW to either AVAILABLE or PRIVATE will update the addedDateTime field, because now the photo is really added to the database. This means that the administrator gets these photos back at the top of the “latest” stream; for everyone else, this is when the photos appears in the stream.
    • Update the user profile to indicate whether NEW or PRIVATE photos can be seen by the user. Update all logic to check the indicator in the user profile, rather than the "private" category. Make sure that images only get returned if the user has the right to see them.
  • Make groups explicit. Groups, in the initial implementation, are derived from other attributes: the year field (for the chronological groups) and the file name (for the other groups). This means that individual folders (sets) can actually appear in multiple groups, which defeats the concept of a hierarchical “browse” function.
    • Introduce a group attribute for folders (sets), defining that that folder is part of one group only.
    • Create a groups lookup table with the available groups and their names. Need to figure out if year groups are explicitly entered into that table, or are generated explicitly. Probably want to make them explicit.
    • The year field should always, when possible, identify the year in which the photo was taken. It will be used in searching, but not in browsing.
    • Parents’ photos, and the film photos from Frank and Mark, are to be taken out of the year-based browsing altogether. However, films 001 through 362 or such will continue to be returned by the year-based browsing.
    • This effort will result in a lot of cleanup of the archive, in that the year value of thousands of photos will have to be revisited.
  • Implement the “Random” function.
  • Try to improve the app icon. It is showing up with a big white border, and it may be possible to avoid that by providing an "adaptive" icon. Need to do more research.
    See https://web.dev/articles/maskable-icon?authuser=53, I think that worked.\ It’s as simple as adding “maskable” to the manifest...

To do after the initial release

  • Editing. I want to be able to use the same photo app not only for displaying photos but also for administering the archive.
  • User Management. Maintain users, but also groups, and other elements of the photo archive system.
  • Add photos from inside the app. Make it possible to upload photos from your phone directly inside the app.
  • User preferences that are saved on the server, rather than in the local instance?
  • Filters. Allow the user to set persistent filters (what the user wants to see) that are applied to all displays: “Latest,” “Browse,” “Search,” and “Random.” Things like specifying a minimum quality to display. Also, allow filtering on any result set.
  • Integrate the Photo of the Day.
  • Social media sharing.
  • Rethink the hard-coded file and folder names. I am not sure where to go with that, but the hard-coded names do not seem to be very scalable.
  • Additional options for categorizing photos.
  • Keep track of original file names and time stamps when photo is added to the archive.
  • Consider a “Pro mode” for using the archive, versus the default used for guests and occacional users.
  • Look into streamlining sharing photos from the photo archive to the blog.
  • “Stories” section where photos from the archive can be integrated with a longer textual narrative. Like a blog post, but more photo-heavy than text-heavy.