A Quick Lesson on Program Design

Whenever you’re programming there are always numerous nuances that can impact how you write the code both on the side of style and on the back end (on the conceptual side of how something works). At the moment, I’m working on the subtitles feature for the Delight XR video player and I’m going to use that as an example for the nuances involved in programming.

If someone tells you to make subtitles, you might think something along the lines of “You just put words at the bottom of the screen, right?” However, stylistically there are so many variables to deal with. The obvious ones are font type, font size, color, etc., but some of the ones you might not think about are when a new subtitle is displayed, does it appear or does it ease in so that it doesn’t catch the audience’s eye in a distracting manner, do you place a background so that the text isn’t hard to read against the video, if so how transparent do you make it, and the list goes on for a while. Some of these details are pretty easy to see. If you watch the news with subtitles, the text scrolls on screen as things are said, but if you watch something on YouTube, for example, that has non-auto-generated subtitles, each line appears on screen. When I was using YouTube to research styles and techniques some of the things that caught my eye were that the corners on their background were sharp (as opposed to round), their background was particularly opaque, and they didn’t use any transitions or fade-ins. Another large factor that I have to keep in mind stems from the video players ability to be viewed on any device. So I need to think about how my choices look on a cell phone as opposed to a laptop or maybe a tablet, or even in virtual reality (which has its own set of items), but all of this is just what the user sees.

On the other hand, we have the back-end, which is completely hidden from the audience and is based around how the program works. Each subtitle file (usually a .VTT or .SRT) has a list of cues (the text of the subtitle) and corresponding timings (the range of times (usually with precision to the millisecond of when the line should be displayed), so one of the things that I experimented with for a while was seeing what needed to happen to make two or more lines with overlapping timings to appear and not take up the whole screen. But this brought up a new problem on the backend, do I tell the computer to check the entire file to make sure that I gather each line that needs to be shown or do I trust that the file is in order and tell the computer to find the first current subtitle and stop looking once I find one that doesn’t need to be displayed. I then got to test if there was a noticeable delay if the subtitle file had a whole lot of lines that the computer would then need to search through and since I’m a computer scientist I thusly wrote up a quick script that told the computer how to auto-generate a subtitle file with about 200,000 subtitles.

And now for the reason that I wrote this for the prompt. Although there wasn’t any ambiguities in the instruction itself there are many, tiny choices that go into the programming aspect of anything digital. In addition to final review (the step where people review the new change before it gets shipped out), I often look for peer review. For a style choice, I might send a screenshot to one of the people working on design and ask for their opinion or for a programming question I might ask for help in debugging or syntax to make sure that everything runs smoothly. So I hope that someone found this interesting even though this is pretty far from the business side of the spectrum.