Obviously I had nothing to do with the naming of Hugo, but it seems to me that its name is a nod to Golang (Hu-Go) and a tribute to the legendary Victor Hugo.
I would suggest Hugh - a CMS for Hugo
Hugo is a first name basis environement.
Hurry, first names starting with the Hu sounds are going away fast. You don’t want to be that loser who settles for Humphrey. (no offense to Humphreys, they just shouldn’t be a Hugo service)
PS: Nice work by the way.
Maybe Huglify - Netlify + Hugo. It is certainly available…
I have some real ideas, but i’m still accepting opinions.
Thanks for the tip anyway. And for the compliment.
PS: I hope to release a small video very soon to show it working. I’m just polishing a little bit more.
Well, “Victor” might be one choice.
Wikpedia says the illustrator for Les Miserables was a “Emile Bayard” so, another idea is “Emile” or “Bayard” since your CMS is a visual GUI on Hugo.
Or Zola. Never liked Victor Hugo anyway, let him stay at Netlify
I have been building a CMS for Hugo for a while and plan on launching this spring, although it’s not Hugo-centric enough to really call it a Hugo Admin Interface, more of a Markdown CMS.
My business (Graphia Ltd) is focussed on making it easier for companies to write their internal documentation (SOPs, handbooks, instructions, guides, runbooks, etc) in a web-friendly manner, to allow them to save their documents in a open format that doesn’t require heavy, slow, inefficient and ugly tools (cough Sharepoint) that make reading a strain for users; rendering a word processor in a browser to read a file is beyond pointless.
How it works
The backend is written in Go and the frontend in Vue.js, importantly, the content is written to and read from a git repository. The database is only used to hold user credentials, everything else is in git.
Creating a document actually creates a bundle, so all images are stored with the content - really important when you’ve got hundreds of operating procedures full of images, diagrams and charts!
Every time a directory or document is created, saved or deleted, the CMS actually creates a Git commit.
As expected, the full history for every file is easily viewable through the frontend although in fairness the UI here could do with some polish!
Some nice features
- Frontmatter is automatically dealt with by the editor, fields are placed alongside the document and everything’s put back together server-side prior to commit.
- Advanced authors/users can upload their SSH public key (as they would on GitHub, Gitlab etc) and clone the repository, push commits etc.
- Designers can do the same with the Hugo theme to customise at will
- The CMS works with Hugo’s Multilingual Mode and makes creating translations of documents easy. Thanks to the bundling, all translations live in a single directory and can share assets. The CMS won’t ever do auto-translation but will (at some point!) automatically generate XLIFF files that can be sent to translators.
What it isn’t designed to do
- File-based user permissions
- The web UI will be aimed at regular business folks and will have no knowledge of branches and merging
What it doesn’t do yet
- There is no UI to edit Hugo settings
- Take enough advantage of Hugo’s shortcodes (yet). I want to be able to (and have some ideas on) allow users to drag in CSV or
.dotfiles and let users configure charts, graphs and tables. But that’s in phase two with the new ‘block’ based editor.
- Auto completion for links, this is next on my todo list
- Auto publish on commit
Long term goals
If there is any interest in it as a product, I would love to open source the CMS and shift my company’s focus to the onboarding process - definitely the biggest hurdle for most companies. Getting decades of poorly-formatted Word docs into consistent Markdown is quite a big task and not for the feint of heart.
The target market for this product, IMO, would be folks not using text editors, folks who are stuck with Word and/or Confluence. And that’s a huge market… unfortunately.
Products like these give me a little hope that documentation in future will be all plain text.
So much this! I am currently working/promoting for development of new documents in plain text (Org mode erm, better than Markdown… but Markdown is still waaay much better than Word docs ). It’s a slow process, but eventually will get there… Though, need to fight the new evil: Confluence “documents”… which are ephemeral web pages, and not even documents.
Completely agree on the Confluence thing @kaushalmodi mentions . We moved away from it, because it was similar lock-in to using Word, since the whole thing was in a DB (and, java which was a horrific nightmare to self-host; oh, the headaches!).
I’m not sure if anyone on here knows about DITA, which was originally developed by IBM to store their incredibly massive library of documentation. Even if you never use it, it’s an interesting technology to learn
a bit about.
When I was researching “future proof documentation” a few years ago, I came across DITA, and various editors for it. A company called Codex had developed an editor for a subset of the DITA spec, and this editor was by far the easiest to use among the ones I tried (DITA can be pretty complex). The CMSs being developed for Hugo and/or generic sets of text documents, mentioned here, especially given the new concept of “bundles” in Hugo, reminded me of this foray of mine into the DITA world.
We took a pretty odd approach in my company to getting away from Word, which was not DITA (in the end), but rather to author our documents in markdown, and store them in a table in our home-grown ERP database. Most people are authoring in a markdown text editor and pasting a version into the textarea in the ERP’s UI.
I back up all the various data in this DB a few times a day, and stick the output files into a git repo. It’s not pure markdown, but, it’s at least accessible in a text editor and, in a repo so I can diff them. The biggest itch my staff have is, images and attachments are not very easy to upload to these documents.
I love the idea of having a simple editor that can work with Hugo bundles, so I might convert our process yet again.
Thank you for your feedback.
Essentially the CMS web interface is straightforward enough for people used to Word or Confluence to grasp. Navigating to a document, editing it and saving it with a commit message (that will probably be renamed to “describe your changes” or similar) are all trivial, the process and workflow are all familiar to anyone who has used a CMS.
For advanced users (IT folks, developers) the notion of supplying a SSH key and cloning the repo and using
<editor> shouldn’t be a problem.
The problem area is that some authors will find the web editor too limiting and the cloning process too complicated. I know that the long term answer to this is to build a better web editor, but that’s a mammoth task and I want to launch with a basic editor first to ensure the concept is sound.
The quicker approach is to make cloning and working locally easier, which isn’t too bad on a Unix/Unix-like OS, but setting up SSH keys on Windows was a ballache last time I tried it. Plus, git’s stage→commit→push workflow really isn’t straightforward.
Thankfully, the rise in popularity of Visual Studio Code with built-in git and the fact that Windows is getting SSH should hopefully make this much simpler.