So, the next two talks will be presented by Josie and Michael, and so it's going to be
how hard is it to bring a professional level sustainable advance CMS to the market,
as well as rethinking the web CMS and finding the excitement.
These two talks are expected to be around 15 minutes each, and we will do a break just in
the minute. Thank you.
Hello.
I'm Vanu. I'm Josie. Michael, we along with our in-office and out-of-office team make-up
bite studios. It's a interactive studio dedicated to libraries and public institutions.
And so, when we create a project, we have a scope of course, but we also immediately start
thinking about what we don't want to do, and we create a manifesto around that.
That includes data rules, which basically, like, we want to see it any given time,
a visual of all the data, and any time that we can see a relationship.
So, you've seen something like SQL Pro to edit, manage data.
We want to be able to export it easily to switch databases entirely with a reusing post-gressor
MySQL. We like it to be pretty much equal. We want to do the database to be simple.
We don't want to use stored procedures and forced relationships.
We'll do that on the software side.
We use denormalized data whenever we can versus extra tables, which turns out to be hard to do,
but then it saves a lot of time in trouble.
Or, I'm just too far.
When we're talking about build rules, we make large projects.
We want to make them as quickly and efficiently as possible.
We've learned that SAS, or less, something like a trans-coded, in this case scripts.
We don't want to use that because it requires this process to do it.
Type script doesn't give us magical powers. It's cool.
It's nice, but can we do it in JavaScript? No.
Let's just go ahead and skip that.
Test-driven development is another kind of area where we think for a smaller project.
It's not really worth it. We want to test it in different ways.
A whole idea of a build step of running to NPM, run dev, or whatever.
We don't even do that.
We can skip so many of these parts.
But what it does mean is then we can use tools, frameworks, and the, like,
that actually work with this system.
And that part saves us a ton of time.
And it causes problems, no doubt.
But we found lots of good solutions to them.
Functionality-wise, of course, just like any standard project,
you want to have like cool, new tech.
You want to have the billing system set up right away.
You can have live everything.
And the reality is, that's all coming.
If this project takes off, we're probably going to rebuild the entire project,
maybe even in a different language, as it grows in two or three years.
So why do we want to imagine trying to build and force all of this into the current?
It's kind of like imagining this is a smaller project until the time it gets big.
And that's just kind of part of the manifesto.
We think about things like simply dark mode.
Of course, you have to have dark mode.
At least Ryan thinks so.
And we love it.
And then we have a builder mode and we have a super admin mode.
And every time you do an interface, interface change,
you now have two times, two times, two ways that you have to test it against.
And you multiply how many of the different modes you have.
We try to think about that and try to keep things to a minimum.
We kept dark mode.
So the parts of a web application.
I'm just going to start by explaining kind of probably what you already know.
If you're here, so I'm going to do it real quick.
And then Josie's going to get into specifically how a content management system is built.
Of course, you define the CI and CD.
You basically want to make a system where you can do proofs of concept.
You can do data backups.
You can publish into a stream.
You can back one up if something really falls apart.
Of course, there's interfaces like what kind of front-end you want to use.
What kind of component library is design systems.
When you think about the application, you want to think at some point or another about things like
the indexing.
What goes over what?
Because at some point you're going to find that didn't work out.
And of course, the data interfaces graph QL.
They're rest.
Whatever you want to do with that.
If we want to have other finest parts to it, of course,
there's user accounts and all the things that go with that.
And performance-wise, we want to know when things are going slow.
We want to know when things are actually areas.
So we have a decent system for tracking all of that.
A whole bunch of puzzle pieces we threw in the air.
Just for fun, which Josie will explain.
As a content management system is thought of as similar to web application.
But there are quite a few things actually set at the part.
It's run through some that we have.
There's page management where you can edit and view the page content and elements.
Navigation management to understand hierarchical data.
Digital asset manager where you can upload and organize any files to your website.
Buckets to view any content on any or all pages.
Data sources to supply the data across the whole site.
Thames for if you want to edit a color or font just in a single click.
Settings for small changes.
Admin accounts to control who can edit or change or look at anything across the site.
Search in Texas to create context for searches.
And dashboards and special tools to view information in an understandable and useful way.
So create a clear image of what a content management system is.
And so for the content management we created.
We started it in 2020.
You'll see in the next talk why we bothered to do this and why we didn't just use
Rouple or Wordpress or whatever.
The idea in 2020 we had some months off to think about what we want to do
Achieve next.
So we started thinking through kind of this whole process.
At first we were just really kind of creating proofs of concept.
Between being a good way to create a connection to let's say.
The data all the information architecture scheme modeling etc.
2021 we wanted to start importing live sites as quickly as possible.
So we take some of our regular client sites all libraries.
Import the data and find a way to put real data on a real screen.
If it's all fake data or alarm.
It is going to be really hard to tell what works or how it works.
And so we did that pretty early.
Creating of course the APIs we do.
We should do internal documentation more.
We sometimes fail.
And then of course the branding and build system.
In 2022 we put our first production site live.
So it took a couple of years to get to that point.
We continued building site tools and issues system.
All the other fun things that you would imagine.
And this is the start.
We always knew this is going to be a closed and open source product.
So we wanted to have a standalone which is the open source.
And we wanted to build the first part and then start finding a way to have one code base.
That we can manage and use and that exports to the standalone version which becomes open source version.
In 2023 we put the website out.
We came up with a series of functional testing.
Since we don't do unit tests and things like that we do want to have a decent way to test.
And the consistent way it's a functional testing and interfaces for that became really worthwhile.
Joe's going to be talking about the whole sign up process as a case in point of one of these things.
Last year we put up a third and fourth site.
We worked a lot more on documentation, new tools.
And a big key thing is we found the export systems.
We want to export my SQL.
That creates a one amount of headache if we want to take sites data and put them all into one.
And then be able to take any given site and pull it back out.
There wasn't a data system that worked like that.
So we ended up creating yes, a 17th standard of group CSVs or some, I don't know what the G stands for.
But the idea of merging CSVs that we can have higher agricultural data,
we can have relational data all built into the CSV and any given part is still just basically a CSV.
Lots of stuff to do next year.
The open source this year.
Oh no, this is fair.
And more stuff to do next year.
It's been a wild ride.
So the sign up is an easy part of the wild ride.
It's an important part of it because our librarians actually need to be able to make a website.
Make their configs, add administration accounts, create their site maps, load up their branch data,
hours, choose a theme on and on.
The process itself.
I mean, it took a month for like the original wire framing design process.
And actually building the original outcome was a month.
Testing and doing the sign up and API creating that was two months.
And actual testing and tuning of it was another month.
Plus all the scope expansion.
Sorry.
inevitable.
The sign up itself.
We stir off simple with basic information.
Information about the library.
If they have multiple branches, but in that information what their hours are,
library features.
Like if they want to add blogs, spaces, booklets, anything to their website.
As well as global site tags for the actual to take your content with across the site.
Site map themes.
We have three of them originally preset, but librarians can then go and reorder,
rename, delete, add their own to make their own fully custom site map.
And in the end, library gets a website.
They're happy.
And we're happy as a result.
That's where how to build.
And so the whole talk is about how difficult is it to do.
So I guess time and people would be the way to think about it.
It's easy to reinvent the wheel.
It also gives you some options.
A lot of ways to redo things entirely.
So the sign up as we talked about it's five months.
The digital asset manager, which is like a file manager that has a lot of digital asset manager material,
is six months.
And I should say this was one person, one person, and you that built it.
So five months for one person in average.
This was two people for six months.
This is three of us.
And it took a year just to come up with a really solid way to make the front end work and solve all the problems.
Data editors because there's so many each one has a different layout.
And we wanted to have a generalized system.
So it's really easy to switch to spreadsheet motors,
which to data or tiles view can ban whatever modes, 16 months.
However, the real advantage of this is when you want to do something quick and that would be a lot of work.
And another system, something like a branch match map,
or we want to have a non Google map because we're trying to eliminate Google from library sites.
And have just a system where you point and click where the different branches are.
That whole thing took less than a half a day.
And it's usable in any data source.
And so that we can keep adding new ideas that are all essentially plugins.
And in the end, being able to fulfill any client requests,
there are no limitations to the templating, the backend.
Because we control it, we will never ever say, oh, well, the content management won't allow us to do that.
Well, if we do, it would be our fault because it's our content management.
It really lets experimentation be a big solid idea.
And I feel experimentation and content management is what we need next.
So no denying making the content management system is difficult,
but it's worth it in the end.
So we persist.
Any questions on the session?
Yeah, so sorry.
What is your content management system called?
And when do I find out more about it?
I didn't want to make this a sales pitch.
So we kind of hit it.
If you go to the bite dev fast time, you learn a little bit more.
But it's called Kalata, C-O-L-L-A-T-A.