In my original template, dates and deadlines, kinds of material and their topics, and everything else I needed to know about a note was indicated and organized visually in map view using nested containers, colours screen position, badges, borders and even pattern overlays. This worked well but it also made my maps rigid rather than creative spaces. Every visual element was assigned with little room left to experiment. I’m trying to change this with my template revision my displacing some of this visual information from the map onto other attributes.
Because of how I’ve generated notes using my “wiki view,” my maps start out autogenerated, unadorned and monochromatic.
To begin working with these maps, I simply grouped notes loosely to get a basic sense of flow. This arrangement was ad hoc and changed based on what I was looking at. As I’ve worked and my notes have multiplied, this map has become a challenge to work with and to “see”–but this confusion is useful and generative. So I’ve resisted eliminating it by simply “tidying up” the map.
The one container I have created so far is called “Daily Schedule” and I use its map view to plan activities that have clear start dates or deadlines. But even here I have resisted nesting containers and have tried to move information into non-map attributes: my schedule is now built with overlapping adornments and on-add actions set the $StartDate attribute automatically for aliases dropped on an adornment.
Having working $StartDate data allows me to use timelines, something I couldn’t do before and have barely begun experimenting with.
Boolean Attributes & Agents
In addition to $StartDate, I have created a series of user attributes to carry the information I’d previously stashed in note colour, badges, etc. For example, material types are now stored in $Story, $Film, or $SecondarySource attributes. $OralPresentations and $Assigned attributes criss-cross these and distinguish materials selected for use from those that were simply considered.
All of these attributes are boolean, which is another departure. In my previous template I used mostly sets. For example, I had a $MaterialType attribute that was first a string and then a set. But typos were a hassle and selecting from (or remembering) multiple names for the types I was using was too. Having multiple yes/no attributes (one per type) is easier for me to maintain and keep consistent.
These new boolean attributes also make it easier for me to build agents on-the-fly. Do I need a schedule of oral presentations? Then I create an agent that searches for $OralPresentation as “true” and set it to sort by $StartDate. Am I building a bibliography of supplementary readings and screenings? I create an agent that searches for $Story, $Film and $SecondarySource as “true” and $OralPresentation and $Assigned as “false.”
These agents have a simple syntax and take only moments to create. As a result, I can make them up as I need them even if I need them only for a short time.
Link Types on a Map
Finally, the links on my top-level map have become extensive and they read primarily in terms of density. But I have been thinking about what else they might be made to tell me if I thought of them in terms of link types.
What I’ve realized is that many of these links are simply for navigation, and I don’t need to see them in map view. Others are navigational and also informational insofar as they indicate kinds of materials and the relationships between them. It seems there would be value in assigning these different links different types and then setting them to display differently on the map. Navigation links could be hidden, for example, but links to required and supplementary materials might be presented in different colours.
And in a Note Text…
If link types can be useful in map view, it also seems they ought to be able to differentiate relations between materials in note texts as well. For example, right now link-text colour simply tells me what I’ve clicked on. Knowing instead that a green link leads to an assignment and a blue link leads to reading notes could be very useful. But I suppose this depends on whether I could set up rules or agents to make link-text colour representative of link type. And I don’t know how to do that or even if it’s possible…
The End (for now)
And so this post ends with ideas and speculation and I take that as a sign that my description of my template revision has caught up with my practice and that it’s time to wrap up the series. When the term is further along and I know more about how things have gone, I’ll give an update.