It's like a less elegant version of Jade.
282 karma · joined October 6, 2011
We released something built on the same stack (jade, stylus, coffeescript) that's a bit more lightweight, more geared towards building prototypes called [proto](https://github.com/droptype/proto). Because it's focused on building small prototypes, it saves everything to gists and provides a viewer at http://proto.es/{gist-id}.
Droptype wasn't much more than that. It used Dropbox's then-new revised API to look at Dropbox/Apps/Droptype and then displayed any Markdown files as a list. If you added a README file, it would render the contents of that. It was a quick and dirty Django app.
There wasn't any control over the design or any web-based editing capabilities. Others are doing interesting stuff in that space, most notably http://scriptogr.am/ which is probably a lot like where Marquee would have ended up if we continued to go keep going down that route. They're doing a very nice job with it though.
That said, we're looking at Dropbox/GitHub integration as more of a feature than a product. We're approaching the problem space from a somewhat different direction; the focus on our authoring environment is the first step to getting there.
I think of HTML as an output format more than anything else. LaTeX, while powerful, is terrible for reading what you've authored. That's why Markdown is so appealing, it's a semantic syntax rather than markup; it's easy to write, easy to read, and has the added benefit of being programmatically processed.
Kudos for not reducing this to a vim/emacs flamewar.
Mou has become essential. Donated $50, worth every penny and then some.
- You're absolutely right, we definitely need more error feedback.
- We're planning on writing a Markdown tutorial on site and building a browser-based editor (based on Ace, most likely). Will take this under advisement.
- I need to test with more variety of profile images. I held back on doing this until I could abstract away the entire image handling code.
- We wrote all the text files on a Mac so we're probably seeing some problems with Windows vs. *nix line-endings. I'll address this tomorrow.
- You're not the first person to be confused about how we're handling publishing, so we'll address this in a UI update.
- In terms of publishing images, we want to be able to process more than just text files in your Dropbox, so eventually you'll be able to relatively link to images instead of having to host them somewhere else. Our browser-based editor will let you browse your Dropbox and select images.
- We do support custom titles (and summaries) using the MultiMarkdown formatting syntax. Just make the first line of your text file look like this:
Title: The title I want
Summary: A summary of my text file
---
Again, thanks for the feedback and I hope you can give it another go once we make a few tweaks. I really appreciate you input.
Again, it's still very early and this is more to prove that the idea is doable, but we'd love to hear any input. We're working on some commonly requested features like customized designs, cname redirection, rss feeds. The idea is to have a very hacker friendly publishing tool that doesn't require very much work to set up.
On to your questions:
1. Like I said, delivery of prettified plain text was a problem we were having. The process of going from Markdown'ed text to something you can send to, say, a client, is a complete PITA (read: I want to punch LaTeX in the face). On a macro scale, it's still way too hard for people who are good writers to focus on writing when there's all this other stuff they need to do to just get their words out there (find a publisher, set up their own site, etc).
2. Absolutely nothing, but that's true of just about anything. We built the app in a matter of weeks and I suppose someone could release an open source version. If some intrepid writer is able to set up their own server, install the software, and configure everything themselves, well they're not really our target market anyways. There's not a lot of magic here; you can probably figure out the basics of how this works fairly easily. By that logic, why use Dropbox if SparkleShare is like right there.
3. The sale of content and additional features for people that take the service seriously will be our main revenue drivers. We're taking the eBook thing very seriously and are imagining a marketplace where you could buy access to content and have it available, in different formats, on all your devices. The content on your Dropbox will be considered the canonical source; we simply would create optimized experiences and provide the transactional marketplace on top of that. We've run the numbers and even if we capture a statistically insignificant marketshare, we're living a pretty good life doing interesting work. You might be absolutely right, that's probably not the scale YC was looking for.
I appreciate the bluntness and the time you took to put together your thoughts. They are incredibly appreciated. We're actively working on development and want to make sure things like themes are properly implemented in a way that is a.) flexible for our future plans and b.) geek friendly.
Again, thanks a bunch. We're just trying to build something cool and your thoughts are very welcome.
Our hope is that by having a pretty flexible data storage format (plain text), we can concern ourselves with laying out the content in an optimized manner for any device that might like to access it. By eventually outputting to ePub, responsive HTML/CSS, KF8, we hope to allow writers to write once and let us handle putting it in formats that would make it available everywhere.
Also, 100% agree with you on authors not understanding plain-text and Markdown. These are at the forefront right now because the product is rough enough where the only people that will get it are people that understand these things. To build something your average writer will want to use, we're going to need to provide a soup to nuts experience, but one that respects the content creator and keeps them in control of their content.
We want to do syncing of images, video, and audio. It would be nice to be able to construct a well designed page by dropping assets (text files, images, other media) into a directory in Dropbox and having Droptype automagically arrange those items.
Any other genres you can think of that might be a good fit?
1. Control over their own content. That's why we liked the idea of building on Dropbox and using plain text. No lock in, everything you write is always on your machine.
2. We've worked out revenue numbers, and if we can provide a simple way to publish and consume ebooks that takes up a tenth of one percent of the market not currently owned by Amazon, Apple, and BN; well, that's more money than I could ever spend.
3. Dropbox can definitely do it; but I don't see how it's in their interest. I'd imagine their newly launched API was developed in hopes of having people like us build things on their platform. They've build a great hard drive in the sky, I don't think that people should fear to build on that any more than people should have feared building on top of traditional hardware.
From what we discussed, publishing on the web isn't easy if you're a writer who doesn't have an interest in blogging. We don't want to for people away from the tools available on their computer that they're comfortable with and we don't want you to have to know how to set up a web site (Wordpress, while great, is a PITA to set up for non-technical users).
We're hoping by providing ways for authors to broadcast their content and the tools to analyze traffic, they'll be able to bring their own readers in. Once we have some people writing, we can better enable discovery of new content.
Our monetization strategy is focused on providing writers with the tools for selling their content and then building a solid reading experience on top of that content.