Projects Workflow

Projects are really the preferred medium to organize and store the result of your research. As such, this Project management workflow is probably the overarching one for the whole tool. All other workflows will somehow stem from this one.

To better illustrate my point, let's use an example. Say that you want to investigate 19th century architecture in Brussels and publish a scholarly work based on this research. Here are the recommended steps leading you to the finished product.

Create top index node for project structure
Create project record
Start your research...
Structure your project
1. Restructuring as you work
2. Cross-project work
Generate report
From the Hirtius report to the finished work
And once all is said and done...

Let's now discuss each of the steps in details. Please keep in mind that some of them only apply to the first time you will do this.

Create top index node for project structure

(optional, but recommended) Create a top node for all your research projects in the INXtree (e.g. History | Research). Grouping all your research projects together beneath a single entry point makes them easier to manage. Of course, you could also spread your research projects throughout the main categories they relate to, but I personally prefer the first approach, as it is tidier.

Typically below the top node we just discussed, create an entry node for your new research project. You can call it anything you like, as this item will not appear as such in the final project report. In this example, we called it 'Brussels architecture'. This step is required if you want to use project reporting at all.

Create project record

Through the Projects List and Projects Edition Page, create a new research project, and link it with the project's entry node created above using the 'Structure container node' field (all Tiddlers created in this project afterwards will automatically be linked with that INXtree node to start with). The 'Project name' will appear as part of the project report title, and the project record 'comment' field will be used as abstract.

If you plan on writing your project in a different language than the one defined as global default in the Global Definitions File (and provided your target language is already part of the list of supported ones, of course), you should specify it through the 'Contents language' drop-down on the Projects Edition Page when first creating the project. Please refer to Language Support in Reports for the effects this will entail.

Start your research...

You can then start researching your subject, creating objects as you go. With a subject like our example, you're likely to create different kinds of objects: still images of buildings (Slides), notable moments of the Belgian artistic and political scenes (Events), biographies of some architects (Individuals), original documents from the period (Sources), etc.
Each of these can then be documented as you investigate them, and all should be linked (through their Categories section) at least with the entry node of your research project (or any node beneath it -- more on this topic below). Of course, feel free to link your new objects with as many other categories as you see fit. It is even possible to link the same object with multiple project structures in the INXtree.

At the same time, you should create Tiddlers in the project you created above to record your line of enquiry, your hypotheses, theories to be put to the test, and general reflections on the subject. Use these as well to track all relevant facts you discover that don't fit in any of the other object classes. Use them to build the story you want to tell. All of these tiddlers can be organised through the use of tags, documented through bibliographical references, linked to other objects, and all of them will also be linked automatically with the entry node of your project structure.

Don't forget to use the "journal" feature offered by the TiddlyWiki interface to trace the progress of your research and your milestones (such as minutes of meeting with your promoter). Just don't link those entries to the project reporting structure (and remove that link it if was made automatically) as you most likely don't need them included in the final report -- unless of course you specifically want them to appear there, such as in a dedicated appendix for instance.

Structure your project

To start with, all your objects will thus be linked with this entry node, that we created in the first section above, thereby giving your project a flat structure. But as your research deepens and as you gain a better view of where you want to lead your work, you should start creating some structure in your project: adding new INXtree nodes beneath the entry one, to represent your chapters, for instance. To determine their order, have their names start with 2 digits and a dot (if you do, the project report builder will automatically remove this numbering from the printed output -- only to replace it with its own, based on your LaTeX report layout).

Example:

  Brussels architecture
    00. Introduction
    01. Historical context
    02. The Académie des Beaux-Arts
    ...
    12. Conclusion

(the first row in the example above represents the entry node for your project structure).

Depending on the intended complexity of your structure, you can number your headings on 1, 2 or more positions. Dot, white space and underscores are all valid delimiters between numbering and heading. As an illustration, all the following notations are supported and equivalent:

    0. Introduction
    00. Introduction
    000. Introduction
    0_Introduction
    00.Introduction

Please note: You don't have to start your numbering at zero, and you may as well use increments of 10 (a technique that would be familiar to ex-adepts of Basic) in order to make it easier to insert new entries between two existing ones. The number themselves are irrelevant (they will be discarded during report generation). Only their order matters.

Once this structure has been created, you should review the classification of your linked objects and re-classify them, linking them instead to the chapter where you will discuss them.

As time goes by, and the structure of your final work grows clearer in your mind, you can create a deeper structure below your chapters. I would typically recommend to avoid nesting it over 4 levels deep (chapter, section, subsection, subsubsection). If you go to five levels, the top-most becomes a "part" (in LaTeX parlance). Anything deeper than five is mapped to "paragraphs". At each sublevel, please use the numbering technique explained above to control the order in which the sections will appear in the report. Also please remember that the same object can be linked to multiple sub-nodes of the structure if needed (in that case, the object contents will feature multiple times in the resulting Project Report, of course).

Example: the structure introduced above with deeper nesting.

  Brussels architecture
    00. Introduction
    01. Historical context
      01. Dutch occupation
      02. Belgian revolution
      ...
    02. The Académie des Beaux-Arts
    ...
    12. Conclusion

Restructuring as you work

In addition to creating a more deeply nested structure for your project and updating the category each linked object points to accordingly, there are several other strategies you can use to restructure your project as you work.

By using the INXtree Move feature (see: INXtree Browser), you can act on the project structure itself, for instance moving a sub-section to a different chapter. Doing so maintains the links to all the objects this sub-section referenced (and their respective order inside the sub-section). Of course, you may need to edit the digits in front of the sub-section name (via the Categories Edition Page) to control its order inside the target category (see next point).
Simply editing a category name to alter the digits in front of it, you can easily re-order the chapters, sections, etc. of your work or "make some space" to insert new ones in between. A shortcut to this feature is now also available from the INXtree Report Page in Project Preview mode.
Using the Level+ action on the Object - Category Edition Page, for instance, you can very easily re-classify your objects (i.e. change the category that they are member of), which translates into moving this object from one section of your Project Report to another.
From the Project Preview mode of the INXtree Report Page you can reach the Object - Category Reorder Page, that will allow you to reorder the objects linked inside a given category. Initially, when you link multiple objects to the same category, they are listed in their "natural" order, i.e. the one in which the 'INXlink' records were initially created. But since this category will in fact become a section in your Project Report, it is important that the order of the objects it contains match the story you want to tell -- the page in question lets you do precisely that.

Cross-project work

As already mentioned before, even though a Tiddler can be member of a single project only (i.e. you can edit it only by accessing that project's TiddlyWiki interface), it can be linked to the reporting structure of any number of projects. This means that you can "invite" any external Tiddler into your current project, like you would other objects like Sources or Individuals for instance. The techniques described below can make this kind of cross-project work easier.

Using the Advanced Search Page and the Index Categories Bulk Add Page, and provided you have a suitable criteria to isolate the Tiddlers you are interested in (tags may come in handy here), you can easily "invite" them all inside the reporting structure of your current project in one go.
Similarly, using the INXtree Copy feature (see: INXtree Browser), then the Index Categories Bulk Add Page to "invite" all its tiddlers into the current reporting structure, you can easily make project 'B' a chapter or section inside project 'A'.
Of course, since all the imported Tiddlers will have received the same new category, you will then need to reassign them manually to the right place inside the now extended project 'A' reporting structure.

To make your life easier (as already hinted at earlier), a Project Preview feature is available (accessible from the INXtree Browser and the Projects Report Page) to help you build this structure and review it as you work, without needing to go all the way to the PDF report generation (which is time-consuming and more resource-intensive).

Please note: there are limits to the size of your INXtree, not in terms of "lines" as this is stored in a database table, but in terms of leaves per node and maximum depth of the tree. Please refer to Database Layout and Database Statistics Page for more information. Both of these parameters can be tweaked at installation time (see Global Definitions File and the INSTALL document).

Generate report

Once your work has reached a maturity level that you deem sufficient, or you met a specific milestone in your project, you may wish to generate the Project Report. This can be used as a basis for discussion during progress meetings with your promoter, and eventually as the rough draft for your final work.

It may also come in handy to tote around during field or library research trips if you can't bring your computer with you.

Generate this report by clicking on the Report action on the Projects List, then select the parameters and submit to create the report source (in LaTeX format). Once done, download the .tex file locally and use the Makefile provided in the scripts section of the distribution archive to build the document and convert it into a PDF file.

From the Hirtius report to the finished work

If you're working in any kind of scholarly context, do not ever imagine that the Project Report you just generated will represent your final work. It hasn't been designed with that goal in mind, and the fact that each section in this document will be composed by a mere "collage" of Project Hirtius objects means that it will never end up as something that's enjoyable to read. It may also lack any sort of textual transition between the objects, for instance, although this is something you could work around using dedicated Tiddlers.

All of this means that the best you can hope for (and that was its intended use from the start), is for the Project Report to be used as a rough draft, an outline of your published work. So, what are the techniques you can use to bridge the gap between this draft document and the finished product? Here are a few suggestions:

use as input: since the project report will be generated as a LaTeX document, and depending on how close you feel this draft is to the final work you have in mind, you could simply take this .tex file as starting point for your published work, and rework it as needed (re-order the paragraphs issued from the linked objects if needed (although you can now do this from inside the application), add the necessary "glue" text, remove all Hirtius-specific metadata that is no longer relevant, etc.), using an integrated LaTeX project builder such as Kile.
cut and paste: create a new document for your published work (in whatever format you prefer), base its internal structure on the one you defined in Hirtius, and then cut and paste the relevant data from all linked objects, either from the Hirtius Project Report or directly from the objects themselves through the web interface, using the Report or Project Preview as guide.
re-write most of it: create a new document for your published work (in whatever format you prefer) and start writing its contents anew, using the Hirtius Project Report merely as a guide or a draft.

Your choice of technique may be based on how close you feel your Hirtius data is to your finished work, and also on your preferred tool for writing that scholarly paper. In any event, we hope that Project Hirtius will help you organise your research data, make it easier to discern patterns in it, and speed up the process of going from draft to finished paper.

And once all is said and done...

(optional) Once all your work on that project is finished, Hirtius offers you the ability to close it (this is done by checking a box on the Projects Edition Page). There are two advantages to this approach:

closed projects, as well as the TiddlyWiki they contain, become read-only, meaning that they can still be consulted, searched or printed, but no longer modified in any way (please note that this R/O state does not extend to other object types that may be linked to the project through INXlinks, as any of these objects may belong to several projects, contrary to Tiddlers).
your user profile can be configured to hide closed projects by default, which will reduce the clutter in the Projects List (a check box on that page enables you to easily override that display choice while there, though).

Closed projects and all the Tiddlers they contain will be identified by a special, greyed-out, font style in lists and search results. Similarly, a read-only TiddlyWiki interface will be visually identified by a grey banner instead of a blue one.

Obviously, it is always possible to reopen a closed project should the need arise...