zim-wiki team mailing list archive

[Brendan Kidwell <snarf@xxxxxxxxx>]

On Wed, Jan 25, 2012 at 8:34 AM, Jaap Karssenberg
<jaap.karssenberg@xxxxxxxxx> wrote:
> Related to this discussion I have a question to get some feedback on
> how people use their notebook.

My answers are from my perspective, using Zim as a work diary.

> How many levels of sub-headings do you typically use?

2 or 3 levels (H1 title, H2 sections and sometimes H3 sub-sections).
My Zim page files are typically 500 to 1000 words and at most two or
three attachments.

> How many levels of sub-pages do you typically use?

Around 4 or so in my office notebook.

> On what level would you want to split it up for export?

I am not too concerned about export, but I am concerned about
usability of the viewer/editor in day to day tasks. I require a Page
object (implemented however you like in the back-end). See below.

> Do you have a strong use-case for having both sub-pages and headings?

Yes. Let's define a Topic to be one meeting, event, project module or
some kind of entity that can possibly be described to your manager as
the answer to "what did you do this afternoon?" Consider these minor
tasks that happen all the time with some users like myself:

- Navigate to the top of a Topic, where the introduction is found.
- Navigate to the bottom of a Topic and add text.
- Select all of a Topic and copy or delete.
- Find a string within a Topic.

Of course you can see I'm describing things you'd do to a Page object.
While I find Dave Winer's and Evernote's outliner structure without
Page boundaries interesting, I feel that I need Pages. I want the
primary navigation widget in my UI to NOT have headings like
'example', 'my reply to the requester', or 'possible fix'; they should
be headings on a page.

We could certainly do some interesting things in the back end to
support the display of subpages based upon query parameters or UI
defaults, but please keep the Page boundaries. In the back end we
could remove Pages and imlement Nodes like this:

[Node]
identity of parent Node (numerical ID or filesystem path) (null for root)
cardinal order number of this Node, among siblings
title
starts a Page? true or false
date created
text (headings in text not allowed; must be put in a child node)

In keeping with Zim's plaintext spirit, each Node could be one file;
parent/child structure could be indicated by directories; and Sqlite
could index it all for fast querying and remixing in the UI.

This would also be great for Google Wave-style non-textual Nodes. A
Node can be a picture, a Zip file, an equation, a table, or anything
that can be rendered and/or edited via a plugin.

I would also prefer that we keep the general idea of one FILE per Node
or per Page. I sync my Notebooks by putting them in a Dropbox-backed
Encfs/BoxCryptor collection. Encfs encrypts and decrypts each file's
data and filename as it is written and read; Dropbox can't sync PART
of a file because it has no knowledge of what is in the file, so it
must push the whole file every time a change is detected. This works
fine for Zim but it wouldn't work for a big blob of a binary database.

Brendan Kidwell