Update 21/08/2010: I've found enough beta testers for the moment - thanks to all those who volunteered.
I'm looking for beta testers for Confab, a new conformation generator I've been working on over the last while. It's based on Open Babel and aims to generate diverse low energy conformations. In particular I am interested in feedback on what sort of features should be added.
If you have access to a Windows system and are interested trying out Confab, please send me an email at baoilleach@gmail.com and I'll follow up with download instructions.
Note: The software is open source (GPL v2) and the source is available on the fastconf branch (commit b9300dd) at http://github.com/baoilleach/openbabel-svn-mirror.
Image credit: dalbera
Thursday, 19 August 2010
Tuesday, 17 August 2010
Why a wiki does not work well for documentation - and what you can do about it
I've been working on moving documentation from the Open Babel wiki (Mediawiki) to a Sphinx-based system, and it's really so much better.
Wikis are great because they have a low barrier to contribution, make it easy to collaborate on documentation and (less importantly) have versioning. Wiki are rubbish because they don't impose a hierachical structure (they have some ideas about categories, but that's just not enough), pages get orphaned, and never get read. (They don't look great either, without a lot of customisation.)
Take, for example, the Open Babel wiki. Over the years a lot of effort has gone into creating content. However, there are many pages on the wiki I simply have never seen before because there is no clear path to them from the front page.
So, what to do?
As I said, I've been moving the docs into Sphinx (either manually, or using Pandoc). This uses a simple markup, reStructuredText (reST), to highlight headings, links and so forth. Most importantly it imposes a hierarchy - only pages that are included in a table of contents get incorporated into the documentation. The best part of all is that unlike a wiki (or at least, unlike Mediawiki) Sphinx can output not only HTML, but also LaTeX (for making PDFs) and HTMLHelp (for Windows CHM files).
But it's not a wiki any more, you're thinking. Well actually, that's where you'd be wrong. Through the magic of the internets, if you store your source code on Github, you have a de facto wiki, because reStructuredText is understood by Github and rendered reasonably well. You can click "Edit" right there on Github, edit the source and immediately see the result (and it's versioned of course).
An in-progress version of the Open Babel user documentation is available here, and you can check out the source code on Github (and fork it too, if you want).
Image credit: Ross Mayfield
Wikis are great because they have a low barrier to contribution, make it easy to collaborate on documentation and (less importantly) have versioning. Wiki are rubbish because they don't impose a hierachical structure (they have some ideas about categories, but that's just not enough), pages get orphaned, and never get read. (They don't look great either, without a lot of customisation.)
Take, for example, the Open Babel wiki. Over the years a lot of effort has gone into creating content. However, there are many pages on the wiki I simply have never seen before because there is no clear path to them from the front page.
So, what to do?
As I said, I've been moving the docs into Sphinx (either manually, or using Pandoc). This uses a simple markup, reStructuredText (reST), to highlight headings, links and so forth. Most importantly it imposes a hierarchy - only pages that are included in a table of contents get incorporated into the documentation. The best part of all is that unlike a wiki (or at least, unlike Mediawiki) Sphinx can output not only HTML, but also LaTeX (for making PDFs) and HTMLHelp (for Windows CHM files).
But it's not a wiki any more, you're thinking. Well actually, that's where you'd be wrong. Through the magic of the internets, if you store your source code on Github, you have a de facto wiki, because reStructuredText is understood by Github and rendered reasonably well. You can click "Edit" right there on Github, edit the source and immediately see the result (and it's versioned of course).
An in-progress version of the Open Babel user documentation is available here, and you can check out the source code on Github (and fork it too, if you want).
Image credit: Ross Mayfield
Friday, 6 August 2010
Open Babel Quick Reference
Subscribe to:
Posts (Atom)