Thoughts on Collaboration

The Internet is an amazing tool for information procurement, and increasingly more of our culture and knowledge is delivered using Internet technologies: this is pretty easy to grasp. Knowing this, it's startling to think that the Internet as information delivery technology is largely overshadowed by the Internet as a technology that facilitates collaboration.

We're used to technologies like the printing press, radio, television, the telephone, the xerox machine, etc. vastly expanding the facilitation of dissemination and spread of information and knowledge, so it's easiest to think of the Internet in these terms. At the same time what makes the Internet so powerful is that it bridges the distance between people and provides technologies that in making it easier to share information, groups of people are able to create information on the Internet.

Open Source and Free Software is a result of this collaboration, for example, but the Internet is full of examples of communities coming together to produce information and resources that are bigger than any one person could create on their own: social networking sites (ravelry.com, facebook, nings) blogging communities (eg. livejournal, wordpress.com) wiki-projects (eg. wikipedia, flossmanuals c2-wiki.) In truth the technologies of the Internet that mediate these projects are relatively simple. For example:

• Mailing Lists

  Discussion lists are ancient in the land of the internet, but many communities function very well with just a mailing list. We are often overwhelmed by email, but there are many features which recommend email over newer tools like blogging. Primarily, email is "pushed" to your members'. Since we generally presume that people check their email, getting information in email requires less intention than getting information via blog or wiki, while audience can remain stable for longer.

• Wikis

  Wikis are a great tool for collaborating on a text which is uniquely digital, uniquely hypertext. While encylcopedists have adopted it to great effect, the form is flexible, discursive, and highly interactive. As a result it can be--with proper guidance--a great tool for collaborative projects, but unguided they often are too flexible and underutilized as a result.

• Blogs

  The blog is perhaps the easiest technology to use, and use well. We're familar with the form if not from other blogs, but from columns and analog journals. The biggest challenges are keeping blog posts indexed and useful for more than a few weeks, and learning to blog as a habit. Blogs make a great experimental space for playing with new ideas, in addition to recording personal perspectives and historical contexts.

• Messaging

  Before instant messaging, IRC (internet rely chat) provides group chat experiences that allows collaborators to "talk" things over in real time, in groups, both as a primary form of communication and as a "back-channel" for distributing links and other information in other forms of real time conversations. Often, however, such messaging can be distracting, and hard to follow for the uninitiated. Furthermore there are some kinds of projects for which sporadic telephone calls are more productive.

• Social Networking

  While "work" in the conventional sense isn't often accomplished on social networking sites, they do foster community and communication, and contemporary functionality includes a "feed" of information that can automatically keep your team in touch with their collective activities.

• Version Control

  Programmers use version control systems (subversion, git, etc.) to allow a group of people to work on one project concurrently, to store chronological iterations of their projects so that they can return to "known working states" if an train of thought leads to a dead end. The technology is quite simple, but remarkably powerful in the creation of shared works, while still allowing and respecting individual contributions. Software engineers use these tools to great effect, but I'd argue that additional kinds of creators and creative teams should use version control and similar tools.

This isn't to say that all collaborative tools are perfect and we don't need new and more inventive tool to facilitate collaborative work. I've touched on some of the more specific challenges, but collaboration on the Internet--as a whole--face one major challenge: one of expectation.

When we understand how simple technologies are, when we see the great accomplishments of Internet technologies it's all to easy to say "well wouldn't it be great if I did that," or "you know, why [my project] really needs is some good collaborative technology." It turns out, not surprisingly, that harnessing the power of collaborative technology this is much more difficult than simply flipping a few bits on a piece of software and then waiting for emergent phenomena to develop.

This challenge, how to facilitate and shepperd a nascent community--even when that community is all located in one place--can take many different forms. While the specifics of these challenges form the basis of much of our work here, and are highly dependent on the goals, resources, and contexts of individual projects there are some general themes:

• Communities need editors and moderators to provide leadership and ensure quality.

• Raw information is rarely useful without curated guides and views onto the data.

• Communities need the flexibility to have wide reaching discussions and sometimes stray from topic, in order to develop unique identities.

• Beyond an initial set of necessary tools, community needs should dictate the development of technology, and often fewer tools and platforms are better than more tools and platforms.

On Customization and Adaptation

One of the applied issues related to cyborg interactions that I find myself contemplating with some (too much?) frequency is the problem of customizing your computing interfaces. Problem? Well here are two arguments that I've been considering:

1. Customization of our computers and our computing interface allows us to work more efficiently and naturally, so that the computer just works the way we need it to and doesn't get in our way. When I say customization, I mean, tweaking the configurations on your text editor/editing program, creating shortcuts, using programs like Quicksilver emacs, or awesome to shape your environment.

   No matter how geeky you are, though, we all customize our environment somewhat. Some of us are a bit more into this than others, of course, and I'm a big fan of customization, obviously (or not) but customization isn't without it's drawbacks...

2. Which are, that customization means additional learning curve, and increased start-up costs whenever you get a new computer. Additional learning curve because you have to learn what a program/system is capable of to begin with, what needs to be changed in order for you to work better, and then you'd need to know how to change it. Which takes some know how.

   Increased start up costs are a bit more complex. Basically if you customize your system/applications, then when you get dropped into a system that's new or with which you're unfamiliar, you have to spend some time either adjusting back to the defaults or customizing things to work with your system. The even worse corollary to this is that you use multiple system you also have to keep the customizations on all of your systems in sync, other wise, it's all sorts of complicated. There are ways to ameliorate these problems, but they have to be considered.

I, obviously, fall into the "customization is optimal" school of thought, but the other school--in many circumstances--has a lot of merit for some users. This is one of the topics that I'll be exploring more in these blog posts, that we can discuss on the wiki and/or that you and I might discuss in a more applied context if you or your organization would like to discuss your work and technology with me. In any case, I look forward to hearing from you!

About tycho garen

Speaking of my byline, I should make clear the tycho garen/Sam Kleinman distinction. It's a long story, the origins and reasons of which aren't particularly interesting or relevant, but some years ago, I began to feel uncomfortable with the lack of privacy, and potential ?confused contexts that goes along with contemporary culture. So I began writing my blog as tycho garen, when I publish fiction I use it as a byline. I send emails (by default) from tycho, I was photographed for a portrait project, and put tycho garen on the model release (as the name). tycho (never capitalized, it seems) is even the originator of my PGP key.

I wouldn't want to make things as cut and dry as saying that "Sam" is the ?meatspace identity and tycho is the cyborg/cyberspace identity, though properly contextualizing my work and relationships is one of the inspirations for using "tycho." In the beginning, I suspected that the domains Sam would work in and the domains that tycho would operate in would be distinct enough to avoid overlap or collision, but time proves me wrong.

If you wondering about the method to the madness regarding how I choose which moniker to use, here's my intention: Sam will cover all of the public-facing and administrative content for the Institute, but on the wiki I will sign contributions (when appropriate) with tychoish and a link to this page. Because it only seems fair.

Appendix

Awesome

Notes and Thoughts

In no particular order.

• Examples of other window managers: Aqua in OS X (under Quartz), explorer.exe in windows, Metacity in GNOME, and scores of alternatives for X11.

• There is a lua library that supports dynamic tagging called "shifty" that lets you create, destroy, and rename tags on the fly.

• There is a lua library for "Growl style" notification pop-ups called "naughty" if you like that kind of interruption, and they work much the same way that widgets do.

• Tiling window managers are less flexible that stacking/composting window managers. That's the point, but that isn't to say they're inflexible.

Awesome for the rest of us.

• Applescript and the Spark Framework make it possible to script and customize some aspects of your environment in OS X. I'm not as familiar with options for similar scripting/custom key-binding support for windows.

• Awesome can be used--more or less--as a drop in replacement for metacity in GNOME or for Kwin in KDE so if you use one of the other mainstream X11 desktop environments, you might consider trying one of these methods.

• I've seen evidence of successful Xmonad installation on OS X (though it can't manage native OS X applications); and there is a package for awesome in macports it's for the oldstable (stale) version. But possible and useful aren't always the same thing.

• There are some applications that feel particularly suited to the Awesome experience for their minimalism and keyboard-driven interfaces. Awesome is great alone, but it's better with the right apps. The reverse is also true: you can get a little bit of the experience by using these apps inside of your current environment. For example, mutt, emacs, vimperator, irssi, and so forth. More links at the end.

Awesome Applications

• vimperator (firefox)
• emacs (or vim, if you're like that)
• mutt
• mcabber
• bash
• mocp
• irssi / weechat

Org Mode

I think one of the most beautiful things about org-mode is that it's possible to only use parts of it: You don't need to know all of the possible agenda views in order to use it for outlines, you don't need to know how to use the export functionality, or the RSS import functionality for this to enhance to manage your tasks, brainstorming and work.

Org-remember from anywhere.

You can also, with some nifty lisp from Jack Moffit call up a remember buffer from anywhere. I of course have this set to a key-binding in Awesome, but you could quicksilver (or other similar alternatives) to get the same effect in OS X, and something in windows.

• On org-remember:

  • Org-remember allows you to specify templates to automatically capture some information, and provide prompts if necessary.

  • With the emacs server (and emacsclient) trigger remember even if you're not in emacs. Information in the appendix.

• On navigating outlines in org-mode:

  • tab cycles visibility of the current heading.

  • shift tab cycles visibility of entire outline.

  • meta-arrow navigates the position of the current heading.

Links and Resources

• Window Managers for X11
• http://metajack.im/2008/12/30/gtd-capture-with-emacs-orgmode/
• http://identi.ca/group/awesome
• http://identi.ca/group/orgmode
• http://awesome.naquadah.org/
• http://awesome.naquadah.org/wiki

Thoughts on Introducing the Wiki

It was my intention to present with the launch of the Cyborg Institute website, a wiki that would serve as a forum to present the product of the research that I hope will become one of the, if not the most important aspects of the Cyborg Institute's work.

Establishing a wiki is a non-trivial project, that involves many hours of work to work with contributors, to research and write "seed content," to get the software setup and configured for the needs of your community, and every community, every wiki, is different. Indeed one aspect of what we do is to figure out how individuals and groups can establish wiki's in their unique settings.

I've written "seed text," a partial substrate really, of what I envision for this wiki. I've outlined my intentions for initial work, and posed--in the relevant pages--questions that I hope to be able to explore and answer in the wiki in the coming months and years. In all, I'm proud of what I was able to write, and believe that it's a good beginning.

The more I worked on it, however, the more I started to realize that my goal of launching the wiki's "seed" when I launched the rest of the Cyborg Institute website was a flawed goal. The wiki is a massive project, wikis are always massive projects that can't just be "whipped out" in a week or two by a single prolific writer. I ran into all sorts of challenges: areas that I knew I needed to cover where my knowledge was limited, software that I couldn't get to work quite right, subjects that I felt belonged in the wiki that aren't part of the Cyborg Institute's focus on Information Management. While I continued to feel that the Wiki was essential to what I was hoping to accomplish here, I also felt that waiting for it to be "done," even in a provisional sense, was counterproductive to the goals of all the other projects of the Cyborg Institute.

To bring us to the present, I decided to launch the Cyborg Institute website with a wiki that isn't even provisionally complete. However, as incompleteness is the usual state of wiki's I see no harm in publishing the ciwiki in its present form. With a few disclaimers and caveats:

• Most importantly, there is no (functional) web-based interface for editing the wiki at the present. All edits to the wiki must be submitted over the ?git interface.

• There are many fundamental, "core pages" that are incomplete, or uncreated even in "stub" format. Without (working) web-based editing, the traditional "red link" or "?EditMe" question mark is absent from this generation of the wiki.

• The existing content is (primarily) written by me (Sam) as a starting place, and thus doesn't (yet) represent any sort of peer-reviewed, collaborative output. I encourage us all to view this as a work in progress.

With those concerns in mind, what follows is my original introduction/index page. Enjoy and I look forward to working with you.

— ?Sam Kleinman, 16 April 2009

Lightweight Markup

If you've browsed the source files for this blog or for the forthcoming cyborg institute wiki, ciwiki you may notice that my work is mostly stored in "markdown format" which is a lightweight markup language for generating richly formatted text. Markdown isn't the only format around, indeed formats like reStructured text and textile are other very similar tools. Different, but they achieve same purpose. What purpose, you ask anonymous inquirer? They make it easy and painless to write text with links, emphasis (italics), structure (headings), and other features, in an easy to read plain text format.

The truth is that there isn't a really good way for "rich text" (bold, italics, links) to be stored in a format that's both universal enough for computers to read in multiple context (desktop applications, on the web) that's also easy for humans to read and write in a consistent way. Sure there's (x)HTML which is a great format for computers to read, but its hard to write and difficult to read casually. At the same time word-processor formats (.rtf, .doc, .odt, etc) render inconsistently across platforms and don't work as well for use on the web, or for email.

Lightweight markup formats, and particularly markdown, provides a solution to this problem. Rather than creating a format that will render well on web-pages, on paper, and in plain text, these formats provide a limited syntax for most common markup needs and then provide a script to translate this "lightweight" language into other formats. These scripts exist as plugins/modes for most common text editing software, and are implemented in a great many programming languages so that standard lightweight markup can be used in many contexts.

Here's the rundown (note, I'll use markdown as the example but these facts all hold true for other similar products):

• Markdown is human readable, so in some cases (like email, and collaborating with other writers) there's no need to convert a file to XHTML or some other format.

• Markdown is designed to replicate many common editing conventions for plain-text email. So the chances are, that you already know much of the syntax and can understand texts written in markdown quite readily.

• Markdown generates standards compliant XHTML. Even sloppy markdown generates compliant XHTML. XHTML is easy to translate into other formats (including word processor formats), and non-trival to generate perfectly "by hand."

• Markdown interpreters are written in many languages, including Perl, PHP, Python, C, Lisp, Java, C# and so forth, which makes it particularly easy to integrate markdown into whatever environment you're used to working in.

• There are tools, like Maruku (and others) that convert text to other formats (like PDF), for non-web output.

• Text editors (including, vim, emacs, textmate, notepad++, bbedit) have support for syntax highlighting for markdown, so that your editing environment provides a rich interactive environment while still editing simple plain-text files.

• Markdown makes it easy to "live in plain text" without sacrificing features that we, as writers of words, are accustomed to.

The benefits of using markdown, are perhaps most fully realized in the context of using plain text itself, but that's another argument for another time. And as always, if something in this post struck a chord with you, but you don't quite know how to integrate it into your workflow directly, that's something we can work on together.

tycho's notebook archives

information-repository-systems
Posted Thu May 6 21:20:23 2010

archive
Posted Sun Sep 27 17:27:22 2009