Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Optimizing the experience for non-technical content contributors #1977
It's an interesting point because it acknowledges that Jekyll's relative ease of use and other benefits are seeing it brought into increasingly new scenarios for which it was not initially conceived of. Jekyll boasts itself on being the static site generator/blog platform for hackers, which implies solo usage.
But being that hackers of adopted it with such open arms and grown to love so many things about it, it's only natural that it's usage is going to be pushed far beyond the original use case of blogs for devs, and into more mainstream scenarios complete with non-technical content contributors.
I'd love to discuss what this broader adoption means to the Jekyll community, it's future development, and specifically if @parkr and @mattr- think Jekyll should be optimized in any way for non-technical content contributors, and if so, how?
As a related aside, I was actually just contemplating this scenario myself yesterday when I was talking with my wife about helping her get setup with a blog somewhere. She said it had to be something really easy to use, so while I wanted to make her a simple Jekyll site, my obvious concern was that she would get frustrated with trying using Jekyll and GitHub - both of which are almost completely foreigh to her. So I realized I'd probably have to setup a Tumblr, Wordpress, or Medium account for her.
I started thinking about what could actually be done with Jekyll to make it friendlier for her to use, and my first thought was wiring it up with prose.io, a la the contribution links on @benbalter's blog.
So, something like making prose.io integration easier could even be a good first step.
Obviously, my example is merely anecdotal, and doesn't really represent use cases we should pursue or optimize for (individual family member's blogs, etc). But it's parallel to the real use cases that could be interesting, like creating a scenario where whitehouse.gov might ditch Drupal for Jekyll, etc.
Favourite issue of the day.
I would love to make Jekyll even easier to use for non-technical content creators. One idea I had was to create a Mac app that we'd sell in the Mac App Store, which would make the experience of writing a Jekyll blog a lot less scary. Clicking a button to spin up a jekyll server is way easier to learn how to do than opening up a terminal, navigating to the right directory and typing "jekyll serve --watch".
But to get to your point of whether Jekyll should be built around newcomers, the only feature I still want to make the transition easier is generators. I want to be able to write "jekyll generate post TITLE" and for it to know where to put it and with what date, front-matter and slug. #1148 took a stab at it, but it still needs some work.
Beyond generators, I'm not sure there's much more we have thought to do besides implementing generators. We want Jekyll to stay simple, but also allow for the possibility to be simple to build tooling around (e.g. Prose). Right now, there isn't much push in that direction because the people contributing to Jekyll aren't non-technical.
It's a chicken and egg situation. Non-technical folks won't approach a system that makes them go cross-eyed, and technical folks don't feel the need to make things less technical. First strike must be made somewhere.
I like the idea of using Jekyll as the simple generation piece and building another system that handles content administration. The question is whether that should be a Mac App, a hosted web app, or a whole new set of features in GitHub... Zooming out, I think GitHub as a company has a tremendous opportunity to capture a huge chunk of the personal (not necessarily tech-y) "blog" market.
Personally, I don't think the onus for increasing the subjective experience of creating content should be on Jekyll. It's fine where it is in terms of it's scope. Another project that wraps around it makes much more sense to me.
That sounds like a REALLY practical and significant step in the right direction.
The Mac App idea sounds cool - and I'm not opposed per se - but it really seems like it would be an awful lot of work for very little benefit. Having never built a Mac App, however, I can't accurately speak to how true the cost part is. Just seems like no matter what the cost, it's going to be disproportionately higher than the benefit it will have for very many users.
I think this is spot on.
It seems to me that prose.io is the de facto content editor for Jekyll. Prose is brilliant (particularly its meta-data editor) and essentially sufficient for the "post-CMS" world and Jekyll's stated goal of simplicity.
Yet, prose is in need of some love that its creators don't appear to have time for. I realize it's presumptuous of me to say so, but, while I agree the onus shouldn't be on Jekyll to maintain prose.io, and also agree that it shouldn't be a part of Jekyll, it seems to me it would be in the interest of the Jekyll and GH Pages projects to get more involved in that project.
@jglovier Jekyll is not the tool a non-technical contributor interacts with. She needs technical help at some stage. But this is not the real problem.
So if your wife is creative and write an article in markdown, she will need three days. You will need three minutes to upload it to your Jekyll setup. If she writes 12 articles in year, you need 36 minutes to upload it.
People that publish not that often don’t need to run an own website. They can write for a magazine, like authors do for the last 150 years.
Just to be clear, I'm not talking about the blogger use-case. I'm working with, among others, people at a fairly large government organization to whom I made the case of using a static site generator. In my proposal I made clear that while the experience for the developer and the consumers of the site was great, the experience for those responsible for entering content may not be. Fortunately, they were willing to make that trade-off, at least for testing.
All the energy you guys are putting into Jekyll is bound to increase the variety of use-cases for it, and therefore the need to accommodate content creators. You've created a much more powerful tool than a 'blog for hackers'. You all know this, but the use cases and advocacy of Jekyll for large, non-blog projects and non-hackers was started by Development Seed and posted about by @benbalter and manifested in several of their projects.
However, I think the tools are essentially there for anyone who cares to implement them in their project: links to edit entries from a page (ala @benbalter's blog), filterable posts listings (I use list.js), and prose.io and the prose.io Chrome extension.
I think the fact that using Jekyll is a bit technical is perfectly fine. After spending years trying and mostly failing to teach non-technical people how to use CMS interfaces it seems to me that editing files that are listed in the same way they would be on one's computer is less abstract than all the little fields in a CMS. The simplicity of the concept of using a text file initially is powerful.
But I also feel like content creation is the missing bit overall.
I want to take a moment to describe my use cases with Jekyll so @parkr and @mattr- have a better idea on how Jekyll is used by me. Maybe I'm an exception in the way I use it. I would like to connect with others who have similar use cases.
(2) Websites for clients: last year I did an experiment where the client would use prose.io to edit their content, then the site would get re-compiled on a separate server running Jekyll. It works but it has obvious limitations towards traditional CMS'es. I was inspired to do a CMS-less website (mostly by Development Seed) but in practice I find that I get called up for basic website edits that clients should be able to do themselves.
I only build 1 client site in Jekyll before going back to Wordpress. Sites need a contact form, image upload, preview of draft stuff etc. It's not the goal of Jekyll to provide this but just noting that this "experiment" invalidated using Jekyll as a CMS for client for me.
(However, given the right tools in the future it could be an ideal lightweight CMS. The approach is valid but just-not-there-yet).
(3) HTML prototypes of apps. I use Jekyll all the time to design web applications (and prototypes of native apps in HTML/CSS). This is my main use case.
These are web apps which look like the real thing, but aren't actually connected to a database, and the HTML is just what I typed into my templates (not generated by ERB or something else). Some people would call it "designing in the browser".
Jekyll is a huge help here with the includes, Liquid templating language and YAML front matter which allows you to never repeat yourself in HTML and add "state" to pages (e.g. re-use an include to provide a success and error state of the same form)
(4) Increasingly these HTML prototypes of apps have to have "real content" to validate the design. I use _data and ask my clients to provide me with .yml files. Here's a screenshot of a data table used in a recent web app http://cl.ly/image/2w1w433e0f1M the content of the table is actually provided by the client and reflects a real use case of this (ticketing) web app.
What's happening now is that the traditional UX people and business analysts get involved in the HTML prototype of these web apps. For example, I will put down a basic form structure in HTML/CSS but an analyst will fill in the actual form data (based on business requirements). This is great because I can worry about the design and clean code and the business people can worry about the content.
The web dev/designers (me) on the team know how to work with Jekyll but these business analysts and traditional UX people don't. (think people who wireframe stuff but are not technical i.e. don't code).
There are a lot of technical hurdles to cross until you get to the point where you can edit the HTML templates, render the static site and push it to Github. I am planning a series of workshops to help them get up to speed to actually do this but it won't be easy - they will need to learn a lot of stuff including how to set up their ruby/terminal/work with an IDE/push to Github/work with branches/Use liquid/etc.
I think some more technical profiles can get past that hurdle and enjoy building application prototypes in HTML code that is closer to the end result thus resulting in an efficient proces.
@Wolfr What is the current environment of these people? OS, IDE, language?
@penibelst The people I have attempted this "strategy" with all used Mac OS in which case it's easy since I know how to do a setup on my machine. If they are somewhat technical I can just give instructions on how to install various things. Stuff like bundler, brew and rvm have made it relatively easy to quickly have the right setup.
Now, in the future when someone comes around with Windows I'll probably not be too hasty to attempt a Jekyll setup - never tried but I read a lot of bug stories about dependency hell. I also have no idea how to configure shell tools on Windows. I know there is a guide floating around somewhere but I don't want to myself up for tech support :).
I might just have to bite the bullet and at least try it, since the HTML prototyping process is so efficient that it pays itself back.
(When I talk about HTML prototyping process I mean making static prototypes of [business] web applications using a combination of various tools i.e. I often use Jekyll + Grunt + Twitter Bootstrap + Addons to Bootstrap)
My experience with prose.io + Jekyll sites is that they lack some functionality that you really want when you edit a website, like a preview of what you're doing in-context before publishing, and a visual way to deal with images.
It alsow wasn't easy to get the setup working where the client could do an "edit" and then it would appear on the site. We did this by generating the Jekyll site on the server with a post receive hook after commit but it's a hassle to maintain (I am not a ruby dev and had it done by someone else so if it breaks I have to call them).
I imagine the open source version of Prose is only the core and the Development seed guys have integrated a lot of custom and interesting stuff in it, but probably "for one client" (for the data.gov client). I would be interested to see that.
You say it jokingly that Prose should integrate more fully with Github but I don't think it would be a bad idea for Github to provide a basic "CMS" like functionality on top of repos. It's only logical for small sites. In a way they already have a programmer version of that with the "file edit" that creates a commit.
Now, for our site (wolfslittlestore.be) we initially made it in Jekyll but ran into some problems:
We decided to port it to Wordpress instead which makes this and some other stuff we needed easier (multi author etc) and some other stuff harder (maintenance, lots of files we don't use).
However, I still believe that with the right CMS-style layer on top of it Jekyll could really be the right tool for lightweight sites that can be maintained by a non-technical person. The idea is solid, the current ways to do it aren't.
@Wolfr FYI - if you're config file is set right, you can indeed get a preview of your post right on your site with prose.io. You can also drag and drop images directly into the post. That said, it's "quirky" to say the least - the sort of quirkiness that tends to stop non-technical people from trying again, as well as the fact that it does take a bit to get the prose config just right, particularly if you're using it for meta data.
+1 for @mattr- half-fantasy. Prose seems so close...
referenced this issue
Feb 4, 2014
Having just migrated to Jekyll as a decidedly non-technical (not-so-much-) content-creator (-yet), I thought I'd add my two cents here:
Anyway. I can't stress enough how much of a difference text-based (not database! not WYSIWYG) content creation and open source distributed version control / collaboration (not another proprietary SharePoint, Google Wave, etc.) can make for the rest of us.
Please, somebody help us.
Great point regarding templating. It’s been so long since I got started with Jekyll that I forgot how frustrated I was with the default template and CSS; I actually still rely on a 'custom.css` to overwrite the default CSS, which in no way is a smart way to go about it. I also thought about a Jekyll Themes solution, but I think the first step towards that would be to rewrite the basic HTML to something cleaner, and then leave most of the re-theming to CSS. I have some ideas around how to do a theme garden/marketplace, if we get something going, that I initially wanted to give to Ghost.
The reason we probably don’t think more about this, is that we have to rewrite everything else as well—writing a bunch of stuff from scratch in a weird way is comme il faut with static blogging—so including the HTML/CSS to the bucket list doesn’t feel as annoying as it would to people for whom theming is a much larger hurdle.
Speaking of Ghost and Jekyll, I also think there is a fundamental question people need to ask themselves, which is “Is Jekyll for me?”. We all love Jekyll to death, but a static, programmatic blog engine is not for everyone, as inadequate as alternate blog CMSes can feel. Ghost is a great option for people with a less technical background and ambition worth considering.
Those sound like CMS-specific traits. Jekyll is CMS-free, basically, so you need a third party for this. It’s fundamentally out of the scope of Jekyll, but obviously we need to be mindful of the missing features that make people choose something else over Jekyll, so it’s great you bring this up.
However, as emphasized before, just like we shouldn’t defend art by saying “It’s art; it’s supposed to be boring”, we should not default to a defensive position of arguing that “It’s static blogging; it’s supposed to be written from scratch in a command prompt and vim on a UNIX-based OS”. And templating is one of the most obvious ways in which we can improve the product of Jekyll for a wider audience.
Like any good software, Jekyll's scope seems to be more what its users do with it rather than what its creators intended. It seems to be taking on a life of its own.
I've done both multi-lingual and multi-author sites with Jekyll (and development seed has done a write-up of how they accomplished multi-lingual for the healthcare.gov site). The YAML-based data model in Jekyll is unique in that it's easy for humans to use (being YAML) and can serve nearly any purpose (including a store for multiple authors), and keeps non-technical users out of the config file.
I'd also say that the concept of theming is easier in Jekyll than in Wordpress, but I imagine not too many people would agree with me.
I'd agree with you that it's easier in that it is more straightforward, but
On 17 April 2014 00:36, Bud Parr firstname.lastname@example.org wrote:
Great discussion here - thanks to everyone for participating. There have been some really solid points made, and for me key the takeaways are:
Thanks again for all the shared perspectives. Feel free to leave further thoughts, but since this has been open for 6 months and there are no actionable items, I'm going to go ahead and close this out and leave any actionable decisions up to @parkr and @mattr- to make.