I really like Github’s Jekyll “baking” system for managing my personal blog. Unfortuately, I couldn’t really imagine this solution working on most client sites. At least not until I came across Prose.io, which is a browser-based editor for github files or more specifically the web-based content editor for managing a jekyll site.

Let’s look at the advantages of the Jekyll system as such, the major problem of this approach (=the content editor) and finally how Prose.io provides a potential first step towards solving this problem.

The Advantages of Jekyll-based Site

I’ve been spending quite a bit of personal “geek out” time working with Jekyll and Octopress. The key advantage for site building is that you completely remove the server-side element with programming languages and databases, and instead, you take a well-structred grouping of documents and “bake” them into an html site. For a hacker, it’s zen-site-creation heaven.

For a writer, it also significantly improves the writing experience since you write in markdown, instead of misleading WYSIWYG editors. If you want, you can version control your various drafts. There is also the up-and-coming Draft application, which is an excellent web-based editor for writing in markdown and getting feedback for others on your writing.

As a developer, this deployment process significantly removes error and security worries from the final process, since well… baby, got no backend. While I have yet to dig into how I’d develop a more complicated project with this approach, the essential architecture is to develop processing plugins which take specific keyword markup and template files and converts it to the final site. More complicated sites would have additional tags and processing plugins as needed.

In terms of site speed, it’s a signifcant performance boost since you only need a single server (or personal computer) for the site generation and the rest of the site and content can be delivered as static content via the web server(s) alone.

Unfortunately, there is a big missing element in this kind of workflow: the brower-based content editor.

The Big Problem: Lack of a Content Editor for Non-Technical Users

For all of the developer-ZEN-heaven-liness we have in this approach, it’s impossible to imagine at time when most non-technical editors are able to fire up git and their terminal applications for making site changes. Also you can’t really expect the editors to be able to run the various ruby and/or python scripts needed to “bake” and deploy the site.

This is where we see a major problem in this approach: How can non-technical editors get involved in the content creation workflow?

WordPress and other CMSs like Drupal really shine in their ability to allow non-technical editors to make changes and see them on the site almost immediately. From the browser, user can add text, upload media and combine them in a way to create the final page. Most sites also dynamically take the create posts and, in turn, render various listing pages like front page, category pages, sidebars, etc. Admittedly, there are a number of types of sites where you need dynamic storage, particularly in the case of ecommerce sites or community discuss sites.

At the same time, there is a segement of sites for bloggers and content-based sites that would really benefit from the html-backed site IF and ONLY IF it could be combined with some kind of friendly web editor.

That’s exactly the role Prose.io fills in: a browser editor for github.com-based markdown files.

While it probably could be used for any files you have in github, it’s optimized for text documents in markdown. The editor display is very clean and provides a preview option. It also provides a clean way to add additional meta-data and control the publication status.

Most importantly it allows you save (or in git terms, commit) your changes. In this way, you don’t need various technical tools locally to edit and manage your site’s content.

Also if you are publishing your site via github pages, then once you save your changes (i.e. make a git commit to your repository), you’ll trigger github to rebuilt your html site. In this way, you can use Prose.io to manage the content editing and “commits” and github to handle the content generation and server hosting. So, no editor, no server and a free site up in running.

A Dreamy Conclusion: A Future for Jekyll, A Web Editor for HTML-backed Sites and the Site-Build Process

I’m a huge fan of the jekyll/octopress method of site creation. It takes away a lot of the technical B.S. like performance, dynamic servers and other stuff you don’t need for a generally static site. If all you are presenting is content, then this approach works well. Even if you want to allow users to comment, integration with disqus is also very easy to add.

Moreover, having the content for a site in GIT is great. You can version-control, fork, merge and see the diff through different editors. Changes and collaborative work becomes very fluid and transparent.

I think Prose.io is a great step forward for content management for a Jekyll site. At present though, it’s limited to github.com repos. It also kind of annoying to have it exposing all jekyll and non-jekyll repos there.

The design and editor mode is extremely well-done. I can imagine some improvements there, but essentially the actual markdown page editor is aweseome. It provides a few help areas on syntax, and it divides out sections for the main content, meta data and publication status. There are also various colors, which indicate working status.

I guess I’m still worried that this presentation is pretty intimidating to non-technical editors. We need to provide these folks with a quicker access to what they can edit. At present, I’d worry about the general newbie fear of “breaking stuff,” so they end up avoiding getting involved.

Also I think there needs to be some level of control about what gets published in terms of changes. Perhaps a workflow around forking and pull requests has the potential to work well here, but I’d also prefer to see the edges cleaned up editors can focus on the content and not on the github process. Still feels pretty heavily focused towards developers with significant improvements made to the browser editor.

Finally, while I’m extremely impressed by the tight integration with Github.com and their API (truly admirable acheivement!), I see this as a limitation for some projects. Certain projects prefer to have their git repo elsewhere and also might want to manage their own site pages generation outside of github pages and hosting.

As such, I hope to see (and perhaps contribute to!) the development of a simple heroku-based server where you host and integrate your own prose.io editor. You’d provide link and api keys to a specific git repo and authenification system. Equally, there’d be settings for staging deployment on commits and perhaps an additional role for deploying changes to the production setup. This would create an ideal setup where you have a server for the management and baking and a process for deploying to the web server. This would give you something dynamic, something git-based and finally the html bake site.

Obviously not something that’s going to happen tomorrow but in our technoloy-driven age. It’s good to dream :)