There seems to be two schools of thought here:
A dedicated ‘Hugo Web Editor’ that is closely bound to Hugo, regardless of whether it’s packaged in the same binary.
A ‘web-based interface’ for Hugo. Largely the same concept as Prose.io, but configured to work well with Hugo’s file structure, rather than Jekyll’s.
I subscribe to a highly modular school of thought. This is why all the current static-CMS solutions such as Webhook, CloudCannon (w/ their new Jekyll integration), Site-Leaf, etc, etc; don’t interest me.
As Hugo promotes a CI/CD deployment method from Github through Wercker, isn’t an intelligent editor that acts on the Github repo for the site the best way forward? It splits up all the responsibilities to separate services, and allows a great deal of redundancy if something breaks.
If said editor could be told that posts go/come from X, adding a new page uses Y template and new content files get stored in Z location based on their file path, then we’re in business. It basically requires abstracting away the file-tree from the non-technical user.
As I’m unfamiliar with Go & Hugo, I may have this totally wrong, but surely Hugo needs no API or knowledge of this? As long as the editor acts in accordance with default Hugo file structures (prescribed ones if needs be), then it could work. Content is edited, Github notices the change, causes a huge-build on Wercker and Wercker deploys the site to wherever it’ set to.
Like I say, I may be missing something; but this could work, right? It will obviously have it’s limitation as you would be working with Githubs API, and not one designed for Hugo; but in terms of satisfying the “Non-Tech editing of Hugo sites” brief, it hits all the key points.
Just my £0.02