Kicking off new prose work #295

tristen opened this Issue Mar 20, 2013 · 12 comments


None yet
4 participants

tristen commented Mar 20, 2013

Quick announcement: We're excited to be kicking off new development in prose. You can read more about the changes proposed in this blog post:

Let us know what you think in the comments below.


ghost commented Mar 21, 2013


  1. It sounds like the new interface for a "settings" section will handle any number of different types of variables I might choose to put into my post/webapp - correct? Example: comments: true
  2. Is this now going to be a tool exclusively used for Jekyll projects - or - Markdown only? Have you considered processing markdown which is enclosed inside of an HTML block element? This could be used to allow a user to put markdown based text inside of a special colored block, or columns, or some kind of Specialized UI element - For example, a simple e-commerce site with an area designed for displaying a product.

tristen commented Mar 21, 2013

@uberbuilder For 1. That's definitely the direction we want to take. comments: true is an interesting example - limiting comments shown per post that are managed by disqus or some such. Some thought will need to go into handling use cases.

For 2. The goal is for prose to really shine on Jekyll projects. You could otherwise edit other pages on a site if you fed it a url. limiting content you can edit on a page by adding class in your markup is an interesting idea too and something to consider down the road.

What about supporting dropbox?


tristen commented Mar 21, 2013

@voidfiles Currently there are no plans to support a Dropbox feature.

@tristen, hi!
Let me know if you need some help. I'm very interesting in this.


tristen commented Mar 22, 2013

@Integral Awesome. We're kicking off development on Monday with tasks outlined in issues


ghost commented Mar 25, 2013

@tristen I've given a lot of thought over the weekend to this. Over the last ten years of observing how people using applications I would like to bring up a few topics of thought as you move forward with the progress of

Consider making a "Mission Statement" to solidify what prose is supposed to do. In the current version of what I would consider your mission statement:

Prose is a web-based interface for managing text-based content in your GitHub repositories. Use it to create, edit, and delete files, and save your changes directly to GitHub.

Prose is great for making quick updates to your code or managing your blog. Prose pays special attention to Jekyll sites hosted on GitHub Pages with Markdown text preview and syntax reference. It's configurable to restrict users to files that live within the _posts directory so you can use it to manage the content on your blog without fear of changing other critical files. Using Jekyll in conjunction with Prose is a smart way of maintaining websites for developers and editors alike by allowing them to use a visual, web-based tool to manage the content.

I see two themes emerging.

Theme 1: [Prose] is a web-based interface for managing text-based content in your GitHub repositories. Use it to create, edit, and delete files, and save your changes directly to GitHub.

Theme 2: [Prose] pays special attention to [Jekyll sites]

I see these as two paths which will not necessarily always be the same.

Really Long Rant

I feel like now is a good time to tell you what happened on Friday. When I heard the news and read your blog there was a ping of sadness that shot throughout my entire company. I've been secretly watching for a while now. Working on other things while I've been observing the direction you would take with Personally I see a huge need in the web design community for this very specific product.


Looking at how people actually use WordPress seams to be inconsistant with how WordPress actually runs their development. Now, I don't want to turn this into a "WordPress" bashing thread. But I think it is important to use what I believe to be their development failures as learning moments to do things better now. Consider the facts.

  1. All other solutions are bad, and we need to continue to shine:

    Nobody who is ever really serious about blogging, or authoring any kind of content in WordPress actually uses the "Visual Editor". It murders any goodness anyone tries to put into their content. It automatically (and demonically) tries to do way too much to "save" the user while it ends up just confusing all of us and we give up and switch over to the raw HTML tab asap.

    One of the first things any people do when they start a new WordPress project is they disable the visual editor.
    I've taught many different kinds of people of different levels of proficiency how to work with WordPress and I have determined that hands down the best way to teach somebody how to write content on the web today is undeniably MarkDown with some HTML blocks injected for the more complicated contents they wish to add to their page/blog article (such as live voting, "responsive" columns, etc.)

    I believe that is the single largest promising improvement to an editing interface that I see has the potential to completely solve this problem we're having with online editors.

  2. Use it, or lose it:

    The best interfaces/applications are the ones that developers make for themselves and continue to develop and improve for themselves - in other words _"Use it, or lose it"_. I find it hard to believe that anyone of any technical knowledge still uses the Visual Editor in WordPress (If you do, than please show me how to use it because - I just can't... I must be dumb).

    I firmly believe that part of the reason why it sucks so bad is because no one ever spends time to actually fix the problems that it has.

    Many web-developers build WordPress websites for people and then expect them to actually be able to write good content while they give their customers tools which actually reduce their capacity to produce professional results. I know many of us secretly hate our customers.

    Everyone always talks about it all the time about how the "End user" or "Clients" or "Business owners" are annoying, don't know what they are doing, know nothing about web design... and in response to this we spend countless hours worrying about pixel perfection and come up with all kinds of amazing ways to improve our own workflows for design all while ignoring the most important person - the one who's paying you.

    We sell them a site they can edit them selves, and then turn our backs on them once we've launched it.

    Some worse than others... but most of all of us do this to some extent. We cannot continue to do this. This issue must be addressed, and it must be done now.

    We are at a tipping point, and is the first thing that has really given me hope that other people out there are also worried about the same things that I am, and are willing to do something about it!

    The point here is that if we want to have a shake at solving this problem we need to give our clients access to the same tools that WE USE to write our own blogs and edit our own sites. We cannot continue to give them something different than what we use. If we like what we use and make it useful to use, it will work awesome for them and work well for them. The trick to this is designing an interface that works well for both parties. Both the experiences designer and the customer who knows nothing except [ #, ##, ###, - list, and > block quote ]

  3. GitHub infused website/blog editing eliminates meetings, annoying customer communications and saves both the designer/developers and the customer time allowing every effort to count toward the progress of getting the website built and content created all while teaching the customer automagically how to properly write content (differentials, issue posting, automatic emailing when a developer solves an issue/merges a change, automatically tells the customer when you've changed something, allows them to track your progress in a friendly non-pressure way, etc.)

    With a few of the suggestions that I have to bring to; I believe with all of my soul that I will take any business owner or client I've ever worked with and teach them how to write Organically SEO'd content in HTML5 standard code and give them direct access to including (in appropriate places) in their pages/blog articles more advanced content structures that I have designed and branded for their specific site.

We're already more then 80% of the way there with the awesome development you've already done. However I feel as though some of your design decisions that you have proposed in your blog article might be taking off in a direction that I think will actually lead to it's demise and ultimately make it just another trapped editor like the WordPress visual editor.


  1. Use it or lose it - by making specific to just Jekyll Markdown editing you're choosing to not allow Prose to grow up to be the awesome power that could be as an integral part of an online editor for other more complex text-based content which powers a client's site (like the "template pages" for example).

    If is only a Jekyll site editor than you're going to lose all of the support from the developers who don't spend any time on Jekyll sites right now, but would use to edit their [insert complex project, like a Javascript library or other] - these developers are the movers and the shakers of the web and should be considered your first priority. Together with those developers your first priority should be to make work for you and all of your programming needs while not making design decisions which would exclude the "Just Jekyll content contributor".

    In other words:

    If you make Markdown based Jekyll sites too high of a priority, you will end up losing access to the very people who will be able to take to where it should be. Those advanced designers and programmers are integral to your open-source community. If they don't use it they will lose it. If we all use it and spend time making it better for both ourselves and our clients it will be very natural to teach them how to use it. We can actually treat our clients and business owners who want to edit content with the respect they deserve. The clients can now be first-class citizens in the web development team. We can give them the tools they need to succeed rather than continue to ignore them.
  2. If you do what you're proposing to do I will end up losing one of my favorite tools in my tool belt - this will be a very sad day.

    If we could implement a better "find on page" I would be using all the time when I want to work on my many GitHub projects. Most of the work that I do is editing markdown on GitHub across many different projects - some of them Jekyll, but most of the ones I've been working on are not Jekyll based at all and won't ever be.

  3. By making focus only on Jekyll site editing you are going to exclude all of the other editing that we would like to use on. has the potential to be even cooler than the web version of "Sublime Text" or [insert favorite editor] which is directly connected to your GitHub account.

    It's SO EASY to teach clients right now how to use - all they need is a GitHub account. How could it be easier than that? They don't need to install anything at all and they can immediately get access to whatever I choose to give them access to as a developer and I can work with them in any kind of workflow that I choose to.

[End of Really Long Rant]

Back to your Mission Statement... and on to my suggestions.

Theme 1: [Prose] is a web-based interface for managing text-based content in your GitHub repositories. Use it to create, edit, and delete files, and save your changes directly to GitHub.

Theme 2: [Prose] pays special attention to [Jekyll sites]

Suggestion 1:

Consider keeping the way it currently is framework, language and technology agnostic.


Solidify the "" Mission Statement to just one theme:

Theme 1: [Prose] is a web-based interface for managing text-based content in your GitHub repositories. Use it to create, edit, and delete files, and save your changes directly to GitHub.

Suggestion 2:

Develop a Jekyll-focused aspect to without eliminating the current framework, language and technology agnostic feel that is has.

You obviously really love Jekyll (I do too) and this should be a focus... but please don't sacrifice the raw unlimited potential that currently possesses. I have some very awesome suggestions on very important aspects to keep in mind when developing a "Blog/Article" editing interface. Which would work really well with a framework like Jekyll or BEM. I would be more than happy to be come directly, and heavily involved on the development of this project if you are interested I could share my ideas with you and help you implement them, along with help out with your design goals as well.


Could we add a way to allow people to configure their on a project-by-project basis? We could have different types of interfaces enhancements based on the different kinds of work you're doing - and do this in a way that is smart, well designed and not intrusive to the interface or jarring from one type of work to another.

I have more ideas

After my many years of working with clients and helping them edit their own content I have found 4 or 5 things that are very useful but there has not been one interface that has brought all of these things into one easy to use place yet. It is one of my personal goals in life to actualize these findings and I would love to bring them to the project because I believe this is 100% consistant with your design/development goals.

If that's not the case, than I'll just say THANK YOU for all of the work you've done - learn from how you've done it and start a different project :) I hope we can work together though - I think it would be much more fulfilling, and we'd have a better product in the end bringing our ideas together.

Thank you so much for all the work you've done. I hope nothing I've said here is offensive to anyone's work be it WordPress's work, or yours. I believe that somebody needed to bring these points to light and have some discussion about them - and I don't mind being that person. It's always about moving forward and being the change we want to see in the world.



tristen commented Mar 25, 2013

@uberbuilder Thanks for the comments

Could we add a way to allow people to configure their on a project-by-project basis

Absolutely. In fact this is already a feature in prose and is not about to go away.

Given the new features outlined what do you see as incompatible? To be clear, the aim is to make jekyll shine as its the only static site generator supported by GitHub pages.


ghost commented Mar 25, 2013

@tristen Thanks for all the hard work you're doing, I am a HUGE fan of and everything you and your team is all about.

I see is so beautiful and very well designed. The fact that it works so well with GitHub API integration makes this tool extremely powerful, and with the right direction we can really shake off so many of the horrible design/development stunting aspects of the current trends in the market.

We need to have a well designed Markdown editor for blog article/website page content creation - this is a fact, and I believe is it.

My main point is this:

The best products/interfaces (particularly products like are always the ones which are built by the very people who use them.

So, the more "builders" you can continue to support with, the more people you have at your disposal to help maintain in a direction that will keep it alive and well for a very extended period of time.

The reason the "Visual Editor" in WordPress sucks is because no one works on it. Because the people who maintain WordPress don't use it, they don't think about improving the visual editor. In fact, it doesn't even really work at all.

Why should we support more than just Jekyll

So, right... Many of us who have projects on GitHub would love a great editor like to manage our Jekyll sites. By that very nature you've already got a great audience. And because Jekyll is the only static sight generator that is natively implemented on GitHub pages makes it very important - and I believe that very fact makes it worthy of your cause.

Jekyll is very cool, I use it myself all the time - so of course I'd like to have work in a Jekyll aware way - fantastic!

But what if I wanted something more?

DocPad anyone? What about emerging technologies like BEM? Using GitHub with something like Strider we now have access to using any kind of framework you could dream of using just for content editing for our clients... and allowing all developers and designers to use whichever workflow they currently like to use.

By keeping framework agnostic at it's heart while giving us the ability to create multiple personalities on a per-framework basis we can use whichever personality which best fits our purpose/client. I use many different variables in my YAML configuration area on one of my projects.

In the very near future I will be developing sites exclusively in BEM. These sites will almost exclusively use Markdown files for content that I would like to be able to edit using

I'd like to be able to use with my clients - and extend with some interface enhancements that I believe solve most of the developer/client communication issues and allow this end user the ability to rapidly write content which is O-SEO'd from the start. (Some hand-holding/quest-game based interface techniques, and some custom documentation integration techniques)

Have access to a more intelligent developer eco-system

If you keep framework agnostic at it's core, but still make the improvements which can be framework aware (like personalities) you allow more users to use for the processes they use in their workflows while also giving them the option to gain from the benefit and perhaps eventually completely graduate to a better way of working.

If we keep language agnostic then if we work to make also work for other files like .css, .sass, .html, .bemhtml, .js, .json, etc. We're going to attract a crowd of developers who really know what they are doing and can not only raise issues, but give you pull requests for features and improvements and help speed up the process of development. Eventually we can even tap into things like to give documentation help on a "personality" basis. Giving easy access to documentation when needed.

If keeps focused on being purely an authoring platform for Jekyll than I fear your developer eco-system will suffer from the same thing that WordPress suffers from; Not enough users who really know how to build and maintain what they build.


ghost commented Mar 26, 2013

@tristen, I'd be interested to hear more from you on this conversation.

Perhaps is really going to just be a Jekyll only thing - And if that's what you all want to do with it... no problem - I support it and I'll help here too.

I have dreams that has helped me invision with your awesome design and work. Dreams of really having something that can really do what is said in the readme:

We hope Prose + Jekyll will provide a simple, efficient alternative to traditional CMSs that require web and database servers to host content.

That we can have an efficient alternative to the traditional CMSs. This is such a great step forward in the Web Community - one I entirely support.

And in continuing to support that effort I thought that we could continue to extend beyond only focusing on Jekyll. The opening statement we have higher up in the readme says:

Prose is a web-based interface for managing text-based content in your GitHub repositories. Use it to create, edit, and delete files, and save your changes directly to GitHub.

And it's very simple and clean and - everything a text-editor should be. I love it.

Anyways... So, I think you understand where I'm coming from here @tristen, do you have anything to add? Or anyone else watching - does anyone else have input on this idea?


tristen commented Mar 27, 2013

No argument from me! This definitely covers the project goals.


tristen commented Apr 7, 2013

Closing this - work has started in the v1 branch and issues will be cut to tasks to reflect this new work.

@tristen tristen closed this Apr 7, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment