University Lives Collection Launch
Monday, 12 Oct 2009 :-: ["Permalink"]

Last Thursday, we launched the University Lives Collection in conjunction with the announcement of the World University Rankings by the Times Higher Education.

Now it's time to finish the full site in preparation for our launch on November 16.

The Shepherd and the Table
Sunday, 11 Oct 2009 :-: ["Permalink"]

In my triple life of software engineer, executive producer, and serial volunteer for things in Cambridge, one of my favourite activities is a weekly gathering with people from the Christian Graduate Society at Cambridge University. Some people in this particular study (there are many CGS studies throughout Cambridge) are Christians, some are not, but we are all interested in looking at and discusing the canonical texts of Christianity.

Our group recently started a blog, which I am editing. I thought you would enjoy reading this post, which describes a discussion we had about Psalm 23.

The first in a series of poems we have studied from the Psalms this summer, the 23rd Psalm is the the best known. In the English tradition, it has inspired poems by George Herbert, Isaac Watts (3 poems!), Henry Baker (whose version was sung at Princess Diana’s funeral), and hundreds of musical compositions by many famous composers, including Tchaichovsky, Pink Floyd (satirically), Rutter, and Leonard Bernstein (choirnet listing).

Reading poetry from another culture and time is a wonderfully rich experience with significant pitfalls. Our imagination fills in details, as it ought, and can bring up strong memories and ideas that we hadn’t been able to express before. As a piece of writing from another place, it reveals things about the perception of someone from that place. As a result, we risk either letting our personal response overpower the poem itself, or alternatively, keeping the poem at arms-length. When we read translated poetry, we unearth yet more richness and peril.

Since we have spent most of the year studying writings which attempt to explain ideas, we started this discussion with the questions, “what use is poetry to Christians? What role does it play in your life, and what would we lose if we got rid of poetry?” People discussed:

• Songs in public worship gatherings, and how lyrics written by someone else make it easier to affirm a shared understanding of the world, even when we’re too tired to think creatively.
• Particularly well-put phrases that stick with a person
• Moments when we feel like a poem expresses something we often wanted to say but never knew how, and that the poem somehow seems deeply true in a way we instantly recognize
• Ways that poetry gives us new ways to look at the world
• Opportunities to imagine ourselves in a position similar to the narrator, or to draw hope from the similarity of our situation to that of the narrator.

Next, we looked at the poem itself. It is customary in Christianity to focus considerably on David, who is said to be the author, or on the art of shepherding, or on Jesus as the Good Shepherd. In this study however, we decided to look closely at the poem itself.

The group made several initial observations about the poem:

• Psalm 23 was apparently a favourite song of religious pilgrims as they traveled to the temple in Jerusalem.
• Two clear extended metaphors: “The Lord” as a shepherd, and also as a host. The amount of detail in the metaphors seemed quite unusual in the Psalms.
• The use of present tense (”he leads”, “he restores”, “he guides”) suggests intimacy, or at least familiarity with The Lord, arising from his repeated goodness toward the narrator.
• The poem isn’t organised in the classic Hebrew couplet form. In fact, only a few parts of the poem follow the statement-and-elaboration form so common in Hebrew poetry of the period.
  • He makes me lie down in green pastures,
    he leads me beside quiet waters
  • You anoint my head with oil;
    my cup overflows.
  • Surely goodness and love will follow me all the days of my life,
    and I will dwell in the house of the LORD forever.
• Apparently, “anoint” is not the word used of kings or of the messiah, but rather a reference to fatness and plenty. It can also mean “saturated”, in a probable pun connecting the overflowing cup with the anointing of God.
• “be in want” could also be translated “be deficient”. The Psalm is purposefully generic in ways that could be understood as ( other / more ) than simply material.
• The table “in the presence of my enemies” isn’t an scene of reconciliation but one of antagonism.
• “in the presence of my enemies” suggests that the hospitality metaphor is from a refugee’s perspective.
• The poem shifts from “he” to “you” when discussing the presence of the Lord in difficult times. (this also happens in Psalm 73, which we studied a few weeks later)
• The image of God as shepherd first appears in Genesis 48:12-16, when it is used by the historical character Israel to describe God’s activity in his life.
• Subsequently, the term is used of those who lead the nation of Israel:
• Of Joshua, when Moses hands over leadership to him in Numbers 27.
• Of David, when the people ask him to become king in II Samuel 5.
• Psalm 23 is a political poem, since the king— the “shepherd” of Israel— is declaring the Lord to be his shepherd.

After initial observations, we discussed a wide range of topics relating to this poem.

Some in the group shared stories about times when this poem was especially meaningful to them.

Others were keen to draw correlations to the life of David and specific moments in his life. Some were skeptical of this exercise, since we have no indication of the time the poem was written, and since the poem’s simple imagery and personal pronouns make it seem like it’s written for everyone to identify with, not just the king.

Some excitedly described comparisons between the shepherd and Jesus, who explicitly links himself with this poem in the gospels when he says “I am the good shepherd.”

One person thought that it is invalid to seek learning from the makeup of a metaphor, or from parallels in the text, unless the function of a poetic technique is intentional. Since authorial intentions from antiquity are opaque to us, we should take care building conclusions from features of the text which aren’t explicit statements. While we do and can draw conclusions or sentiments from a poem, it was argued, those outcomes are less valid than carefully constructed theological arguments or cross-referencing and correlating a text with other parts of the Bible.

Someone else, on the other hand, thought the poem illustrates power of literary metaphor to engage with the fundamental difficulty of perceiving God. In this view, this poem attempts to express the love of God, even though the life and thoughts of God are too great to be fully comprehended (Ps 139), and the love of God surpasses understanding (Eph 3). Accepting that the span between God and humans is too great for humans to reach, the poem compares this span to the relationship between a shepherd and sheep, between a refugee and a generous host. This vast difference is spanned by the Shepherd who cares for fundamental needs, illustrated by the water, paths, valleys, shadows, tables, cups, and homes. In this view, the poem demonstrates, by using the rhetorical device of metonymy, how to see an invisible God: just as we understand that “rod and staff” refers to the shepherd, that the table and the wine illustrate a generous host, we know God’s presence through the instruments He uses in the world.

Finally, our group discussed the end of the poem. The narrator expects to dwell in the house of the Lord forever. Christians see our current lives as a journey in which we are led by God to follow the paths of righteousness, and hope for a life with him forever. Yet by illustrating the work of the Lord for those on the path of righteousness, the poem implicitly warns about how tragic life can be for those who chose against following him on those paths.

Although this discussion opened up many more questions than it answered, we all agreed that Psalm 23 presents an attractive view of knowing God, and that this Psalm carries special hope and comfort for Christians.

P.S. John Piper and Tom Steller have posted two fabulous sermons about Psalm 23 online on Desiringgod.org, which they preached in the 1980s: The Lord is My Shepherd, and Restful Words for Labor Day.

Plans For the University lives Collection
Sunday, 20 Sep 2009 :-: ["Permalink"]

Last weekend, I caught up with Sylwia Presley, in-between her preparations for the Oxford Twestival. She's one of the organizers of BarCamp Transparency Oxford 09, editor for Global Voices, and a social media / word of mouth ethics consultant for 1000Heads.

Our topic? How can the University Lives Collection reach out to students worldwide, and how might the way we set up the project affect our reach?

We had a great conversation about motivations. The people who submit videos will be people who take pride in their communities, who are looking for PR and poularity, who think the prizes are cool, whose professors are suggesting they submit videos, and who are driven to spread their viewpoints. In addition, we need to be aware of the the organisations and governments of which our participants are a part. Sylwia had some great ideas on how to make the site acceptable to such a wide range of groups while keeping our own integrity.

This led us to the question of censorship, moderation, and permission. This is an ongoing conversation for us, and Sylwia's experience with Global Voices and cyber activism will help us take into account the needs and risks of content producers. We want to be as open as possible, but we also want people to stay on-topic and will frown on inflammatory content.

As a result, we think we can probably open up the platform more than we initially expected, allowing people to post, comment, and vote on videos. We expect that there will be an approval / moderation arrangement for new videos, but we still have to work out the details ineternally and with Automattic.

We are definitely going to offer prizes, and there will be a way to vote for videos you like. We want to be careful however, to avoid getting Colbertized. So no details on the voting system have been decided yet.

Sylwia asked if we will accept videos from faculty. Our answer? That would be great! - though we will focus our limited marketing resources on students.

She was also wondering what countries we want to be involved. The short answer is 'as many as possible', but we have only so many people. Consequently, we're going to pick a few regions to focus on; for other regions, we're going to look for organisations or new volunteers/promoters to do the advertising for us.

We also talked about language and subtitling. We had initially planned to accept videos only in languages known by our team. Sylwia convinced us that we should accept videos in any language, so long as they're subtitled in English. JBL thinks we should be even more open than that, so we still have some deciding to do.

Even though we are already familiar with social media and online publishing, Sylwia has done a great job helping us think through important issues and make good plans. We're looking forward to more strategy conversations in the future.

For now, we're focusing on getting the initial marketing site up, fitting our visual designs into the technology, and organising our fabulous volunteers for what is going to be a huge marketing campaign.

if you would like to help out the World University Project or can suggest ideas or contacts for the University Lives Collection, please contact planning [at ] worlduniversityproject [ dot] org

Automattic, Inc. Sponsors the University Lives Collection
Friday, 18 Sep 2009 :-: ["Permalink"]

Great news! Those of you who have been following the World University Project will be delighted to hear that Automattic, the creators of WordPress and the team behind Wordpress.com, will be providing hosting and technology for the University Lives Collection!

This is the beginning of a new road for us as a charity. Ever since filming in Libya, we have been establishing the organisation and building support. Now it's time for action.

We have a lot to do. There are plans, policies, and designs to be made and finalized. Publicity is going to be a huge task. Happily, technology *won't* be a headache, due to the generosity of the people at Automattic.

We owe a lot of thanks to those who have been involved.

• The Trustees: Joao Pereira, Braphus Kaalund, and William Redfern, have provided helpful perspective and carried out the key decisions throughout this past year.
• Tom Isherwood has provided critical assistance, leadership, and support
• Gloria Dawson managed the project initially, in-between a triple life as a poet, an intern/consultant on humanitarian policy & advocacy at Oxfam International, and a research assistant in the House of Lords.
• Joshua Blanchard Lewis is the current project manager for the University Lives Collection. His hard work, sound advice, and keen ethical sensibility have been fabulous.
• Karen Collis has been a great encourager and supporter of the project, and has been a star of the cold calling and email campaigns.

Barcamp Transparency Oxford
Wednesday, 29 Jul 2009 :-: ["Permalink"]

This past Sunday, I spent a day at BarCamp Transparency Oxford, at the Oxford University Club. It was truly fabulous. Many thanks to Sylwia, Marcus, and Ben.

Met lots of fabulous people, including Rob McKinnon, Wojciech Gryc, Brett Husbands, and Alejandro Ribo Labastida.

I also had a very helpful and thought-provoking conversation with Talal late into the night about how to be an academic that truly cares for people, especially students, in a whole sense. Inspirational.

Thanks to the sponsors:

• Google
• www.1000heads.com/
• www.dontreadmyblog.com/
• outmap.org/
• uk.moo.com/
• www.terminatetherate.org/

Jessica Rubart Gives Suggestions For Tinderbox Collaboration
Sunday, 26 Jul 2009 :-: ["Permalink"]

Following on my series of posts about collaboration and Tinderbox (especially the one about patterns for teams to follow), Jessica Rubart sent me this truly staggeringly-fabulous set of suggestions.

Jessica is an experienced team manager, and a researcher on the use of Tinderbox-like spatial hypertext for team-based activities. Her latest project (brilliant) is an app which uses spatial hypertext to plan Scrum Meetings (more about scrum).

• Meeting structure:
  • Describing an agenda (notes in a column)
  • Adding references to documents (e.g. URLs)
• Team structure:
  • Persons and groups, e.g. through a composite note
  • Organizations and persons, e.g. through additional composite notes and aliases
  • Persons and roles
• Process structure:
  • Task notes as composite notes containing relevant document references
  • Workflows, i.e. task notes, process links, and maybe links to team structure
• Group forming (E-Learning):
  • Group areas for joining
  • Group recommendations through agents based on profiles of persons in the model
• Project plan:
  • Priority lists through spatial arrangement (E.g. Task lists for persons with dependency links to other tasks)
  • Date attributes for tasks
  • Status adornments for tasks, e.g. within a person composite note
  • Scrum-like task boards using adornments for setting tasks states (a state could be an attribute) and an agent for generating a sprint burn down chart from a current task board (this is good -- Nathan)
• Goals
• Recent changes:
  • In addition to a description of changes it might be useful to include a status of the tinderbox file or an area, saying e.g. that a review of person or role xy is required.
• Landing areas:
  • Adornments for groups of people who get the notes by e-mail, which one drops there
  • Adornments as a kind of todo-lists for users work items can be dropped there; after a user has completed the work on an item, he/she can drop it on the todo-list of the following user.
• Cooperative access:
  • Use version control and visual diff :-) (by this, Jessica is referring to my ongoing work on comparing changes in Tinderbox files)
  • Further development could think about splitting a tinderbox file into several parts that could be put into a version control system separately. Then, those different parts can be locked by different people at the same time so that simultaneous work on different parts of the shared model is possible. Alternatively, one could use different files for each part. But then linking between those might be constrained.
  • Use application sharing for synchronous access, e.g. through WebEx (Nathan: This is a great idea)
• Brainstorming/Mind Mapping:
  • Use application sharing for synchronous sessions
• Mashups:
  • Composing notes from different files or different areas of one file
  • Providing a merged view of notes and resources on the web that somehow are related to the notes
• Overview:
  • Guided tour (this can be done with Tinderbox Demo/Tutorial format)
  • Reading advice (see above)

University Lives Collection Page Launched
Monday, 20 Jul 2009 :-: ["Permalink"]

Over the weekend, the World University Project site launched an announcement of the University Lives Collection:

We are hoping to hear about a successful grant application by the end of the month. In the meantime, we're looking for alternative sources of funding. If you or someone you know might be interested in sponsorship, contact the project. The project is expected to reach around 5k universities worldwide. We're looking for sponsors to:

• Donate your products as prizes
• Provide technology or marketing support
• Financially sponsor the project overall in a major way

Collaboration with Tinderbox
Monday, 20 Jul 2009 :-: ["Permalink"]

This is the fourth post in a series on collaborating with Tinderbox and version management software. Previous posts discussed:

1. Tinderbox and Version Management
2. Backing up and Version Tracking with Git
3. Git, Tinderbox and Online Repositories

This post explains some practical ideas for how to actually use Tinderbox for collaborating, a template file on github, and lots of screenshots.

Contents of this Post

• When not to use online collaboration
• Introducing the Tinderbox Collaboration Template
• Workflow Overview
• Recognizing changes in diff (boring, and helpful)
• Patterns for Collaborating with Tinderbox

When Not to Use Online Collaboration

This post is about collaborating online, when the participants are in different places or working at different times, and need use of a shared repository for their document. If you're all in the same room, use a scribe. Mark Anderson, Robert Brook, and I have all found Tinderbox to be great help in meetings. This kind of collaboration really needs only one Tinderbox user.

The Tinderbox Collaboration Template

Ever since around 2004, when my brother and I gave a joint lecture on Parliamentary Procedure (fun!), and prepared the lecture by emailing Tinderbox files around, I have been collecting ideas on how to work together on a single Tinderbox document. The Tinderbox Collaboration Template includes the basics which I find helpful for any collaboration:

• Individual Prototypes for each user's own comments
• A personal space and note for each user
• A trash bin
• Notes
• Legend for Prototypes
• Meetings
• Recent Changes
• Metafilter color theme (Happy 10th!)

Workflow Overview

To set up the template, you can either fork the project on Github, or check out the project, and push it to the repository of your choice. From that point, you do the following things to set up the Tinderbox file with your team:

1. Give each person permissions to check out and commit changes to the project
2. Create a new personal space for each person, and a new set of comment prototypes for them
3. Each person (or a newcomer) checks out the latest version and jumps right in

When actually collaborating, the workflow looks like this:

1. Work on your stuff
2. git pull to checkout others' contributions when necessary
3. You should be the primary user of your personal space. Use it extensively, and only drag things out into the main areas when your things are ready to show the others, or if you need others' comments and contributions
4. commit and push your changes when you have something to contribute
5. commit, push, and pull often, to prevent conflicts (this is contrary to software dev practices, where everything has to work. This is a document, not a computer program, so this shouldn't be a problem)

Recognizing Changes in Diff

GitX will show you changes you have made. GitHub will show you changes which others have made. Since GitHub and GitX only know about XML and don't understand Tinderbox, the output of diff can be confusing.

Over time, you will can a sense for what it all means. I hope these screenshots of diff can help give you a head start:

• New Links Added
• Boderer and Color Changes (GitX)
• Border and Color Changes (GitHub)
• Two Notes Added Next to Each Other
• Attributes Added, Text Added to note
• New User Attributes Added to Tinderbox Document
• New Color Names Added to Tinderbox Document
• Document TextFont Preference Changed
• Adding and Annotating a Picture in Map View

Patterns for Collaborating with Tinderbox

The following set of recommendations are based on my experience, so if you have further idease, please write.

• Don't limit yourself to one file. In cases where lots of changes are being made frequently, it might be best to have a separate file for each person, and to designate one person to keep a composite document up-to-date. If you all share the same prototypes, it should be simple to drag notes across Tinderbox documents.
• Recent Changes is your friend. If an agent produces too much noise, then ask people to create a "Recent Changes" area in their personal space. Before they commit and push a set of changes, they can create aliases of important changes and drag them onto the recent changes landing area. Much quicker than describing the changes, and it also gives others ready access to what each person thinks is important.
• Independent master files like this one simplify the task of starting new things. As people develop generally useful features within their project files, drag those features into your master repository so you have ready access to them when you start your next collaboration.
• Split large documents into sub-notes, so people can work on different parts without stepping on each others' toes. Nakakoji View is your friend.
• What to do when you try to push something and Git complains about a merge conflict (giving the error "needs merge"):
  • Git creates three files- your old local copy, the latest version from the repository, and a mutant hybrid of the two which you need not worry about.
  • Open up your local copy
  • Open up the repository copy
  • Find the things in your local copy which you have changed, and drag them over into the repository copy. (because while you know what has changed in your copy, you don't know what has changed in the repository copy)
  • Save As the original filename
  • Delete the extra files
  • git add, commit, push
  • (this is an ugly solution.I'm working on a better one (a) (b))
  • Always remember to commit before you pull
• Want to record who went to the meeting, or who should be working on X? Simply drag aliases of their personal space into an area.
• Tinderbox is great for arranging things just how you tend to think. If you bring that attitude to the common spaces in a collaborative file, you will spend more time explaining than collaborating.
• Messy things with lots of lines and structure are often hard to understand. Seek simplicity, and don't be afraid to have lots of clear, simple areas. In Tinderbox, choosing a few relevant things to show is often harder, and more valuable than just dumping everything on the rest of the team.
• Deleting is bad. Deleting other people's stuff is really really annoying. You might end up deleting something with 50 aliases and render your entire project incomprehensible. Just drag something to the side, or use the Trash Can if you must.
• You know this already, but do remember that sometimes you just need to go out to the pub, share a sandwich, or pick up the phone.
• Write me if you have other good ideas you think I should share

Git, Tinderbox, and Online Repositories
Tuesday, 30 Jun 2009 :-: ["Permalink"]

This is part three in a series of blog posts on backup, version control, and collaboration using Tinderbox. Prior posts include:

1. Tinderbox and Version Management
2. Backing up and Version Tracking with Git

This post will explain how to use an online repository, and how to collaborate with others. The next and final post will suggest some patterns for multiple users to collaborate online using Git.

Online Repositories: Github, Unfuddle, and Codebase

In addition to using Git to track the history of your own materials, you can also use it to share your materials with others and collaborate with them. Many good online services exist to make this task simple. Three that I like are:

• Github(free, if you let the public see your project, and a fee for private repositories)
• Unfuddle (commercial, private repositories- I use this for my own projects)
• Codebase (also very good commercial option)

Good Explanations on how to use Github

Well, I was going to write something about setting up a github account online, but then I found these two excellent resources:

• Pragmatic Bookshelf Insider Guide to Github (35 mins video)
• Setting up a remote repository using GitHub and OSX, by Jasen Mathai

Using those resources you should be able to:

1. Sign up for an account with Github or some other service
2. Generate your public and private key (for security and authentication)
3. Push the contents of your local repository onto github or some other service

The online services themselves are very helpful (especially Github) and will walk you through each step.

Especially with Mathai's article, you should read it thoroughly before starting, because he often explains the simple option only after explaining the complicated way in great detail.

If this all seems too technical, hang in there. Once you set up the online repository as described in these articles, you can still continue to use GitX in the same way I described before.

Once you have set up a remote repository, you will only need to use the Terminal in order to run two commands: git pull, to fetch the latest version from github, and git push, to update Github with your latest commit. This will be easier if you installed Shell Here, earlier. If you have, simply:

1. Navigate to the folder
2. Press the "Shell Here" button which you have set up in Finder
3. Type the git command you need to run

Backing up and Version Tracking With Git
Saturday, 27 Jun 2009 :-: ["Permalink"]

In my last post, I explained why using Tinderbox properly with version management software has been tricky. In brief, two Tinderbox files can be identical in content, and yet have a very different file structure. That has confused tools like git and Subversion, which expect changes in the files to indicate changes have been made to the document.

This post will explain how to use Git to back up and track the version history of your Tinderbox documents. In the post after this one (which I will post this weekend), I will demonstrate how to collaborate using Github, Unfuddle, or some other online repository. The final post in this series will look at specific options for using Tinderbox with Git.

Preface: Ways to Share and Back Up

• Finder Litter was my strategy before GIt. This involved making copies of documents at sporadic times, at various points of development.
  • The folder for this weblog is littered in this way. I have "Lifebox", "lifebox copy", "Lifebox Copy.tbx", "Lifebox copy 1", "Lifebox.bak", "Lifebox.orig", "Lifebox-xrefered-to" , and a "baks" folder full of other copies
  • These backup copies get messy, and it's hard to tell from the "Date Modified" which ones are older, since the date changed when I copied the files from my old laptop
  • These backup copies no longer work, since they are now out of sync with the current version of the template files, which are now themselves cluttered about all over
• Time Machine, which comes with every Mac, will back up your files automatically. This is great. But it has some downsides:
  • There is only blunt control over what goes into the archive
  • You don't control when things go into the archive. While you may wish to archive things at certain key points in development, Time Machine will do it on a regular, timed basis. You might really wish to go back to where you were at midafternoon, but Time machine will take you back to the night before
  • To address the timing issue, you have to resort to Finder Litter, which will just get compounded over numerous Time Machine backups
  • There is no facility for sharing
  • Time Machine is OK-ish for personal backups. But it won't help you with sharing materials or working with documents which you live with over time
• At $99 a year for 50GB and a free 2GB option, Dropbox seems like a great way to back up and share your files-- so long as you're online with a good connection when you need to work on things
  • If you look at the instructions in this post and think that they're maybe too techie for you, Dropbox is a fine alternative.
  • note: the recent Tinderbox fix over line order will likely lead Tinderbox files to take up less space on Dropbox
• Git is "a free & open source, distributed version control system designed to handle everything from small to very large projects with speed and efficiency. Every Git clone is a full-fledged repository with complete history and full revision tracking capabilities, not dependent on network access or a central server." With git, you can:
  • Keep a version history of your things on your local computer
  • Decide which things are important to backup and version
  • Decide when the snapshots are made
  • Keep related files in sync
  • Create branches (of things like templates), in which you experiment with something you may not wish to keep, and then merge them into the main history when you decide to keep it, or just revert to the main history if you decide against it.

Step 1: Obtain Git

There are two ways to install Git on OSX:

• Git OSX Installer (Leopard Only)
• MacPorts (Recommended, but very techie)
  • MacPorts makes available a large number of useful GNU and other Free / Open Source software on your computer. To install, you will have to install Apple's XCode first, then run the MacPorts installer. You will need to sign up for an Apple Developer Connection account (quick and free) to access XCode.
  • After you hae installed MacPorts, run the following command from a Terminal:

You should download GitX, a very helpful tool.

You will definitely want to get "Shell Here", by John Daniel and Marc Liyanage, since you will probably end up using the Terminal at some point or other. This button, when you add it to the Finder, will open a Terminal in the current finder window (installation explained here).

Step 2: How Git Works

(note: why read my blog post when you can read Swicegood's helpful book, Pragmatic Version Control Using Git ?)

Most of what you need to do will happen within GitX. There is also a helpful article on the GitX website, which is slightly more helpful for people who already have repositories.

• First, initialize a repository. From GitX, select File->New and select the folder you wish to track.
  • Git will store all of its version history hidden inside this folder.
  • If you delete this folder, your backup is deleted
  • If you copy this folder somewhere, your backups and version history also gets copied
• Next, commit files to the repository, which tells git which files you want to backup and track. To do this, you:
  • Click the "commit" button, or select View->Commit from the menu. GitX will switch to "commit view" (click to see screenshots, with annotations).
  • To preview a file before committing it, just click on the file. Tinderbox files probably seem incomprehensible unless you know XML.
  • If you already have a repository and have already committed files, GitX will highlight files which have changed, let you compare differences, and decide if you wish to commit those changes.
  • After previewing the files, drag them into the "staged changes" area to show which ones you wish to commit.
  • To help you find your changes later, Git permits you to add comments to your actions. My comment here is probably more verbose than necessary.
  • Click "Commit" and your files will be added to the repository
  • If you go back to "History View", Git will show the history of your archive much like stops on the rail line.
• Whenever you want to commit something new to the archive, or just tell Git to update its archive to the most recent version of a file:
  • Use the File->Open menu to select the folder
  • Select "Commit view." Git will show all of the files which have changed, or been added.
  • Repeat the steps you used to commit your files initially.
• If you want to recover a file from your history, simply drag it from the "History View" into the Finder. If you want to use that older version in your archive:
  • Commit the current version
  • Overwrite the current version with the historical one you just dragged into the Finder, and commit again. Git will then archive the file you decided not to keep, while also letting you start again from an older version.

This post is long enough, and I need to prepare for Hypertext 2009. I will write from Milan late next week about how to collaborate using Git. There will have to be a fourth post about how to use Tinderbox with Git.

Tinderbox and Version Management
Thursday, 25 Jun 2009 :-: ["Permalink"]

Earlier this month, I took a careful look at version management for Tinderbox files. My paper at this year's Hypertext conference will be about comparing spatial hypertext collections, so I was curious to see just how well Tinderbox worked with existing solutions, such as git and SVN.

Badly, it turns out. But it's not the fault of Tinderbox.

Tinderbox files are stored in XML, a plaintext format which is easy for other programs (like my Web Viewer) to load.

In theory, the Tinderbox XML files should work well with Version Management software. The tools are designed for plaintext, and Tinderbox files are plaintext. Perfect!

Unfortunately, the XML standard breaks some assumptions of version control systems. In most plaintext formats, the order of the lines is significant. Code is executed line by line, so software such as git and SVN treats the reordering of lines as a change. In some parts of XML however, the order of lines is insignificant. In those cases, changing the order of the lines does not imply a significant chance to the XML. Such changes confuse version tracking systems.

Tinderbox follows the assumptions of XML. Two saves of the same tinderbox can look very different. As a result, git and SVN get very confused. This flickr gallery demonstrates just how confused version control systems can become:

I discovered this issue in advance of Tinderbox Weekend London, where I was speaking about version history, backups, and collaboration with Tinderbox. So late on Saturday night, Mark and I had a conversation at Spoons (yeah, I know), and he offered to look into it.

Last week, I had a chance to look at beta versions of the next release of Tinderbox. These betas output consistent line order, and work smoothly with the version control systems I have tested.

(in the next post, I explain how to set up and use Git on the Mac)

Wagn
Saturday, 20 Jun 2009 :-: ["Permalink"]

Wagn is wiki as it ought to be.

Meditation on Christ as King
Friday, 19 Jun 2009 :-: ["Permalink"] Our Father God,
of all the ways you have given us to understand your care for us--

perhaps none is as troubling as
God the King

Even we your church,
[who have committed to risking all to follow your rule ]
prefer autonomy,
though your loving decrees are at our fingertips
We are your citizen ambassadors
yet we tend to mistrust kings
preferring ideologies, democracies, bureaucracies
instead of total power

We worry about bloodshed and oppression caused by kings,
and you are a God of bloodshed -
even Jesus spoke of presiding over
the slaughter of those who resist his rule

If you were not righteous
we would be just to resist your rule
even if this world were rightfully yours

But we see that our sins, our rebellion
the rebellion of the devil, and the curse
have polluted the world with great ills and injustices
and that the world you made
will only be restored
through your righteous judgment and loving rule
not ours.

Help us come to grips with your loving kingship.
Help us, like Christ, humble ourselves
in your mission of mercy,
sacrificing our interests
in love, generosity, and gospel witness
to grow that future multitude
which will celebrate your power and love
in the heavenly kingdom

Without your grace,
we are corrupt ambassadors.
Correct and guide us in love and truth
and we will praise you,
our chief hope in a troubled world,
even as we struggle to understand and accept you,
now, and forever, Amen.

The Coffeehouse
Monday, 8 Jun 2009 :-: ["Permalink"]

It is spring. I am in a dusty little cafe, tucked into a corner of art-deco, post-industrial America: the rafters are lined with a few hundred hanging coffee mugs, above scattered tables and scattered people-- old books, old laptops, an out-of-date menu on the chalkboard. Quote of the week: "I thought Goth was over," by "Acey". Next to it, scuffs of chalkdust form the shape of a rose.

The barista is writing about Barthes, dictionary open. A dude in the corner is working on a short story. He's covered in tattoos, and his extremely relaxed girlfriend's kisses. A couple of old hippies are reminiscing about that time when they truly *experienced* pure music.

"I wish I had a tape recorder back then," one of them says.

Someone new walks into the cafe.

A head appears from behind the cloudy-grey ibook in the couch.

"Hey- I remember you from City View; You know, my second, third, and fourth first drafts were all written there. A cup of coffee, an appetizer, a few cigarettes, and some beers into the evening, and there you have it. 3am. I write everything in notebooks, you know."

"Badass."

I had forgotten what it's like to be around people who read, write, and think about ideas out of raw thirst.

Departure
Saturday, 30 May 2009 :-: ["Permalink"]

Tonight, ater performing for the wedding of my friends Paul and Solveig, I will be leaving the UK for two weeks.

The implications of this are:

• I will not be able to take on anything new, or handle WUP requests
• I will be able to catch up on the existing email backlog
• Emberlight and other Tinderbox related items are expected to advance

See you in mid-June!

Literary Studies Now
Saturday, 23 May 2009 :-: ["Permalink"]

On April 27, 2009, a number of gradstudents and fellows met up at University College, Oxford for Literary Studies Now. Our aim was to discuss recent and upcoming issues within literary studies (flickr).

Over the next few weeks, I will be posting about this interesting gathering- drawing from my own notes and including text, commentary, and bibliographies from the other attendees. Feel free to participate in this conversation by emailing me.

Wagn: A Stretchtext Wiki
Friday, 22 May 2009 :-: ["Permalink"]

Yesterday at the office, we discussed creating a wiki for sharing documentation. I have been looking around for a decent wiki on Rails. The more info we put onto the Wiki, the more we will have to worry about

• Losing track of what is in it
• Letting things get out of date

I think that Wagn, a Rails-based wiki, may help us stay DRY while providing handy tools for monitoring the state of information within the wiki.

Wagn is a card-based wiki. Cards can link to or include information from other cards. Comments may also be added to cards.

Cards have a type. For example, the image type makes it easy to upload images into a specific document, and also to share that image into several documents. The file type works similarly.

One of the most useful types is "search". Using this feature, it will be possible to embed a search into any document. For example, I could create a home page for my account which automatically searches for "chat", "performance test", and "user interface". When I log in, I would then be able to see recent changes to documents referring to those topics.

Oh, it also does rich text editing, which is a nice plus when you're in a rush.

Unhelpful Visualisations
Monday, 18 May 2009 :-: ["Permalink"]

I have been posting an occasional series to the office email about unhelpful visualisations.

Having been fascinated by good qualities of The Cambridge Phenomenon influence map (1) (2), I then wrote about the Star Wars influence map:

Today, I came across another unhelpful diagram: a history of information, a stacked graph which apparently displays data on media users since 1800. This beautiful and impressive diagram shows the transitions between epochs of news history: newspapers slowly supplant word-of-mouth, television and radio start edging in, and by 2020, thin bands of online options -- websites, blogs, social networks, social news, and targeted news-- completely supplant the old world.

The design elements of authority are all there to support belief in a coming future of targeted news: evenly spaced labels, vertical bars for each label, and specific datapoints for each medium for each labeled year. The graph tells the whig history of media as a story of inevitable progress from one new medium to the next. Next to the progression of newspapers, television, and websites, social news and targeted media look like sure winners in the next decade.

The graph, however, is a fabrication. Baekdal cites no actual sources for his graph(although he says the last 10 years are based loosely on what he has seen from "probably" 1000 surveys he has conducted. For data about life before 1990, he interviewed people and googled some stuff). But even if it were properly researched, it would be deceptive at best:

• Time is stretched inconsistently: the intervals between labels begin at 50 years, then 20, to 10, 5, 2, 1, and then 5. With time made so flexible, we cannot trust the implicit argument of progress, which relies on the visual similarity of subsequent regions of color. When questioned about this, Baekdal said, "I fail to see how the scale of the graph can be seen as a lie. You can clearly see each year."
• The total sum remains constant: The last 200 years have seen vast increases in media audiences: literacy, communications technology, and the rise of the gobal middle class have all expanded the pool of media consumers. A study that recorded socioeconomic data alongside media use would be able to display or (possibly) adjust for population growth within that group.

To be fair, there is no way to design the graph correctly. It is simply not honest to present non-quantitative opinions using means reserved for quantitative information. Although he argues in the comments that his graph is based on interviews, surveys, and "careful analysis", he finally admits that the "graph does not illustrate the size of the different forms of media. It illustrate their importance."

P.S. Notice how the color selection subtly supports Baekdal's argument. Newspapers, radio, and television have colors which contrast each other, while the electronic media "websites, blogs, social networks, and social news" all have similar colors. The eye naturally groups them, contrasting them strongly with television.

This Blog?
Thursday, 14 May 2009 :-: ["Permalink"]

Over the last year, I have been refocusing the nature of my writing. Since I studied at Cambridge, I have spent much more time focusing on individuals. Blogging can seem to be about the blogger, while writing emails lets me focus on others more easily.

Unfortunately, friends who live in other places have been at a loss. Furthermore, some of the more polished things I have produced over the last few years need to be archived.

Email's most tempting feature is the potential to permit multiple identities. Blogs encourage integrity because everyone sees the same one. People assume the written word is your final word. Questioned orthodoxies and scandalous thoughts can safely be shared with those best prepared to help- but there can be a strong temptation to keep keep ideological secrets.

Then there are the embarrassing posts. First, the ones that will never leave the massive "Drafts" area. Then the ones that did. I prefer however to be uncomfortable with what I have said and done. Keeping them online forces me to remember and pressures me toward honesty and integrity.

More recently, my work for the World University Project, Emberlight, and the knowledge Generation Bureau have reconnecting me with the wider world in exciting ways. While I don't expect to blog regularly, I expect to resume posting things of interest when appropriate.