I finally switched to WordPress

I finally switched to WordPress

wordpress_logoAfter a long time of consideration I turned over to WordPress for this weblog and I will not be using Tinderbox to blog here anymore. Tinderbox is a great software for thinking and writing – and I love to have a more graphical/visual note taking approach to weblogging. But it was getting too clumsy to update my weblog or simply correct a typo. It also is a client side application – thus requiring me to use Tinderbox to blog (so it didn’t work with other clients or other computers).

feed-icon32x32  RSS Feed

Now I just need a slick design for this site.

Tinderbox 3.6.3

One of the tools I love to use is Tinderbox. The homepage says: “Tinderbox is a personal content assistant that helps you organize, analyze, and share your notes.”

I just downloaded the latest beta version (3.6.3 b17) and found that it has a list of improvements that push it forward again.

If you never heard of Tinderbox try looking at some of the screencasts that are online.

Tinderbox is a tool that has been around for ages now and while the technical progress is slow compared to other tools it remains unmatched for a lot of tasks. The sad part of it is, that it does have some limits and missing features that people expect from a writing tool. But besides of that it’s potential has not yet been fully exploited by its community.

The tricky thing with Tinderbox is, that it does “take off” unless you know how to use the tool wiseley. For a newbie it may feel like just another note-taking tool that misses some core features. But once you discovered some of the core concepts of Tinderbox a whole new set of options.

Findamentally it is a tool that keeps asking you: What do you want to do with your thoughts? How do you create relevance out of randomness? What does order in a chaotic world of fragmented information mean?

Tinderbox somehow forces you to answer these questions and define a concept how you want to process everything you write down. You may start with no such concept and try to develop it while playing around with Tinderbox. But once the level of interdependence of notes, actions, templates and such gets high (which can happen quickly) you need to become smart about how you manage you material.

Blog lag….

There has been no post here for over a month now. I really feel bad about that as I can see from different stats, that there are more than 550 subscribers to this blog (slowly growing) – which is not too much compared to some other blogs… but a hell lot of people for me. And with a 20% reach (people that actually click or act on a blog post) I think it is not wise to neglect a blog for so long. But then again I need to thank all subscribers for the confidence I sense from that.

Truth is that I have been way too busy the last month. I stopped working as a professor at the computer science department of the Cologne University of Applied Science (I still do teach Design though) and started to work on an international project related to the music and TV entertainment busniess. I probably will contemplate and write about that sooner or later, because there are really a lot of stories that I’d like to share in future.

So keep me on the radar… I am still alive!

Experimenting with Tinderbox XML

After I sucessfully imported some parts of my old weblog I reconsidered the idea to publish with Tinderbox to a database instead of using it to render HTML. Here is the current idea:

  • A Python script will read the Tinderbox file and publish this into a MySQL database
  • The database will be synchronized with a copy on the server
  • The server uses Zope to publish content (but can use anything that works with MySQL)
  • Server will use meta data, link data and possibly other things to create the site

Some advantages:

  • No need for agents anymore, the searching/collecting is done entirely on the server
  • No need for export and rendering from Tinderbox
  • A wider range of possibilities when translating data to HTML (full scripting)
  • Agents and HTML export is still possible – e.g. to keep a “internal work site”
  • Can possibly be extended to work for other environments
  • Possibly opens a way to use other ways of translating ASCII text to HTML (e.g. ReStructuredText or Textile)
  • Could allow many authors to contribute to one site (but not edit content created by others)

Some disadvantages:

  • Obviously there is code needed
  • Needs Python and MySQL on the client and MySQL on the server
  • Concept for a database structure and content specifications needed (how to use actually information from the Tinderbox file in the site)
  • A great deal of development needed on the server to turn the database into a site
  • Changing the Tinderbox file a lot could break the system
  • It is a one-way process – so no edits on the server travel back to Tinderbox

I investigated PyXML and elementtree which I found via Uche Ogbujis article on XML.com. I also found this XML & Python tutorial by Alexandre Fyolle very helpful. This Devshed tutorial on MySQL & Python reminded me about how to connect to the database. All this worked pretty well in first experiments.

The translation script will have to do some heavy work:

  • Translate Tinderbox commands (or invent own)
  • Maybe convert links and styles
  • manage images that are inside the Tinderbox file

Tinderbox to database publishing?

Right now I set up this weblog to be rendered on my laptop and upstreamed to the server with normal HTML pages. This somehow put the burden of organizing the site on Tinderbox. But somehow I get interested in the idea to let the server care for the public face of my content and rather use Tinderbox in a “freestyle” way. The server should only get a “content feed” from which it should construct a site.

One rather simple way would be to publish the Tinderbox content directly into a database on the server. The quickest (and dirtiest) way to do that would be to render SQL files and use a script on the server to import these. The HTML rendering would be completely the job of the server (and of course I’d need to set up templates & everything there).

A more sophisticated approach would be to render XML files that are parsed into the database. This would maybe allow to reduce the amount that needs to be uploaded per update.

Unfortunately I don’t think I am going to have the time to check this out. But somehow I hear a distant voice telling me that this would even allow several Tinderbox users to work on one site together (or at least publish into the same space).