Footnotes!

Self explanatory? Ha! :)

I have been thinking about the problem of footnotes. To me the problem is that I don't really want to spend lots of time to build a traditional footnotes implementation since that's rather specific and I like to think of Mori as a "generic" ideas program. So I'm trying to think of ways that we can use Mori to implement footnotes.

I think one way to do it is with something similar to Hog Bay Notebook's section links. So to create a footnote you would create a link from the article that you are writing to another entry that would contain your footnote. When you exported your document the exporter would resolve all of these links and create footnotes in the final document.

One advantage of this is that you could have a large collection of shared footnotes that were referenced by many different articles.

Does that seem like a good way to do things? Are there any other footnote tasks that need to be supported?

Footnotes would be a great new feature for Forest/Mori. It certainly isn't needed for a '"generic" ideas program', but this is exactly why you should implement it. There are so many "generic ideas programs" out there. But there are no outliners/notebooks/organizers that support footnotes - if there were any, I'd know them. (Ulysses supports footnotes, but only through a clumsy LaTeX markup/export function.)

Many people who use notebooks and outliners are academical writers. Many HBN users are academical writers (see the long thread about Writing a book/dissertation in the HBN forum). Support for footnotes in Forest/Mori would be quite a selling point. It's a very special feature, and this is exactly why it could make the next release of your program successful. It would be the first and only program of its kind to support footnotes, which would guarantee a lot of interest and mindshare among academical writers. I think that spending some time to implement footnotes will be worth it - for both you and your users.

I don't know how hard it would be to build a full implementation, and how such a word processor feature would fit into Forest/Mori's interface. I'm all for a full implementation of course, but I don't want to push my agenda too far :)

The solution you suggest sounds interesting, though it seems a bit complicated. Maybe I don't fully understand what you have in mind. Usually you write something, insert and type a footnote, and continue writing. The solution you seem to suggest means you would have to create a new file somewhere else (in another folder in the project structure), type the footnote, then switch back to the main text, link the footnote file to the passage you were working on and finally be able to continue writing. It's better than nothing, but it's a very convoluted workflow.

Being able to share footnotes between different articles sounds appealing, but frankly I have never felt the need to re-use a footnote in another article. I also start a new project file for every new article I work on, so Forest/Mori would need the ability to create linked files between different projects to share footnotes between them.

I've been thinking about this more. I don't think adding a WYSIWYG word processor style footnote implementation is the answer. It requires lots of effort for a specialized feature that's only really usable for one thing. Instead I would like to take an approach a bit more like:

(Ulysses supports footnotes, but only through a clumsy LaTeX markup/export function.)

:( I hope you don't think it's tooo clumsy. :)

Do you remember the Assemble command from Hog Bay Notebook? That would allow you to export a bunch of different entries into a single text file and each would be replaced by the contents of the entry that it linked to.

It's a bit confusing, but it's also a powerful idea I think. It allows for a document structure and writing process that takes advantage of an outline structure and that's just not possible in a standard word processor.

So I would like to extend that idea and make it generic so that you can add other link types (or really assembling instructions) that are recognized by the assemble command. The general form for these links would look like this:

If you know XML then you'll recognize that as a processing instruction. Here's some examples:

This is how a section link to an entry titled "my notes" would look.

This is how a footnote to an entry named "joe's paper" would look. The assemble command would look for these links and create footnotes in the document exported by the assemble command. So Mori wouldn't really know about footnotes itself, but it would be able to export them to another program.

Plugins could augment the assemble command to support all kinds of processing instructions. For example applescripts could be run on the page with something like this if the was an applescript plugin to support it:

The system isn't easy to learn for new users. But it offers a lot more flexibility and power then plain old footnotes would add. And to me it fits better with Mori's idea processor goal then a standard footnote implementation does.

Ideas? Improvements?

Jesse, the code examples didn't show up in your post. Could you repost them? The concept itself sounds very interesting, and I want to give you some more thorough feedback, but I'd like to see your code examples first. Thanks.

Humm, it doesn't seem possible to edit project follow ups, that's a pain. Well lets see if this works. In Hog Bay Notebook sections looked like this:

Using the new format that would look like this:

So the new stuff doesn't look quite as nice, but it's more flexible because it's tagged with some information that can be used by the assemble command 'section' in this case. Now we could change this to treat the linked to entry as a footnote instead of a section like this:

Or some applescript code to run like this:

Jesse

Humm, it doesn't seem possible to edit project follow ups, that's a pain. Well lets see if this works. In Hog Bay Notebook sections looked like this:

<< mysection >>

Using the new format that would look like this:

<?section mysection ?>

So the new stuff doesn't look quite as nice, but it's more flexible because it's tagged with some information that can be used by the assemble command 'section' in this case. Now we could change this to treat the linked to entry as a footnote instead of a section like this:

<?footnote mysection ?>

Or some applescript code to run like this:

<?applescript
return "hello world"
?>

This doesn't fully solve the footnote problem, the assemble command still need to be made smart so that it knows what 'footnote' means, and how to export it. But that will be a lot easier then trying to build a UI that knows about footnotes.

I think this is a smart idea, and the assembling instructions you suggested are logical and easy to understand.

The only problem I see with regard to footnotes is that inserting, editing and managing footnotes would still be a very complicated process. You would have to create a new entry (e.g. in a folder named "footnotes") for every footnote you want to insert, give it a title (e.g., "footnote 3") and then insert that title into the brackets.

Now, if you edit your main file and change the order of paragraphs and their depending footnotes so that footnote 3 suddenly comes after footnote 7 which comes after footnote 10, it's easy to totally lose track of your footnotes. It will get even more confusing if you have different notebook entries for every chapter of your article. With a system that relies on linked entries, managing footnotes could become a pain. It won't be much of an issue for linear writers who don't change the order of paragraphs and chapters once they're written. But HBN/Forest/Mori's strength is its flexibility as a non-linear writing tool (at least that's why I prefer it over programs like Word which is great at managing footnotes but not so great for composing stuff). A lot of this flexibility would be taken away with a footnote system that relies on hard-linked entries.

However, there is a simple solution to this problem: why not allow the insertion of footnotes within the main entry itself?
The user would have to put tags around the footnotes that can be interpreted and processed by an export plugin. (Something like: ) It's far easier to manage footnotes if they can be kept and edited in the main entry.
This idea is somewhat similar to the way Ulysses handles footnotes (minus the dependance on LaTeX). It's less convenient than a traditional footnote implementation, but still a very good compromise, and it would be in accordance with the design and concept of Forest/Mori.

(The forum software messed up my last post, hope it comes through in full length this time:)
I think this is a smart idea, and the assembling instructions you suggested are logical and easy to understand.

The only problem I see with regard to footnotes is that inserting, editing and managing footnotes would still be a very complicated process. You would have to create a new entry (e.g. in a folder named "footnotes") for every footnote you want to insert, give it a title (e.g., "footnote 3") and then insert that title into the brackets.

Now, if you edit your main file and change the order of paragraphs and their depending footnotes so that footnote 3 suddenly comes after footnote 7 which comes after footnote 10, it's easy to totally lose track of your footnotes. It will get even more confusing if you have different notebook entries for every chapter of your article. With a system that relies on linked entries, managing footnotes could become a pain. It won't be much of an issue for linear writers who don't change the order of paragraphs and chapters once they're written. But HBN/Forest/Mori's strength is its flexibility as a non-linear writing tool (at least that's why I prefer it over programs like Word which is great at managing footnotes but not so great for composing stuff). A lot of this flexibility would be taken away with a footnote system that relies on hard-linked entries.

However, there is one very simple solution to this problem: why not allow the insertion of footnotes within the main entry itself?
The user would have to put tags around the footnotes that can be interpreted and processed by an export plugin. It's far easier to edit and manage footnotes if they can be kept and edited in the main entry.
This idea is similar to the way Ulysses handles footnotes (minus the need for LaTeX output). It's less convenient than a traditional footnote implementation, but still a very good compromise.

WTF?!? 3rd and last try (please delete the 2 posts above - I can't edit my posts)

I think this is a smart idea, and the assembling instructions you suggested are logical and easy to understand.

The only problem I see with regard to footnotes is that inserting, editing and managing footnotes would still be a very complicated process. You would have to create a new entry (e.g. in a folder named "footnotes") for every footnote you want to insert, give it a title (e.g., "footnote 3") and then insert that title into the ?footnote ... brackets.

Now, if you edit your main file and change the order of paragraphs and their depending footnotes so that footnote 3 suddenly comes after footnote 7 which comes after footnote 10, it's easy to totally lose track of your footnotes. It will get even more confusing if you have different notebook entries for every chapter of your article. With a system that relies on linked entries, managing footnotes could become a pain. It won't be much of an issue for linear writers who don't change the order of paragraphs and chapters once they're written. But HBN/Forest/Mori's strength is its flexibility as a non-linear writing tool (at least that's why I prefer it over programs like Word which is great at managing footnotes but not so great for composing stuff). A lot of this flexibility would be taken away with a footnote system that relies on hard-linked entries.

However, there is one very simple solution to this problem: why not allow the insertion of footnotes within the main entry itself?
The user would have to put tags around the footnotes that can be interpreted and processed by an export plugin. It's far easier to edit and manage footnotes if they can be kept and edited in the main entry.
This idea is similar to the way Ulysses handles footnotes (minus the need for LaTeX output). It's less convenient than a traditional footnote implementation, but still a very good compromise.

I'd be VERY interested in footnotes for Mori!!! But I'd need it to be easy to utilize. Not involving typing in too much stuff other than a footnote number. I don't know, but if you could follow your idea on how to implement footnotes as sections but automate the process in some way? Click a button or make contextual menu selection and have the program insert whatever tags need to be created? Could be a script? Not that I really know how you'd do all that. But I do know as a writer who uses lots of footnotes, at times, it would need to be a quick and simple process or I'd not use it.

Alexandria

I like Jan's idea for initiating the footnote from the text. That's where I usually put at least rudimentary footnote info anyway, in every draft but the last. That way I can cut and shift and reorganize and rarely unmoor the footnote from its text. But it would be wonderful to have a really simple way to do that--and to be able to configue the assembled final text so that footnotes would print either at the bottom of the relevant page or at the end of the section--different publishers, different demands.

I found this forum while searching on Internet for a writer's tool that would offer me the possibility to assemble text and notes as footnotes into a final document. I'm now using DEVONthink Pro for my writing (as I have at hand all my quotations and personal notes) but it does not allow me to practically make footnotes.

I agree that footnotes is quite essential to make Mori maybe the best tool for academic writing. I think footnotes could be implemented as sections in HBN. This allows footnotes to be put out of view to keep concentrating on the main text. Would'nt it be possible to use smart folders to collect all the footnotes related to a particular note/document. Obviously they should be properly tagged. It should also be possible to renumber and reorder footnotes in the order of sequence they appear in their parent note/document.

I hope you can implement this soon. It would make Mori a unique tool, quite useful in particular for academic writers.

Footnotes would make Mori very much more usable for acamemic writing; currently if I write in Mori i put the footnotes in square brackets, and when I exort to Word for final formtatting I have to go through very carefully and create footnotes for the bracketed material.

If you support some time (I think there is another feature request for this) export in Word outline format, it would be essential for academic writing to at the same time export footnotes as Word footnotes (maybe also Tex as well as an option, because that's the other format widely used for final document formatting)