For information, static sites are unchallenged imho.
Even for a certain level of collaboration, I think one could get away with using static sites. I haven't tried this in practice but imagine having a git-based CI/CD flow for a static site, where non-technical end users could use the web-based Markdown editors of github.com or gitlab.com to make small changes, save and push via a pull request.
Each merge is of course approved by a more technical user.
I would love to hear if anyone has tried this model.
I've thought of something similar! A git-based flow for a friend's static portfolio site, where he can make text edits and upload images, and the site builds that content with HTML templates.
Not sure how the GitHub markdown editor would feel for the user. It might be really great, even for uploading images.
I was imagining a static admin page, WYSIWYG, that makes git pushes on submit. These were the headless CMSs that seem to be able to accomplish that:
Github.com and Gitlab.com have after all put a lot of effort into their WYSIWYG editors, but they're not very useful for image uploads.
That part should probably be handled separately just to avoid slowing down the git repo with huge binary files. For example upload an image to S3, note the path, enter it into a markdown syntax image url.
There are many ways to skin that cat, depending on the technical skill level of your client. They could even e-mail the images to a script, or message them to a bot on an IM service, that then returns the URL for them to use in Markdown.
There's a fairly popular site I run that is run like that, except we don't use github. Just `git push production production` to push the production branch to the production machine. The bare git repo there has a post-commit hook that detects production branch pushes and unpacks the branch to the correct server directory, compiling some static assets along the way. If we want you to be able to push to production we just add your public key to the machine where that git repo resides (no login, just git). Makes pushing changes very easy. But it's obviously not high-availability, or CDN-backed or anything crazy.
I am trying it now for some volunteers that I am building a web site for. Building the web site and responsive theme almost from scratch took about 10 hours of work, and further changes will only be the addition of news items ("posts" in Jekyll slang).
The theme is HTML and CSS plus about 20 lines of jQuery JavaScript to handle simple toggle effects such as the hamburger menu on mobile. Probably could be done without jQuery but I am not a web developer and that's what I know. Posts are written in markdown and the idea is that the others will either send me an email or later will open a merge request on GitLab.
I'm a technical writer and this is how I'm running docs at my company. You'd be shocked at how easy it was to get one of our content marketers comfortable enough to start opening pull requests for an internal-only docs site. (It helped that I assured them that, thanks to how branches and approval workflows function, absolutely no changes they made could ever wreck the live site.)
What are your thoughts on (1) Obsidian vault (folder of markdown files), (2) stored on a shared Google Drive folder (several team members can edit files using Obsidian) (3) Less technical users could publish the site by using GitHub Desktop app. When they commit changes (4) git-based CI/CD uses MkDocs-Material to publish the site somewhere...
Even for a certain level of collaboration, I think one could get away with using static sites. I haven't tried this in practice but imagine having a git-based CI/CD flow for a static site, where non-technical end users could use the web-based Markdown editors of github.com or gitlab.com to make small changes, save and push via a pull request.
Each merge is of course approved by a more technical user.
I would love to hear if anyone has tried this model.