Topic: Cyborg

I wrote an article for my friend Melissa Barton about how to use computers/technology more successfully and more effectively, and it went live over the weekend. I'm really happy with it, and it represents all of the things I've been working through here, except tuned for a more general audience. It's also under my given name (gasp!) as if the tycho thing wasn't confusing enough as it is.

Emacs is great, and I'm a huge fan, but it's not for everyone, and for those audences, thinking about what we learn from "advanced useage" and then workind to apply that to more general use can be quite powerful. This is a different take on the "how to attract general audences," process. I guess I'm mostly arguing that rather than make software/hardware more "friendly," better to (also) educate users to be more gruff?

In any case, that's up. I'm also posting an extra tychoish essay on Wednesday because it didn't get posted (as I would have hoped) due to my error a few weeks ago. Stay tuned for that. Also, maybe new Critical Futures this week?

cheers, ty

I mentioned the other day that I was looking to build a fact file, but that I wanted to follow up on this in a bit more length. As you know and/or have probably guessed, I'm a writer, and I consume a lot of information in the pursuit of this practice. That's par for the course. The problem is figuring out a way to store collected information so that it's useful later. Here's a story:

I have a story that imagines a future where there are colonies and outposts throughout our solar system (among other things). I found myself a few days ago plotting out some details and I realized that I might be imagining a future with not only far flug outposts but also a substantially different system of orbital mechanics. I know about Hohmann transfers and enough about gravity assists, that getting between planets in the solar system is complex. My hope is that by knowing a bit about these things, I can avoid rank absurdity. In any case, I found myself looking up the length orbits of Jupiter and Saturn around the sun.

Now mostly this was just to get a sense of the distance, because unless I also posit free, lightweight, super-powerful propulsion systems, a trip between Jupiter and Saturn is going to take a number of years (say, 5-15; and even with posted amazing-drive, we're probably still talking several years,) and no matter how fast/what kind of propulsion system you use, there are going to be a very limited "windows" for transport. If you miss the buss from Jupiter to Saturn, it could be 10 or 20 years before you could get off world. Not to mention the huge impact this would have on the course of cultural development on these colonies.

But having said that, this detail about the orbital lengths (though burned into my memory at this point), isn't the kind of thing that I track very well, and what about the next time I have a question like this? Or what about a news story that I come across, or the abstract of a scientific paper that catches my interest? This detail about orbits of the outer planets was really just the straw that broke the camels back.

It was clear that I needed a system for storing information, facts, notes for later retrieval. I wasn't sure what that system would look like, or what I would need from it, but I was sure that something was better than the "read and hope" method I've been using.

I did some brainstorming and came up with some basic requirements. I needed something pretty unstructured so that "records," which were just links and a few words would be just as complete as records that had lengthy notes. I needed built in meta-data functionality to store categories, tags, and citation information (links, date, identifiers). Easy capture and editing is a must, and while I was, and am, willing to consider functionality outside of emacs, but emacs is preferred, and it would take a lot for me to want something that couldn't be stored in plain text files.

When other people (individuals) come to me with similar problems I almost always recommend private instances of Wordpress where people can post notes. This often is just the right thing. Conceptually it works like a notebook or journal in the physical world, but it has good meta-data support (categories, tags, dates), you can use it from anywhere (the web, the API), and it's a mature system. This works great for a lot of people, but I'm not incredibly happy with the web-interface, and I'd need to rely on search more than I think I'd like.

I put out a call on identi.ca for help on this problem. There were suggestions of PlannerMode and various systems based on org-mode (which is what I'm inclined to use at this point.) I then had this "moment" issue about not wanting my "fact file" to be built on some sort of to-do list. Todo lists are great, I love todo-lists (perhaps too much?) Having my information management software be built around "tasks" and "projects" provides too much of the wrong kind of structure.

I was frustrated, as you might imagine. After all I just wanted some sort of index-able note-card system, that I could use to store some basic information without fuss. I've settled down a bit and I'm using a format using a skeleton/org-remember template to store my fact file in an org-mode text file (data.org). The entries look something like this:

* The title                    :a:list:of:tags:
  :PROPERTIES:
  :date: <2009-03-14 Sat>
  :cite-key: a-u/uid
  :link: http://tychoish.com
  :END:

And then finally some notes text

And the input is just an prompt-tab interface. I can also add more details to the properties, section. If that makes sense at a later date. So the creation of these records is pretty quick. I'll get come code up when I have something a bit more clear. In the mean time, I'd like to continue to have a bit of a discussion about this information management problem. It's a domain that is clearly very suited to technological enhancement, but at the same time there aren't a lot of solutions on the ground. I suppose that's where I come in, but feedback is most appreciated on interface questions, on alternate use cases and applications. I look forward to hearing from you...

I'm working on a longer post on the topic, but the past few days have seen me spend a bit of extra attention trying to develop some way of doing a "fact file" inside of emacs. Basically what I need is some way of storing information (links, quotes, text) along with bibliogrpahic information (where I got it, when I accessed it) and some sort of meta-data (tags, categories, search index) so that I can find things again. Largely, this data isn't for any specific project, but it is a way to record general notes on the information that I consume in an effort to make that data more useable in the future.

As I firm up the solution, I'll write more about it, but I've discovered something about the software targeted at this domain (generally, "personal information management,") that's worth sharing: there are a lot of notebooks and databases around, but they're all very much alike: anything that's structured as a database is generally desgined to store addresses, contact information and other "CRM" data, which is nice, but not what I'm going for at all. There are also a lot of notebook applications that are modeled on wikis (too unstructured) or outliners (ok, but hierarchical). Interestingly, it seems every kind of personal information management package that isn't an address book (for emacs, but I think this is to some degree generalizable) has grown to a point where it can manage and extrapolate todo-lists from your notes.

Once upon a time, emacs itself was critiqued (and still is) because it has the ability to send and recieve email, and that this feature (email sending) was a sign of "feature bloat," becasue after all, sending email with a text editor. That's a bit a field. I'll let you decide how history has dealt with the email issue. I in the mean time am going to write, and figure out some way of doing a better job with this information.

A few weeks ago, a friend told me about this IDE (integrated development environment) called PIDA, and while I'm nothing more than a casual programmer, my interest was immediately piqued.

We'll call it part of my interest in how programmers work. The truth is, as a text-editor junkie, my impulse is to say "meh, IDEs are passe," but I think that's probably unfair, and in my writing IDE post I think I recognized--by analogy--their worth. In any-case there's something sort of nifty about PIDA: rather than recreate tools, it just makes use of what's already there: the editor is emacs (or vim), the version control system is whatever you want (and already use). PIDA just brings all these things together in a nifty little package.

On the one hand, it's not a really big deal. Cobbling together working software from a bunch of different existing tools isn't particularly new. This is sort of the basis of unix-like computing, and further more it tracks the ways most people/geeks actually use computers: by finding the best tools for all of the jobs they have to do and then using them. This way of interacting seems to hold true for command-line and graphical users, I think. So rather than recreate the wheel, PIDA just uses all the existing wheels. The saddest part is that we don't see more things like this in the graphical application world.

The end result of this mode of application development is that we're given/build powerful tools that function in familiar ways and that are more powerful as a result of their integrations.

And that's about it.

I initially thought that this was going to be a really long and really blathering post about integrated tools, and the power of open source/free software to allow tools to be combined rather than be forced to compete. While these are indeed important issues, they're pretty self explanatory, and IDEs like PIDA provide a great example of how this can be the case, so much so that I find myself saying "why aren't there more programs like this?"

Why not indeed?

I wrote in my post on the one true system about the informal systems that we use to interface the way we interact with knowledge and information in the "real world" with the way we represent that information on our computers. Exploring these systems lay at the core of the cyborg question, but today's essay [1] is more about how our logic systems adapt as we use computers and as the kinds of information we need to store change and grow.

As near as I can tell there are a few kinds of "systems review" that we tend to do. Theoretically if you develop a system that's flexible and that accounts for all of your future information needs, then you shouldn't have to modify your system very much. Theoretically this is a good thing: better to spend time "doing things," rather than thinking about "how you're going to do things."

The sad truth is that this doesn't work out very well pragmatically: we change our work habits, and our information changes, and our projects change, and our informal logic for interacting with our computers fails to address the problems, and eventually everything spirals out of control. This is pretty abstract, but every time you see someone with hundreds of icons stacked on your (or someone else's) desktop, or you find yourself with hundreds of unsorted (and unread!) email messages, or you have to hunt through half a dozen places for a PDF you are witnessing the symptoms of a flawed system.

The only way to address this is to review your "systems," and make sure that you capture any problem before information spirals out of control:

1. Have an overflow bin, but only one overflow bin. This is important, but counter intuitive. By overflow bin, I mean something where unfile-able items are placed. This hopefully alleviates the tension to file away information that hasn't been fully processed, or that doesn't fit into your system, or might be ambiguously filed [2].

2. Do major reviews of your system only infrequently. By major review, I mean, think about how you use your information, what has worked, and what hasn't, and then use this as a model for revising your system. Don't do it regularly, even if you know that something isn't working. Think of this as something that you do only about twice as often as you get a new computer. As part of this major review process:

   Keep a regular journal when you aren't in the process of updating procedures. Track about what works and what doesn't. Often I've found that I have ideas about how things should change, but the changes aren't the kind of thing that I could reasonably change during normal work. These insights/problems are useful, eventually even if they aren't always immediately relevant. So record them for later.

3. Do Minor reviews regularly. Look in the "overflow bin" from item one and see what's falling through the cracks, file things that do need to be filed. The GTD folks call this a "weekly review," and while GTD-task processing is only part of "the system." [3] It depends on what kind of information you're managing, but staying on top of and in touch with your "stuff" is important.

4. Be sure to "touch" your information regularly. While I'm in favor of keeping information even when it's not apparently useful (you never know), I also agree with the idea that information is only really useful if you use it. I've often found myself falling into the trap where I'll stockpile stuff "to read later," which of course rarely happens. Avoid this and browse from time to time.

I mean in the end, I'm just a guy who writes more than he should, and has a pile of digital information that's probably a bit too big, but this is how I do things, and I think the lessons I've learned (and continue to learn) may be helpful to some of you. Reviewing and thinking about systems before hand is, if nothing else, instructive.

Onward and Upward!

[1]	I use the word "essay" under the terms of its slightly less common meaning "to make an attempt," rather than the terms that describe a genre of writing.

[2]

Borrowing from the Python programing language motto, somewhat, "Every bit of information in your system should have one, and ideally only one, obvious location." Now of course, we can categorize information on many different axises, so the key isn't to pound data/information it's to build your system around a consistent axis.

[3]

The system, for me, represents everything from the way we store bookmarks on line, to notes that we collect as we work, to tasks and other time-sensitive data, to the way that we store resources like PDFs and papers. Though we don't have "one" system for all these things, and we're not likely to revise them all at the same time, on some conceptual level it's all the same thing.

There's this idea in linguistic/cognitive anthropology that the limitations of linguistic possibility limit what the bounds of what we're able to think about. If we lack words for a given thing or a concept, it's really hard to even conceive what it is. I'll get to the strengths and limits of the hypothesis in a bit, but lets just say the reception of these ideas (i.e. "linguistic relativism") is somewhat mixed. Nevertheless it's had a great impact on me and the kinds of ideas I deal in.

For instance, though I'm not an active programmer, I talk to programmers a bunch I tweak code from time to time, and I've tried to learn programming enough times that I sort of get the basics of enough stuff to know what's going on, and if there's one theme to my interests in open source and software development, it's looking at the software and tools that developers us, in part for issues related to linguistic relativism. Basically, if the people who develop programming languages, and software itself don't provide for possibilities, developers and users won't be able to think about things downstream. Or at least that's the theory.*

The problem with linguistic relativism in general, is that it's really hard to test, and we get into causality issues. "Describe this thing that you don't know about!" is a bad interview tactic and we run into the questions like: Is it really language that limits knowability or is some other combination of typical experiences that limits both knowability and language? I've read far too many a number of papers from a couple of different scholars, and I almost always end up in the "relativist camp," but that might be a personality feature.

In computer science, I suppose it is also not quite so cut and dry. Questions like "Does the advancement of things like hardware limit technical possibility more than programing languages and tools?" come up, but I think for the most part it is more cut and dry: Erlang's concurrency model makes thins possible, and makes programmers think in ways that they're not prone to thinking about them otherwise. Git's method promoting collaboration requires people to think differently about authorship and collaboration. Maybe. I mean it makes sense to me.

These low-level tools shape what's possible on the higher level not simply in that a programing language implements features that are then used to build higher level applications, but if you teach someone to program in emacs-lisp (say) they'll think about building software in a very different way from the folks who learn how to program Java. Or Perl. Or PHP.

And those differences work down the software food chain: what programmers are able to code, limits the software that people like you and me use on a day to day basis. That's terribly important.

I think the impulse when talking about open source and free software is to talk about subjects that are (more) digestible to non-technical users, and provide examples of software projects that are more easily understood (e.g. firefox and open office rather than gcc and the Linux kernel, say.) This strikes me as the wrong impulse, when we could focus on talking about more technical projects and then use abstractions and metaphors to get to a more general audience if needed. I'm not saying I've mastered this, but I'm trying, and I think we'll ultimately learn a lot more this way. Or so I hope. There is always much to learn.

Onward and Upward!

* In a previous era/maturity state I would have been somewhat guarded about that subject which I think is going to be a major theme in oh the rest of my life. But, this is open source and knowledge wants to be free and all that. Actually, less altruistically, I'm much more worried that it's a lackluster research question than I am that someone is going to "snipe it from me," and suggestions and challenges I think would be really productive.

So I've been posting about cyborg systems on tychoish, about the informal logical systems we use to interface our lives/reality/thoughts/work into digital systems to organize what we accomplish with our computers. It's a topic of some interesting to me, and I'm going to provide a simple piece of advice in this post:

Try your damnedest to only use one system. For as much of your data as you possibly can.

This might be an odd piece of advice, you say, coming from someone who proudly supports the Unix philosophy of "use tools that do one thing well." I think, however, that the question of tools and systems are fundamentally different. Having tools that do lots of things (poorly) means that you have ineffective tools. Having more than one system to organize your data means that things get lost.

Joseph Spiros, a friend of mine from way back, wrote an essay that I think serves as a pretty good introduction to some of these ideas. Read Prelude to Haven and come back when you're done.

Back?

Great. Lets continue.

Having one system that houses everything is a great boon to our representation. If you know, from the very beginning, what kind of data you're going to be dealing with, and develop some sort of organizational system based on this knowledge then it's really hard for files to get lost, for things to be double classified and without reference. Basically, for any given thing, there should be only one given place that you should have to look for this.

This is of course pretty difficult to do. So maybe I don't mean "only have one system for everything" but, rather "have one system for any given thing." More concretely:

• Only have one email account. If you get mail at more than one address, use a client that allows you to view/send email from more than one address (eg. gmail) or forward multiple accounts to one address. This way, if you're looking for an email there's only one bucket to look in.
• Organize data by either projects, subjects, or kind, but not more than one of these categories. Projects would be spheres of your work that form a body onto themselves: if you wrote books, a project would be a book and you'd collect notes, drafts, and versions related to a book in one "pile" [1]. Subjects can get dicey (as they require you to sort your data into a given number of subject-based piles and then be able to recall that sorting again. Kind-based organizations require you to keep all your notes in one pile, drafts in another, final copies in another which can grow unwieldy depending on subject, but greatly decreases the chance of misfiling.
• For data manipulation standardize your practices on specific tools: tasks go in one place, project files go in another, references in another, and so forth. If you track two todo-lists that don't synchronize with each other, then the chance of loosing track on some things in one when they should have gone in the other system. One "OK" system is superior to 2 or more excellent systems.
• Use search tools to your advantage, but avoid the google-method of relying search to be smarter than the index of files. Search is good, and there are a lot of times when searching for something is helpful (lost files, finding a specific quote), but often times they take a lot of system resources to build a gross index that likely doesn't contain the kind of information your looking for.

And that's it. One more step on the road to a better, more fulfilling cyborg experience.

[1]	I've deliberately avoided using terms like "folders," or "categories," or "tags," as these abstractions aren't in and of themselves useful metaphors.

In the last six months or year (or two years) I've written a lot here, about technology open source software and related topics. In a way this was a new thing for me. I majored in Women's Studies and Psychology in college. I wrote about gender and queerness, and knitting for many years. My big thing (or one of them, at any rate) is science fiction literarture, where I'm interested in very historical/"soft" sub genres. While some SF writers feel ghettoized by the "hard"/"soft" boundary in the genre, I love the fact that there's (a very popular) field of science fiction that isn't based on firm understandings of existing science/technology and tightly formed elaboration thereon. I love being non-technical on some level. Despite my current technological musings, this is very much a past that I must contend with.

But I digress.

Before all of this hippy-drippy stuff, I wrote a lot about technology. Back in 1999/2000/2001 I was reasonably active in the discourse surrounding mobile technology. Indeed through this I discovered blogging itself. There are a couple of subtitles to this that I think are appropriate: first, the state of mobile technology about 10 years ago was much different than it is today. Much different. Laptops were significantly bigger and less portable, cellphones were much less "smart," and disconnected PDAs were the light of the times.

But sooner rather than later, I broke down, bought a nice fountain pen and just kept a notebook when I was away from my computer. It worked. Eventually I got a cellphone, but I always tended toward the "dumb"-phone type that were incredibly simple. They worked. The paper worked. When I went away to college I got a 12 inch iBook (as my only computer) and it was great. Small laptops with wireless and long battery life seem to be a great solution to the "mobile technology" problem, and as--at the time--it seemed like my life/work was trending around in a different direction, I stared writing about different things, which when you think about it is all for the best.

For the intervening years, I've been sort of cool toward a lot of gadgetry. Laptops are small enough and powerful enough and frankly cheap enough (considering) to account for a huge percentage of digital mobility, that the remaining need is actually pretty small. And it was my experience that mobile technology wasn't there, for the in between spaces yet. Recording bits of minutia in a usable way on a PDA was never quite as quick and seamless as doing it either on a computer or with paper.

Eventually I've gotten back into writing about technology, but by this time it was a different kind of technology: unix/linux stuff, cyborg stuff, tools for writing, usage methodologies, and organization stuff. The technology itself (for me) has taken a backseat to the ways we use technology.

But in the mean time the mobile technology has mostly caught up. At least somewhat. Cellphones became a lot smarter, the data transmission got cheaper (and unlimited), syncing tools through google and mobile me (if that's your style) make the experience much more coherent. In a lot of ways, the fact that cellphones and connected devices can--independently of host computers--interact with the internet has made them infinitely more useful. And the fact that, at least in my case, do this via protocols that we're already familiar with (REST API's or email) makes this even more attractive.

I also think, at least in some cases, that a lot of this "web 2.0 stuff" makes the most sense in the context of mobile devices. While I don't often think about twittering, or dicking around on facebook when I'm sitting somewhere with just my Blackberry, the applications that connect with these web 2.0 services on phones are really clever. Maybe it's that limited functionality apps make more sense on phones/PDAs than they do on desktop computers, but that could just be me. In the end, I'm still dubious of all this "web stuff," but I think it at least makes sense now.

So there.

Onward and Upward!