Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Real-time Wiki

document.ly

Post reply on HN
Print view View original

21–30 of 54 posts

Re: Show HN: Real-time Wiki

#23

Post by bengillies »

ronreiter wrote: post #5
tarr11 wrote: post #2

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.

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.

Re: Show HN: Real-time Wiki

#24

Post by johnchristopher »

alexchamberlain wrote: post #19
edtechdev wrote: post #12

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 ca…

We really need to get people out of the habit of using WYSIWYG editors.

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

Re: Show HN: Real-time Wiki

#25

Post by seletz »

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.

Re: Show HN: Real-time Wiki

#26

Post by ronreiter »

luchs wrote: post #22

I get an exception in Opera: Uncaught exception: document.body is not defined -- do not create socket from script in .

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.

Re: Show HN: Real-time Wiki

#27

Post by ronreiter »

seletz wrote: post #25

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…

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.

Re: Show HN: Real-time Wiki

#28

Post by seletz »

ronreiter wrote: post #27
seletz wrote: post #25

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…

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.

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.
Post reply on HN