GitHub Git Merge 2022, 18 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: How Git Can Power an Exciting Future for Content Management - Git Merge 2022

Description

Presented by Mike Neumegen

Git-based CMSs address the perceived technical barrier of using Git by providing simple interfaces to Git functionality for non-technical editors. In this session, we'll explore a new wave of content management systems that are built on top of Git.

About Git Merge:
Git Merge is dedicated to amplifying new voices in the Git community and showcasing the most thought-provoking projects from developers, maintainers, and teams around the world. Git Merge 2022 took place at Morgan Manufacturing in Chicago, IL on September 14th and 15th.

A

All right, it's great to be here.

A

um Today I get to talk about two of my favorite things: uh git and content management.

A

And the click is not working there. My name is mike newman, I'm the co-founder.

A

Of cloud canon- and you can find me at mike newman on twitter.

A

So, let's start by talking about why we're all here.

A

Git an amazing tool: it's changed how we develop software um and it's really created um a new.

A

Wave of open source development: now we have a global community of developer developers who.

A

Are building very high quality software together without ever having met each other in person, often.

A

It's such a powerful tool that it's a shame that the rest of the population doesn't have.

A

Access to it, there's 83 million people on github and there's a lot of internet.

A

Users, who doesn't don't even know that git exists or what's possible, with git.

A

And so, if we peer through the blinds of what the other people are using, um we have things.

A

Like wikipedia dropbox, google docs notion, these all have elements of what is possible with git.

A

Version control, content, collaboration, some sort of concept of pull requests or like reviewing.

A

Things, but none of these can really hold a candle to what's possible with git. So that's really what.

A

A git based content management system is trying to achieve. Is it's bringing the power of the.

A

Workflows of git to a list of technical audience and making this technology more accessible.

A

And the real goal is to have this unified workflow, where you have the developer, using.

A

Git workflows to develop websites or software, the gitbase cms is pulling syncing any changes.

A

That's coming from git and putting it into a user interface we're a non-technical person.

A

um Can easily edit the content, it has an interface for editing, text or images or.

A

Whatever assets they need and then when they save that's going to commit back to.

A

The repository so we get this unified workflow with git at the core and typically because you.

A

Want everything as text and a git repository, you want to store your content and markdown or front.

A

Matter so, naturally, aesthetic site generator is a very good fit for a git-based cms everything's.

A

Just text based and static site generators are great at dealing with markdown and front matter.

A

And the types of use cases um that git-based cms's really excel at is the more like staticky websites.

A

So something like a mark, a marketing website. Documentation is a great one. There's a good.

A

Chance that the website is already using a static site, generator, microsites or supporting websites.

A

Of sort of the main corporate website- a blog legal pages, about pages, all that sort of thing, client.

A

Websites, if you're an agency or a small e-commerce websites, so these are use cases that typically.

A

Can and in my opinion, should be static websites because they're going to be a lot faster. A lot.

A

More secure, reliable and scalable, but often aren't because you need a non-technical person to update.

A

That content, so then you deploy a dynamic content management system and add a lot of different.

A

Complexity layers in there in order to have a non-technical person, updating them.

A

And so with the git based cms, if you tell a non-technical person, okay, you need to branch.

A

To create a new copy of your site, you're instantly, probably going to lose them.

A

Branching sounds are really scary, whereas making a new version of a website not so.

A

Scary, so if we change some of this terminal terminology for non-technical users, then we.

A

Can get more in line with the the type of workflows in terms that you they used to.

A

So git become save branch version, pull request, review status, checks reports, merge is a publish.

A

And so now, let's step through some of the um functionality basic functionality that.

A

You might do in git and talk about how that works in a git-based content management system.

A

So, first up we have making changes developers. You know we were in the code editor we're making.

A

Changes if there's one thing I know about non-technical users, is that they don't like.

A

Code, editors, so that's an instant no. Instead, what we want is some sort of gui where they.

A

Can edit the content for a website directly on the page and there's no guesswork? They can see.

A

Exactly what that content will look like right on the page, so they can add assets. They can.

A

Change the order of components move components around. It's that visual editing experience.

A

um But behind the scenes, it's all powered by git and aesthetic site generator.

A

So next up is committing no terminal, there's a good chance that your content, editor or marketing.

A

Person doesn't even know what a terminal is, um but so, instead of committing, um we have an analogy.

A

That works save when I click save. I know that the state of whatever I'm working in is going to be.

A

Saved somewhere, I don't really know where or care where and so for a git based cms behind the scenes.

A

That's doing all the git magic but from the user's point of book view just hit save and it saves.

A

A

This time we're going a little bit less technical with a git gui like github, desktop.

A

Even with this, it's still fairly technical. um You know I've got a code diff here.

A

um And there's just a lot of terminology: that's really aimed at developers.

A

um That's in this case hard to difficult to train a non-technical person on.

A

So, instead we can talk about versioning and really simplify the interface where I have different.

A

Versions of my website that I can switch between and I can create new versions of my website.

A

For pull requests um there's a couple of things you probably want to. As developers we typically.

A

Do with pull requests so the goal of the poor request is to have a discussion about changes.

A

And ensure it's as high quality as it can be, and one way is doing that is, it is a code of reviewing.

A

Those changes, so editors can have something similar with the content diff. We don't want.

A

To show any html or source code to them, but we can show quite succinctly what what content has.

A

Changed between versions, so they get a really good idea of what is changing between the old.

A

Version and the new version and there's a couple of ways: we can do this as well. So another way is.

A

Visual diffing, so here I have uh old version of the git merge website and a new version, and I.

A

Can windshield wipe between them to see what the changes are? um Percy is a popular visual.

A

Testing app that does this as well, so it'll take two screenshots, uh the old and the new.

A

Of the website and overlay them and highlights uh what's changed so there's a lot of different ways.

A

Of visually, representing, what's changed between two versions without having to rely on a on a code.

A

Statistics, these are great for ensuring software is a of a high quality and using machines to do.

A

Tasks that humans don't want to do, or just aren't very good at.

A

We can do the same thing with content, but instead of reviewing code, we're really.

A

Ensuring the content is a higher quality, so we can do things like seo report and give.

A

Prompt the user to fix up a title or improve the seo in different ways.

A

Accessibility, ideally take a lot of the load off developers and some of those easier accessibility.

A

Things just have the editors fixed same with broken links. It's very can be very difficult.

A

And time consuming as a human to find broken links. But um if there's a broken link report it'll pick.

A

Them up straight away and the editor can fix that without having to rely on the developer.

A

Pull requests often have conversations about whether the support request makes sense for the.

A

Project or what it would take to get over the line, um it's the same with content. How can we.

A

Make this content higher quality and what needs to happen before we can publish it.

A

And the best way to do this is in line directly on the website. Get that feedback where it is.

A

Where it, where it's in context- and this doesn't just have to be editor to edit to feedback, because.

A

This is a git based cms. This conversation in feedback into something like github.

A

um And then you know there might be feedback for a developer here. So then you're having this.

A

Conversation between tool sets um and everyone's just using an interface that makes sense to them.

A

Emerge we're not even going to try and explain marriage strategy to a non-technical person. This.

A

Decision probably needs to be made up front, um but what we do want to do again is provide as much.

A

Context as possible on when I click that publish button, what's going to happen, um and particularly.

A

For more advanced branching strategies, it's hard to escape some sort of git tree or visual.

A

Representation of of what's going to be yeah, what's been merged or what's been published.

A

So often with content management systems, we have this trade-off that we're really weighing up.

A

On one side, you have the editing experience. We want to provide great tools for editors to.

A

Empower them and just be less reliant on the developer, to make changes on the other side.

A

We have developers that we want to empower with tooling and interesting ways of accessing content.

A

um And using it in different applications.

A

And so something like a website builder, it's often prioritizing the editing experience where.

A

If you think of a wix or squarespace, an editor can set up an entire website by themselves.

A

Without talking to a developer, once you raise the limit of that tool and then you need a developer.

A

That's where things really become limited, but it hasn't been designed with developers in mind so.

A

It's it's kind of added on um and it's fairly limited in what the developer can actually do.

A

um So yeah great editing experience but limited um limited for developers. On the other hand, we.

A

Have headless cms's, which are really built with developers in mind? They have incredible apis.

A

And ways of accessing manipulating the data that can be used across a lot of different use cases.

A

But the editing experience is all is often um just trying to fit in with those apis, so we essentially.

A

Just get form fields that fit the content model, and so what we're really trying to do with the.

A

Git based cms is blend. Those worlds together as much as possible have git is the foundation for.

A

Everything and then have um tools that are really empowering editors to not be reliant on developers.

A

And this is what we're really trying to achieve this unified workflow that has.

A

Git at the power at the core of it, um and if we can achieve this, then we can.

A

Have large teams on either side collaborating on these websites? Just like we do on software.

A

Finish off, I just want to give you an example of the sort of workflow that's possible with this.

A

Approach so here we have the git merge website, there's a spelling mistake. This is in the actual.

A

Website I did this um and so me, as a user, I don't have access to the source code, but I've seen I've.

A

Spotted that spelling mistake, so I can go and click the edit me button on the git merge page.

A

It's going to bring up an inline editor. I can just go and type and fix the editor at that.

A

That spelling mistake, publish it which creates a pull request and then on github sides. Maybe.

A

They have someone non-technical managing this website, so they can use a non-technical tool.

A

Set to review that change know exactly what is going to change and publish it or chances.

A

Are they have a developer managing it, in which case they can go into the pull request on github.

A

Same review process using the tooling that they want, so it's really a choice and it.

A

Gives a lot of options, but it really brings those workflows together and I think if we can do that.

A

Like git and the surrounding ecosystem has created this global community of open source.

A

Software development, I think we can do the same with content and create a global community of.

A

um Of content developers and that's what we're trying to do at cloudconom. Thank you for your time.