If Google docs is an alternative to Word, then this is an alternative to Sharepoint.
As opposed to collaborative document authoring, collaborative knowledge management allows things like collaborative document arrangement, a better permission system, links between documents, better searchability and more.
Indeed. Google Docs suffers a lot from discoverability and, while you can collaboratively edit on it, it feels too much like a locked down blob of content and so suffers from a lot of the same problems that Word suffers from (in my experience with it at least): it's hard to know when it's changed; when someone updates it, you get an email; when someone writes something, they have to "share" it with with you before you know it exists; WYSIWYG is a terrible way of editing content.
I'm not sure how many of these problems this solves, but Wikis in general solve many of them.
SharePoint dev here. I fully realize that SharePoint is not the greatest platform out there on a number of counts; but I can't really see this as being anything close to an alternative to SharePoint. It would definitely serve as a HUGE upgrade to its native Wiki functionality, however.
Very neat! I have thought quite a bit about how to make wikis easier to work with, but I don't know if I'll need to anymore because you pretty much nailed it! Real-time markdown editing is a great idea.
A few things:
* Making an ordered list right after an unordered one and vice versa doesn't render properly.
* New pages always become children of the first page, and I don't know how to turn them into root pages or make them in the first place.
* Signing out doesn't work.
* Clicking away while editing a page title doesn't save it.
* Public links and history are on top of my wishlist for this.
This would be very popular indeed if a WYSIWYG editor was used instead of a markup language.
There has been study after study showing how the wiki markup syntax is a hurdle to participation on wikipedia, to the point where wikipedia is now finally, after 12 years, working on a wysiwyg editor: http://techcrunch.com/2012/06/21/jimmy-wales-on-new-editing-...
There are so many free and open source wysiwyg editors that can be easily plugged into a site: aloha, tinymce, ckeditor, etc.
At some point around 2005 there were talks on the web about [WYSIWYM][1] editor. It hasn't widely taken off yet. Or maybe markdown simply meets those needs.
This is a very naive view of reality. WYSIWYG editors are superior in almost every way for almost all users. I used to force markdown on people too, but WYSIWYG is really a killer feature for most users. It requires far less learning, the features are more discoverable, it's quicker to edit even after they manage to become proficient with markdown, and there is no mental translation from what they're editing to what it's going to look like. But also other features that you might not immediately think of are very important, such as the ability to copy-paste from their existing word processor documents and preserve markup. Editing rich text with a plain text editor rather than a rich text editor is to most people like editing your photos with a hex editor instead of Photoshop is to you: not the right tool for the job, unpleasant, slow, requires learning, requires mental translation, and can't easily copy paste from existing material.
It is comparable to the difference between digital cameras and film cameras. I see results sooner.
Sure, I can take good film pictures if I know the lighting conditions, shutter settings, business about f-stops but being able to see how you failed sooner is a big plus.
A really simple editor that only had the formatting options allowed by markdown would be functionally equivalent, and the great unwashed would find it much easier to use.
Wikipedia has been working on a WYSIWYG editor for as long as I can remember, it's just that creating one for a markup syntax as convoluted as MediaWiki's (with templates, Turing-complete parser logic etc) has been near-impossible until recently.
I like how Tumblr does it. Tumblr defaults to a WYSIWYG editor, but you can switch it to accept Markdown if you prefer. (The API also accepts Markdown or sanitized HTML)
Oh man -- this almost fits a perfectly for me. I just wish that reStructured text was supported, but I could live with markdown. Yeah, I'm old-school.
It would be awesome if this service supported dropbox and stored all files there -- using a simple directory structure. This would allow me to edit my files using VIM during the day, and I'd have a super easy search UI.
I currently keep daily notes on dropbox using rst files (one per day) -- so this would fit my workflow perfectly.
Hmm - why would the document structure difficult to map to a filesystem structure? Just map every document type to a folder, and the contents of the documents to individual files in the folder.
The concept isn't much different, but the permission model is. document.ly is very similar to Asana and Trello (allowing every user to participate in multiple projects and inviting anyone in the world to view and edit any document), while Hackpad aims for a standard B2B marketing strategy.
When I signed out of the application it didn't forward me to a logged-out verification page or give me a model that tells me I've signed out. It kind of just hung there without letting me edit anymore. When I sign out I like a very robust verification that tells me I've signed out. It looks great regardless.
Is this going to be freeium? I really recommend putting a pricing page up even if you don't know what the pricing will be, just to make it clear... hard to even try something (and I want to b/c it looks very useful) without knowing that important detail.
I've been seeing demos of this sort of thing since 2003 and yet no real-time collaborative editor has actually caught on. Does anyone have any intuition as to why? I'm baffled - it sounds like a good idea to me.
53 comments
[ 3.0 ms ] story [ 133 ms ] threadAs opposed to collaborative document authoring, collaborative knowledge management allows things like collaborative document arrangement, a better permission system, links between documents, better searchability and more.
I'm not sure how many of these problems this solves, but Wikis in general solve many of them.
This application is temporarily over its serving quota. Please try again later.
JS console shows:
http://requirejs.org/docs/errors.html#timeoutA few things:
* Making an ordered list right after an unordered one and vice versa doesn't render properly.
* New pages always become children of the first page, and I don't know how to turn them into root pages or make them in the first place.
* Signing out doesn't work.
* Clicking away while editing a page title doesn't save it.
* Public links and history are on top of my wishlist for this.
There has been study after study showing how the wiki markup syntax is a hurdle to participation on wikipedia, to the point where wikipedia is now finally, after 12 years, working on a wysiwyg editor: http://techcrunch.com/2012/06/21/jimmy-wales-on-new-editing-...
There are so many free and open source wysiwyg editors that can be easily plugged into a site: aloha, tinymce, ckeditor, etc.
[1] http://imperavi.com/redactor/
[1]: http://en.wikipedia.org/wiki/WYSIWYM
Sure, I can take good film pictures if I know the lighting conditions, shutter settings, business about f-stops but being able to see how you failed sooner is a big plus.
A really simple editor that only had the formatting options allowed by markdown would be functionally equivalent, and the great unwashed would find it much easier to use.
In any case, it doesn't load well because it loads a lot of Javascript asynchronously (no production version yet). Just refresh it.
It would be awesome if this service supported dropbox and stored all files there -- using a simple directory structure. This would allow me to edit my files using VIM during the day, and I'd have a super easy search UI.
I currently keep daily notes on dropbox using rst files (one per day) -- so this would fit my workflow perfectly.
The service should support Dropbox eventually, but the structure of the documents is kind of a problem to arrange as a set of files and folders.
Also, sharing a document with someone else seems to throw an exception when they try to sign in...
Error: Server Error
The server encountered an error and could not complete your request.
If the problem persists, please report your problem and mention this error message and the query that caused it.
What's the business model? I would be sad to see this acquihired and disappear in a puff of smoke.