Wow, the UI on that is gorgeous. I noticed a trend to add features and capability to GitHub which makes a lot of sense because it must have something like millions of users by now and it's something many of here personally use. I'm also working on something for GitHub (a work in progress, http://gitify.me - better notifications). I think we're going to see a lot of growth in the ecosystem around GitHub and tools. Using git and GitHub is going to become more important as time passes by.
For Prose, the front-end architecture makes a great deal of sense, and they must be using a proxy to get around same origin on API requests. I think some server side operations for caching might make sense to enable speed and reduce the number of requests on GitHub.
Using this thread to extend the discussion about digital content authoring...
Prose relies on Markdown, the current de-facto standard for content authoring on the web.
But what comes after?
If you ask me the answer is clearly: Semantic Rich Text Editing.
So if you like Prose, you might also like the idea of Substance, which is essentially about considering content as data and separating it from presentation. The challenging part here is to come up with web-based tools, that reliably maintain plaintext and annotations separately. Once these tools are ready, a new generation of application for collaborative content composition can be built. The resulting structured content is ready to be analyzed, visualized, turned into arbitrary output formats (PDF,ePub, …) or integrated with other applications.
Imagine Prose, providing WYSIWYG editing in realtime, plus the concept of patches to suggest improvements to a particular document.
Related links:
- http://github.com/substance (see composer, surface, text as well as architecture and document repositories)
You have it entirely backwards. Markdown is successful precisely because it isn't a semantic format; it's a reaction to overengineered semantic formats like HTML. Markdown is a purely presentational format; asterisks don't represent some abstract notion of emphasis, they denote italic text. The whole point is that you don't "maintain plaintext and annotations separately"; the formatting is part of the text.
I agree on over-engineered semantic formats. HTML used to be a document representation format. But for me it has turned into a presentation format, with all the DOM manipulation etc. This is perfectly fine, I just had to realize it. Now i just use divs and spans for my layouts, not trying to 'render' semantics. However, on a higher level there should be some document representation formats that can be turned into anything. That's the idea.
Well and I really don't think inline styles / annotations are good.
>Well and I really don't think inline styles / annotations are good.
Oh but they are. For the vast majority of content creators, semantics are inseparable from presentation; an article I write really does the semantics of looking how it looks, and can't be transformed into something different.
Just like in programming, to extract a good abstraction such as the semantic content of an article you need to test against three different implementations. But most people only write for and test against a single presentation version, so it should be no surprise that even if they try and separate the semantics and the presentation, they'll get it wrong.
How will Substance be an improvement on TeX/LaTeX? You can write content in LaTeX and use Pandoc to convert it to just about any other markup language. And it produces beautiful print proofs.
It's meant to be very strict about semantics (LaTeX actually isn't - it has a lot of style-related commands), and it will be extensible (so you can add your own content types). It's based based on a JSON document model that is describing a series of operations that can be used to reconstruct any document state and also enabling realtime collaboration. Authoring will take place in WYSIWYG-fashion. By having a real data-representation of the document, it can be turned into anything (e.g. LaTeX, PDF, HTML).
We use Pandoc to support a variety of output formats already.
However, we're working on a new architecture (https://github.com/substance/architecture) because we don't want to treat the symptoms of the current implementation and instead fix the problems we've identified at heart.
I would LOVE to be able to drop this and jekyll into a rails app as a gem (say a standard SaaS app) and serve/manage the about/blog part of the app with this. Is there anything like that?
This is quite awesome… I would love to see support for uploading files though! For a Jekyll based site you also want to be able to put images etcetera in there…
A lot of similar functionality is provided in GitHub’s wiki editor Gollum… which you can use on any git repository, actually. Thought it was quite fun to try out as well.
These solutions get more useful when there are more mixed repositories with code and other content. In our design studio we have all kinds of content usually in our Git: so the standard git viewing interface doesn’t do it justice.
I've been working on an obtvse fork that uses github gists as its backend. However, looking at this, I'm thinking of possibly just shifting to a jekyll-like repository base structure, instead of the complex gist+json based stuff I was using.
Thanks for the github.js. I'll try to add gists related stuff to it.
Btw,it didn't work on my iPad. Got to the repo choosing screen,but it gets stuck after I choose a branch, or even if it autoselects master.
We'll do some optimizations for iPad if we get time. However, this would be a great piece for getting involved. One blocker I see is that CodeMirror does not work well with iPad touch events yet.
I created a Svbtle/Obtvse clone (in terms of styling) that uses Jekyll Bootstrap if you are interested (https://github.com/joehand/joehand.github.com). I took some liberties in terms of functionality to suit my needs.
Definitely love using Prose.io with it. It has made my writing process much simpler.
How easy is it to integrate with other git providers or git from my own servers? Jekyll is not the best for content management and has its own drawbacks. But, this is something orthogonal to Jekyll, in that it call be used to edit any git files. Definitely looking forward to tinkering with this :)
Does this work with hosted jekyll sites or just those that live within github? The documentation only mentions github, but after a quick look at the source code I can't see any reason this wouldn't work (at least with some minor modifications) on any hosted jekyll blog.
One thing I miss about wordpress was the SEO plugins to look at my article, heading, meta, etc. This is the only thing I actually miss from wordpress. However, I miss it so much, I am thinking of going back. Please save me this frustration.
SEO is totally up to the website developer. The version Google sees is a generated static version of your Jekyll-site specification (layouts, posts, configuration etc.).
How are you guys making the Explanation videos like the one on the prose website or the the substance.io website? Is it some open source tool where you can provide the strings or just low level flash tweens or some thing?
Does Github's support for Jekyll mean that Github automatically "publishes" a blog post? I'm using something similar(Pelican), and I know I can't publish a post using Prose only, is that different for Jekyll sites?
I've been wanting a tool like this for some time. I've considered migrating simple websites running on a CMS into Jekyll but the lack of content editing for "humans" has always been the blocker.
This is really cool. And a little bit depressing that the typography in the preview is better than the typography on my actual site. I should really fix that.
Thanks. I ended up creating an issue for this and they mentioned a url like yours, except that I needed to append a master at the end, like @BHSPitMonkey suggested bellow.
There's only support for Markdown right now, but you should be able to edit any textfile in a repository. There might be some remaining flaws though, so please submit issues and help us fix them.
For Prose, the front-end architecture makes a great deal of sense, and they must be using a proxy to get around same origin on API requests. I think some server side operations for caching might make sense to enable speed and reduce the number of requests on GitHub.