When I got the Linux rig, I was pretty sure that I was going to live in vim–probably mostly the console version–while I work on weaning myself off of my TextMate dependency. It’s not that I don’t love TextMate, or that I can’t afford it, but I think Linux/open source is where I’m headed, and in the short term I think I’d like one editor for both platforms, and that means open source. The problem? Vim is great, but I find it sort of tedious for day to day editing…

This is probably the result of the fact that most of my personal text processing (like 80%) is prose of one form or another, with the remainder being very limited code-related things. Vim is great if most of what you’re doing is jumping around in a file, re-factoring code, and hunting for little bugs to tweak. It’s not so good if you’re writing a novel or a story and you only put carriage returns after each paragraph. I like vim a lot for short editing tasks, for writing email, for proof reading a document. For heavy duty lifting? I’m not yet decided.

I should introduce another character/factor into this story: my editing habit. Basically rather than grouping similar files into one window/buffer and toggling between various files, I really like having a bunch of different windows open. A bunch might understate it. At this moment I have 4/5 TextMate windows open, and I should probably have at least 7 (if I were more on top of my tasks) and more like 10-15 wouldn’t be out of the norm.

Console vim works great with this usage paradigm, open a bunch of terminal windows, open them to the documents that they need to edit, and tag the terminals properly in Awesome, and I’m good go, except we run into problem 1 (editing prose in vim is bothersome). I’ve tried (and quite like) a GUI vim called “Cream” that totally fixes problem 1, but utterly fails at problem 2 (the usage paradigm).

So this leaves me? Using a hodge podge of solutions. I’ve taken to using gedit–of all things–for most prose writing. Gedit is the Gnome editor, and if you customize it right, it’s reasonably functional. I haven’t been able to hack Markdown support into it (and I haven’t bothered with vim, so I must not be to keen upon it), and it won’t post blog entries like TextMate, but it’s decent, and I can have a number of different container windows, so I don’t end up with a window with 20 different tabs open that I can’t find anything in, and I use vim for anything that it seems like I can get away with.

Jack has been pestering me to convert to emacs for a while now, and after all this fuss, it’s tempting. Emacs can handle blog posting, it’s fundamentally a bit more like TextMate,¹ with “longlines-mode” it seems to handle prose pretty well, and the quirky things that I like about TextMate like its Screenwriting Bundle and LaTeX support seem to be handled a bit better in emacs. The multi-window usage paradigm is counter to the general emacs way of thinking, so that might be an issue. But the largest problem by far, is that to a newbie² like me it’s like an alien world. Surprisingly enough, (e)lisp code is pretty easy to read, and the key commands are pretty easy to deal with.³ So who know, I might make the switch yet.

Stranger things have happened.

I had occasion to confess my undying appreciation for xml-rpc this weekend at Drupal Camp Chicago. I might have been a little more expressive. I also might have explained this appreciation as being a product of my general disdain for web-based interfaces. Which we have to admit is kind of awkward at a conference of web-based developers.

Clearly I was being a little over the top, but it’s more or less true. I’ve come to ways of using the internet and digital data that means I spend as little time in a web browser as I have to. While the obvious–and predominant–reason for this is generally that I think most browsers are utter failures, there’s another reason that I’ve not written about explicitly: browsers lead to inefficient data consumption methods.

Browsers, with the exception of some very subtle trickery are an entirely “pull” based technology. That is to say, there’s nothing in your web-browser that comes to you and says “hey there’s something new out there for you, come look.” It’s as if the entire web is out there, just waiting for us to check it out and see if something new has changed.

This is a huge issue with the internet, particularly as data begins to migrate from our own computers to the internet–by way of web-based applications. Web programmers/content creators have a couple of ways of counteracting this problem. First, they can do little programing hacks to make the content rearrange itself even if there’s little if any new content, so it looks like it changes. Adding “interesting dynamic” content is a sort of “user hack” that gets people to check back more often with a website, and is pretty low tech solution to the problem, and sites like facebook and twitter are really good at this.

The truth is, that if you have a pull technology, where users have to check to see if there’s anything new, the only way to make it work like a “push” technology (one that notifies you when there’s new content), is to check it again and again and again. If it’s automatic the frequency is high enough it almost looks like a push. This is how most twitter-apps work, for instance. This is also how most email clients work. Though email is a push (because other people push email to your server) in most cases you have to pull email yourself, but that moves us more from the “usability effects” to “technological semantics,” and I digress.

While this might seem like a really minor complaint about how we access technology it has a profound impact on the communities that we form on the internet and how we use technology on “web applications.” Here are a few of examples:

• “Critical mass” for online communities that are push-based (twitter, IRC channels, listservs) are much smaller than for pull-based communities (web forums, blogs). An IRC channel seems active if there are 25 people in the room and 5 people really active. A listserv with 200 subscribers is lively and bustling. A blog needs thousands of regular readers before comment threads start to seem lively, and most “successful” websites have tens of thousands of regular visitors.
• Pull based applications must be both “useful” and “compelling,” and I often find that the later interferes with the former. This is mostly a personal preference issue, but I think it’s important, and I’d like to think that my concerns are rooted in efficiency rather than curmudgeonliness.
• Data that we have to go out and look for means that we spend our time on the computer looking for new data rather than consuming data. I, begrudgingly, spend a lot of my internet time for instance reloading my LiveJournal friends page, because there’s no way for me get that feed all rolled up and pushed to me (even semi-pushed, like RSS.) I feel the same way about twitter, frankly.

The astute among you will realize that RSS works over pull technology, and I accept this but I think that the interaction paradigm for RSS is more like push based services. Because while your RSS reader has to pull from a lot of feeds every time you check for updates, you probably only see “unread articles,” if there are new items in your feed reader. So maybe the push/pull–while rooted in a technological division–also represents an independent interaction paradigm.

Maybe it’s not that I don’t like web-technologies (because I so clearly do), but rather that I want them to suck a lot less? It’s not so much that the applications are “in the cloud,” but that the ways we interact with them (like browser based interfaces versus desktop apps built around XML-RPC) are flawed.

Onward and Upward!

I went to Drupal Camp Chicago last week for work, and while a lot of what I did was work related–learning about Drupal and what the really hard core folks are doing with it–the camp was an emersive experience, and I couldn’t help but make a few casual observations about geeks in general. They’re documented and explored below, and I’ll have a more technical/theoretical reflection of the experience tomorrow or the next day.

This was my first “BarCamp”/unconference, and I really liked the way it felt. There was a lot of knowledge being shared, there was a lot of collaboration, and there was a lot of energy in the room. I go to Morris Dance Ales, and Knitting Camp for the same reason, really. Intense interest and activity around a shared sub-cultural identity/activity, is a really powerful and invigorating thing. This is probably the same reason that “(gay) men’s gatherings,” science fiction conventions, and the “Michigan Womyn’s Music Festival” are so appealing to so many people. (I dare anyone to find something else on the internet that lists all of these things in such close proximity).

One thing that the conference had that I think made it particularly interesting is that there was always a “back channel” on an IRC network for the whole conference. While there were downsides to this (correlating peoples handles with their faces was difficult), this was incredibly fascinating. It also made the sessions go off better: people who were confused were able to ask questions of the room, it kept the background noise down which was better for participants, and since there was only one room for the whole conference it gave me a sense of what was going on at the conference as a whole.

Someone pretty early on said something like “this is literally the subtext of the room,” and they were right. I’m a fan of creating/organizing IRC/Jabber (XMPP) MUCs back channels for various conversations. We use one at work during conference calls to pass links/notes between our side (to keep down the number of voices/unmuted lines), and we had one for the Open Microbloging Meeting which made that really productive. It’s a cool idea.

The other great thing is that I got to watch other really geeky people use their computers. While I’m not a UI (user interface) designer, UI/UE (experience) is something that I’m very interested in and have an opinion or two about. One thing I noticed was that there were more Macs in the room than you might expect. Part of this has to do with the fact that the market share for non-enterprise laptops is something that Apple has basically clobbered, I’m sure. Mac laptops are also more popular among the young hacker crowd (which drupal developers are.) There were some PCs, and more than a few people running ubuntu on laptops, which I don’t have the guts for right now, thats for sure.

In terms of actual usage, there actually wasn’t as much of the “hardcore hacker” stuff that you’d expect. I didn’t see a lot of terminal usage (except for the woman who had tsch visors and wrote a pretty complex SQL query by hand on the projector. to answer a question after her talk.) I saw a lot of people who used the gmail web app. Virtually all of the non-mac people used Zend Studio or Eclipse, though I know I wasn’t the only TextMate user in the room. The most surprising thing, was the shear number of people who I saw using gmail and Firefox. Gmail is ok I guess, but it isn’t brilliant and it isn’t mutt, and surely I’m not the only one with a gripe about firefox.

Sorry for such an odd analysis of Drupal Camp Chicago 2008. I’m going to be working on some more… Drupalish for work, but while I’m a huge geek–no surprise there–I always seem to be more interested in watching the room than in watching the speaker.

Onward and Upward!

So this is a knitting blog?¹ Right! A knitting blog. And I’ve been knitting some interesting things. In my last post about knitting, I mentioned getting unstuck. Though I’m entering a slow patch, it’s clear to me that this is just a time management issue (and sleeve island issue) and not a real block. Here’s where I am:

I knit the collar and started the first sleeve for the Latvian Dreaming sweater. I’m a that point about 4 inches into a sleeve where time seems like it stops. For the non knitters, allow me to describe the anatomy of the process of knitting a sleeve for a sweater.

The top of the sleeve where it hits the shoulder goes very quickly. This is ironic because the sleeve is it’s largest at this point. I think it goes quickly because you are either near the beginning (if you start at the shoulders,) and anything new seems to go just a little faster. Conversely if you start at the cuff. the top of the sleeve goes fast because it means that you are almost done.

The cuff of the sleeve and the last 4-6 inches go reasonably quickly. For the opposite reasons as the top of the sleeve, but the ideas the same. It’s either near the end or the beginning which equals a larger compulsion or interest in the knitting.

There are about 4 inches near the top of the sleeve which take forever, because the knitting never seems to grow no matter how much you knit and or measure. This is, I think a product of the fact that sleeves are a much larger proposition than anyone expects and there’s a lot of knitting to be done in a sleeve. I think this feeling is properly thought of as “sleeve hell,” but you can call it whatever you want.

The remaining 6-8 or so inches go slowly, but not too slowly and in that can be pretty therapeutic, once you realize that you are making progress and that you may actually like the sweater you’re knitting.

So that’s where I am, anyone have any other theories?

In my post about calendar programs a number of great readers suggested that I should try “Lightning” or “Sunbird” which are part of the Mozilla Calendar Project. Calendars from the people who bring us Firefox and Thunderbird.

I didn’t include these programs in my initial review for a couple of reasons. The first, is that I downloaded an early beta of Sunbird, and was (unsurprisingly) rough, and I didn’t see that there was anything particularly earth-shattering. The second is that I find the Mozilla applications to be remarkably awkward and borderline unusable.

So I’ve begun to to download and test Sunbird, in an attempt to be complete and because I suspect that the quality of the application has improved in the past couple of years. I don’t use Thunderbird because of my aversion to Mozilla and XUL (and mutt sucks less), which nixed the lightening option.

And now on to the interesting part, why I hate Mozilla apps. They all suck. Which is to say that they all look the same, and have this shrink-wrap feel that feels awkward in almost every operating system/environment. This means that everything looks ugly and functionality is never where you’d expect it to be. This might be a good thing if you use a bunch of different operating systems, and want your apps to be consistent cross-platform, but generally I think this is heavy handed and it means that your “cross platform” apps don’t work like any of the other “platform apps.”

Now of course web browsers and email clients are pretty straightforward and there isn’t a lot learning curve, but I think usability and ergonomics in contemporary desktop computing comes down to seconds of frustration and confusion, and not upfront learning curves. At least for me.

To be fair I use Firefox without complaint on my linux environments and I think they work great for that, and I think the real test of Sunbird will be how well the experience is on a linux system. I’m not sure if this is a product of the fact that everything seems a little disjointed about user interface on linux. In this direction I find it particularly annoying that Mozilla apps don’t work with the “Services” menu on OS X.

I’ve found this annoyance factor with any Mozilla product I’ve used in recent years. I’ve always blamed it on XUL (the Mozilla interface design methodology), and the idea that Mozilla seems to place a greater emphasis quantity of users than specific quality. Am I the only one who feels this way? Do other people really like the Mozilla apps’ user interface? Why?/Why not?

Cheers!

This is part three, in my ongoing series on the Awesome window manager. For an introduction to what Awesome is, read part one, and for some of my complaints/gripes about Awesome. This post is more a collection of “things that should be done about awesome.”

In a lot of ways this post brings up a number of points that aren’t necessarily specific to Awesome, but rather provide a good (start) to and an idea of what people who aren’t programers can contribute to open source projects.

User Guides/Documentation

Most open source projects need help writing documentation, so anyone whose good at understanding technical concepts (or figuring them out, which is, I think a good chunk of my remaining readership,) can probably write pretty good documentation. Perhaps most difficult in open source projects is editing old documentation to reflect changes and revisions/expansion. If you’re interested in doing this, you can basically take your pick of any open source project and go to town. Everyone needs help with documentation just about, and to publish a GNU GFDL/BSD-Style manual isn’t the kind of thing you need to get approval for.

The truth is that programs like Awesome don’t need formal documentation. The man pages are pretty complete with all the formal functions/features pretty well documented. The problem is that the initial learning curve is pretty tough, and the man pages can be pretty unsympathetic. The truth of the matter is that a lot of times what isn’t needed as much as formal documentation, but rather shorter more accessible documents that explain key features and help new users get acclimated to the system. Let’s call them “user guides,” and Awesome needs them.

More Configuration Files

Configuration files in unix/linux programs are almost always these really simple, straightforward lists of various settings and key-bindings. In awesome, you have to describe and create the interface in the configuration file, so configuration is non-trivial. While I think there are various merits to this kind of setup, like it allows more flexibility and the user base is pretty high level so super-usability isn’t a big concern, the down side is that it’s hard to know where to start.

To this end, I think it would be really great if there were (even more) different and well commented example configuration files so that interested users could “try out” a number of different settings, and have a basis for starting to modify their own config files. I proposed in a previous entry that I thought a more modular/segmented approach to the config file might be good to separate widgets, key bindings, and hooks/etc. into separate files, and while this might be a good idea, I think having examples around would make this easier.

Special Use Case Reports

Aside from the initial learning curve, I’d say the biggest problem with Awesome is the name. Odd complaint you say? Well it makes it really hard for google to index information about Awesome. So it’s hard for users like you and me to find blog posts about how to do cool things with awesome. Outside of the Awesome Wiki, its hard to figure out what cool things folks are doing with Awesome, or even how most awesome users are overcoming every-day-use challenges.

I’m calling these sorts of things “special use case reports,” but it’s really just blogging. I’d love to hear and be able to collect discussions and blog posts from other Awesome users about what they’re doing with the software. I think the collection of this knowledge would be a great resource.

Thoughts?

This is a continuation of my earlier post on the awesome window manager read there for the background. I’m going to focus on some of the challenges that I’ve had trying to use the awesome window manager

Applications made for Awesome

The truth is that most (linux) applications work pretty well with awesome, so linux users won’t need to find new programs. GNOME and KDE apps all work fine. Having said that there are some applications which are more suited to the “Awesome” environment. Generally anything that runs in the terminal is fair game. That means mutt for email, vimperator for firefox, mcabber for jabber (but there are some issues here). Terminator is my favorite terminal/console program. Irssi for IRC. Vim as a texteditor.

That’s a good place to start as any, but I’m sure that there are other apps out there that I’m missing. Your thoughts and suggestions of cool command line apps is always appreciated. Non-Awesome apps that I find myself using with awesome include Cream, and Pidgin.

The Scripting is Hard.

This is mostly a whine, and something that I can get over. Ideally once I get this to work, I can save this Lua file and make awesome work wherever I need to in no time flat, but it’s a lot to get the brain around. I think it might help if there were more examples of Awesome configuration files to ease the tradition. Furthermore, I think it might also be helpful if there was a structure for multiple config files, or an allowance for “sourced” files (a la mutt/vim/bash). Basically I think it’d be cool to have a “widgets” file and a “tag file” and a key-binding file. Or at least have the option of such. This would make tweaking the config file much easier, and give some structure to a chaotic system.

Notifications

I’m a big fan of growl, the notification framework for OS X. which makes it easy to get notifications if you have a lot of windows open, have things running in the background, or need to track things running in the background. I haven’t found an equivalent solution, though I’m sure something exists.

Things I haven’t figured out yet:

• I want to be able to assign firefox to only open in (multiple) selected tags, but not in others, and I’m not sure how to make this work.
• Some sort of menu of currently running applications that would let users select a running application/client and jump to the appropriate tag. That would be awesome.
• Using this configuration file, I can’t get the pidgin (or any other) system tray icons to pop up. Weird.

The truth is that Awesome pretty much does what you want it to do, and there aren’t any real serious bugs or oversights. Part of this is Awesome’s success at having a very clear and limited scope, and part of this is the fact that just about everything that Awesome doesn’t do, you can use the existing tools from GNOME or KDE (the more typical open source desktop environments.) But I think it’s useful to at least make note of the frustrations, if nothing else so that people newer to awesome than I don’t feel so lost. It’s normal, and I think (hope?) it’ll get better.

So despite being a huge geek and pretty technically savvy, I’m not much of a gadget person. I have a cellphone–but who doesn’t these days, and mine’s 3 years old and seems to only barely have an address book–and an iPod, but it’s old reliable and not sexy. The iPod touch that I got as part of a promotion when I got my new computer sits unused most of the time.

The thing is, that my cell phone contract is (blessedly) up in March and I’m beginning the long slow slug towards deciding what kind of phone I should get. I’m slow on the decision making process, and I thought it’d be a good idea to get started now. It’s of particular interest because my phone usage has changed dramatically recently. I’ve gone from using it a few times a month to being on the phone for an hour or two most days (and sometimes more.) And since I even have a calendar now, I think something more robust is in order. Basically this boils down to iPhone or BlackBerry (or Google Andriod). Admittedly this doesn’t really cut out any option other than the OpenMoko (which is ironically more expensive and I don’t think quite production ready.) We’ll start with the iPhone, vis a vis the ipod touch:

While I was initially optimistic that the iPod touch would become more useful as applications matured, and people (myself included) developed workflows that incorporated the device. As it turns out, I’m not sure that this has really happened. Applications seem to be: well intentioned but missing the extra-zing that would make them really amazing, or they feel like some Suit said “iPhone app, we need one of those,” and thus they place more emphasis on the existing than on the being useful. And I’m not going to lie, I haven’t really adjusted to the virtual keyboard. It’s functional, but I think only barely. So while the iPhone is very sexy, and the obvious choice, its not automatic.

Another anti-iPhone factor is that I’m generally avoidant about syncing my iPods and tend to go months without syncing them, and I fear that this might really cripple the the utility Particularly in a couple of months when my iTunes library once again outgrows my hard drive. Oh, and did I mention that I already have an iPod?

Right.

At the same time I’m pretty impressed with the upcoming BlackBerry Bold Hardware keyboard, an established platform, good hardware? Blackberry’s can manage background processes, and they have good XMPP/Jabber/IM email support, which is, most of what I’d want to use an internet capable phone anyway.

I hadn’t really considered the Google Android phones a viable player, and I think largely they aren’t. I don’t suspect the hardware will be there by March or April of 09, and while I like a lot of the idea (from what I’ve seen) of Android, the truth is that I haven’t seen much. Maybe this is because I don’t follow these things, but I think if I’m worried about the ipod for not being developed enough, then that’s going to be an even bigger barrier for Android.

There’s a long time between then and now, so this could all change. Clearly I’m leaning BlackBerry, but I’d love to hear what you all are using.

Onward and Upward!

I’ve been meaning to write a post about awesome for some time now, but I always seem to have a problem figuring out how to approach awesome. In part because I feel like an utter newbie, and in part because it presents such a radically different way of thinking about computer interaction that I don’t really have a good way of explaining it or my issue. Not only does this make it difficult for me to figure out what I need to do, but it’ makes it difficult to contribute to the project by working on the wiki (which I think needs to be done.) So I’m going to just start at the beginning. Expect that this will be an ongoing series.

What is Awesome

Awesome is a piece of software for operating systems running the X11 window server (Unix/BSD/Linux)¹ that controls and determines how different clients (windows in the parlance of most systems) are displayed and allowed to interact. Unlike most other window mangers, Awesome tiles windows, so that the entire screen is used. No space is wasted.

Why is Tiling Good?

Using all available space with tiling seems like a good idea–or at least not objectionable–until you realize that if all windows are “tiled” until all space is taken up, you’ll probably realize that, depending on your monitor size, as soon you hit 4 or five open windows, everything gets too squished for words. And you can’t “minimize windows” in the conventional sense using awesome, so what gives? Tags.

Tags equate, roughly, with virtual desktops, as provided with OS X’s “Spaces” or the virtual desktops that KDE or GNOME have. Virtual desktops/tags “multiplex” the desktop enviroment so that rather than having to cram all your windows into one “screen” you can cycle between different virtual “slates” of windows. Go to an Apple store and get someone to show you a demonstration of “Spaces” if you’re still confused (or find a video of it on you tube.) It might be the kind of thing that you have to see to understand.

In any case, awesome allows for a really large number of tags. And each screen has it’s own set of tags. Typically you have 9 tags per screen, but it’d be possible to have more. And there are all sorts of things you can do to tags, like assign certain applications to only open on certain tags, assign certain window tiling patterns to certain tags.

So that’s all?

I hinted to this in the last section but the environment and interaction in awesome is entirely scripted in Lua. While Lua presents yet another scripting language that I don’t know, it’s clear even to me that there’s a lot of flexibility in this approach. While you sacrifice something by not being able to dynamically adjust the settings, the extra control over shaping your interactions between the window manager is really cool.

What makes this even more cool, however, is the fact that any action, can be bound to a key command or group of key commands. Any window management task. Which means that the only need for a mouse are for very clearly “mouse related” application specific tasks. Which means that you don’t need to use the mouse for very much. Less mouse use means better ergonomics and better user efficiency. Also, awesome is very “lightweight,” and runs very fast because from a computing perspective it’s very minimal. This is a good thing.

Ok, that’s all I have for now. There’s more, so stay tuned.

So I, um, bought a computer last Friday.

People who followed the lead up to the purchase of my current computer–which took six months, or a year depending on who you ask–will be surprised that this happened so quickly.

For a while now I’ve wanted to have a computer that would be able to always be on so that I could download big files when I needed to without needing to fuss with making sure that my laptop could be on all night, or similar such concerns. I wanted to have a computer that I could add cheap drives to as needed. I want to be able to have a computer connected to a couple of IRC channels without needing to worry about my computer dropping on and off-line constantly (which is a politeness that I worry about.)

The thing is that it never seemed feasible. Macs are expensive computers, and this wasn’t a premium sort of use case. For many years of my life I was really mobile and having a desktop computer never made much sense. Now that this new job has started to settle down, and as I’ve gotten more into linux, it’s becoming more and more clear that having a desktop computer with lots of screen space is going to be really valuable to me in this next stage anyway, and the truth is that I spend a good deal of my computing time (with my laptop) at my desk, so a desktop made a lot of sense.

And with this growing interest in open source technology/community/history it makes a lot of sense to gather some greater familiarity with the environment. So between the new usage profile, the fact that the hardware isn’t nearly as expensive in practice, and the fact that having a linux box would be a good ethnographic experience, I just hunkered down and bought it, after only a few weeks of dithering on the subject. I even splurged and got a second monitor so that I could run dual monitors, even so it cost less than the souped up MiniMac (which is sans monitor). I’m psyched.

While I’ll spare you the unboxing photos, I think its highly likely that I’ll be writing about my experiences with this new computer as I settle in. Stay tuned…