export.

New export options in Zim.

zim is an outliner.

OK casual blogosphere cruisers, Twitter loiterers and general ADD infected youth: The executive summary here is that Zim is an outliner, and if you're lucky enough to have fired up this blog entry in Firefox, you can try out this working demo.

And for the rest of you (all 3 of you), let's talk why Zim:

Over the past couple of years, the most important personal productivity tool I've used has been OmniOutliner on OS X. The open-ended nature of the tool means I use it for a range of things, from task lists to meeting notes to presentation plans. It works well with my brain, to the point that I rarely actually think about the software, I just find myself using it in all sorts of situations. Most excellent functional design strikes me as 'boring' to talk about (there's not much to say about something that works so naturally), and OmniOutliner is no exception. If I were to describe OmniOutliner I would say it is

Quadratisch. Praktisch. Gut.

Which also happens to be the tagline on these little quadrilaterals of brilliance I eat daily.

The personal productivity tool of choice for Mac users right now is OmniOutliner Pro with a GTD plugin called Kinkless. I find the whole thing fiddly, opting to stay with an ancient version of the original OmniOutliner, which on the face of it contains nothing more glamorous than the ability to add multiple columns and export your lists in a couple of formats.

Over the last couple of weeks i've been playing with the idea of a browser-based Outliner not unlike DECAFBAD's XoXoOutliner. So here's a working demo of Zim (Firefox only), and here's the javascript source. Right now it's all pretty basic, so bear with me. I'm building it for a few reasons:

• To come up with javascript design patterns that don't suck.
• Because OmniOutliner is proprietary.
• Because I live in my browser.
• Because I use multiple computers daily.

On the short-term todo list for Zim you'll find such nuggets as:

• Proper undo feature
• OPML import/export
• Drag'n'drop node functionality
• web/email publishing (good for sharing meeting notes)

And longer term daydreams include:

• Hyperlinks and rich-media support
• Actual user accounts
• Multiple columns & column types (e.g. 'date')
• Multiple projects
• Overview page with 'next actions'

Zim will never be an application with many features, and you can expect it to come together slowly - it's a 'weekends' project after all - but with a few social touches and some attention to detail, it could grow into my substitute to OmniOutliner in the long run. No public trac/svn for now but I will shout here if it does happen.

on paper.

Sony research group demo an 'augmented surface'

Spurred by Miranda's reference to Malcolm Gladwell's article, The Social Life of Paper and other articles on the subject ( MIT Press' The Myth of the Paperless Office, Passion for Paper and Bill Gates' paperless working methodology), i thought i'd throw in my $.02.

I really can't see a case for paper in the workplace outside of enhancing co-located group sessions/workshops (i've described some below - Gladwell points one out as well). I'm trying, but i don't see it. At least for software development, though i believe this view is defensible for a range of industries.

One of paper's great advantages lies in its physicality. As a result of its portability it can potentially radiate information to multiple people in different locations without any technology requirements other than a pen/pencil. It's spatially flexible and provides a low barrier to authorship.

When you access paper-based information, subtle authorship traits are clear (handwriting and drawing styles communicate myriad things to us which digital typography and rigid outlines do not). Paper media retains these traits so well because the paper/pen combination provides one of the greatest interfaces mankind has ever come up with. It allows for much self-expression. From an accessibility perspective, the printed press gives you high resolution fonts you can take to bed with you. No eye-strain included.

So it's not all bad for paper. But the paper-less office isn't a myth. I don't use any paper at work. The only pieces of paper i have touched involve HR processes such as holiday forms (arcane admin rituals).

I use OmniGraffle or a whiteboard for quick visualization of ideas. Whiteboards beat paper hands down for radiating information to groups in the workplace (see Cockburn). Textual collaborative, dynamic information resides in the web browser - accessible by all, manipulable at all times. Wikis, chat-rooms and project management tools sit there. The browser is our core communication medium.

For notes, I have OmniOutliner which i also use to deconstruct large problems into identifiable tasks. Technical designs can be drawn in applications pretty quickly. These designs can then be uploaded for others to comment, in their own time. I can re-organise and re-prioritise my tasks at a keystroke. I can take notes on a meeting with others, during a presentation (backchannel). Put all this together and paper is starting to look a little ragged.

In the processes of archiving and organising (search/sort), paper also makes a weak case for itself. Digital alternatives exist for tracking ideas, dialogues, designs, tasks and most other everyday information. The notion that paper is a more secure information storage mechanism is also often mistaken and i can only assume comes from a misunderstaning of modern technology (stories of giant electromagnetic guns and hackers making people nervous).

In contrast examine the issues that arise from using paper instead of digital tools, and accumulate these over time (no versioned history of events, unsearchable, restricted ability to re-organise, closed access). It's a cludge. Moreover, it's potentially harmful; paper is, after all, the medium of bureaucracy. Solutions to everyday design problems require agile, accessible information. You need to be able to mix and match approaches, sculpt them in a group environment and change them on the fly. Your chosen media should reflect this.

The only place i see for paper in software dev is in CRC cards and planning sessions (blitz planning, sprint planning or xp planning games) - specialized techniques peculiar to the field (though kaizen-blitz sessions are widespread in the manufacturing industry). Broadly speaking, these are group processes taking place in one location, in which members pursue a single goal of identifying and organising many discreet chunks of information in real-time. Paper's spatial properties come to the fore here. Note that the paper is often thrown away after the session is complete and results captured.

All of these group operations could be carried out on a screen, but screens are interfaces to personal computers, which are designed with the individual in mind. Personal Computers are not for groups (as the name suggests), and a network of such computers does not constitute a true group interface. Turkle has alluded to the solipsistic design of the modern computer in the past. I think as better groupware interfaces are commoditized, such as augmented surfaces (sony research video), the use of paper even in these group processes will become optional and ultimately deprecated.