I’ve been reading a book about writing. Not one of those dry technical pieces either, it’s a downright reasonable read. Not that I’m recommending it of course, unless you want to hear about writing from the tiny little voice in someone else’s head.

Anyway, in one of the chapters that I read this week the author talks about how to write. Not how to form sentences of any semblence of coherence, but how to actually get off your ass and do some writing. It’s an interesting problem, one that she illustrates with several funny stories and metaphors.

My favorite device-slash-image from the chapter was the suggestion to write everything that you would like to write about in a 1×1 inch square, a list of sorts. You can’t fit much in an inch of space, which makes it easy to actually do. Even better, the visual of a problem smashed into a 1×1 square is powerful: it makes the problem even smaller than it is, providing the sort of nudge that might actually get you to do it. It’s a small step.

And even better yet, 1x doesn’t allow a lot of room for distraction.

Speaking of distraction and metaphor, while writing this post I was watching House, M.D., a show about an obsessive-compulsive doctor. He had something funny to say about metaphors:

You do realize that the point of metaphors is to scare people from doing things by telling them that something much scarier is going to happen, than what will really happen? God, I wish I had a metaphor to explain that better. — House, M.D.

The 1×1 inch constraint is a good tool to help you focus on a small amount of work, but it doesn’t save you from external distraction. Getting things done is both about starting, and continuing at a useful pace.

And that’s where the web comes in

So I’m writing tonight, something I don’t spend near enough time doing. I have no problem with the starting or with the focusing my initial blob of work. And I don’t struggle to find inspiration or with the tools. All of that is easy for me. The problem I have is that I’m constantly distracted, and not by the sort things you’re expecting. I’m interrupted by the variable of the network itself, and the low quality of appications used to do web stuff.

While the net is everywhere, it isn’t there all of the time. It goes up. It goes down. It stutters. It’s a pencil that keeps on breaking (some days more than most). A tool that’s only there part of the time is a royal drain on my gusto.

And the net isn’t just spotty, it’s a bad excuse for shitty applications. I am still far more productive working in a real word processor, which is a writing interface well-tuned over a decades of development. These damned web interfaces look cool, but they’re a distracting drain on my desire (and ability) to write.

I mean not that anything stopped me tonight, I still wrote something … it just wasn’t as focused on the writing as it could have been.

More recent releases of Gnome and Rhythmbox incorporate a hip notification bubble for song changes. It’s subtle, informative, and looks good too (the shape, colours, and font sizing is great). The whole notification applet feature has become a stable mainstay for Gnome applications.

I’m quite impressed at how Rhythmbox has matured. I’ve been using iTunes for some time now, and was initially impressed at how well it was polished compared to Rhythmbox. Comparing the two side-by-side now, Rhythmbox has gained over iTunes: it has all of the useful features with a simpler interface, and no commercial tie-ins.

The main interface is similar to iTunes with a standard last/next/play toolbar, an artist/album filter, a song list (with ratings and a song source list). The filtering is instant, and playback is crisp (especially with ogg, which I don’t think iTunes supports). As with iTunes, Rythmbox has a party mode, and rule-based playlists.

One of the most exciting things about tools like Rhythmbox is its rate of improvement. In the time that I’ve used iTunes, there have been a handful of bugs that have not been addressed, like severe redraw issues on Windows, CPU usage problems, and an intrusive installer (removing iTunes is difficult). In the same time, Rhythmbox has released several patches and three major releases.

I realize that Windows is not the primary platform for iTunes, and yet it’s one of the best players available. The remaining players on Windows are either encumbered with advertising, DRM, and bling, or they’re hackish and baroque. I’m lucky to have great free tools like Rythmbox (and Gnome) available to me.

The latest beta of the Gnome instant messaging client ([Gaim]) sports several user interface improvements. My favorite is the status selector: it’s changed from a complex menu/dialog, to a simple drop/edit combination.

While static, it shows your current state and status message. When you start to type (or change the drop-down) it alters the drop-down text subtly (small/grey), which it commits shortly after you stop typing. It’s simple, and it’s exactly what I need for setting status quickly.

While not quite finished yet, I’ve finalized the features that will be available in the next release of SimpleLink. All of the existing functions will continue to be available, as well as the following improvements:

• Correct, semantic tagging. Allows all links to be used by Technorati for categorizing posts by cleaning up all outbound links. Example: A Google search that normally looks like http://google.com?q=term+term will now look like http://warpedvisions.org/tags/google/term+term (site based on WP configuration).
• All link targets are configurable with a new WordPress administration page.
• Link generation is template-based, in plain PHP. Templates can access key (and custom) WP variables.
• Link clicks are tracked for site usage analysis. Allows site admin to track downloads, specific image clicks, or abuse.
• Targets can be used to inject content into posts (like templates). This makes it possible to use the proxy to insert images, template content based on WP settings/posts, or other dynamic content (like a scrape of another site). Example: You could generate an IMDB/Amazon combined div that contained a table of data taken from both sites (images, summary stats, etc.).
• Targets can also be used to generate WP admin-specific content into posts. This allows WP admins to see edit links for locally linked articles and image upload/update forms inline to their posts.
• Link injection allows writers to insert chunks of AJAX easily into posts. This will allow WP users to display inline graphs ([sparklines]), and other real-time content.
• Improved handling for pre and code blocks.

Updated Syntax

• [!!target: term1 term2 term3|param1|param2|param3]. Targets can either be links or injections, as defined in the SimpleLink WP admin panel.
• [!![localtarget|param1|param2|param3]]. Local targets are also links or injections, but format is consistent with MediaWiki. Can also be a direct link: [!![http://test.org]].
• {{Templatename|param1|param2}}. Template targets provide a pure injection syntax similar to the [MediaWiki] template syntax.

Generated URLs

URLs will be generated to point to a local proxy, based on your site url. Examples (syntax/rules subject to change):

• http://warpedvisions.org/tags/google/test1. A simple google-search link.
• http://warpedvisions.org/tags/amazon/warpedid/0045354. An amazon link with a referal . id as a parameter.
• http://warpedvisions.org/tags/injection/sitestats. Returns a chunk of JavaScript that is used to inject content into a post.

I’m reworking my SimpleLink WordPress plugin based on some feedback and code contributed by a few users. This release will also fix a sticky bug found by a developer at Technorati, where search-based links do not form useful semantic tags. The main goal of the release will be to make the link generation configurable and to properly reflect the tagspace of the links.

Tagspaces

Tagged links are used by tools like Tecnorati to figure out what weblog articles are about, based on tagged urls in the content. Tagged urls are href elements that use the rel="tag" attribute to indicate that the url portion of the href has meaning. The tagspace of an article then, is defined by all of the tagged links found in the content. Tagged links are automatically generated by the SimpleLink plugin.

Unfortunately, many SimpleLink targets (like Google search) produce useless semantic tags, as the generated urls are crusty. For example, the [!!this is a test] markup generates a link to a Google search with the terms this+is+a+test. The url is crusty, though, as it contains words and characters that are not related to the search terms. Notice all of the line noise before, between, and after the search terms:

http://google.com/search?q=this%20is%20a%20test&btnI=

Instead, a useful tagged link would look more like:

http://google.com/feelinglucky/search/this+is+a+test

Most search-based links are crusty, making them useless as tagged links (even though it’s a really handy way to write an article).

Approach

This version of the plugin will split the plugin into two parts: a simplified plugin and a link proxy. Splitting the functionallity allows for a few neat improvements:

• Tagspaces can be represented for any type of link, as the proxy can normalize all urls and redirect them to the right search
• We can move the messy (and expensive) parts of the processing out of the WordPress rendering loop, as all links will point to the local proxy script. This allows us to delay database lookups for targets (and other magic) until the user actually clicks a link
• It will allow for a new JavaScript injection target that will allow using the local proxy as a site interface for accessing other objects (like pictures, downloads, etc.)
• It also allows the linking logic to be used from other Weblogging systems (and some of my non-weblog sites), as the proxy contains the useful logic

The proxy will be a simple Php script and .htaccess rewrite rule. The rewrite rule will transmogrify a clean url into the required Php script parameters as follows:

http://site-url.domain/tags/google/term1+term2+term3

Will be converted to:

/simplelink-proxy.php?target=google&terms=term1+term2+term3

The plugin portion will translate the SimpleLink syntax into html or javascript that references the proxy. Search links will reference the proxy directly, and content links will either generate html directly or generate Javascript injection code to grab data from the proxy. The js injection method will be useful for images and thumbnails, especially for Flickr images.

The target definitions will move from code to the database, and a simple administration panel will be added to the WP admin tools.

I’ve been searching for the ultimate design tool for years. I’ve cycled between various software approaches (outliners, textfiles, wikis, diagrams, etc.) and through the many real-world alternatives. In the end, I’m more productive designing away from the machine.

Take my notebooks as an example. While they’re full of large sheets of paper, I don’t find them a useful place to think out design. They’re far too open, encouraging designs to grow prematurely. Blank sheets of paper are a bit better, as they allow for more rapid drafting (there is no need to rip out pages), but suffer from the same lack of constraint as notebook pages.

On the other side of scale, I’ve tried using different sizes of Post-its. They’re small, forcing a very productive economy of expression. They’re also handy for sticking to stuff, which allows the ideas to be moved about and related to each other (especially useful on a whiteboard). The greatest drawback to the Post-it is that they don’t archive well, making for a very temporary store.

Recipe cards, recently repopularized by the Hipster PDA meme, represent my ideal design form. I stopped using them several years ago in an attempt to go all-electronic (which crashed and burned), and am now getting back to their beautiful simplicity. They’re small, representing a sensibly-constrained, portable thought-space. They’re rugged, traveling well in my backpack, and can be tacked to a corkboard dozens of times before wearing out. They’re cheap, easy to find, and have many available forms of affordable long-term storage hardware. They also last for darn near forever, longer than even the average burned CDrom (in a format that’s always readable).

I still use electronic tools for tracking certain portions of design, just not for the early creative stages. I have to explored the design of a project in depth before I can start to document it with standard electronic tools, otherwise I just waste too much time mutating the design with inflexible tools.

Something hit me today talking with our founder about web stuff. Most web services provide drop-in Javascripts for embedding their content, and others provide more standard interfaces for accessing their content, including REST-style APIs, SOAP APIs, and RSS/ATOM feeds. What’s seems to be missing is an interface for discovering which of these interfaces a service offers.

The idea came to me when I was describing some of the things I added to my site on the weekend, like a view of my Flickr feed and summary of my Bloglines subscriptions. For both services I had to hunt down their interface details deep in the documentation. A standard way of finding out what (and how) each site provided access to their data would be very useful.

There are a few ways that sites let you embed their content in your own site:

1. Javascript injections. You add a Javascript include tag to the HTML of your page (often in a weblog template) that causes a user’s browser to fetch a script that writes some HTML in their browser. This approach can include parameters that customize what is returned to the browser. This is a client-side API that works in most recent browsers.

2. CGI injections. Executed on the server-side, often in weblog templates, CGI injections call the remote service and add HTML to the generated before it gets to the browser.

3. XML feeds. Feeds are not generally used directly in web pages, as few browsers apply stylesheets to XML properly. Several aggregation services convert and reformat XML feeds to HTML that is later fit into the hosting site. This is a bit more work, but useful where standards exist, as in the case of RSS feeds and Atom feeds.

(I’ll ignore HTML frames as method of including content from other sites because it’s not considered a balanced approach … and it’s usually used for evil.)

So back to the discovery API, I was thinking that it would live at a standard location and return a somehow-useful set of specifications. Say something like a list of available API calls and links to their documentation. A standard for API for injection would be nice too, one that could switch between JavaScript, XHTML, XML (of various schemas), and so on.

The reason why this whole interface discovery thing hit me was that web applications are becoming exoskeletons, connecting, collecting, and reflecting our data from various locations in new forms. No one tool is complete, but in aggregate a lot is possible. So it’s about making the aggregation easier.

I had an interesting conversation today at work. We were talking about the design of a product we’re working on, something I have laid out in the deep recesses of my mind. I was planting the seeds of approach with another developer, getting him to start thinking in the new product space, and digging for feedback on the approach.

I’m always amazed at how useful these discussions are. Many years ago, I used to think that the tangent-on-tangent hallway sessions were a waste of bandwidth, a way to avoid real work. I mean, how much can be accomplished from the pasty depths of witty geek-banter? Quite a lot really.

Not all shit-sessions are useful, of course, in the same way that not all developers are productive. Or like the way that some beers really do taste like skunk water, while others are the nectar of all that is good. With the right people, office banter is golden. And with the wrong people, the office banter is better than letting half-wits build bad software.

So the impromptu design discussion covers a bunch of stuff I’ve learned in the last few weeks, and the basics of an intended approach. Within a few minutes, the developer asks a few intelligent questions. Each question pointed out something I missed from my perspective under the chaos of ideas, technologies, and seemingly infinite possibilities. That short conversation solidified my thinking, what is now our thinking, which is the first step toward a great product.

It wasn’t the only useful conversation I had today either. I was talking to our founder (who I share an office with) and our wisest Elder about technology trends related to our products. The three of us came to a realization that we’re witnessing another shift in computing, and some of the implications it has on our business. Each of us on our own had noticed the trend, but failed to fully wrap our minds around it. In discussion we realized what it was, together.

I suppose we may have found a way to describe the phenomenon it on our own, but I don’t think it would have had the same impact. Successful leaps of thought, when shared between peers has a way of sticking out more than the stuff that we dream about by ourselves. Maybe it’s the fact that you can track the event in time as a story to tell future generations, and have another voice to back you up. Or it could be that the extended consciousness of a group realization results in clarity that just can’t be found in isolation.

I’m noticing the value of office discussions more now that I work from home a few days a week. The time I spend in my home office is very productive, as I can concentrate on a problem for hours at a time without interruption. When I get to the office later in the afternoons, I’ve already put several hours into design or code and have queued up several things that need more gray matter. I like the productivity that I get in issolation, but am grateful to be able to talk out designs and trends with other able minds.

It’s been one of those active cranium weeks. The days are getting longer, we had a record month of sunshine, and I stopped watching TV. So now my brain is circling around the web publishing problem. Again. I’m waffling between building the damned solution myself and writing plugins to connect existing tools.

Last night I had myself convinced to build a new wiki/weblog tool. It was so obvious too, I could see the entire design. It was the only approach that would do everything I wanted. And then tonight, after playing with WordPress 1.5 and talking to a few people at work, I can see another path: to build it as a set of plugins and additions to WordPress, MediaWiki, and other external or home-grown bits.

It’s a balance between what I want to spend time on in the short term, and what I can honestly commit to in the long term. I keep asking myself if I really want to build, maintain, and support an entire publishing platform. I’m really more interested in the ability to create content. It strokes my ego, and lets me show other people some of the stuff I do. But I want all of it in one set of tools that are interconnected and easily extended.

The software has to integrate different types of content nicely. As I was saying last week, I want a hybrid of a page-based and news-centric tool. Something that’s sort of like WordPress, something that’s kinda like MediaWiki … and then something that can connect to various other bits.

There are problems with the many-tools-hacked-together approach that adds an odd balance to it. Styling each tool in a consistent manner, for example, or allowing inter-tool searches requires deep integration. Providing a single user login between tools and providing a consistent syntax for content markup are also important (and non-trivial). But I don’t think that any of these things make itimpossible, and they can be built incrementally.

The existing tools (like WordPress 1.5) improve regularly and significantly. Each has a mountain of community support. The tools are well maintained, tested, and they are good at what they do. Contributing to and connecting these tools together seems to be the sensible approach, but it will force me to rethink my expectations.

Damn it. I think talked myself out of building it again.

We received (and bought) a few Lego tubs this Christmas. The price was right ($23 CAD for 2000 pieces) and the stuff is fun, but Lego is starting to skimp on the plastic.

Old Lego	New Lego

You can see the reduced thickness of the walls and the centre shaft. The pieces feel lighter, and don’t quite fit as well - though no where near as badly as the knock-off brands. A good value overall, but they need to be careful how much they play around with the brick quality. Someone might notice.