19 ms·

I'm Building a GitHub for Writers

311 points by guynamedloren 13y ago

zfrenchee 13y ago
I wonder if Github is working on something like this. I'm sure they're familiar with the idea and they seem like the best team to bring it online. They're still a startup looking for growth opportunities: this one seems obvious.
uams 13y ago
The key to this one will be figuring out what features of git (and in particular github) will make it successful in other verticals. I wonder if some key CS concepts are so fundamentally ingrained, but that writers think about their work flow differently.
mehulkar 13y ago
What about draftin.com? I use that already and I like it a lot.
- guynamedloren 13y ago
  Big fan of Draft (and Nate). It's got the version control part down, and I think it works well for gathering feedback on blog posts and other short form content, but it isn't designed for longer form content as far as I can tell. It's also missing the community aspect that GitHub has, which is huge, as well as features that would make writing an ebook or textbook feasible. Definitely a great tool though.
  - spartango 13y ago
    Any reasons not to work with Nate? It seems like the social stuff could be built in tandem with his strong editor.
- jms703 13y ago
  ditto. simple and easy to use.
- wkdav 13y ago
  https://draftin.com/ https://draftin.com/ - Agreed, great. http://www.roughdraft.io/ http://www.roughdraft.io/ - Also, I like it. I don't think it's a bad idea to proceed with it, I would just find a way to differentiate it from what's out there.
srameshc 13y ago
I am trying to do the same. I never even thought about sharing this concept till I could launch. I know for sure this a great area to work on and it will make a huge impact for collaborative story telling.
babuskov 13y ago
I was looking for something like this. I'm planning to write an epic sci-fi novel and make it available under some open license (Creative Commons BY-SA probably). Since I'm not a native English speaker, I'm hoping those who are would jump in and help me perfect the text. My final hope is to see a Hollywood movie made out of it one day, because many recent SF movies lack good story. My other idea is to make the story branch into different directions. I would write the main storyline, but another writer could come and fork it at some point. The reader would be left with a choice at some point: would you like this character to take that decision or the other - and after choosing, the reader could read the forked variant. This is the first time I'm publicly writing about this idea. I'm still undecided what technology to use to create it.
- maxerickson 13y ago
  Have you looked at Z-code? There's lots of reasonably modern interpreters for it and there seems to be a fairly active community.
  - babuskov 13y ago
    No. I just googled now, but there seems to be a lot of stuff named Z-code and I'm not sure what exacly am I looking for. Can you give me some URL?
    - VikingCoder 13y ago
      I think Max is talking about the Z-Machine interpreter that Infocom created to make games like Zork and Hitchhiker's Guide to the Galaxy. There are many of modern ways to use it, like Inform (I recommend Inform 6 over 7), and even a web interpreter, Parchment. That's if you want someone to PLAY the choice in the story. Which is slightly different from what you're talking about.
      - maxerickson 13y ago
        Yeah, the Z-Machine interpreter. But I think it is reasonable to look at choose your own adventure as a fairly straightforward game, so Z-code presumably provides the necessary features for it.
joshdotsmith 13y ago
I know that Michael Hartl of RailsTutorial is working on something very much like this, but will be a full end-to-end product including things like sales. I can't wait to see what he comes up with.
bliker 13y ago
How are you solving the diff problem? Word based diffs tend to be jumpy and hard to follow. On the other hand line based diffs do not work well for text (prose).
- guynamedloren 13y ago
  Yeah, prose.io uses word diffs and it's definitely hard to follow. I'm doing 'fragment diffs' (doesn't really have a name) - but basically, all the text is displayed as you would read it (sentences and paragraphs), with diffs displayed inline and colored. Added content in green, removed content in red - doesn't matter if it's characters/words/sentences/paragraphs - it all works. Screenshot is not the best, but something like this: http://www.flickr.com/photos/madebyloren/9620674181/ http://www.flickr.com/photos/madebyloren/9620674181/
  - philsnow 13y ago
    Don't know if you've already thought of / planned this, but please please implement a side-by-side diff view. Code is easy enough to read in a unified diff because lines are usually short (unless java). Prose flows a lot more fluidly, and there is no formal grammar for human language. I have had the displeasure of having to read "redlines" (prose with inline diffs marked in red strikeout) and I find them completely impenetrable.
  - cauthonLuck 13y ago
    I'm using latex+vim+git for this purpose currently. I put two spaces after a period to signal the end of a sentence in Latex. Which helps me break the document up by sentences with vim. If you're using markup then encouraging the period-double-space could be a harmless way of easily breaking the document up by sentences
- rzimmerman 13y ago
  I think for writing, sentence-based diffs would be the most useful.
- 2mur 13y ago
  We've been working on a similar problem. Writing in markdown, pre-processing the saved markdown to truncate to 80 column (best fit) paragraphs and then diffing on the markdown.
crazygringo 13y ago
A lot of programmers already find it awfully hard to wrap their heads around how git works. I can only imagine how hard it will be for non-programmers to (it doesn't suprise me that the successful example used is written by mathematicians). HOWEVER, that doesn't mean it can't be done. In fact, if there are ways to visually simplify git and make it more intuitive for non-programmers, those techniques could wind up making git even better for programmers too. I could also imagine a convergence of the git model and the wiki model someday -- where anyone can edit (like Wiki), but where there are branches, merging, etc. Obviously, a lot of internal wiki's don't need such complicated version control, but for things like Wikipedia, it could be amazing. I think there are a lot of areas for working on writing collaboration -- group projects in school, business proposals, technical manuals, all sorts of things. And the main attraction for users over, say, Google Docs, is that your changes don't overwrite others'. The fact that your edits create a "branch", that then others can accept/reject/modify/merge, is a vast improvement in creative collaboration.
- guynamedloren 13y ago
  > In fact, if there are ways to visually simplify git and make it more intuitive for non-programmers, those techniques could wind up making git even better for programmers too. That's the goal. I want git to handle everything behind the scenes, and everything that the user touches just 'makes sense' - ie its not all that different from what they're already doing. A 'save' button makes a git commit, editing somebody else's content automatically creates a new branch, 'submitting' that content on the new branch creates a pull request .. etc.
  - dylangs1030 13y ago
    You could combine the advantages of git versioning with wiki style collaboration and make a git-wiki like the parent said, but for writers. Wikipedia is largely prose, but of a nonfiction variety. This would be a good intersection for git, which was born out of code. You could call it..."geeky"...too bad it wouldn't be for geeks.
  - terrycb 13y ago
    This is a really fantastic idea. I can also imagine writers will get a great deal of use out of git cherry pick.
scottfr 13y ago
I'm currently using GitHub to collaborate on writing a book with a non-technical coauthor. Generally it works great, but there are two key issues: * Changes are tracked by line which is equivalent to a paragraph in a book. If I go in and add a comma to a paragraph and my coauthor simultaneously changes a word in that paragraph that can create issues. * Errors are very difficult to solve for my coauthor. When Github Window's app encounters an error, it basically says "Just open up the command line and you should be able to figure out how to solve this". Of course this isn't feasible for a non-technical audience. If your product can fix these two issues (which it looks like it is trying to) it could be very valuable.
- nadaviv 13y ago
  > Changes are tracked by line which is equivalent to a paragraph in a book. When using Markdown, I usually split paragraphs over multiple lines (usually between sentences) which makes diffs much easier to read, while still rendering as a single paragraph.
  - vidarh 13y ago
    Same here. "Single line paragraphs" are a pet hate of mine - they have no place in plain text files even if those files are intended to be post-processed.
    - tasuki 13y ago
      I'm still undecided on this. Say you have a long paragraph and have to add one word at the beginning. You have two options - either rewrap and introduce a silly diff, or don't rewrap and exceed your chosen text width. Single line paragraphs don't put such a difficult choice in front of you. If your diff software is any useful, it'll highlight your change within the line.
      - gknoy 13y ago
        Perhaps you could have a special kind of commit, a "text-rewrap" commit (similar to merge commits), which might let your diff presentation tool alternate between diffing lines, pararaphs, or the like. I agree, the presentation layer really needs to be as granular as your editing team needs to be. I __really__ like how Github shows the differences within a line that is different.
gprasanth 13y ago
Just today, I was checking out the JS API wrappers for Github API v3 and I found Github.js. There, I discovered this site called prose.io Check it out! It's awesome!
gt5050 13y ago
This sounds great. I am also working on something similar called Papyrus. It lets authors create and edit ebooks simultaneously. http://papyruseditor.com/en/home/collaborate/new http://papyruseditor.com/en/home/collaborate/new
tptacek 13y ago
This is sort of what Nate Kontny is doing with Draft, which I like kind of a lot, much more than I expected to.
- emhart 13y ago
  I've been loving draft to the point that I haven't really engaged with any of the other new platforms out there, like editorially. I sign up to beta just about any of them that come along, but Draft just feels like home already. That said, I can't imagine I wouldn't at least play around on the platform the author describes.
- artgon 13y ago
  Agreed. Draft tackles versioning and editing in markdown very well. The incremental save feature makes all of this transparent to the writer.
- Shank 13y ago
  My biggest issue with Draft is consistency in behavior. Personal anecdotes are frowned upon here, but for most of last week the ability to export files wasn't working at all for me. When I'm dealing with Markdown, this is the last thing I want to happen. I much prefer a system that's geared to projects and not specific types of document too. For example, if this supported housing a collection of documents and an image or two - with changes able to be made on each file, it would be amazing. Google Docs I edit with others quickly tends to devolve into three different types of sharing/permissions issues, and I'm left frustrated or wondering why some people can access one thing or another. There's definitely room to innovate here.
  - guynamedloren 13y ago
    > I much prefer a system that's geared to projects and not specific types of document too. For example, if this supported housing a collection of documents and an image or two - with changes able to be made on each file, it would be amazing. Nailed it. That's what I'm building :)
- spartango 13y ago
jawerty 13y ago
I think this is a really interesting idea; however, I don't think it's a very good method to build it as 'Github for Writers' since coding and writing are two very different processes. For instance, writers often create their work on their own instead of with multiple contributions. Contributors is more of a code project attribute, for anyone who knows how to program well can add/modify code while not anyone who knows write well can add/modify to a story. It is true that writers need editors but editors are certainly not writers. If there was a system where all of the contributors acted more like 'editors' rather than writers than I personally think it would be an awesome version control program.
- gizmo686 13y ago
  One question is, do writers create their own work because of the nature of writing, or because they lacked the tools for collaboration. I have seen several examples of collaborative writing. The first example that comes to my mind is the SCP Foundation [1]. [1] http://www.scp-wiki.net/ http://www.scp-wiki.net/ EDIT: Actually posting the link might help. (Although redacting it has a nice sense of irony too).
- RougeFemme 13y ago
  I think this may be true for fiction (. . .writen often create their work on their own. . .not anyone. . .can add/modify a story), but I think it's a great idea for non-fiction, such as the textbook and research paper examples that the OP cited. Other examples include user or technical manuals, requirements documentation. . .The team members are often more akin to contributors (code or otherwise) than to editors. Individual but interlinked units have to come together to form a whole.
  - gknoy 13y ago
    Absolutely. My wife's job as a professional editor involved editing hundred-page documents, often with more than one author. A tool which made version control simple, yet writing easy, would be a godsend. The down side is, many such organizations (e.g., military) have standardized on Word, which is terrible for collaborative review, editing, and version control of long documents. (Of any documents?) She would have been extremely happy had her employer allowed them to use LaTeX or similar.
pavanred 13y ago
This might be naive, but don't authors use Latex to write? So, in a sense why can't they use github as it is to collaborate on writing? (I guess it goes without saying, I do not have any experience or knowledge about the writing process authors follow)
bayesianhorse 13y ago
I always thought "forking" in writers is sort of frowned upon...
- guynamedloren 13y ago
  Just like 'forking' code was frowned about before open source software came about ;)
  - Thrymr 13y ago
    > Just like 'forking' code was frowned about before open source software came about ;) Long after that, in fact. Forking an open source project was a desperate measure to free it from unresponsive/difficult/differently opinioned maintainers, that could leave a rift in the community for years (see Lucid/XEmacs). GitHub made forking something that was normal, common and expected.
felipebueno 13y ago
It's sad for me to see what you are doing because I had the same idea like 5 months ago. But I'm not that good on putting ideas into actions so it didn't go that far. :( That'd be an awesome tool for witers, bloggers, editors, etc. Keep up the good work! =)
Doctor_Fegg 13y ago
Great idea. Yes please! But Markdown as UI... is less than ideal. It's great for hackers, but there's already a GitHub for hackers, and it's called GitHub. No matter how much prose.io prettifies it, you still get those damn asterisks all over the place. Personally, I write in TextEdit, Helvetica 12pt. That's not a universal answer, but it works for me. (Previously I used MacWrite Pro, ClarisWorks and Word 5.1 at different times, but the basic appearance was the same.) Anything that makes a bold word look like "* * this * *" breaks 20 years of habit, and I won't do it. Markdown as backend storage, fine. But not as the primary editing interface.
- guynamedloren 13y ago
  > Markdown as backend storage, fine. But not as the primary editing interface. That's interesting - hadn't thought about storing in markdown and just displaying as html. Hmmm.
- fian 13y ago
  At work we are trialling Lyx + Subversion for collaborative creation of developer documentation. The stored data is in a text + markup format which allows for easy diffing. Lyx being a layer over Latex means we can easily transform into a wide variety of formats, but mostly we output to PDF and HTML. Subversion was chosen as we already had a server available and there isn't really the same need to branch/merge documents compared to code. Writing in Lyx took a little time to get used but I definitely feel more in control that when trying to wrangle complex docs in Word.
  - kraymer 13y ago
    I used to write my documents in Lyx too but spreading the tool amongst my colleagues involved a lot of evangelism. Markdown is a backend storage easier to adopt as developers are used to it (stackoverflow, github) but it produces output for the web : no pagination, header/footer, etc. Throw pandoc+tex template into the mix, and it starts to get really interesting : a quickly hacked markdown file transforms into nice pdf will all needed attributes. But why stop there? Now that you have a build process, move it to a server and add some hooks to injects traceability infos (author, last edit date, commit hash...) into the generated document, etc... I went down this road, and it works surprisingly well. If you're trialling different solution for writing technical developer documentation, see a more precise description of the workflow that I pushed on my blog yesterday: http://kray.me/pro/doclegit-git-documentation-server/ http://kray.me/pro/doclegit-git-documentation-server/ (sorry for the copy quality, english not my first langage, corrections by mail are welcomed)
hrjet 13y ago
Could this be used for other text-based documents? I am thinking of accounting systems such as ledger-cli which let you keep your accounts in plain text files.
RazerM 13y ago
This site doesn't work very well on mobile http://imgur.com/opmjUGn http://imgur.com/opmjUGn
- guynamedloren 13y ago
  Ah I know.. I've been meaning to fix that.
- guynamedloren 13y ago
  Fixed now btw.
AndrewDucker 13y ago
What I mostly want, when writing collaborative documents, isn't a git equivalent - it's a code-review equivalent. I want to leave comments on individual words, sentences, paragraphs, etc., with suggestions for changes. And that's something that git doesn't allow, because the smallest change you can comment on is a file, with no ability to comment on specific parts of it.
- manish_gill 13y ago
  You can usually do it with shared Google docs. I know a few writers who share their content with a few trusted betas. It provides the necessary features, I think. Highlights, commenting etc. I think there is also a "real-time" feature that it provides (not sure about that), so there is usually more than one eye on the doc as the chapter is being typed.
- JeffJenkins 13y ago
  If you're using google docs for your collaboration this sort of commenting is built in. It's a great feature. Almost better than collaborative editing
- guynamedloren 13y ago
  Git doesn't support it, but GitHub does. You can comment on individual lines via GitHub. I'm going to do something similar - maybe on a more granular level (words/sentences).
- gamblor956 13y ago
  It sounds like you're looking for Microsoft Word, which has offered this feature for more than a decade (albeit though not online until this past year).
- cauthonLuck 13y ago
  Latex has line comments and since it is compiled into a document you can place line breaks anywhere. It does break the flow of the sentence though. I've used Latex+vim+git to write scientific papers recently. It is unfortunately much too complicated for my colleagues to adopt. They're holding onto MS Word which is far inferior in terms of markup, citing, and VCS. I've been converting my Latex documents to ugly word documents for collaborating and editing. The MS Word editing isn't great either. The strikethrough method breaks up flow. I've also had problems deleting side comments in Libre office. And the MS Word experience isn't always the same on Macs.
begriffs 13y ago
I think the guys at Github do want to help non-technical people learn to collaborate with git in areas like education, government, and literature. Check out this interview where one of the Github trainers, Brent Beer, talks about these ideas. You might want to get in contact with him. http://blog.begriffs.com/2013/08/an-interview-with-brent-beer.html http://blog.begriffs.com/2013/08/an-interview-with-brent-bee...
- guynamedloren 13y ago
  > I think the guys at Github do want to help non-technical people learn to collaborate with git in areas like education, government, and literature Yep, they're doing it, just not quickly enough :) Neat, I'll check out the interview. Thanks!
nwhitehead 13y ago
An idea is to think about rendering/typesetting as a feature. For many, getting an environment set up to turn the project files into final files of whatever form is a huge barrier. It would be great to have a bunch of back-end rendering be just a click: Markdown->HTML, Markdown->PDF, Markdown->epub, Latex->PDF, Latex->HTML.
- guynamedloren 13y ago
  Already done
- cauthonLuck 13y ago
  especially when you throw in citations for scientific articles. Which often require compilation of the citation database, citation order, and citation insertion. Adding 3 more steps to the process. I've recently switched to papers to help with this. It seems to have a strong community and supports both MS word, libre office, and vim. Jury's still out though. http://www.papersapp.com/papers/ http://www.papersapp.com/papers/
GrinningFool 13y ago
Is this going to be focused on those who use latex and markdown, or the the broader audience of 'people who write'? If the latter, you run into a problem pretty quickly - MS Word. It's still one of the most popular document editing tools out there. More recent versions do store content in zipped XML, but are you willing to put the work into parsing that content at a level sufficient to let it integrate into the kind of flow you discuss? (EDIT: That said: if your target is those creating text-based documents, then I think this is an excellent idea. )
FiddlerClamp 13y ago
Have you asked a representative sample of writers whether they write this way, and would like to use your site to write this way? Outside of business, collaborative writing seems to be pretty minimal (I say this as a novelist)... Also, if there could be some cross-compatibility with MS Word's Track Changes (I know, I can dream...) that would be great.
frozenport 13y ago
We edit research quality publications on Bitbucket. So Git already works for writers.
chalst 13y ago
I'm familiar with similar workflows. Last week, I edited via a (private) Github repo with a scientist client who use Emacs/ org-mode/ ediff, authoring .org files, editing using Git staging to create change sets and inline \NB[]{} commands to annotate changes, and ediff/git-merge to step through and resolve changes. Some observations: 1.Ediff is a nice tool to use for resolving Git conflicts; 2. Org mode works very well with this workflow, provided you use one paragraph per Unix line; 3. Latex generation can be very nice from org-mode sources, and the org-mode -> Latex exporter allows a nicer separation of content from presentation than you get with vanilla Latex. I'd love to hear of anyone who has success with a similar, but vi-based workflow.
- cauthonLuck 13y ago
  I use a similar setup with vim+latex+git for chemistry articles. It works amazing for me. I feel like it is the most powerful presentation setup and most efficient editing setup currently available. I break sentences by ending with two spaces. (this doesn't matter since Latex is markup) The only issue arises when ideas span across multiple sentences, but I believe there is a flag for controlling the number of lines around a diff. (sorry, I'm new to git) But this sort of proves the point that an easy wrapper for git should be created for scientific writing. The two main problems I have are: 1. adoption by collaborators (they can't surmount the learning curve) 2. diffing sentences is very different from lines of code
  - chalst 13y ago
    Typical Org-mode code diffs better than typical Latex code. This is a serious argument in favour of authoring in Org-mode and using its Latex export facility.
lizelfman 13y ago
As a writer I'd be glad to use something like this. I'm working on a book with the founder of a non-profit in DC, and it involves a lot of sharing articles, trading thoughts, and sending documents. We've been using Honey.is which is nice for small businesses but just not as collaborative as we need it to be.
deleted 13y ago
[deleted]
mallyvai 13y ago
From @kmatzen's comments on Authorea.com: " What do you get when you combine authors with gonorrhea? Authorea! I like it! There are two things I would still like though. One would be page rendering in the browser. We often have to iterate several times on a paper adjusting figures, text, padding, etc. to get everything to fit within the page limit. I could write the paper in this and then export it to tex, but that defeats the purpose. The second thing is support of popular LaTeX packages. It looks like I can upload arbitrary tex documents, but that's going to get messy if I have to upload the same packages for every paper I'm writing. We use github for our papers right now. Less than ideal. "
- natejenkins 13y ago
  What can I say? Naming is hard. We initially thought to ourselves, "Spreading science should be fun and intuitive, like an STD. And it should be hard to get rid of." Thus Authorea was born. Have you tried our pdf exporter to check page length? We are trying to build it out to where you, as a user, don't have to worry about packages. If there is a journal you would like to submit to and we don't currently have the journal setup as an export template, please contact us and we will be happy to add it. It's funny how authors worry so much about page length and figure placement, and then the first thing a journal does is remove all of the formatting the author has put in place.
- apepe 13y ago
  hi @kmatzen/@mallyvai! Adding briefly to Nate's comment (my co-founder at Authorea), I would like to point out that we do support many popular LaTeX packages. One big reason why we do not support custom LaTeX packages is that some of them are really intended for the printed page and cannot be easily ported to the web- and the point of Authorea is to create web-native documents, which render in the browser, first, and can then be ported to print formats. In other words, we support a safe subset of LaTeX which we can easily convert back and forth into other web formats (such as Markdown). Do let us know if you have a LaTeX package in mind and we will see if we can add it for you.
stared 13y ago
Take a look at "Why use version control systems for writing a paper" (http://academia.stackexchange.com/questions/5277/ http://academia.stackexchange.com/questions/5277/). When it comes to diffs for text, just add "--color-words": git diff HEAD~1 --color-words my_file.md But I agree with other stuff, that for non-techies Git + GitHub may be to hard to start.
diziet 13y ago
Do authors really collaborate as much as developers do? Wikipedia is an example of people collaborating on writing something, but the subject matter is quite different from the kinds of writing that gets done.
rrrene 13y ago
So I get the vibe that this will never be open sourced but is a side-project of yours that (should it come to fruition) will be run as for-profit. Am I right?
jedc 13y ago
Is it just me, or are there a number of fairly high-profile writing tools that have launched recently? The ones I'm thinking about: * Draft http://draftin.com * Editorially http://editorially.com * Quip http://quip.com * Loren's Penflip http://www.penflip.com * Google Docs (obviously not new) A lot of thoughts running through my head, including that finally products are being built from the ground up both for collaboration and for mobile/tablets. (And that this appears to be an early sign of the end of Microsoft's dominance in the office productivity software world.)
- guynamedloren 13y ago
  I'm on your 'high-profile' list! Made my day, thank you.
- Myrmornis 13y ago
  Are any of these projects aiming to interface well with MS Word or OpenOffice?
  - sdoering 13y ago
    Well you could use pandoc [1] for creating MS Word or other file-formats. As far as I know MS Word is still the choice to use for novelists, when it comes to giving test to editors and a like. So pandoc could be used for transforming a text into many different formats (even ebook formats). Might be an interessting thing to look at for the creator of "git for writers" ;-) [1]: http://johnmacfarlane.net/pandoc/ http://johnmacfarlane.net/pandoc/
bambax 13y ago
This is a fantastic idea, beautiful and beautifully simple. Of course, one can think of a million objections to its success, but I really really hope it succeeds!
rrhoover 13y ago
Ironically, I posted a call to action to build a community for writing together. Very curious to see how Loren's project does and how it compares to Draft and others. https://medium.com/writers-on-writing/920214571e3d https://medium.com/writers-on-writing/920214571e3d
dylandrop 13y ago
This is interesting, but I think it kind of fails to take its audience into consideration. 1) It assumes writers write like programmers code. This isn't true. At least with scripts, what typically happens is the writer will write an entire script, send it to their boss for revisions, and then rewrite it. They would consider it a pain in the ass if they had to make "commits" for every page they wanted to add, and especially if their bosses had to review each change (mostly because bosses are executives who just want to leave their mark by making unnecessary changes on things). 2) In either book or script writing (or whatever) small grammatical changes are unimportant, and there will be way more of these than we would care to look at. Who cares about reverting a change of "its" to "it's"? I see this kind of thing as being useful for writing an informal, informational book in the form of an extended blog post (see http://gettingreal.37signals.com/ http://gettingreal.37signals.com/) but otherwise, I can't really see it being that useful for professional writers. Also, something that I think would be REALLY useful (that I'm honestly surprised I haven't seen is a Final Draft - meets - Google Docs (screenplays editable by multiple people via online, all stored online). Dunno if anyone's seen anything like this. Sources: My dad is a TV writer.
- gcb0 13y ago
  i try to get my SO to write academic essays in applications that have history or diff viewing... but never had any success. but that only means the current offerings are bad. even for programmers. regarding your points, when i set up `meld` to show the text she sent vs what her professor or coleague sent back, she is amazed. So there is usefulness. Second, have you ever used Kwrite in KDE? you don't have to commit or anything. just type. and it shows the diffs marks on the left. pretty hand. and avoid commits and all. about point #2, just make branches and tags more practical. Also, try to merge back those 'word fixes' in other branches ' heads. would be awesome even for programmers. source: optimist :)
- baby 13y ago
  Exactly. I don't care about the document progression or the changes of words. I just want "versions" and "notes". I actually did a writing application for myself only and I had two windows, one on the left with the actual text, one on the right with the notes, also a sidebar with the chapters and progression of the book.
agentultra 13y ago
Github for lawyers, laws, court records, etc. I wonder how the lobbying industry would change if there were highly-public records of everyone's additions to a bill.
thenerdfiles 13y ago
Just re-purpose git-flow with a "writing/publishing" namespace: https://github.com/nerdfiles/Concept-of-Flat-Design#adaptation-of-git-flow https://github.com/nerdfiles/Concept-of-Flat-Design#adaptati... master <-> publication develop <-> draft feature <-> chapter release <-> edition hotfix <-> redact support <-> copyright
based2 13y ago
Wooki* is a smart tool to write documents. It let you publish them and get reviews https://github.com/spreadthesource/wooki https://github.com/spreadthesource/wooki
malcolmmcc 13y ago
See also https://www.scigit.com/ https://www.scigit.com/
- michaelbuddy 13y ago
  link fails. no https on that site.
  - malcolmmcc 13y ago
    huh, both work for me.
deleted 13y ago
[deleted]
guard-of-terra 13y ago
The idea is terrific but focus is all wrong. Writers don't need branches. They don't code features in. Hell, most developers don't do stupid updates-on-branch-then-merge-merge-suffer-merge-curse-merge commit accounting. Writers usually write alone, what they need is: A (desktop) tool with basic WYSIWYG markup (paragraphs, bold/italic, that sort of thing) with version control, visual diffs, export into common formats. Maybe a pull request or two.
- cauthonLuck 13y ago
  Scientific writers do need branches. When there are 10 authors on one paper all suggesting different paragraphs/figures/equations at different times.
decadentcactus 13y ago
This might be useful for contracts, as well. Editing points and having history, being able to comment on specific parts etc. Not 100% sure on how to solve the "legally binding" part if the other party declines digital signatures, but it'd be a good way to get the contract written and agreed on.
hyperpape 13y ago
I wonder if you might prefer something like Darcs to Git. I've heard a lot of amnbivalence about Darcs as a practical software project (just seems to be losing momentum, and it has never matched Git for speed), but I wonder if the model is more apt for writing than Git.
cauthonLuck 13y ago
How many of these options penflip, draft, etc are actually open source? I'm looking for very specific features on the level of Latex libraries that would never make it into a for profit application.
ozh 13y ago
I'm a little late in the party but I wanted to express my feelings anyway. I wrote a book with 2 other authors 2 years ago, and would have LOVED a tool like this. Going over Word documents in revision mode was a colorful nightmare. In general, having to work with Word was not the ideal stuff anyway. To my point: to be totally useful along the whole typical writing process with traditional publishers (authors -> technical review -> authors -> editor review -> authors -> punctuation/misc review -> authors -> editor) you'll need at some point to export as Word documents. Ideally, collaborate in Git like environment, export as Word, receive a new Word with all those colored revision and import into Git like stuff.
SunboX 13y ago
> What's so awesome about GitHub? It isn't all reasons mentioned in this article ... the most awesome about github are the developers. This is the biggest reasons why a "github for writers" could fail
victormier 13y ago
As I was reading all these words about project collaboration I started getting more and more excited about the thought of myself collaborating in your project. Until I saw it was not open sourced...
dbspin 13y ago
Can't emphasise enough how important offline editing would be for something like this. As a professional writer (whose co-written a book), you can't rely on always having internet; but you always need to be able to work on your current project.
user1241320 13y ago
I thought https://poetica.com/ https://poetica.com/ was doing just this
theorique 13y ago
Github works on source code, which is text files. Writers work on English text (or other languages) which is text files. What does this do that Github itself (or equivalent - bitbucket, etc) does not?
albertoperdomo 13y ago
Just a heads up: I just tried to signup for the newsletter and got a nasty Rails error page (500). It turns out Iwas browsing with JS turned off (using NoScript). It worked fine after activating JS.

311 points by guynamedloren 13y ago

I wonder if Github is working on something like this. I'm sure they're familiar with the idea and they seem like the best team to bring it online. They're still a startup looking for growth opportunities: this one seems obvious.

uams 13y ago

The key to this one will be figuring out what features of git (and in particular github) will make it successful in other verticals. I wonder if some key CS concepts are so fundamentally ingrained, but that writers think about their work flow differently.

mehulkar 13y ago

What about draftin.com? I use that already and I like it a lot.

guynamedloren 13y ago
Big fan of Draft (and Nate). It's got the version control part down, and I think it works well for gathering feedback on blog posts and other short form content, but it isn't designed for longer form content as far as I can tell. It's also missing the community aspect that GitHub has, which is huge, as well as features that would make writing an ebook or textbook feasible. Definitely a great tool though.
- spartango 13y ago
  Any reasons not to work with Nate? It seems like the social stuff could be built in tandem with his strong editor.
jms703 13y ago
ditto. simple and easy to use.
wkdav 13y ago
https://draftin.com/ https://draftin.com/ - Agreed, great. http://www.roughdraft.io/ http://www.roughdraft.io/ - Also, I like it. I don't think it's a bad idea to proceed with it, I would just find a way to differentiate it from what's out there.

srameshc 13y ago

I am trying to do the same. I never even thought about sharing this concept till I could launch. I know for sure this a great area to work on and it will make a huge impact for collaborative story telling.

babuskov 13y ago

I was looking for something like this. I'm planning to write an epic sci-fi novel and make it available under some open license (Creative Commons BY-SA probably). Since I'm not a native English speaker, I'm hoping those who are would jump in and help me perfect the text. My final hope is to see a Hollywood movie made out of it one day, because many recent SF movies lack good story. My other idea is to make the story branch into different directions. I would write the main storyline, but another writer could come and fork it at some point. The reader would be left with a choice at some point: would you like this character to take that decision or the other - and after choosing, the reader could read the forked variant. This is the first time I'm publicly writing about this idea. I'm still undecided what technology to use to create it.

maxerickson 13y ago
Have you looked at Z-code? There's lots of reasonably modern interpreters for it and there seems to be a fairly active community.
- babuskov 13y ago
  No. I just googled now, but there seems to be a lot of stuff named Z-code and I'm not sure what exacly am I looking for. Can you give me some URL?
  - VikingCoder 13y ago
    I think Max is talking about the Z-Machine interpreter that Infocom created to make games like Zork and Hitchhiker's Guide to the Galaxy. There are many of modern ways to use it, like Inform (I recommend Inform 6 over 7), and even a web interpreter, Parchment. That's if you want someone to PLAY the choice in the story. Which is slightly different from what you're talking about.
    - maxerickson 13y ago
      Yeah, the Z-Machine interpreter. But I think it is reasonable to look at choose your own adventure as a fairly straightforward game, so Z-code presumably provides the necessary features for it.

joshdotsmith 13y ago

I know that Michael Hartl of RailsTutorial is working on something very much like this, but will be a full end-to-end product including things like sales. I can't wait to see what he comes up with.

bliker 13y ago

How are you solving the diff problem? Word based diffs tend to be jumpy and hard to follow. On the other hand line based diffs do not work well for text (prose).

guynamedloren 13y ago
Yeah, prose.io uses word diffs and it's definitely hard to follow. I'm doing 'fragment diffs' (doesn't really have a name) - but basically, all the text is displayed as you would read it (sentences and paragraphs), with diffs displayed inline and colored. Added content in green, removed content in red - doesn't matter if it's characters/words/sentences/paragraphs - it all works. Screenshot is not the best, but something like this: http://www.flickr.com/photos/madebyloren/9620674181/ http://www.flickr.com/photos/madebyloren/9620674181/
- philsnow 13y ago
  Don't know if you've already thought of / planned this, but please please implement a side-by-side diff view. Code is easy enough to read in a unified diff because lines are usually short (unless java). Prose flows a lot more fluidly, and there is no formal grammar for human language. I have had the displeasure of having to read "redlines" (prose with inline diffs marked in red strikeout) and I find them completely impenetrable.
- cauthonLuck 13y ago
  I'm using latex+vim+git for this purpose currently. I put two spaces after a period to signal the end of a sentence in Latex. Which helps me break the document up by sentences with vim. If you're using markup then encouraging the period-double-space could be a harmless way of easily breaking the document up by sentences
rzimmerman 13y ago
I think for writing, sentence-based diffs would be the most useful.
2mur 13y ago
We've been working on a similar problem. Writing in markdown, pre-processing the saved markdown to truncate to 80 column (best fit) paragraphs and then diffing on the markdown.

crazygringo 13y ago

A lot of programmers already find it awfully hard to wrap their heads around how git works. I can only imagine how hard it will be for non-programmers to (it doesn't suprise me that the successful example used is written by mathematicians). HOWEVER, that doesn't mean it can't be done. In fact, if there are ways to visually simplify git and make it more intuitive for non-programmers, those techniques could wind up making git even better for programmers too. I could also imagine a convergence of the git model and the wiki model someday -- where anyone can edit (like Wiki), but where there are branches, merging, etc. Obviously, a lot of internal wiki's don't need such complicated version control, but for things like Wikipedia, it could be amazing. I think there are a lot of areas for working on writing collaboration -- group projects in school, business proposals, technical manuals, all sorts of things. And the main attraction for users over, say, Google Docs, is that your changes don't overwrite others'. The fact that your edits create a "branch", that then others can accept/reject/modify/merge, is a vast improvement in creative collaboration.

guynamedloren 13y ago
> In fact, if there are ways to visually simplify git and make it more intuitive for non-programmers, those techniques could wind up making git even better for programmers too. That's the goal. I want git to handle everything behind the scenes, and everything that the user touches just 'makes sense' - ie its not all that different from what they're already doing. A 'save' button makes a git commit, editing somebody else's content automatically creates a new branch, 'submitting' that content on the new branch creates a pull request .. etc.
- dylangs1030 13y ago
  You could combine the advantages of git versioning with wiki style collaboration and make a git-wiki like the parent said, but for writers. Wikipedia is largely prose, but of a nonfiction variety. This would be a good intersection for git, which was born out of code. You could call it..."geeky"...too bad it wouldn't be for geeks.
- terrycb 13y ago
  This is a really fantastic idea. I can also imagine writers will get a great deal of use out of git cherry pick.

scottfr 13y ago

I'm currently using GitHub to collaborate on writing a book with a non-technical coauthor. Generally it works great, but there are two key issues: * Changes are tracked by line which is equivalent to a paragraph in a book. If I go in and add a comma to a paragraph and my coauthor simultaneously changes a word in that paragraph that can create issues. * Errors are very difficult to solve for my coauthor. When Github Window's app encounters an error, it basically says "Just open up the command line and you should be able to figure out how to solve this". Of course this isn't feasible for a non-technical audience. If your product can fix these two issues (which it looks like it is trying to) it could be very valuable.

nadaviv 13y ago
> Changes are tracked by line which is equivalent to a paragraph in a book. When using Markdown, I usually split paragraphs over multiple lines (usually between sentences) which makes diffs much easier to read, while still rendering as a single paragraph.
- vidarh 13y ago
  Same here. "Single line paragraphs" are a pet hate of mine - they have no place in plain text files even if those files are intended to be post-processed.
  - tasuki 13y ago
    I'm still undecided on this. Say you have a long paragraph and have to add one word at the beginning. You have two options - either rewrap and introduce a silly diff, or don't rewrap and exceed your chosen text width. Single line paragraphs don't put such a difficult choice in front of you. If your diff software is any useful, it'll highlight your change within the line.
    - gknoy 13y ago
      Perhaps you could have a special kind of commit, a "text-rewrap" commit (similar to merge commits), which might let your diff presentation tool alternate between diffing lines, pararaphs, or the like. I agree, the presentation layer really needs to be as granular as your editing team needs to be. I __really__ like how Github shows the differences within a line that is different.

gprasanth 13y ago

Just today, I was checking out the JS API wrappers for Github API v3 and I found Github.js. There, I discovered this site called prose.io Check it out! It's awesome!

gt5050 13y ago

This sounds great. I am also working on something similar called Papyrus. It lets authors create and edit ebooks simultaneously. http://papyruseditor.com/en/home/collaborate/new http://papyruseditor.com/en/home/collaborate/new

tptacek 13y ago

This is sort of what Nate Kontny is doing with Draft, which I like kind of a lot, much more than I expected to.

emhart 13y ago
I've been loving draft to the point that I haven't really engaged with any of the other new platforms out there, like editorially. I sign up to beta just about any of them that come along, but Draft just feels like home already. That said, I can't imagine I wouldn't at least play around on the platform the author describes.
artgon 13y ago
Agreed. Draft tackles versioning and editing in markdown very well. The incremental save feature makes all of this transparent to the writer.
Shank 13y ago
My biggest issue with Draft is consistency in behavior. Personal anecdotes are frowned upon here, but for most of last week the ability to export files wasn't working at all for me. When I'm dealing with Markdown, this is the last thing I want to happen. I much prefer a system that's geared to projects and not specific types of document too. For example, if this supported housing a collection of documents and an image or two - with changes able to be made on each file, it would be amazing. Google Docs I edit with others quickly tends to devolve into three different types of sharing/permissions issues, and I'm left frustrated or wondering why some people can access one thing or another. There's definitely room to innovate here.
- guynamedloren 13y ago
  > I much prefer a system that's geared to projects and not specific types of document too. For example, if this supported housing a collection of documents and an image or two - with changes able to be made on each file, it would be amazing. Nailed it. That's what I'm building :)
spartango 13y ago

jawerty 13y ago

I think this is a really interesting idea; however, I don't think it's a very good method to build it as 'Github for Writers' since coding and writing are two very different processes. For instance, writers often create their work on their own instead of with multiple contributions. Contributors is more of a code project attribute, for anyone who knows how to program well can add/modify code while not anyone who knows write well can add/modify to a story. It is true that writers need editors but editors are certainly not writers. If there was a system where all of the contributors acted more like 'editors' rather than writers than I personally think it would be an awesome version control program.

gizmo686 13y ago
One question is, do writers create their own work because of the nature of writing, or because they lacked the tools for collaboration. I have seen several examples of collaborative writing. The first example that comes to my mind is the SCP Foundation [1]. [1] http://www.scp-wiki.net/ http://www.scp-wiki.net/ EDIT: Actually posting the link might help. (Although redacting it has a nice sense of irony too).
RougeFemme 13y ago
I think this may be true for fiction (. . .writen often create their work on their own. . .not anyone. . .can add/modify a story), but I think it's a great idea for non-fiction, such as the textbook and research paper examples that the OP cited. Other examples include user or technical manuals, requirements documentation. . .The team members are often more akin to contributors (code or otherwise) than to editors. Individual but interlinked units have to come together to form a whole.
- gknoy 13y ago
  Absolutely. My wife's job as a professional editor involved editing hundred-page documents, often with more than one author. A tool which made version control simple, yet writing easy, would be a godsend. The down side is, many such organizations (e.g., military) have standardized on Word, which is terrible for collaborative review, editing, and version control of long documents. (Of any documents?) She would have been extremely happy had her employer allowed them to use LaTeX or similar.

pavanred 13y ago

This might be naive, but don't authors use Latex to write? So, in a sense why can't they use github as it is to collaborate on writing? (I guess it goes without saying, I do not have any experience or knowledge about the writing process authors follow)

bayesianhorse 13y ago

I always thought "forking" in writers is sort of frowned upon...

guynamedloren 13y ago
Just like 'forking' code was frowned about before open source software came about ;)
- Thrymr 13y ago
  > Just like 'forking' code was frowned about before open source software came about ;) Long after that, in fact. Forking an open source project was a desperate measure to free it from unresponsive/difficult/differently opinioned maintainers, that could leave a rift in the community for years (see Lucid/XEmacs). GitHub made forking something that was normal, common and expected.

felipebueno 13y ago

It's sad for me to see what you are doing because I had the same idea like 5 months ago. But I'm not that good on putting ideas into actions so it didn't go that far. :( That'd be an awesome tool for witers, bloggers, editors, etc. Keep up the good work! =)

Doctor_Fegg 13y ago

Great idea. Yes please! But Markdown as UI... is less than ideal. It's great for hackers, but there's already a GitHub for hackers, and it's called GitHub. No matter how much prose.io prettifies it, you still get those damn asterisks all over the place. Personally, I write in TextEdit, Helvetica 12pt. That's not a universal answer, but it works for me. (Previously I used MacWrite Pro, ClarisWorks and Word 5.1 at different times, but the basic appearance was the same.) Anything that makes a bold word look like "* * this * *" breaks 20 years of habit, and I won't do it. Markdown as backend storage, fine. But not as the primary editing interface.

guynamedloren 13y ago
> Markdown as backend storage, fine. But not as the primary editing interface. That's interesting - hadn't thought about storing in markdown and just displaying as html. Hmmm.
fian 13y ago
At work we are trialling Lyx + Subversion for collaborative creation of developer documentation. The stored data is in a text + markup format which allows for easy diffing. Lyx being a layer over Latex means we can easily transform into a wide variety of formats, but mostly we output to PDF and HTML. Subversion was chosen as we already had a server available and there isn't really the same need to branch/merge documents compared to code. Writing in Lyx took a little time to get used but I definitely feel more in control that when trying to wrangle complex docs in Word.
- kraymer 13y ago
  I used to write my documents in Lyx too but spreading the tool amongst my colleagues involved a lot of evangelism. Markdown is a backend storage easier to adopt as developers are used to it (stackoverflow, github) but it produces output for the web : no pagination, header/footer, etc. Throw pandoc+tex template into the mix, and it starts to get really interesting : a quickly hacked markdown file transforms into nice pdf will all needed attributes. But why stop there? Now that you have a build process, move it to a server and add some hooks to injects traceability infos (author, last edit date, commit hash...) into the generated document, etc... I went down this road, and it works surprisingly well. If you're trialling different solution for writing technical developer documentation, see a more precise description of the workflow that I pushed on my blog yesterday: http://kray.me/pro/doclegit-git-documentation-server/ http://kray.me/pro/doclegit-git-documentation-server/ (sorry for the copy quality, english not my first langage, corrections by mail are welcomed)

hrjet 13y ago

Could this be used for other text-based documents? I am thinking of accounting systems such as ledger-cli which let you keep your accounts in plain text files.

RazerM 13y ago

This site doesn't work very well on mobile http://imgur.com/opmjUGn http://imgur.com/opmjUGn

guynamedloren 13y ago
Ah I know.. I've been meaning to fix that.
guynamedloren 13y ago
Fixed now btw.

AndrewDucker 13y ago

What I mostly want, when writing collaborative documents, isn't a git equivalent - it's a code-review equivalent. I want to leave comments on individual words, sentences, paragraphs, etc., with suggestions for changes. And that's something that git doesn't allow, because the smallest change you can comment on is a file, with no ability to comment on specific parts of it.

manish_gill 13y ago
You can usually do it with shared Google docs. I know a few writers who share their content with a few trusted betas. It provides the necessary features, I think. Highlights, commenting etc. I think there is also a "real-time" feature that it provides (not sure about that), so there is usually more than one eye on the doc as the chapter is being typed.
JeffJenkins 13y ago
If you're using google docs for your collaboration this sort of commenting is built in. It's a great feature. Almost better than collaborative editing
guynamedloren 13y ago
Git doesn't support it, but GitHub does. You can comment on individual lines via GitHub. I'm going to do something similar - maybe on a more granular level (words/sentences).
gamblor956 13y ago
It sounds like you're looking for Microsoft Word, which has offered this feature for more than a decade (albeit though not online until this past year).
cauthonLuck 13y ago
Latex has line comments and since it is compiled into a document you can place line breaks anywhere. It does break the flow of the sentence though. I've used Latex+vim+git to write scientific papers recently. It is unfortunately much too complicated for my colleagues to adopt. They're holding onto MS Word which is far inferior in terms of markup, citing, and VCS. I've been converting my Latex documents to ugly word documents for collaborating and editing. The MS Word editing isn't great either. The strikethrough method breaks up flow. I've also had problems deleting side comments in Libre office. And the MS Word experience isn't always the same on Macs.

begriffs 13y ago

I think the guys at Github do want to help non-technical people learn to collaborate with git in areas like education, government, and literature. Check out this interview where one of the Github trainers, Brent Beer, talks about these ideas. You might want to get in contact with him. http://blog.begriffs.com/2013/08/an-interview-with-brent-beer.html http://blog.begriffs.com/2013/08/an-interview-with-brent-bee...

guynamedloren 13y ago
> I think the guys at Github do want to help non-technical people learn to collaborate with git in areas like education, government, and literature Yep, they're doing it, just not quickly enough :) Neat, I'll check out the interview. Thanks!

nwhitehead 13y ago

An idea is to think about rendering/typesetting as a feature. For many, getting an environment set up to turn the project files into final files of whatever form is a huge barrier. It would be great to have a bunch of back-end rendering be just a click: Markdown->HTML, Markdown->PDF, Markdown->epub, Latex->PDF, Latex->HTML.

guynamedloren 13y ago
Already done
cauthonLuck 13y ago
especially when you throw in citations for scientific articles. Which often require compilation of the citation database, citation order, and citation insertion. Adding 3 more steps to the process. I've recently switched to papers to help with this. It seems to have a strong community and supports both MS word, libre office, and vim. Jury's still out though. http://www.papersapp.com/papers/ http://www.papersapp.com/papers/

GrinningFool 13y ago

Is this going to be focused on those who use latex and markdown, or the the broader audience of 'people who write'? If the latter, you run into a problem pretty quickly - MS Word. It's still one of the most popular document editing tools out there. More recent versions do store content in zipped XML, but are you willing to put the work into parsing that content at a level sufficient to let it integrate into the kind of flow you discuss? (EDIT: That said: if your target is those creating text-based documents, then I think this is an excellent idea. )

FiddlerClamp 13y ago

Have you asked a representative sample of writers whether they write this way, and would like to use your site to write this way? Outside of business, collaborative writing seems to be pretty minimal (I say this as a novelist)... Also, if there could be some cross-compatibility with MS Word's Track Changes (I know, I can dream...) that would be great.

frozenport 13y ago

We edit research quality publications on Bitbucket. So Git already works for writers.

chalst 13y ago

I'm familiar with similar workflows. Last week, I edited via a (private) Github repo with a scientist client who use Emacs/ org-mode/ ediff, authoring .org files, editing using Git staging to create change sets and inline \NB[]{} commands to annotate changes, and ediff/git-merge to step through and resolve changes. Some observations: 1.Ediff is a nice tool to use for resolving Git conflicts; 2. Org mode works very well with this workflow, provided you use one paragraph per Unix line; 3. Latex generation can be very nice from org-mode sources, and the org-mode -> Latex exporter allows a nicer separation of content from presentation than you get with vanilla Latex. I'd love to hear of anyone who has success with a similar, but vi-based workflow.

cauthonLuck 13y ago
I use a similar setup with vim+latex+git for chemistry articles. It works amazing for me. I feel like it is the most powerful presentation setup and most efficient editing setup currently available. I break sentences by ending with two spaces. (this doesn't matter since Latex is markup) The only issue arises when ideas span across multiple sentences, but I believe there is a flag for controlling the number of lines around a diff. (sorry, I'm new to git) But this sort of proves the point that an easy wrapper for git should be created for scientific writing. The two main problems I have are: 1. adoption by collaborators (they can't surmount the learning curve) 2. diffing sentences is very different from lines of code
- chalst 13y ago
  Typical Org-mode code diffs better than typical Latex code. This is a serious argument in favour of authoring in Org-mode and using its Latex export facility.

lizelfman 13y ago

As a writer I'd be glad to use something like this. I'm working on a book with the founder of a non-profit in DC, and it involves a lot of sharing articles, trading thoughts, and sending documents. We've been using Honey.is which is nice for small businesses but just not as collaborative as we need it to be.

deleted 13y ago

[deleted]

mallyvai 13y ago

From @kmatzen's comments on Authorea.com: " What do you get when you combine authors with gonorrhea? Authorea! I like it! There are two things I would still like though. One would be page rendering in the browser. We often have to iterate several times on a paper adjusting figures, text, padding, etc. to get everything to fit within the page limit. I could write the paper in this and then export it to tex, but that defeats the purpose. The second thing is support of popular LaTeX packages. It looks like I can upload arbitrary tex documents, but that's going to get messy if I have to upload the same packages for every paper I'm writing. We use github for our papers right now. Less than ideal. "

natejenkins 13y ago
What can I say? Naming is hard. We initially thought to ourselves, "Spreading science should be fun and intuitive, like an STD. And it should be hard to get rid of." Thus Authorea was born. Have you tried our pdf exporter to check page length? We are trying to build it out to where you, as a user, don't have to worry about packages. If there is a journal you would like to submit to and we don't currently have the journal setup as an export template, please contact us and we will be happy to add it. It's funny how authors worry so much about page length and figure placement, and then the first thing a journal does is remove all of the formatting the author has put in place.
apepe 13y ago
hi @kmatzen/@mallyvai! Adding briefly to Nate's comment (my co-founder at Authorea), I would like to point out that we do support many popular LaTeX packages. One big reason why we do not support custom LaTeX packages is that some of them are really intended for the printed page and cannot be easily ported to the web- and the point of Authorea is to create web-native documents, which render in the browser, first, and can then be ported to print formats. In other words, we support a safe subset of LaTeX which we can easily convert back and forth into other web formats (such as Markdown). Do let us know if you have a LaTeX package in mind and we will see if we can add it for you.

stared 13y ago

Take a look at "Why use version control systems for writing a paper" (http://academia.stackexchange.com/questions/5277/ http://academia.stackexchange.com/questions/5277/). When it comes to diffs for text, just add "--color-words": git diff HEAD~1 --color-words my_file.md But I agree with other stuff, that for non-techies Git + GitHub may be to hard to start.

diziet 13y ago

Do authors really collaborate as much as developers do? Wikipedia is an example of people collaborating on writing something, but the subject matter is quite different from the kinds of writing that gets done.

rrrene 13y ago

So I get the vibe that this will never be open sourced but is a side-project of yours that (should it come to fruition) will be run as for-profit. Am I right?

jedc 13y ago

Is it just me, or are there a number of fairly high-profile writing tools that have launched recently? The ones I'm thinking about: * Draft http://draftin.com * Editorially http://editorially.com * Quip http://quip.com * Loren's Penflip http://www.penflip.com * Google Docs (obviously not new) A lot of thoughts running through my head, including that finally products are being built from the ground up both for collaboration and for mobile/tablets. (And that this appears to be an early sign of the end of Microsoft's dominance in the office productivity software world.)

guynamedloren 13y ago
I'm on your 'high-profile' list! Made my day, thank you.
Myrmornis 13y ago
Are any of these projects aiming to interface well with MS Word or OpenOffice?
- sdoering 13y ago
  Well you could use pandoc [1] for creating MS Word or other file-formats. As far as I know MS Word is still the choice to use for novelists, when it comes to giving test to editors and a like. So pandoc could be used for transforming a text into many different formats (even ebook formats). Might be an interessting thing to look at for the creator of "git for writers" ;-) [1]: http://johnmacfarlane.net/pandoc/ http://johnmacfarlane.net/pandoc/

bambax 13y ago

This is a fantastic idea, beautiful and beautifully simple. Of course, one can think of a million objections to its success, but I really really hope it succeeds!

rrhoover 13y ago

Ironically, I posted a call to action to build a community for writing together. Very curious to see how Loren's project does and how it compares to Draft and others. https://medium.com/writers-on-writing/920214571e3d https://medium.com/writers-on-writing/920214571e3d

dylandrop 13y ago

This is interesting, but I think it kind of fails to take its audience into consideration. 1) It assumes writers write like programmers code. This isn't true. At least with scripts, what typically happens is the writer will write an entire script, send it to their boss for revisions, and then rewrite it. They would consider it a pain in the ass if they had to make "commits" for every page they wanted to add, and especially if their bosses had to review each change (mostly because bosses are executives who just want to leave their mark by making unnecessary changes on things). 2) In either book or script writing (or whatever) small grammatical changes are unimportant, and there will be way more of these than we would care to look at. Who cares about reverting a change of "its" to "it's"? I see this kind of thing as being useful for writing an informal, informational book in the form of an extended blog post (see http://gettingreal.37signals.com/ http://gettingreal.37signals.com/) but otherwise, I can't really see it being that useful for professional writers. Also, something that I think would be REALLY useful (that I'm honestly surprised I haven't seen is a Final Draft - meets - Google Docs (screenplays editable by multiple people via online, all stored online). Dunno if anyone's seen anything like this. Sources: My dad is a TV writer.

gcb0 13y ago
i try to get my SO to write academic essays in applications that have history or diff viewing... but never had any success. but that only means the current offerings are bad. even for programmers. regarding your points, when i set up `meld` to show the text she sent vs what her professor or coleague sent back, she is amazed. So there is usefulness. Second, have you ever used Kwrite in KDE? you don't have to commit or anything. just type. and it shows the diffs marks on the left. pretty hand. and avoid commits and all. about point #2, just make branches and tags more practical. Also, try to merge back those 'word fixes' in other branches ' heads. would be awesome even for programmers. source: optimist :)
baby 13y ago
Exactly. I don't care about the document progression or the changes of words. I just want "versions" and "notes". I actually did a writing application for myself only and I had two windows, one on the left with the actual text, one on the right with the notes, also a sidebar with the chapters and progression of the book.

agentultra 13y ago

Github for lawyers, laws, court records, etc. I wonder how the lobbying industry would change if there were highly-public records of everyone's additions to a bill.

thenerdfiles 13y ago

Just re-purpose git-flow with a "writing/publishing" namespace: https://github.com/nerdfiles/Concept-of-Flat-Design#adaptation-of-git-flow https://github.com/nerdfiles/Concept-of-Flat-Design#adaptati... master <-> publication develop <-> draft feature <-> chapter release <-> edition hotfix <-> redact support <-> copyright

based2 13y ago

Wooki* is a smart tool to write documents. It let you publish them and get reviews https://github.com/spreadthesource/wooki https://github.com/spreadthesource/wooki

malcolmmcc 13y ago

See also https://www.scigit.com/ https://www.scigit.com/

michaelbuddy 13y ago
link fails. no https on that site.
- malcolmmcc 13y ago
  huh, both work for me.

deleted 13y ago

[deleted]

guard-of-terra 13y ago

The idea is terrific but focus is all wrong. Writers don't need branches. They don't code features in. Hell, most developers don't do stupid updates-on-branch-then-merge-merge-suffer-merge-curse-merge commit accounting. Writers usually write alone, what they need is: A (desktop) tool with basic WYSIWYG markup (paragraphs, bold/italic, that sort of thing) with version control, visual diffs, export into common formats. Maybe a pull request or two.

cauthonLuck 13y ago
Scientific writers do need branches. When there are 10 authors on one paper all suggesting different paragraphs/figures/equations at different times.

decadentcactus 13y ago

This might be useful for contracts, as well. Editing points and having history, being able to comment on specific parts etc. Not 100% sure on how to solve the "legally binding" part if the other party declines digital signatures, but it'd be a good way to get the contract written and agreed on.

hyperpape 13y ago

I wonder if you might prefer something like Darcs to Git. I've heard a lot of amnbivalence about Darcs as a practical software project (just seems to be losing momentum, and it has never matched Git for speed), but I wonder if the model is more apt for writing than Git.

cauthonLuck 13y ago

How many of these options penflip, draft, etc are actually open source? I'm looking for very specific features on the level of Latex libraries that would never make it into a for profit application.

ozh 13y ago

I'm a little late in the party but I wanted to express my feelings anyway. I wrote a book with 2 other authors 2 years ago, and would have LOVED a tool like this. Going over Word documents in revision mode was a colorful nightmare. In general, having to work with Word was not the ideal stuff anyway. To my point: to be totally useful along the whole typical writing process with traditional publishers (authors -> technical review -> authors -> editor review -> authors -> punctuation/misc review -> authors -> editor) you'll need at some point to export as Word documents. Ideally, collaborate in Git like environment, export as Word, receive a new Word with all those colored revision and import into Git like stuff.

SunboX 13y ago

> What's so awesome about GitHub? It isn't all reasons mentioned in this article ... the most awesome about github are the developers. This is the biggest reasons why a "github for writers" could fail

victormier 13y ago

As I was reading all these words about project collaboration I started getting more and more excited about the thought of myself collaborating in your project. Until I saw it was not open sourced...

dbspin 13y ago

Can't emphasise enough how important offline editing would be for something like this. As a professional writer (whose co-written a book), you can't rely on always having internet; but you always need to be able to work on your current project.

user1241320 13y ago

I thought https://poetica.com/ https://poetica.com/ was doing just this

theorique 13y ago

Github works on source code, which is text files. Writers work on English text (or other languages) which is text files. What does this do that Github itself (or equivalent - bitbucket, etc) does not?

albertoperdomo 13y ago

Just a heads up: I just tried to signup for the newsletter and got a nasty Rails error page (500). It turns out Iwas browsing with JS turned off (using NoScript). It worked fine after activating JS.