top of page

One Language, Many Features

The design philosophy behind Photo Supreme's variable language

Some features in Photo Supreme look completely unrelated. Rename presets, metadata templates, export definitions, scripts, and custom text all solve different problems. Yet behind the scenes, they share something important: they all rely on the same language for expressing what you want to happen. Most users simply know this as Photo Supreme's macro language: a language of variables, parameters, and context. You never have to think of it that way, but that shared language is one of the reasons so many features behave consistently throughout the application.


Why not store the answer?


When people first discover variables, they usually think of them as placeholders:

  • %FileName becomes the filename.

  • %ImageRating becomes the rating.

  • %xmp:dc:description becomes the description.


That seems obvious. But Photo Supreme doesn't store variables as values waiting to be inserted later. Instead, it stores intent: a description of what information should be available when it's finally needed.


Imagine creating a rename preset before importing a new shoot. The preset may refer to the original filename, the capture date, or metadata that hasn't even been read yet. At the moment you create the preset, none of those values are available. Even after import, the answer may change. Metadata can be edited, labels added, files moved, or information corrected.


If Photo Supreme stored today's answer, the preset would become outdated almost immediately. Instead, it stores the question. When the preset is eventually used, Photo Supreme asks:

"What is the filename for this image?"

"What is its current rating?"

"What is the current description?"


The answer always reflects the image as it exists at that moment.


Templates that age gracefully


This idea appears throughout the application. A metadata template doesn't contain finished metadata. It describes where information should come from. A rename preset doesn't contain future filenames. It describes how those filenames should be constructed. An export preset doesn't know which image it will process next month or next year. It simply remembers what should happen when that moment arrives.


Because the intent is stored instead of the result, the same preset can continue working for years: even as your catalog, metadata, and workflow evolve.


A small vocabulary, many possibilities


Another consequence of this design is flexibility. Imagine if Photo Supreme had a separate variable for every variation you might want:

  • Uppercase filename

  • Lowercase filename

  • First 20 characters

  • Last 10 characters

  • Filename without spaces

The list would quickly become overwhelming. Instead, variables describe what information you want. Parameters describe how you want that information presented.


For example, %FileName asks for the filename. Adding a parameter such as %FileName{UPPERCASE=Y} doesn't create a new variable but simply asks for the same information in a different form.


The result is a language built from a relatively small vocabulary that can be combined in many different ways. As new requirements appear, the language grows naturally without becoming harder to understand.


One language, many features


Every new feature presents a design choice. Should it invent its own way of expressing user intent, or should it reuse an existing language? Photo Supreme almost always chooses the latter. Rename presets, metadata templates, export definitions, scripts, and many other parts of the application all speak the same language. Once you understand variables in one place, you already understand them in many others.


That consistency benefits users because there's less to learn. It also benefits the software itself because new capabilities become available everywhere the language is used, rather than being implemented separately for each feature.


Good design often comes down to recognizing when different features are really solving the same problem.


Context matters


Variables don't really belong to images. They belong to context.


Sometimes the answer comes from the image itself. Sometimes from its metadata. Sometimes from the catalog. Sometimes from application settings, a user-supplied value, or information that's only available while a particular task is running.


The important part is that you don't need to think about those differences. You simply describe what information you want. Photo Supreme determines where that information belongs in the current context and provides the appropriate value.


The goal was never to expose an internal programming language. It was to give users a simple way to describe what they wanted, while leaving Photo Supreme to determine how and when those values should be resolved.


Built to evolve


Photo Supreme has continued to grow over many years. New metadata standards have appeared. New image properties have been added. Catalog features have expanded. New capabilities have found their way into the application.


The shared language was designed with that evolution in mind. Rather than reinventing the system whenever something new becomes available, new capabilities simply become part of the existing language. Existing templates continue to work, while users can immediately take advantage of the new possibilities.

A feature that can grow without forcing users to relearn it is usually a feature that was designed well from the beginning.


Asking the question at the right moment


One of the recurring themes in Photo Supreme's design is resisting the temptation to decide too early. Variables are one example of that philosophy. Instead of storing answers that may become outdated, Photo Supreme stores the user's intent and waits until the necessary context exists before turning that intent into a concrete value.


Most users never notice this design decision. They simply create a template once and expect it to keep working, whether they use it tomorrow or years from now.


That quiet consistency is no accident. It comes from giving the entire application a shared language for expressing intent; allowing each feature to interpret that language in its own context, at exactly the right moment.


bottom of page