2 yr ago
0 viewsThe first of three parts of an introduction to my "LunaGen" software. I may add slides to this later, but currently it's just me talking. This video is also used in my unit-testing.
Transcript:
What is LunaGen?
When I was setting up my new site for Lunatics Project,
I was disatisfied with the options I could find for setting up a static landing page which could provide access to released video episodes and associated viewer content (as opposed to developer or production team content).
So I created my own "Lunatics Site Generator", which I contracted to "LunaGen".
This is a presentation of my design concept, in three parts:
requirements, implementation, and use.
--
PT 1: REQUIREMENTS
I wanted a page that would be served statically
Many popular web applications, including Wordpress, which we had been using for our project website, work dynamically.
Each time you visit one of those sites, a program runs on the server to combine your 'request' with the data it has stored in a database or on the file system, to construct the HTML page that it sends you.
After that, your own computer might do some more work, interpreting a Javascript program that the web page has sent you, which then draws the page in your browser.
--
That's a lot of complexity, and the important thing is:
It happens EACH TIME someone visits the page.
That's fine, if you only get a 100 hits a day. It might even be more efficient, if the pages that are served up have a strong chance of being different from each other, due to being rapidly changing or personalized for each user.
But if you get a MILLION hits a day, and the webpages are all pretty much the same anyway, then it is very wasteful, and requires much more of the server --
which, can mean your server crashes or you have to spend more money on more resources to keep it from crashing.
--
By contrast, for a static website, all the generation of the HTML has been done in advance, and the resulting HTML is simply stored on the server.
When a user asks for the page, it uses the URL to fetch the page off disk and sends it to them.
A well-configured web server might even cache that data in active memory, so that it doesn't even have to access the disk.
--
A static page doesn't have to be unchanging. It actually might be updated frequently.
For example, it might include a clock, with the time updated every minute or even every second.
But it is NOT updated each time you ask for it.
If it is updated too frequently, and the web traffic is slow, it might wind up putting more stress on the server than a dynamic page.
But the point is that not much of the load depends on the traffic.
So it is more predictable, and less vulnerable to a sudden surge in traffic.
--
It also has a significant advantage for security and privacy.
The server doesn't need to know anything about who you are.
And it doesn't take any input from you.
That, by itself, eliminates most concerns about privacy.
And it defeats most kinds of attacks.
I also wanted the page to be simple and lightweight.
--
Besides being statically served, if a web page avoids using a lot of Javascript, and in particular, not using Javascript libraries, then it won't have to send you large program files.
That means less load on the server, simply because less data is transferred.
Also less time to download the page, which matters for people on slow connections.
And, although it doesn't affect the server, it means less time for the user to wait while their browser renders the page.
This makes the page seem a lot faster.
--
These factors were all important to me for Lunatics Project, because we don't have a lot of money for renting expensive, high-availability, servers.
And also, because we don't really have an IT staff ready to deal with a traffic crisis.
And because, as we are a creative project with a plan to have a release schedule, a sudden surge in traffic is a realistic possibility.
I mean, we may not be popular enough to worry about that.
But I like to plan for the possibility of a big success.
--
I also wanted my page to be easy to update, and to respect the internal structure of my media.
--
We are basically producing video and audio series.
Our release page should make it easy to watch our series in order, optionally with extra featurette videos.
This is the kind of structure you see on a DVD or Blu-Ray disk.
Which are obviously static menus.
A lot of web applications, like blogs, on the other hand, emphasize the serial nature of posting over the internal structure of the media.
That is, it is more important to them to record the order of last update than the logical story order.
That turns up all the time, when a series is posted on video platforms, like YouTube or Vimeo.
The site mechanisms aren't really set up to preserve the serial order of the media.
--
What's more, posting on such platforms, involves a lot of drudgery, trying to maintain a systematic structure to each post.
If I were to release my series as a 'blog' -- perhaps using one of the pre-existing static web log softwares, like Jekyll, Hugo, or Pelican, I would have to do a lot of fiddling with Markdown for EACH POST, having to check prior posts to see, if I were being consistent.
That seemed like a lot of hassle.
So I decided against using one of those pre-existing static blog packages.
--
What I wanted was to be able to simply update a collection of facts about each series and each episode, and then generate the web site based on that.
That suggested that instead of a mark-up language I wanted something more like a structured data language.
This would then be combined with templates to generate chunks of HTML which would then be assembled into pages.
It's fundamentally like a data-driven page, but the amount of data is not large, while the multimedia content elements hold most of the information.
--
Finally, I wanted a site that would allow for a friendly and flexible sort of monetization.
--
I don't wish to become a "platform" site.
Nor do I want to be too attached to any one platform.
I don't want to be a "YouTuber", nor a "Patreon Blogger".
We do need financial support to keep going, and our contributors... (me included) ...deserve to get paid for their work. Somehow.
So I wanted to be able to embed "calls to action" directly on the video publishing page.
Not hidden away somewhere, where only the most dogged fans might find it.
So much stuff is published "for free", with the monetization mechanism, be it advertising or data mining, being hidden.
It would be easy for fans to imagine that this is all "paid for" and they have no reason to pay us.
I want to make sure the donation hat is clearly visible! Or the merch store. Or whatever mechanism is working for us.
On the other hand, I don't want gross pop-up ads or other things that ruin the viewers' experience.
So my design needs to naturally allow for this secondary stream of content.
--
After determining that none of the available off-the-shelf solutions seemed to suit me,
I decided I would write my own site generator.
I'd try to keep the scope small, by sticking to my original use-case, and not adding a lot of bells and whistles.
