When I hear "writer", I think of a screenwriter, novelist, or poet of some sort. "Github for writers" is misleading, since I think the people who would use this wouldn't be writers, but rather technical people who collaboratively write things. This is cool, given its audience is people who write blogs or possibly research papers.
I think you showed this (or the premise of this idea) on HN a month ago or so. It still has the same problems as it does then... IF your core audience is still writers as defined above.
1) Writers write in revisions, and don't like to have every word they change critiqued by their editors/producers/etc.
2) Writers don't like markdown -- they want WYSIWYG. This feature alone makes me feel like your goal was to make this tool for technical people.
3) I think a lot of meaningless changes would get jumbled up in the mix if you're writing something long. If you're writing a novel, it would be nice to go between different versions of the novel, but perhaps a bit too much if you had a commit for every punctuation mark.
This being said, I'm sort of interested what you think your audience should be. I think it could be a good tool given the right circumstances.
Novel writer here (unpublished but I've written several books, writing my next one in a month).
The site looks intriguing but yeah, I agree with your points:
1. I do write in revisions. Smaller changes don't matter as much when it comes to the end product. However, what I WOULD love to see is a previous copy on the right of the screen and a text editor on the left. I tend to do my revisions that way so that I can look at what I wrote, copy/paste what's fine, and rewrite what needs to be rewritten while still looking at the original.
2. After trying out a million "distraction free" writers, I am still on MS Office. It's really worth it for me. I can't stand writing in Libre, or OO, or Ohm, or Monkey (whatever it's called). Scrivener may be the only exception but I usually just port my stuff there.
3. Exactly
Here are the things I do like:
1. chapter by chapter separation of concerns. I like that. Even if it's in the form of text files, it's great.
2. one-click publishing. I really appreciate that. It's a pain to go from Word to a properly formatted PUB file. Having a tool that does this for you from the get-go is awesome. I've spent way too much time reformatting Word to be accepted by Smashwords in the past.
3. Comments. I enjoy this as well. If I had someone to help me out with my book, this would be a great feature. If I was to hire someone to help me out with editing and critiquing my work, I'd use this tool. Definitely would.
With that said, I would abuse the hell out of this for blog writing.
> 2. After trying out a million "distraction free" writers, I am still on MS Office. It's really worth it for me. I can't stand writing in Libre, or OO, or Ohm, or Monkey (whatever it's called). Scrivener may be the only exception but I usually just port my stuff there.
Just curious: Have you tried AbiWord? Arguably it shares a lot of the good parts of its interface with MS word -- If you have I'd love to hear what you (dis)like about it (and how Word is better or just as bad). No affiliation with AbiWord - just curious.
Personally I write too little at present, but when I do write, I write in vim, either in plain text or in some variation of ReStructuredText. I very much prefer to keep writing and formatting separate, starting with an outline of headings+notes, and expanding section by section. I've never attempted anything beyond essay-length, though.
Have you looked at Draft (draftin.com)? It has the side-by-side revisions you mentioned (all your revisions ever, in fact). I'm not sure about the other features you mentioned.
Agreed. At the same time though, it's annoying to have to categorize every change. I think it would be better to maybe split the service between blog writers / screen writers / novel writers, since each would have their own preference. I think novelists would prefer having a versioning system for broad changes rather than tiny ones.. And not have to categorize them.
Yeah, I might be late to the party here, but... I signed up for penflip two and a half hours ago and have received eight emails from you guys since then. This is not cool. I don't care if they're notifications. Auto-on is a terrible default from a user experience stand point in this case.
Edit: Also, I can't easily find where to turn them on or off, and if its available I'm having difficulty figuring out how to delete my account.
Edit 2: Done being blinded email rage, I located the notifications control panel which is relatively obvious (so facepalm for me there), however, having searched the site it does not appear as easy to delete my account altogether.
Hey there, sorry about this. I'm the guy building Penflip. It's still in alpha and was not ready to be shared with a larger audience. The email notifications for discussions were helpful for the smaller alpha group that I was/am currently testing with.
Just a quick update - I've disabled all email notifications from the alpha project (the source of these notifications). No more emails should be sent out. Again, very sorry about that. Rough day.
quick reply to feedback, that's what we appreciate, thank you for this!
Just my 2 cents:
* Why can't I use "," in my project name? My book is titled "Je sais ce que je fais, du moins je pense" but I had to replace the , by a .
* Fiction? My book is not really a fiction book, more of an autobiography.
* Edit to add/create files? I know you want to make it like git/svn but this is counter-intuitive (or maybe I missed something here?)
also. I might not be the best writer, but this is how I work : I have one folder for each big "chapters" that has several chapter_x.txt. And each chapter has a chapter_x_notes.txt with notes about the chapter I'm writing.
I wrote a small javascript/php client that reads my txt and display them like Emacs/Sublime Text 2 buffers and display my work on the left and the appropriate notes on the right. Because I really think that it's important to have a guideline at all moment when you're writing something.
For example :
+ china
- chapter 1 - first steps.txt
- chapter 1 - notes.txt
- chapter 2 - first meal.txt
- chapter 2 - notes.txt
+ france
- chapter 3 - paris.txt
- chapter 3 - notes.txt
etc...
* my connection crashed during a save, when I got my connection back the save wouldn't finish. I guess there is a timeout but then it should cancel the save and let me continue it when the connection comes back. I hope I make sense.
* for something as important as a book, I'm really scared doing that on an external website. I normally write on ST3 locally + dropbox for backup. I know I can download the thing on .epub,.pdf,.html etc... but I want to be able to download it in a way I can import it back to your application in case something goes wrong or I want to clone the project.
* I can't delete a file I'm currently editing
* When a filename is too long the bin icon when you hover it in the list of files on the left is overlaping with the name
* in my resolution, which is quite small, it doesn't scale very well, especially when I display the file tree on the left.
* Really need folders on this file tree.
* When editing a project, the only way to go back to its index page is to click on its name in the file tree. Not very clear. A breadcrumbs system would be nicer to tell you at least what project you're editing.
* Also I know this might be too much and too much of a fancy feature, but importing a folder (like the example three I gave you) would be very nice. I have to copy/paste all my .txt now
Hi everyone, I'm the guy building Penflip. Apologies for the load of emails and rough edges - Penflip actually still in alpha, and is not quite ready for the primetime.
The interface is incredibly well-done. Great job on that.
I would ask to see more information before providing my sign-up information, though. Speaking of which, it seems obvious to just let users sign in with their GitHub information.
Other than the scrollbar, there's no indication on the front page that you can scroll down to see more.
Requiring signup is a huge barrier to entry for me. I don't want to give a website my email until I have a clear sense of what their value proposition is. In other words, the more I can do without signing up, the more likely I am to see the value and eventually become a registered user, paying customer, and recommend the service to others.
With Github, for example, I lurked for months before joining. Usually browsing and cloning public projets.
Letting your users see real projects that people are working on (even ones that have voluntarily become public) is a plus.
Also, I think that, since you're targeting a market that's not already familiar with Git, your marketing should focus specifically on the value that Git-enabled workflows can provide. Explain how a reader can send you a pull request with a grammar fix, how you can easily merge changes from multiple contributors, how you can attribute each line to a specific person.
> Also, I think that, since you're targeting a market that's not already familiar with Git, your marketing should focus specifically on the value that Git-enabled workflows can provide.
This is a bit of a challenge, as there's a balance between tech and non-tech. It's possible that these explanations could be overwhelmingly confusing for a large number of (potential) users. I think a video would be the best way to explain concepts like this, which I intend to have eventually.
My humble suggestions to any service/product you introduce, even to beta testers, is to quote a price or an inkling of the upcoming pricing slabs. If there will be a free version with limited features, do mention that. For instance, I know Trello and Evernote will always have a free version which is good enough to a large extend and they promised that. I'm on Evernote Premium out of love though I still do not need the premium features. So is the same with Trello (few people were generous enough to sign-up through my links).
Without a price that I can calculate for continued future usage, I'm very reluctant to "get used-to" a particular app/service/product.
These days, if I like a product/service/site, and cannot find a price tag, I email the founders asking for an idea. Many do reply but it gets irritating that I have to do this quite often.
I do understand the marketing temptations and tricks of getting more users with "free trials". However, if your price in future is not affordable, then I'm going to be sad, irritated and may even hate you. Please don't let your customers hate you. It should be pretty OK to avoid customers from the beginning, who may not be ready to pay the price you quote than to promise them something and charge them another in future.
Thanks for bringing this up. I completely agree. Penflip is actually still in alpha, and wasn't quite ready to be shared with a larger audience. I was planning on posting HN with beta, which would include pricing.
Anyway, just so you know: the pricing model will be similar to github: free for open source / public projects, small monthly fee for private projects ($5+ a month depending on number of projects).
Unsolicited advice, but: I'm not sure that's the best business model for a tool aimed at writers. Github's model succeeded because there was already a thriving community of people contributing open-source work; with writing, most FOSS licenses don't make sense for the way that the content is consumed, and there isn't much of a pre-existing community built up around it that you can lean on. Most importantly, though, and unlike OSS, even people who publish in the public domain generally don't write drafts in it: they release articles and stories when they're finished.
I'd try to structure your business model more along the lines of behavior that people already have. Some ideas off the top of my head:
1. Notebooks. All writers are intimately familiar with the concept, and having separate notebooks is a useful organizational tool. First notebook's free, and you can pay for the rest.
2. Blogging. You can have one private working document at a time, and unlimited number of public blog posts. The private document is important — no one wants to publish half-finished. Want more working documents? Pay up.
3. Collaborators. You can collaborate with one person for free; if you want multiple collaborators, you have to pay.
I'm sure you can come up with others. My point just is: structure your company around your customers.
On your first two points, this is not too far off from what GitHub does (and what I plan on doing) - the main difference is the nomenclature. You call them notebooks/blogs/documents, I call them projects, GitHub calls them repositories. The model is the same, though. FWIW, I'm calling them 'projects' because it's confusing to have multiple names for essentially the same thing.
The "first one's free" concept is interesting, and something I'm considering. However, I'm not entirely sure I agree with 'no one wants to publish half-finished' - Leanpub (http://www.leanpub.com) is built on this concept, and seems to be successful. Another argument is for open source and community-driven projects [1], which could be considered to be always in an unfinished state.
Im not sure you've necessarily cracked the code, but I applaud the effort to get sane version control and collaboration into other aspects of work.
Compared to the elegant and bullet proof code versioning with git, adding v_2013_1026_1300 to the end of file names in powerpoint, word, and excel just feels barbaric.
How am I supposed to create new pages for a "book" project? Also, when I created a new document, it took me a while to understand that I was supposed to edit/delete the text in the current document to begin writing. (In that instance, I was also looking for a "new document" button.)
I don't want to do writing using a web interface. I think a desktop client would make a service like this far more attractive. However, I think it would be a bit of a hard sell because of the slight learning curve. I think you need to demonstrate Penflip's value proposition by providing actual use cases for such an app.
Otherwise, your app looks very slick and quite promising.
If you're comfortable with git, you can clone the project and work on your own computer, like you would with any git repository. If you have the GitHub app on your computer, you can use that for Penflip projects as well:
What's wrong with Markdown? How could it be improved so less technical people will be more comfortable with it?
I always thought that Markdown was about as user-friendly as such a thing could get, since it was based on the ad-hoc conventions people have developed over the years for email.
It looks a lot like the prose.io interface. I like prose.io, but the huge problem with the browser editor is that there's no on-going autosave, so for example, accidental backspaces can wipe out all the work you've done since the last commit. Haven't checked out penflip yet, but I hope it doesn't make the same mistake.
If I'm doing something collaboratively, I'll either use a DVCS or meet with people in person. Or hack something together via Google Docs. (OK, I'm starting to see how this could be useful).
That said, I use Draft on a daily basis and it's awesome.
A suggestion to Author: I signed-up yesterday. The UI and the way it works is okay, with one exception. I get 8 mails from loren@penflip.com. 8 e-mails? Seriously? Reduce the count, and send emails if someone subscribed to them(explicitly)
As a writer for digital media, I use MS Word. Need to write without being online. And I send my file to editorial team to merge (with images and other writers work) and convert to web page format.
Love this. Actually working on something similar ('GitHub for storytellers') as my first Rails project. I have to learn a lot more to get mine even presentable, though.
There's a footer, but with 'infinite scroll', it's impossible to access. (Other than that, looks great so far - just a quick bit of constructive criticism!)
I write in LaTeX and version control with Github. Pretty efficient, considering that losing one's work is always the biggest fear. My commit messages are my word count.
I've a pet project http://mdocs.io aims to be closer to gdocs for markdown. We use operational transformations for realtime editing and we allow connecting Google Apps domains so you can share to everyone in company and so on. The Interface needs more work . it is open source.
Why not just keep your files in git? Use a git GUI if the command line is intimidating to writers. That way you don't have to create a brand new writing tool. I keep scrivener files in git, it works great.
Git is certainly capable of this, but I don't think that makes a service like Penflip that focuses specifically on collaborative writing superfluous.
I like to code and I like to write, but I'd be much more likely to put a Rails app on Github than, say, a short story on which I'd like to collaborate. It's not that Github can't be used as an effective tool for collaborative writing, but rather, that it isn't really the place for it.
I have a lot better chance of social interaction around code on Github versus writing because the primary social object on Github is code.
There is no question that good writing exists on Github and that it shines for particular forms of writing, but the dearth of writers to coders there seems to signify that a service like Penflip has a market that could be better served.
That's a good point, I hadn't considered the collaboration aspect. Out of curiosity, what kind of projects require this? I suppose a book with multiple authors is one good example, are there others?
> Why not just keep your files in git? Use a git GUI if the command line is intimidating to writers. That way you don't have to create a brand new writing tool.
That's exactly what Penflip is. All projects are backed by git repositories, so you can clone them and work on them locally just like you would with any git repository. The web interface is really just a GUI for git.
I think you showed this (or the premise of this idea) on HN a month ago or so. It still has the same problems as it does then... IF your core audience is still writers as defined above.
1) Writers write in revisions, and don't like to have every word they change critiqued by their editors/producers/etc.
2) Writers don't like markdown -- they want WYSIWYG. This feature alone makes me feel like your goal was to make this tool for technical people.
3) I think a lot of meaningless changes would get jumbled up in the mix if you're writing something long. If you're writing a novel, it would be nice to go between different versions of the novel, but perhaps a bit too much if you had a commit for every punctuation mark.
This being said, I'm sort of interested what you think your audience should be. I think it could be a good tool given the right circumstances.