Show HN: Real-time Wiki(document.ly)
document.ly
Show HN: Real-time Wiki
http://document.ly
21 comments
But it's Markdown instead of MediaWiki syntax. Markdown's got a lot of momentum right now, and for good reason.
We really need to get people out of the habit of using WYSIWYG editors.
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.
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.
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.
[1]: http://en.wikipedia.org/wiki/WYSIWYM
[1]: http://en.wikipedia.org/wiki/WYSIWYM
Why? Garish formatting?
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.
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.
My primary reason is version control. It's much easier to diff text files.
Just stick them on reddit and they will learn markdown in a few weeks!
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)
I agree - the purpose of this product is to check if the overall concept is needed. And if so, I will invest in making it a WYSIWYG editor.
And none of them work on mobile.
I just found Redactor [1] that works fine on Android 4.0, so I redact my comment.
[1] http://imperavi.com/redactor/
[1] http://imperavi.com/redactor/
Works on IOS, too. Quite a nice piece of code.
Got past over-quota issue and gave google permissions, but Chrome OSX shows nothing when you login.
JS console shows:
JS console shows:
Uncaught ReferenceError: goog is not defined socket.js:43
Uncaught Error: Load timeout for modules: text!templates/context_menu.html require.js:26[deleted]
Can you explain how this is different / better than Google Docs? I can't tell from the home page.
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.
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.
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.
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.
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.
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.
Thanks!!!
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.
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.
Sounds like this would be a good software for you: http://lurst.github.com/Pendium/
reStructured text will be eventually supported if people will like document.ly's workflow scheme.
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.
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.
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.
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.
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.
The export feature would be really awesome if it could handle larger documents!
Also, sharing a document with someone else seems to throw an exception when they try to sign in...
Also, sharing a document with someone else seems to throw an exception when they try to sign in...
I get an exception in Opera:
Uncaught exception: document.body is not defined -- do not create socket from script in <head>.I actually did not check it on Opera. Will check. Thanks!
In any case, it doesn't load well because it loads a lot of Javascript asynchronously (no production version yet). Just refresh it.
In any case, it doesn't load well because it loads a lot of Javascript asynchronously (no production version yet). Just refresh it.
Also see Etherpad, ShareJS and Hackpad
I love how you improved over bootstrap to create nice and very aesthetically pleasing design.
Very cool design and concept. I loved how you used Bootstrap for this.
How might this compare with HackPad?
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.
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.