Fewer Words, More Action

I've been on a bit of a spree lately here on t.org, with more posts in May than in any other month but last October, and as many posts as any two months since then. I've had a few things worth saying and sharing.

However, the next couple of months are going to be quieter. I hope to keep posting with some regularity, and I'll certainly finish up the CSSimplicity series, but I have a few other things going on. By the time August closes, I will have:

  • moved from Boston to NYC
  • (hopefully) have found a new job in curricular (Educational) Technology, hypertext, or some other form of human-related geekery
  • coordinated IT at the summer program that I work for, and done the usual shuffle from an office of 25 to three campuses of 110 staff and 400-700 students each (and back again)
  • left that job of four years, and left behind documentation and a trained replacement
  • helped a book become a website

It will be a busy couple of months. It will happen (even the new job, I tell myself), but it is going to take ... fewer words, more action.

(and if you know any schools in NYC with tech openings, drop me a line, eh?)

Mapper 2.0

The Tinderbox community comes through once again! Not long after I posted a quick exploration of exporting the Tinderbox map view to the web I began getting suggestions and further thoughts. Mark Anderson stepped up and did what I couldn't because of time and expertise-- he figured out how to get Javascript to wrangle Tinderbox's attributes into a proper display. And as this is a debugging process, he found a couple of challenges that I hadn't tested for.

from Mark

Since Mark Anderson doesn't have a blog, I'm posting a bit about the process as he described it to me in email. Basically, rather than have Javascript somehow find and then be able to change the CSS attributes once they're in the page, he used Javascript to build the page.

Clever! That results in code that is much cleaner and a bit less flexible than what I'd contemplated. I'd figured that if the page was exported directly (in its nice-but-miniature form) and javascript was used to *fix* it, then JS could be used to scale it flexibly by changing the multiplier. I suggested that and he then built another version which is ready to 'zoom'.

There were a few other challenges he overcame. For one, it's possible to get negative values for map position... shame on me for not flinging notes to the far reaches of the map view to find that. While it's okay to have negative positioning values in CSS, you don't get to see them-- Mark's code shifts all the values to positive so that notes don't start off the web page. Also, my guesstimation of "3 em" per TB map unit is just that-- an estimate.

I'm so glad he took this on, and that Mark Bernstein apparently chipped in a few suggestions ... as the next t.org post shows, there's no way I could do this coding now.

Here are some other 'gotchas' he described. Did you find them in my code? <grin>

1. You need to set the Map <div> to sit 'absolutely' below the title. I've hard wired this in both the TB (user attributes) and the templates (fixed values) but the latter could be automated.

2. You must have declared the <style> and <div> tags *before* the JS addresses them . This explains the order of some of the tags.

3. CSS 'outset' for buttons doesn't use TB or CSS colours - though you can supply the latter if you could figure how to work shades of the 'chip' colour (too much fiddling IMO). The result is flat colour button 'sides' - not the nice TB emboss shapes.

4. CSS buttons are added outwards (button gets bigger). In TB, the border is applied inwards.

5. The strange check for colour #6f0000 is a trap for TB's undefined colour value. Why #6f0000 I've no idea.

Some Assembly Required

One of the challenges I saw in my initial experiment was to make the solution drag-and-drop, plug-and-play, or what have you. I wanted someone to be able to take it and use it with their existing file and then forget about it. Mark's solution almost (but not quite) does that.

MapMyChildrenJS uses a couple of User Attributes that don't come in a new Tinderbox file, and that means that you have to add them. It's near enough that you can define them once, give them some defaults, and be ready to go, but if your file doesn't have those attributes, the result will be functional but not pretty. In my case the result was too big, and some text wrapped strangely. Not a fatal flaw by any means.

The new attribute is: MapNameFontSize , a number attribute spelled and capitalized exactly so, and with a default of "12". Without this the resulting map seems to be large.

Look at Mark's test file to see some other attributes. Most of them seem to be for testing, but there are a couple more that deserve a look, like TitleFontSize.

MapMe files

There's still no way to get link lines going, which is sad since finding patterns in link lines is a major source of serendipity when using Tinderbox. Since adornments aren't exported at all, there's also no way to display them. Even with those limitations, these templates could work well for the occasional export of a cool map view or for Tinderbox hypertexts which rely on the basic diagramming that the Map View allows.

Note that the file names are different, so if you would like to use the old (flawed) templates I came up with, they're still around. The new files are:

Tinderbox Map View for the Web ... almost

The other night on my bus ride home a stray thought about CSSimplicity touched off an idea for exporting the Tinderbox Map View onto the web. I've wanted this for a good while, but the only method I could think of for getting a working map view to the web was a screen shot doctored in the HTML to be an imagemap... not exactly a scalable solution.

However, with CSS you can specify everything about an element, from visual styling to screen positioning. Since Tinderbox gives ready access to all of the variables that make it work, a bit of poking around gave me a fair approximation of the map view with only two fairly simple export templates. There's one hurdle left that I think will require some non-trivial javascript, so before I muddy my pretty templates with javascript code, it's worth writing up the TBox and CSS bits-- along the way I learned a bit about the way that Tinderbox works and the what CSS can and can't do.

The Big Picture

The big picture is fairly simple: figure out which Tinderbox attributes correspond to which CSS properties. This meant a set of test notes:

... arranged in a rich map view where I can tweak things and see (through "Get Info" on the notes) which attributes change:

With that setup, I can have "Get Info" open and watch all the map-related attributes change as I move a note or change its color or play with fonts:

Table of Equivalents

I got the following as rough equivalencies. The ones in italics didn't fully work in my experiment.

For the Map View note (rather than the child-notes in the map view):

  • title's background-color: TitleBackgroundColor
  • title's font-family: TitleFont
  • title's text color: TitleForegroundColor
  • map area's background-color: MapBackgroundColor

For the child-notes in the map view:

  • CSS: Tinderbox
  • top: Ypos - didn't work because of units, see below
  • left: Xpos - units again
  • width: Width
  • border-width: Border
  • border-color: BorderColor - Tinderbox gives white text if the color is dark, black text if the color is light. There's no way to automate that cleanly in export or CSS
  • background-color: Color
  • font-family: NameFont
  • color: NameColor

Take Car(e,at)

Once I figured out what made what, I built the styles but put in export codes where the values should be. Word to the wise: don't forget that Tinderbox export codes can be listed with or without a trailing carat. These two are equivalent:

<p>^get(FunnyNumber) the number comes out</p>

<p>^get(FunnyNumber)^ in both of these cases</p>

However, if you want something to immediately follow the export code, you must use the trailing carat. Otherwise Tinderbox doesn't know where the export code ends:

<p>^get(FunnyNumber)no number</p>


And ... not quite.

So far I have two export templates. One, "mapMyChildren.html" which is called for each note, and which generates the html page and the 'map view'. Inside of that is this code:


... which calls another template ("mapMe.html") to make the <div> for each note. (Right-click or control-click and choose "save link as" or "download link as" to get those files, btw.)

However, as you'll note from this browser window screenshot, all is not well:

The problem is that Tinderbox's X and Y coordinates aren't in pixels, inches, or ems-- the units that CSS understands. Trial and error showed that Tinderbox's units are about 3em. But you can't do math in an export, so there's no way to say:

^get(Xpos * 3)^em;

I think there's a way around it with Javascript, and if it works it'll be nifty: you'll be able to zoom in and out with the Javascript multiplying the dimensions as you go. However, as is always the case with Javascript, I anticpate this a) taking forever and a day to code, b) taking another half-forever to make cross-browser, and c) making a Jackson Pollack painting out of my currently Mondrian code.

In other words, don't hold your breath until it's done. I'm going back to CSSimplicity later this week.

There are some other things that this could use: CSS properties to make the text wrap at a fixed note width and not to extend the div if the text is too long for a fixed height. Borders, which Tinderbox handles in a tricky way.

But, for now? I'm elated that I got this much to work in about 45 minutes. It's a testament to the transparency of Tinderbox.


surftrail is Anders Fagerjord's personal blog, and it made a bit of a splash among weblogs in August of 2003 when Anders made each blog entry its own webpage rather than taking the standard approach of collecting many entries onto a single web page.

Most blogs allow the reader to read an entry only in the context (a page) of other entries, whether the context is a chronological archive, a category or subject grouping, or a search result.

When each entry (or thought/topic in an entry) has its own page, several things can happen:

  • style is more flexible - each entry can more easily have its own visual tone through framing and typography
  • more hypertext structures become possible - forks and cycles among your entries become more apparent
  • overlapping structures don't collide - so the chronological nature of a blog can more easily coexist with categories, idea hubs, and non-categorical trails
  • if you buy into the "golden age of hypertext" rhetoric, you get to write 'more like the hypertext novelists'. and if you don't buy into the nostalgia, you still get to take advantage of the features which made the novelists choose the medium in the first place.

This is different enough that folks have started to call such blogs Fagerjordian.

Finally, a page per topic

These things appeal to me, and were part of my thinking when I started textuality.org. I hadn't really finished the implementation, though. Each post got its own page as well as appearing on various indices, but each of the topics within a post didn't have their own pages. That made linking to a topic within a post difficult-- first because the reader would be constantly jumping between otherwise-unrelated posts and trying to find what I'd linked to on the page, and secondly because Tinderbox had a hard time exporting that feature because it couldn't tell whether the endpoint of a link was a page (blah.html) or an anchor (blah.html#ablah)

So last night I finished the implementation and gave topics (Anders calls them sidebars) a template that not only makes them readable but which makes explicit where the reader has ended up. There are links to neighboring topic-pages so that the reader can continue on at the topic level, and there's a link to the post (parent) that originally created the topic. Oh! And there's a perrmalink to the topic as it appears in the post, which is where I'd rather a linker send a new reader. It means that every single character in the posts appears twice in the html --once on the topic-page and once in the entry-page-- but 'disk is cheap', and that's a small price to pay for all this freedom...

I didn't do it quite the way that Anders did. I considered it, but it's a bit limiting. Besides being a blog, t.org is intended to become a directory of readings of 'nouns' in the field of hypertext-- articles, hypertexts, people, events, etc. I don't want to limit myself to having post = noun; I want a post to potentially contain 'nouns' (some already do), or to not be a noun at all.

Blogs and social networks and wikis, oh my!

An article in CNet looks at how corporations are beginning to adopt easy web-publishing tools in their businesses... and how they're not. The article almost avoids clueless sensationalism.

Why now with blogs and wikis?

I wonder why these collaboration tools are taking off where Lotus products didn't over the last 20 years-- or only did so in select environments. Perhaps we've reached the knee of the pervasive-computing curve, and enough people 'get it' to start working by 'hub and spoke' rather than 'point-to-point' models. Or perhaps enough people 'get it' that they've learned how to transfer their business models and social networks into digital tools... after all, we've had project managers and the like doing wiki-like synthesis and management for a long time.

Syndication decentralizes

The points about blogs are interesting on another front. With thorough blogging and thorough syndication, the experience of the web becomes more thoroughly decentralized. People produce and publish information-- it's good to have so many people writing because it makes them reflect, synthesize, and articulate themselves. The tools then aid the flow of that information by adding metadata, searching for relevant relationships, aggregating feeds, and presenting it to others. It's barely even a hub-and-spoke model because the ends of the spokes only see the hub if they're wandering.

Tim Bray recently told Mac users to stop using their web browsers to read the web and pick up NetNewsWire instead. A feed aggregator certainly adds a lot to the experience (and NetNewsWire has relegated my Safari auto-tabs to the dustbin), and my fears that I would stop finding new feeds haven't come true, so I guess it's a good thing. I think that they're still tools to be used in concert, though.

Sidenote: Emergent Structure

A sidenote-- I'm feeling a split between this sort of entry and what I intended t.org for, but I can't articulate it quite yet. I started t.org intending to make post objects that discussed 'hypertext' in some abstract way, perhaps 'hypertext theory' though I haven't called it that so far. This is hypertext in the trenches, social hypertext theory. This isn't a problem, but it's an interesting trend. I'm going to map it out the Tinderbox Map View to see if a casual scatterplot reveals a Venn diagram of my post types.


I've been writing about wikis and related topics, so it's time for a collective entry. I've got a wiki definition in the glossary (the first topic herein), but there's more to be said. This is the wiki tool entry, an entry in the t.org directory for wikis en masse as a tool. It will probably collect more subtopics as I write more about wikis later. For now, it's worth relating an email discussion with Ken Tompkins about wikis in the classroom.


A website that allows users to add content and allows anyone to edit the content. "Wiki" also refers to the collaborative software used to create such a website. [Wikipedia]

An Exchange with Ken Tompkins

Ken Tompkins wrote me after the DokuWiki entry and had some thoughts about wikis in the classroom. After reading his email I had to check to see whether I'd made the post about ideas for wikis in the classroom or not. He was two steps ahead of me.

Ken has tried wikis in his own classes and had some trouble. He gave me permission to post his email, and I can't summarize it any better than he wrote it, so here it is. Links are my own:

I have tried a number of types in a few classes and have come to the conclusion that they do not serve college educational purposes well at least in the literature classroom. I have been playing with wikis and blogs for years; indeed, I run a Manila server at Stockton and each Literature major is required to have a blog. We have over 1500 at present.

The best wikis, in my judgment, are those that offer relatively stable facts; the TB wiki is a good example as is, of course, Wikipedia. These serve real needs, change when the facts change and reflect present knowledge states.

If this is true, then move the functionality to the classroom. I work really hard NOT to repeat much of the material in my classes. This means that exam questions, paper topics, lecture materials, class handouts are all fairly dynamic. If I were to move such materials to a wiki, it seems to me that I would be putting changeable concepts into a stable environment. For me, at least, and you will probably disagree, this is counter-productive.

Where wikis HAVE worked for me is where I put somewhat encyclopedic content for students to find easy access. For example, I put up considerable amount of background information on medieval medicine, astrology and theory of the humours for my medieval classes. The wiki worked well for this sort of thing. ...

This makes sense to me except for the assumption that wikis are strongest with static content. I began to argue (to myself) that the strength of wikis is that they are dynamic. The most static wikis are like coral, with a strong static center covered in a skin of vibrant (and changing) life. Like a teacher actively listening to a class discussion, wikis can help make apparent the emergent structure of the community's knowledge. George Landow's work with Intermedia functioned a lot like a course wiki might work-- a core written by the instructor which is then linked to and from by students hanging their own work on it.

An instructionist (information-transmission) style of teaching assumes a stable canon for students to absorb. The web is most useful to instructionist teaching as a reference, a rich hypertextual presentation of the canon. In that context, a wiki is merely another tool for constructing a reference website.

Wikis, though, like other hypertext tools, can be about participation. They foster a more constructivist pedagogy by facilitating and making explicit the authorship of the reader, by encouraging discussion and expansion of ideas in a collaborative setting. Of course Ken was there way ahead of me:

... It seems to me that what appeals to educators about wikis is the PROCESS. Here is an environment where constructivist thinking can shine. From this standpoint, I should have created a wiki context and then assigned students to create the medieval content that I had created for them. Fair enough except college students are notoriously uneven in contribution to such endeavors.

I actually did teach an advanced Shakespeare class two terms ago and created elaborate and clear responsibilities for posting article reviews on the plays that we were reading. The best students did the work without hesitation; the weak students (these outnumber the best by 5:1) did little, did poor work when they did it, did not understand the concept of the project or of wikis. What resulted was a very uneven set of postings and, therefore, a very limited class resource.

I think I can hear you saying: Well, the responsibility for guiding the students was yours and if you are not willing to watch them, prod them, coax them, threaten them on a regular basis, then you shouldn't have made the assignment! Exactly.

That's a bit harsher than I'd be, but it's a good point: teaching with a wiki will require a very different approach, and that may not apply to all courses and all classes. Rather than come down hard on the teacher in this case, though, I think this raises proactive questions: what scaffolding does the class need to succeed? What lessons lead up to wiki-work so that every student is interested and able to contribute? How can you set up the wiki to be ready for the students? Ken was ahead of me again (I've reformatted the list):

Wikis, then, seem to work when the following exist:

  • an eager and willing attitude about sharing content;
  • actual content to share;
  • an environment where posting can be mindlessly easy (blogs come to mind);
  • an environment where users can glean content easily and quickly (my biggest complaint about wikis is that they are generally ugly and exceedingly hard visually to get content out of quickly and easily);
  • a wiki language that is easy to learn and use; and, today,
  • a place where the spammers cannot enter (this latter is critical on the TB wiki and is the reason I have locked my wiki up). I also think that they work best when the content is fairly stable.

To that list, which focuses on what the wiki needs, I'll add:

  • preliminary excercises to get the class accustomed to hypertext authoring; and
  • clear guidelines for expected participation levels, styles, and locations ... though take care not to proscribe the creativity.

I also note that DokuWiki, from my experience, does well at addressing the ease-of-use, clarity, and protection concerns Ken raises. He also noted in his email that he's enjoyed Moinx and Tiddlywiki. I haven't tried them, though a quick glance at Tiddlywiki excited me about the possibilities for creating a linear projection of a hypertext reading experience.

Exchange 2 with Ken: technical hurdles

I replied to Ken's email with a fraction of because of timing. Thinking more about the wikis I know, there is a tough balance to strike between dynamic and static content. It's easy for the dynamic 'noise' of a wiki to start obscuring what could be the stable reference material.

Further, in the classroom, the overhead required to have students build equally, productively, and in a manner you can usefully assess might be more than wikis are worth as a tool. George Landow found some ways around that problem a while back, or missed them entirely somehow, and I'll have to finish reading Hypertext 2.0 to see how.

Ken went on to point out a problem that I had when I tried to work hypertext into my public school student teaching:

The pedagogical problem with desktop programs -- Radio, Moinx, Tiddlywiki -- is that students don't always have reliable access to a computer, can't always install something, don't have a mac, etc. so one is forced to use more centralized servers. It's a shame because some of the desktop functions are powerful.

I haven't played with desktop-based wikis, and am curious to see and hear about the advantages.

Wikis Flattened the Earth

Irving Wladawsky-Berger, VP of IBM, is quoted in The World is Flat by Thomas L. Friedman:

This emerging era is characterized by the collaborative innovation of many people working in gifted communitites, just as innovation in the industrial era was characterized by individual genius.

Will R. of Weblogg-ed adds, in a discussion of the book, that

We are still in a model that awards individual genius more than collaborative innovation... yet in an exceedingly more 'open source' world, contribution is the expectation.

In agreement, I'll say that wikis can be an excellent tool for breaking out of that educational model. Wikis require collaboration and make explicit the student's engagement with the published 'canon'. Blogs teach that lesson on the large scale as the student's outbound links (and inbound replies) form a broader discursive hypertext; wikis teach the lesson on the local level as students edit what becomes a consensual text, refactoring their own work, and developing their own local canon.

More Wikis

things to check out in wiki-land. Broken links are my newly-created and unpublished root-tips in the t.org Tinderbox file. (I do need to make a 404 page that says "don't sweat, you've hit the edge of my reading-tree")

Matt Barton: there's a continuum for eduwikis

"Matt Barton explains what the heck a wiki is, and why compositionists ought to use them in their classrooms"

So says the abstract of the article, but what catches me is:

  • his explanation of 'the wiki way', the philosophy of a wiki (though he's not so high-falutin' as to call it that)
  • his examination (and judging) of potential wiki applications

The latter is great! He lays out a continuum of applications stretching from 'antithetical' to 'philosophically compatible with the wiki way'. Rather than say the 'wiki way' is for some reason better or best in the manner of a hammer seeking a nail, he notes that applications that work with the 'wiki way' are going to be aided rather than hindered by the medium. He's clearly thought through the philosophy and how it plays out in a wiki and applied that to some likely classroom applications. Yes: reference guide. Bibliography. Editing of a document. Textbook. No: personal site/portfolio. Argumentative essay. Novel.

TSOR on his site doesn't turn up clear links to wikis by his classes, but he does have some forums which are worth a real look.

About Tikiwiki itself... I don't like the cluttered interface on his site, but it does look to be full-featured as a wiki-centered community tool. It's got a wiki for educators, though that seems to be largely moribund. It's worth a look sometime.

Educational Wiki Links

At some point I'll get to read all these. In the meantime, they look heavy on content:


Thanks to Mark for the nifty quotation style which I installed tonight. He set up a smart style on his own site which I've transferred to t.org.

CSSimplicity p.2: Now With Style

Last week I wrote in a series of entries about adapting the Tinderbox Simplicity template to CSS. The first step was to analyze the existing template to glean its structure, and I marked up the stylesheet and the html of a sample page to do so.

This next step, then, is to move it over to CSS. I'm going to take it slowly and with lots of explanation, because figuring out exactly where CSS ends and HTML begins was tricky for me.

Two disclaimers: First, I'll walk things through, but I'm assuming that you have a very, very basic level of CSS. I'm assuming knowledge of CSS Syntax. If you're not sure, scan that link-- that one page is what I'm assuming you know.

Secondly, I'm being "thorough", by which I mean that the end result will be a bit more complex than the Simplicity template. The HTML will be simpler (without the tables), and the templates will be simple and easier to edit, but the stylesheet is going to be rather longer than the old one so that more of the page is stylable. That extra complexity will hit in this post, so if it seems confusing, shake it off and go to the next post.

I'm being thorough for two reasons: First, I want to be able to do CSSZenGarden-like styling, and that means having the CSS mirror the semantic structure of the Tinderbox notes. Secondly, being this thorough means that the CSS can mirror the semantic structure, and that in turn means that your visual style can more clearly indicate the semantics. I.E. You can make your blog easier to read and navigate.

The whole thing is turning out to be a bit more of a process than I thought, so it might take two steps. Here goes.

Templates Wanted: Inquire Within

Looking at the marked-up sample page from the last step, there are several things going on. The table breaks the page into four main parts: a header, a sidebar, a body, and (outside the table) a footer. Inside of those sections, we know by the structure of the Tinderbox file that we have several 'sidebar' notes (About this site and blogroll) and several 'body' notes (Each note is timestamped and Design by Derek Powazek) and several 'footer' notes (Navigation, Copyright).

An export template turns a Tinderbox note into a chunk of HTML, so to produce that page we'll need templates that produce the HTML for the sections of the page that come from notes. We'll need

  • a template that produces the page (bwPageTemplate.html)
  • a template for the body notes (i.e. the blog entries, item.html, which we'll make "post.html")
  • a template that produces the stuff in the sidebar (sidebar.html)
  • and a template that produces the footer.

We don't need any other templates yet because the other stuff --title, 'made with tinderbox' logo, dividing lines on the page-- don't correspond to Tinderbox notes. They're just HTML.

Here's a quick picture made in the Map View out of adornments which shows the structure of the page and its html templates. I'm not sure why the names are of different brightnesses.

And, in fact, we have those templates. We just need to adapt them to use CSS.

Templates, Level 2

A quick note before moving on to styles: We're fine right now if we want to create a site just like Simplicity. It has pages with a bunch of entries on them, and the entries are one TB note each. That's all. If you want to do more, your templates get more sophisticated accordingly:

If you want your entries to have child notes, you'll need a template to make them appear on the pages.

If you want your entries to be pages unto themselves so that you can do "crazy things" like link between them (I've heard the term "Fagerjordian" applied for Anders Fagerjord's Surftrail) then you'll need a template that is ready to put a post on a page rather than a bunch of posts.

If you want to combine these ...say, *blush* have entries appear one way on the front page of the site and a different way on their own unique post-pages, plus have child notes in both cases... well, I'll get to that. Someday.

Styles Wanted: Inquire Within

CSS is very flexible. Styles can be any combination of attributes you might change about text. Styles can "cascade", meaning that if you tell a paragraph to be green, and then have a style that's bold but doesn't have a color applied, the 'green' cascades down into the bold section so that it's green and bold. When you take a bunch of styles and group them to apply to text, that's a class, a class of text. So we need to figure out what classes we need in our stylesheet.

We need classes(s) for all the situations where we want to affect the appearance of the text. If we want the ability to have our posts outlined or in a color or spaced a certain way, then we'll need a style for them. If we want the sidebar to appear in a certain place on the page (or have the flexibility to appear on the left or the right without changing our HTML templates) then we'll need a class for the sidebar. If titles are bold, we'll need a class for them. If links are colored and get an underline when you put the mouse over them, as is the case in Simplicity, then we'll need a class for links.

So, brainstorming, we might want styles for:

  • the header section (to position it)
    • the title of the blog
    • the tagline of the blog
  • the sidebar (to position it)
    • the individual notes in the sidebar
      • the title of a sidebar note
      • the body of a sidebar note
  • the body (to position where the blog entries appear)
    • the title of a post
    • the body of a post
  • the footer (to position where the footer goes)
    • the text of a footer note

In the case of Simplicity, we've got a few exceptions to the style of the sections:

  • links
  • dates of posts
  • list items that appear in the sidebar

Note that I'm being (overly?) thorough with that list. The original Simplicity gets away with styles for just: text, heading, tagline, date, sidebar-head, sidebar-list, link.

IDs, Divs, and Spans

To replace the tables in Simplicity, we'll want two different kinds of classes: classes which determine the appearance of text wherever it is on the page, and classes which determine where on the page the sections are (basically, which replace the table cells). We can't conflate the two because then we'd have all of our ... oh, blog entry titles appearing in the same place on the page, or we'd have our sidebars all over the place (but pretty!).

The final html page will have style classes applied in this structure, then:

Notice how this mirrors the structure of the html export templates on the page. This means that the html export templates are going to be pretty simple (in the next CSSimplicity post).

Building the new stylesheet

In CSS, if you want a class to apply to only one <div> then it gets an ID Selector, and appears in your stylesheet like so:

  1. classname{stuff}

So all those styles which place things on the page are going to go in our stylesheet as IDs.

  1. headerFrame{ /* the frame around the entire header */ }
  2. sidebarFrame{ /* puts the sidebar in place */ }
  3. bodyFrame{ /* the frame around the whole body, probably for positioning */ }
  4. footerFrame{ /* puts the footer in place */ }

Then we can put in the classes that will get applied one to each note. There will be many of these, so they're a regular class. On the other hand, we supposedly don't know what sort of html thing these might be applied to, so we'll include them as classes independent of the html element. It's almost always going to be a <div>, but we need to be open-minded so we'll leave out the selector.

.blogtitle{ }

.blogtagline{ }

.sidebar{ /* an individual sidebar */ }

.sidebarHead{ /* the head of a sidebar piece */ }

.sidebarBody{ /* the body... */ }

.postHead{ /* the headings or titles of the blog entries */ }

.postBody{ /* the text of the blog entries */ }

.footer( /* in case we want to surround multiple footers like sidebars */ )

.footerBody{ /* the text of the footer */ }

We can't forget the basic HTML selectors, which we can bring right over from the old Simplicity stylesheet. These should appear at the top of the stylesheet, but we'll get to that:

a:link { /* each of these from before */ }

a:visited { }

a:visited { }

a:visited { }

p { /* all paragraphs will get this unless the others override it */ }

body { /* will define the way the body appears, unless overridden by bodyframe */

We Made Progress, right?

Now that we know what the styles should be, we can plug in the old styles. Add some comment headings for readability and we have a stylesheet framework.

Next up: Ridiculously simple template making.

ETA: Added pictures

I realized that the diagrams I've made of the html page re: exports and re: classes might help, so I've added them and moved the text around a bit.


I've gotten in on the badge-sharing that has been going around. There's now a "BBEdited" button in the sidebar, made from Vlad Spears' photoshop files. and you're welcome to it.

If you want to make a suite of your own "80x15" badges, there are some nifty tools out there for doing it: one that seems to have started the trend (and generated some controversy) and one that lets you put in small images. I didn't use either because I liked the 'pop-out' graphics of the 2Second(Fuse) badges, but it's a place to start.

ETA: BBEdited

Vlad Spears posted the photoshop files for the 'badges' on his site. I adopted several and made one to pass the love to BBEdit. I've done all my HTML editing (and a fair bit besides HTML) in BBEdit since 1997. Feel free to grab and/or cannibalize my badge for your own site.


I've just installed DokuWiki at work, and I have to say that I am nothing but thrilled with my first real wiki-founding. Warning: the rest of this entry is almost entirely positive... fanboy-ness ahead, even if it is followed by actual discussion of wiki social issues.

Why Wikis Rule

Many, many others have written about why wikis are wonderful. I think that there are two reasons that most others reduce to:

  • easy distributed hypertext editing
  • wiki syntax lowers the linguistic barrier for hypertext authoring-- wiki creation is somewhere between Storyspace (easy) and HTML (markup, but still harder)

There are certainly nuances and implications to these. You can do a lot more with HTML, but wiki syntax makes markup simple enough (reason 2) that it is a negligible barrier to entry. Wikis do some of the 'book-keeping' for you by automating some links and telegraphing the status of a link's destination (reason 1). The reader and the writing tool are the same (the browser) and are almost universally available (reason 1). Most wikis flatten text/file hierarchies, making a text's structure flexible and removing it as a barrier to editing (reason 1 and 2)

Wikis are excellent for having a group of people who may not be in the same place, may not have knowledge of HTML, may not know the structure of the overall text, and may have better things to do than worry about those things (like writing) focus on the writing.

The fact that wikis (and, to be fair, their predecessors) are now making the terms 'read/write web' or 'two-way web' usable shows that there is a ease-of-use cusp, that wikis have pushed us past. It's so much easier that it's something different.

Why DokuWiki Rules

  • First of all, it's called "dokuwiki". Dah-kyoo-wih-key. It's fun to say.
  • It keeps all the wiki-syntax source in flat text files, making them editable by other programs
  • Nice, clean, mellow stylesheeting
  • It automates hierarchy within a page, building an index of your headings at the top of the page if you have more than three.
  • It sounds like it was taken from Zelda. (hm... the author's site icon is a nut... and it is all about links...)
  • It has more sophisticated features available but not required, including
    • permissions via ACL
    • 'namespaces' which serve as directories for pages
    • built-in site index showing extant pages in an expandable outline form
    • complicated structures like tables
    • interwiki links
  • link typing - automates internal, external, interwiki, and acronym links
  • it's open source PHP on Apache-- common tools.

Installation was even easy... after a fashion. To install it on OS 10.3 I needed to have Darwinports. Darwinports required XCode, which wasn't on the machine I wanted to use. I installed XCode but couldn't get Darwinports to install after about two hours of trying. No love came from the Darwinports list, so I gave up and tried an Aqua app. That kept everything in a database, though, and was ugly and low on features to boot. Then... I installed DokuWiki on my company's hosted webserver and ... a half hour later it was running with ACL security active and HTML enabled. Wow!

An Authoritative Author?

Now my wiki-for-work is my first wiki, and is less than a month old, so I'm shooting from the hip, here. That said: I think that a wiki intended as a source of information, even one which is a collaboration between true peers, needs an organizational vision. An authoritative author or authors, or more delicately, an Editor. A wiki intended as a forum is a different thing, and might be more free-form to allow for emergent structure. This seems to be a philosophical schism in wiki authorship; the strength of a wiki is in the ability of every member of the community to contribute, be it with questions, answers, theories, evidence, or signs of cluelessness. All of these are helpful because the wiki can then accurately represent the structure of thought in the community.

But it can also then get pulled into the confusion or the discord in the community. If the goal of the wiki is to represent the 'state of the art' for a community, the emergent structure is important to see even when the structure is 'conflict'. But when the goal of the wiki is documentation, to help bootstrap most of the readership to greater knowledge, then that discord will more likely lead to frustration and abandonment before it will lead to epiphanies about the challenges the community faces. It seems that a greater authority, even in the form of an active moderator (rather than author) may help by setting down the spirit of the community, by providing a vision that the 'cats' are more than happy to be herded by. Regarding wikis aimed at documentation or user support, I side with the authoritarians with the caveat that a good wiki will have areas where open discussion, questioning, and tinkering is clearly welcome.

For instance, the Tinderbox Wiki evidences (as of this writing) that people don't know where to find or place things. Has their comment been replied to? Is the question already answered over in the [FAQ]? Or is that the [Frequently Asked Questions]? These are dummy examples, but the point is: without a clear framework for us to build upon, all the good will in the world is going to be hidden within a tangle of different conceptions of how documentation should work.

And this is done with the best of will. What we could have is a body of documentation which is criss-crossed by trails established by as many indices as we have perspectives on the material. Once the material is there... want an index (linking edit-discouraged pages) for YourFirstDayWithTinderbox complete with narrative context? Sure. How about ProducingPHPFromTemplates? Sure. But without a clear sense of what is an answer area and what is a question area, where discussion should happen and where plain description is, those indices are likely to start bearing content... which someone else won't know is in ProducingPHPfromTemplates and not HowToMakeTemplates or ExportTemplates.

We're already running into this issue in our work-wiki because we're refactoring an old html-based documentation site into the wiki. We have it easier than Tinderbox (or Wikipedia, etc.) for a few reasons, though. Ours is a documentation wiki, and the work we're documenting has a clear structure-- several constituencies with discrete functions and tasks. Several namespaces are clear and useful: summerNetworks and summerSetup vs. yearNetworks and yearSetup. There are grey areas when something applies to several constituencies, but those are by far the exception, and when they pop up I as head of the department can determine policy. We'll have discussion, but most of it will happen offline, so the wiki doesn't need to deal with it.

The answer, as usual, probably doesn't lie in either the extreme of control (restricted edit privileges to the site or hard-line 'fixing' of edits) or of freedom (unmoderation). From my lack of experience as a wiki moderator I wonder whether there isn't a happy medium in clearly defining portions of sites or pages where edits and discussions are encouraged and portions where edits by anyone but the 'editors' are allowed but socially discouraged.

The software I've played with attempts to solve this with software. One package made the easiest way to edit be a 'comment', which was just a wiki editing window that deposited the typed text onto the bottom of the page in a write-only fashion; edits to existing text were still possible but required clicking through the editing process. Dokuwiki doesn't do that, but the top of the edit page asks: "Please edit the page only if you can improve it." I like that sort of social solution.

So much to read on Wikis

There are many, many interesting pages out there about wikis.

For history, there's the original WikiWikiWeb, started in 1995. There's Wikipedia, (can it be called the currently most popular or successful wiki?) and their entry on wikis.

MeatballWiki is a meta-wiki for "a community of active practicioners striving to teach each other how to organize people using online tools." It has neat discussion of social challenges like ForestFires, BarnRaising, and DocumentMode vs. ThreadMode.

Weblogg-ed discusses "The Read/Write Web in the Classroom", often including wikis. I'm really interested in wikis in the classroom... including the failures.

ETA: DokuWiki Review

Someone wrote a nice quick review of DokuWiki which I agree with and hosts a Word file-conversion tool. Can't figure out who, though, because their site doesn't say anywhere.


I've come up with a title for this post that makes it sound like a musical, but the fact remains: I've put up a simplistic rss feed for textuality.org. I'm still playing with it --trying to include html and links rather than just plain text broke it for LiveJournal and NetNewsWire-- but it is up and working. Thanks to Doug Miller for suggesting the feed and for advice.

ETA: Full Text

As this edit indicates, I've changed my RSS feed so that it does full text on the entries and doesn't break. I'd been holding off on full-text because I couldn't get html to work, would have to add children and build a template for them, etc. Alwin pleaded to the world at large, Doug Miller sent advice, and now it's working.

It still doesn't validate, so I've got some work to do. Once it does, I'll post some advice. The (several-year-old) Simplicity export templates have a few problems out-of-the-box and it can take a while to figure out the fixes if you're new to syndication. In the meantime, here are some sites that explain how to set up your own RSS feed. Tinderbox (and the Simplicity template) does a lot of the work for you, but if you're having trouble, these might help you diagnose the problem.

CSSimplicity Step 1: Analysis

I'm making some new templates for Tinderbox. I'm doing this because I think that Tinderbox could use some well-structured, simple, elegant templates that really use CSS. I'm doing this because I think that CSSZenGarden is one of the coolest sites I've ever seen. I'm doing this because it's hacking in one of the nicer meanings of the term. While I'm at it, I'm going to log the process so that you might follow along if you're learning Tinderbox, CSS, or both.


Overall, the editing process is simple:

  • vivisect the current design - tweak it and see how it works
  • edit its structure by editing the templates - so that you get a page that looks like it has but works the way you want to
  • edit its stylesheet - until it looks the way you want

In practice, I have found it useful to take a sample file of output (you do have that "index.html" from the old site handy, right?) and make its html look great with the new stylesheet, then chop it up to make the templates behave accordingly. That's mostly a difference in the way you do step 2, though. You might have more success, especially if you're just experimenting with stylesheets, if you follow the process summarized above and detailed below.

Make the old elements visible

First I had to vivisect the existing stylesheet, which to me means exposing the innards by making the elements visible. I went in and gave borders to all the named styles in the stylesheet. To each style I added:

border-color: #000;

border-width: 1px;

border-style: solid;

... I left html entity styles alone, so this stayed:

a:link { color: #06f; text-decoration: none; }

The resulting page got ugly, but I could see where styles were (and even more usefully, weren't) used:

I left some of these borders in until I was done. I also then made the table borders visible:

<table border="q" width="85%" cellspacing="20" cellpadding="0"><tr>

Now I have this, and I can see where everything is. If I really wanted to, I could start adding colors to the styles or to table cells in order to pinpoint specific elements.

I think I've got it down now, though. The next step (and the next entry) will be to make a new html file, and from it new templates, that are ready to give that same layout but with CSS rather than tables. It's worth asking-- why? There are two reasons. First, by making your html use CSS you're separating the content from the presentation. The html that results is *much* easier to read because it pulls the html junk out of your beautiful entry. Secondly, if you are using CSS to change the layout, you can do crazy things like CSS Zen Garden does. If I have my way, the end of this process will be one set of templates, three stylesheets, and three completely different looks.

ETA: Actually, Styles

I was going to to tables ->CSS next, but that will have to wait. I need to .


Wholinkstome is an interesting tool for wandering back upstream I found in NoCategories. I wonder if it works. It checks the referrer logs and then searches for the referrer among a variety of sources. All this for the lack of structured two-way links on the web. Here it is with their code:

Who Links Here

[2005-05-03] It basically just aggregates results from available searches on Google, Yahoo, MSN, and a few sites you have to be registered on. Ah well.

Hypertext Among the Blogs

One of the wonderful things about personal weblogs is how they cross categories. I may for this site start reading a blog because it mentions hypertext on a regular basis, but then I get to read about good food, or electronic music, or real estate... and maybe how they relate to hypertext. And if I'm really lucky, the blogger has properly categorized their entries into a nifty index.

I don't want to add all of these blogs to textuality.org because this site has a sharp focus which I want to maintain; nevertheless, I think t.org needs a collection of the relevant categorical focii from them. So in this entry, the subtopics should end up in the Categories list rather than this entry itself, and each is the 'hypertext index' from a spiffy blog.

And yes, for the record, I hate the term 'blogosphere'. I want a term for 'the set of weblogs' that doesn't sound like a 1st Edition D&D monster.

The Great Lettuce Head on Hypertext

Steve Ersinghaus' Great Lettuce Head touches (as advertised) on: fiction, English Literature, New Media, Writing, and technology in education. And it has a hypertext category.

Something Different on Tinderbox and Blogging

Doug Miller doesn't have a hypertext category in his blog per se, but his Tinderbox, blogging, and education categories are all relevant to t.org's interests.

NoCategories on Hypertext

Dylan Kinnet's NoCategories' largest or second largest ... category ... is on hypertext.

Kottke on Web technology

Kottke.org doesn't have a category on hypertext exactly, but does have a section on web technology, and that seems to be where the hypertext issues that I'm interested in fall. I need to write about "hypertext" vs. "the web" since that's such an FAQ whenever I mention the term.

URLGREYHOT on Information work and Education

Michael Angeles confusingly lists URLGREYHOT's categories as separate blogs. Regardless, the content is interesting and the topics closest to the heart of t.org are the information work blog, Education, and the Education blog. Even if he is into homeschooling.

It looks like "Education" is separate from the "Education Blog" in that, like t.org, the site contains things which are outside the blog and exist in a broader hypertext.