dwalkr

Myself and my colleagues have spent the last two months working on TinaCMS, and have learned a lot along the way. We believe Tina is a novel solution for managing website content.

For one thing, as the title of this post mentions, "Tina is not a CMS". Our team also works on the Forestry.io CMS, so we know how to build one of those. As we embarked on the Tina project, we felt that another one-size-fits-all CMS wasn't the solution we wanted. This is why we architected Tina as a suite of libraries to enable frontend devs to quickly compose a more form-fitting content management strategy for their clients.

Another interesting innovation that we discovered along the way was that, by having the CMS live on your website instead of in a traditional CMS dashboard, the correlation between source content and rendered website becomes much more intuitive to those who were not involved in developing the website to begin with. With a traditional CMS, users must have some mental model of how their site is composed. They can ultimately figure out that, for example, they can change the homepage title by clicking on Settings > Homepage > Title or something like that, but requires some trial and error and a lot of implicit rules to remember. With Tina, the editor will edit the Homepage title while viewing the homepage; the information will tend to be where they're expecting it. And by having a short-feedback, on-page experience, even more esoteric rules will reveal themselves more intuitively.

We have been thrilled so far with the response to the public release of this project. We hope to continue to improve and extend the capabilities of TinaCMS, and I'd like to thank everyone who has expressed their enthusiasm and support!

+1 for jekyll-include-cache. Relying on parent scope makes includes fragile; having to pass variables explicitly leads to more reusable templates.

I agree with the author that SSGs are tools written by developers for their own use. But what's great about the file-based, command-line-driven interface is that it's possible to hook the input side up to some more machinery if you want a GUI CMS.

I work for Forestry.io, and our product is a CMS that aims to ease the pain of non-developers managing content for static sites. We are committed to bridging the gap between copywriters and developers. I am a big believer in the potential for static sites to transform the web, but I realize there is a lot of ground left to cover.