Slashdot Mirror

Many years ago, I started taking all my 'text-editor-alike' notes, setup up a wiki (dokuwiki plug, but there's definitely others like Mediawiki, ect.) and added a bit of light wiki markup to them equaled instant, half-ass-looking pro-like documentation with an authentication/group control wrapper around it (e.g. local accounts or AD/LDAP tie-in).

I don't know what organization you are in or what you can/cannot setup on a whim --- but that's what I'd do. It's SUPER cool to hear you actually care about documentation and daily note taking, ect., but the step beyond IMHO is a searchable and share-able interface to it.

And even taking documentation with you is a cinch --- I just recently changed jobs and I was able to take 8+ years worth of documentation/notes/you-name-it that wasn't company specific or had a NDA attached to it, tarball it up, set up a new wiki, unpack it and I was done.

At most if you really hate the wiki, just write a few reg-ex commands to mostly strip off your markup business and you're left with what you've started: ASCII text files again.

I'm not sure using a wiki is really the answer but if you insist then try Dokuwiki. It doesn't get much simpler on the end user side when it comes to using a Wiki.
https://www.dokuwiki.org/dokuw...

I used to use organized .txt files but switched to DokuWiki.

https://www.dokuwiki.org/dokuw...

Now I can access notes from all of my devices and share them easily with associates as well.

I tried Evernote, MediaWiki, Atlassian's Confluence and a ton of other options but DokuWiki is the only solution I have found that makes managing a notebook easy, fast and enjoyable.

No.

This is correct. Mod parent up. No disrespect to HTML5, but it is not going to play any key role for "authorship," (which is, although beside the point, absolutely the incorrect term for the query; "publishing and distribution" is what is meant and what should have been used).

I respectfully disagree, though not with all of what parent post is suggesting.

Creative writing is best done in a simple text editor where there is no style and the author/revisionist wrestles with his muse in an empty and barren arena. No witnesses to the bloody mess, and no distractions from the work at hand. WYSIWYG is a terrible distraction when trying to birth some new text into the world.

That said, the whole point of writing is to get one's words in front of some reader somewhere who will pick up on what the writer laid down. Making the raw final draft presentable is what publishing is all about. This is where HTML5 and CSS3 come into play. These technologies have nothing to do with the writing process but they can be necessary and sufficient for converting the writing into something that is readable. And they enable self-publishing in a much easier way, and to a much wider audience, than any other approach. But they do this work behind the scenes.

By far the easiest way to self-publish one's own creative writing is to do the writing in plaintext in a text editor, then copy-paste it into the input field of a good wiki engine. Make a "final" pass with the wiki editor to add the italics, bullets, and other stylistic stuff, and you are self-published on the web, with a potential audience of billions of readers. You will want to use one of the wikis that provides access controls, so that you can determine who can make changes to your work, but there a lot of wikis that support access control lists. You won't have an easy way to monetize the work, but hey nobody starts writing for the money. And maybe you could sell tee shirts or something from your web pages.

Where the HTML5 and the CSS3 come in is in the Javascript, PHP, and style sheets that you can use to adjust the way the wiki engine works. Of course you need an HTML5/CSS3 compliant wiki engine, but all of them are headed that way. Dokuwiki is my personal favorite: fully HTML5 and CSS3 compliant, and I found it easy to develop my own template, adequate for my book.

An example of a novel in progress is my work Artie Wood and his Electric Flying Machine. I could not do this any other way.

1. Blog your progress. Whatever you did today, blog it. Let people know what you did that worked, or what was faster (Nginx vs. Apache), or what wasn't (ColdFusion?). Don't reinvent the wheel, use WordPress, regardless of whether you like PHP/MySQL or not.

2. Use a subscription/payment management company. You're just a small group of nerds, not accounts receivable clerks. Fastspring, Plimus are free; Chargify, Subsify, Cheddar Getter, BrainTree, Spreedly charge; and Zuora is expensive.

3. Use Google Docs and Slideshare to share documents.

4. Chat. Don't just rely on email. Emails can often read like "this way or the highway". Be collaborative. You can often accomplish more with 15-30min collaboratively as opposed to composing and responding to long emails. Skype, Jabber, SIP

5. Take notes on what you did. Made a server configuration or a setting change in your CMS, your compiler, or whatever? Copy and paste from xterm so you don't have to guess about those commandline switches next time. Take screenshots and make them available to others. Zim, Projly, DokuWiki.

6. Have a phone numbers. If not bog-standard landline phones, take advantage of Google Voice and SkypeOut and SkypeIn (people can call your Skype line on a normal phone number). I realize Google Voice might not be available in South Africa yet.

7. Someone mentioned version control. Use git if you're a cool kid. Or svn if you're old and busted. Read the RedBean book. I've had success in having non-tech colleagues using graphical clients like TortoiseSVN (integrates into Windows Explorer).

8. Write tests. Any member of your team, sitting anyplace, should be able to push a button and run all your tests. Tests document how you're supposed to use a given method, class, etc., especially valuable when you're so far flung. Use JUnit, PHPUnit, FooUnit for your language. Write the tests before you develop, and you're doing Test Driven Development.

9. If you're writing tests, that implies loose coupling, which might require dependency injection. Can be difficult to climb that mountain, but it's worth it when you can just run a test and be sure your project works.

10. Development processes: Scrum, Extreme Programming. UML lets you communicate graphically about objects.

If you collaborate on documents I would seriously consider a wiki - http://www.dokuwiki.org/dokuwiki is extremely simple to set up. You get revision control - Plug In structure for ODF/PDF export, easy editing etc. Plus a wiki is accessible even from a simple mobile browser with no extra installation needed. Multicast... well - More or less accessible to all at the same time. Looking forward to see this thread develop, as it could prove to be immensely helpful for any FOSS organization/project.

DokuWiki is meant for document management. Many big name companies(for instance hitachi telecom) use it.

Many wikis solve this problem by locking the page when someone is editing it. My wiki of choice (dokuwiki) also has a time-out on locks, so if you don't save or preview (which restarts the lock timer) within that time, your lock expires, and someone else may edit the page.

True, locking the page is not as elegant a solution, but it's a lot simpler to implement.

I wonder how a multi-user editor handles 2 people editing the same character in a line. I'd suspect that some of them would actually implement locking on a per-line basis. The last one I saw showed each user's current line in a highlighted color. I wonder if that was also used to indicate that you couldn't edit that line.