Attributes, Agents and Links

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.

Flat Maps

Because of how I’ve generated notes using my “wiki view,” my maps start out autogenerated, unadorned and monochromatic.

Autogenerated Map
These maps are also oddly beautiful.

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.

Flat Maps
A very early map with few notes or links.

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.

Adornment Schedule
Same old grid but now flattened into overlapping adornments

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, etcFor 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.

What I Teach. How I Teach.

I’ve been thinking about the mismatch between how revolutionary my “wiki view” seems to me and how completely insignificant it appears when I reread my description of it in my last post. When I reread, my take-away is: so I’ve started writing notes…in Tinderbox…”The Tool for Notes”…and… (yawn).

So I’m wondering: what is it about my work that makes writing and navigating notes with links seem so powerful?

The answer I think lies in the way I have been using “course content” to refer to two different things. On the one hand, it is my knowledge of a field, call it literature. On the other, it is all the lectures, activities and assignments I create for my students so that they can practice skills and demonstrate knowledge. The first of these is what I teach; the second, how I teach it.

In order to organize how I teach, I need to sequence course lectures, activities, and assignments so that they fit within the time constraints of a single semester. I also need to manage and track my movement–and my students’ movement–through this sequence. My original template offers me the tools I need to do these things.

Sequence is less important when organizing what I teach. Literature is complex. It operates through language. It organizes itself aesthetically. It is a field of meaning and a history and an etc. When I organize what I teach, I create an interpretation of this complexity pitched at my students.

My “wiki view” creates a word-based system for organizing what I teach that is independent of the graphical representations of sequence that organize how I teach. It allows me to dive into and swim freely through a sea of words. And when I need a breath of sequential air, I know that I can come up to the surface and bob around in map or outline view.

This new freedom to develop what I teach in a way proper to my field is, I think, the revolution I’m feeling.

Course Planning in “Wiki View”

The roots of my course plan revision reach back to the classroom wiki project I began creating last May. As part of my early preparations for this project, I created a personal wiki to experiment with the software I’d be using and decided to populate it with course materials to get it started quickly. This got me thinking about how planning a course in my Tinderbox template was different from what course planning would look like on a wiki.

Now, it was obvious almost immediately that the wiki was too limited to do any actual course planning. But at the same time there were two real and enormous benefits that I could see in a wiki-based approach. First, the wiki forced me to focus on texts and how pieces of text lead me to other (or new) materials. Second, the wiki nurtured a mild but generative confusion as I worked. Both of these seemed worth importing back into my Tinderbox template.

So, in this post, I’ll explain how I’m rearranging my template to shift my focus to the text of my notes, and in my next, I’ll explain how (and why) I’m “breaking” my template enough to let in some confusion.

The Problem of Title-Notes

Because I worked in outline and map views in my original course planning template, many of my notes consisted of little more than the title attribute (plus whatever attributes or copy-pasted text I used to catch them later with agents). These titles needed to be short enough to be viewed on a single line or within a reasonably sized box. They were also largely static.

In practice, the titles of empty notes named or described content (lecture notes, exercises instructions, etc.) stored outside my template, often as a keynote or word processing file. Generally but not always, I linked to that external file from my note. Generally but not always, I copy-pasted the content of that file to the note on the day I taught so that it would be included in the Nakajoki view printout I brought to class.

Notes as Titles
Dig down into map view and you find a bunch of empty notes.

Notes in my Wiki

In my wiki, things worked very differently. There were no map or outline views, and page-note titles were displaced to the top of my browser window. I was forced to deal with the actual content of pages and found this confrontation with the imperfect messy details of my work inspiring.

I also found that depending on links to navigate created a pressure to state ideas and information rather than merely to name them. In principle, blank pages in the wiki were the same as blank title-notes on my outline or map views, but in practice they were not. I needed note texts with links to navigate from page to page on the wiki. A blank page was a dead-end in a way an empty note wasn’t in map or outline view. The way past these dead-ends was to add content and links, even if only provisionally, so that the blank obstacle opened up and gave me a way to move on to the rest of my materials.

Living in note texts and making them lead one to the other through links pushed me to bring materials into existence and toward maturity in a way I hadn’t been pushed to do in my original course template.

Creating “Wiki View” in Tinderbox

A primary goal of my template revision has been to create a similar immersion in note texts and a similar link-driven push to develop materials in Tinderbox. To do this, I set my old template aside, created a new file, and:

  1. switched my preferences to hide the sidebar;
  2. created a first note called home in the initial outline view and opened it;
  3. closed the initial outline view;
  4. worked out from the home page, creating and writing new notes as I need them.

This set-up recreated my wiki experience. Note titles, which were central in my original template, were here displaced to the title bar, and my note text was pushed front-and-centre. As I write material, I added links to new notes, and used these links to navigate.

Wiki View
My “Wiki View”

But It’s a Tinderbox Wiki

This set-up is not, however, simply recreation of my wiki experience. It also improves on it in two ways.

First, links in my new template open in a new window. Some might find this annoying (and tabs are coming to Tinderbox) but without the sidebars, the note window is very compact and I like seeing and working on multiple related notes simultaneously. (Multiple windows also makes linking pieces of text to other notes very easy.) More importantly, open windows can be arranged on my desktop as an ad hoc map view but with one great benefit over a regular Tinderbox map: my note texts on this map are both visible and editable.

Second, because of how Tinderbox is built, this new way of working can operate alongside all of the course planning strategies I used in my previous template. My workspace has been expanded–an entirely new “ground level” space has been created underneath the eye-in-the-sky map views–but those map views are only a hotkey way. When I’m ready to do so, all of the notes I create in wiki view can be organized into semester schedules and content groupings just as I did in the past. Which is incredible.

(What’s even more incredible is that, although I’m working in a completely new and better way, I get the sense that, if it talked, Tinderbox would say “well of course you can do that” as if it had been designed to do exactly this new thing and had been waiting all along for me to realize it.)

Next up, how I’m cultivating a bit of confusion