The 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.
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,
implementation, and
I wanted a page that would be served statically
Many popular web applications, including Wordpress,
which we had been using for our project website,
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
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
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
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
But the point is that not much of the load
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
And it doesn't take any input from you.
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
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.
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,
And also, because we don't really have
an IT staff ready to deal
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.
we may not be popular enough
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,
The site mechanisms aren't really set up
to preserve the serial order of the media.
posting on such platforms,
involves a lot of drudgery,
trying to maintain a systematic structure
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.
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
I don't want to be a "YouTuber",
We do need financial support to keep going,
and our contributors...
(me included)
...deserve to get paid for their work.
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,
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.
This remains a design goal.