I've been casting about online for some kind of portable training device, something that can keep track of my time on the road while I train for a particular race later this year. There are quite a few options for watches, each with options of their own.

One of the more fascinating watch brands out there is Suunto. There are a couple of other makes that have similar capabilities, but Suunto looks to have expanded on an interesting idea of connecting wirelessly to peripherals like a chest-worn heart-rate monitor, a bike cadence monitor, and even a GPS. The watch acts as a central processor for the peripherals, receiving, recording, and presenting a subset of the information, and then relaying it (via USB tether) to a computer for more intense processing and output.

While all of that is interesting, I think there is a surprising lack of movement in a particular direction that would make watch computing much more interesting.

Ok, so here's the idea I've been tossing around in my head. Imagine that there's some wireless protocol that allows a device to broadcast the control that it offers, and can receive control instructions. Let's call it, say, bluetooth. Suppose that your TV, your DVD player, you MP3 player, your phone... Suppose that all of these devices are broadcasting short-range signals that allow them to be controlled by some controlling device.

And try this: Suppose that there are some other sensors in the environment. Just as an example, suppose that there is a digital thermometer outside your kitchen window, and it too broadcasts data. Instead of broadcasting control data, it simply broadcasts informational data about temperature, humidity, wind speed, etc.

Ok, so maybe you're not happy with just the current weather info outside your window. Your computer can broadcast weather information - possibly any information it wants - from the internet. You could configure your PC to grab any information you like and broadcast it... But to where?

Your watch.

So here were some fun parts I've been thinking about. Your watch receives the signals, and provides UI for any of the controls that the device makes available. Because of the nature of the protocol, the watch maker can provide whatever interface controls it wants. You'll be able to consume those controls not just with your watch, but with whatever device can understand the protocol. So there could even be a variety of watches that provide different interfaces to the same sensor information.

When consuming data, the watch could also vary in the amount of computing power that it provides. For example, a low-power, low-cost device could simply display the temperature data it receives. A higher-power device could store historical data and plot it over time, correlating it with regional historical data retrieved from the computer. Keep in mind that even a low-powered device could be in command of higher-power processors via a wireless command and control link.

Storage is an interesting thought, too. Obviously, you don't want to have to rely on a persistent connection to the internet. So when you're within range of your PC, it transmits a packet of information that the watch can store and use when it is not in range. When you move out of range, it makes use of what data it has in storage.

Moreover, and perhaps more cool, is that as you move through the landscape of free and open sensors, you can choose to consume them as you see fit. So if you're on the beach, and the transmitters on the boardwalk are broadcasting tide info, you'll know when to go surfing or build your sandcastles. Other watches might also provide a broadcast signal to other watches that could use this proximity information for presence or even a loose grid network.

There are a few issues. One is the size of the interface. I think that a touchscreen is probably pretty efficient, but not with the finite control to select specific points in the UI. If you look at the Tissot T-Touch, they've got an interface where you can touch the screen around the edge of the bezel in about 6 places to indicate the function you want. I think that's a little draconian in comparison to our modern multi-touch controls on MP3 players and phones, but consider a control interface that typically isolates "click" control to a finite number of discrete areas and also allows you to "swipe" across the face of the watch to flip through interface pages or confirm menu options. Applying an interface like the Zune's "twist" interface could provide a reasonably intuitive way to select options and browse through any available data.

Another issue is battery power. I'm reluctant to have to plug the watch in to recharge every night. Plugging in some necessarily tiny and usually sealed connector seems like a pain, especially considering that my current watch is solar-powered and doesn't ever need a battery change. Some kind of inductive charging/docking station would be neat. Set the watch in the station to both charge and dock it to the PC for data exchange. Pretty slick, I think.

Ultimately, I'd like ubiquity of my data. I want to use my watch - my same, every day watch - to keep track of training data, then check out the TV schedule while sitting on my couch, then set my house alarm when I go to bed, then review my flight itinerary while on vacation, then see the caller ID info from my ringing cell phone and maybe even answer it... Etc.

I think there's a mental roadblock with how processing power should be distributed. People seem to think that their phones are capable of all of this. Phones are great. I rarely leave the house without my phone. Nonetheless, my phone is just a small part of the overall picture, and I'd still like to have some device that is a window - even if it's a small one - into my processing power and data strapped to my body, always available.

Even if the eventual window has to be my cell phone, which I think is a very myopic view, it should still have the same abilities that I've described for this watch. Also, it shouldn't be limited to just the phone. You should be able to do this with any device, and all devices that are capable should also be able to commandeer processing power from any device that offers it. If you've got 4 PCs in your home enabled for it, your watch should be able to pool their processing power to perform any task asked.

I think it's a good idea, and the technology should exist to produce it.

Photo by: http://www.flickr.com/photos/jmrosenfeld/ / CC BY 2.0

I've lately had the inclination to rebuild my blog's relevancy from the last year of once-per-month posting. Maybe you've noticed the last few days. By integrating blogging into my daily schedule, I think I can churn out blog posts with regular enough frequency to get "back in the game." As with most things, it would probably be easier to have someone to do this with rather than doing it alone.

So I was thinking about Inksmith lately. We've seen ideas like this come and go, but I think the idea of a new blogging fraternity is a good one. A membership system would simply relate all of the bloggers to the others, maybe aggregate posts, and provide a topic support system.

I'm not sure how much I'd like to personally invest in building such a fraternity, but it seems like it could be done with very little effort. Write up some simple rules of membership, post them somewhere people can get to, and behave accordingly. What rules would such a group have? Any thoughts? Wanna start one with me?

Alex and I have been going back and forth in comments over the areas of our interest that overlap. In his recent post, he asks, "how long can organic communities self-moderate?"

I admit that I haven't read the Starfish and the Spider, although I did just one-click it into my Kindle, so it's doomed to suffer my analysis. Nevertheless, I had some comments about how leaderless organizations can thrive, particularly in open source communities, of which I happen to be a part of a couple.

Obviously, one of my passions is working with Habari and the people that have come together around that common goal. When we started, there were just four of us, each with various levels of ability and availability. I think you can pretty well call that "leaderless", since we all worked in tandem, and any small change any one person made was easily detected and reviewed by the other three. But as the project has grown, I think there is some kind of tragic irony in that the size of the operation inevitably leads toward a need for at least an informal management structure.

Of course, any of the Habari folks reading would rightfully start screaming at my last statement. The cornerstone of our philosophy is that no animal is more equal than any other. Still, without naming myself supreme ruler of the project, I think there remains a practical aspect to several individuals having responsibility for making things work and controlling the direction development takes.

What I've always hoped with Habari is that the community would fracture, but in a good way, and that the different aspects of the system would be able to communicate with each other in a way that is productive for the whole. An example of this came up today regarding our published documentation.

We've been using TiddlyWiki for our distributed documentation - the manual - which is supplied with the source of the software, separate from the online wiki. Basically, the large online docs have been distilled into a neat little dynamic wiki manual that comes with the software. A few folks who are less technically inclined decided to make documentation their project, and upon reviewing what we had, concluded that the manual was nice but not internally consistent, because it simply pulls parts of the larger wiki. As a result, they have started rewriting the manual as a single cogent file.

Following pointing out this effort on IRC today, I was asked by the person who originally suggested TiddlyWiki for the manual as to why we were dropping TiddlyWiki. My response to him was basically that some folks had decided to own it, and what they were doing was probably better for the project in the long run, and how could I not support that? And I think he agreed with my reasoning. But also, a personal reason - one that might or might not have been implied - was that I didn't really want to have anything to do with the manual.

I long ago realized that I simply can't keep the whole project in my mental scope any more. Back when it was just four guys, I could keep track of every change. Now there are 25 PMC members, and many, many more contributors and users that supply insights and patches with a regular flow. I can't possibly track it all in a way that makes my own contributions worthwhile. So I've decided that if people come along that want to manage a part of the project, they present their ideas well, show some vision I can get behind, and lead other people to follow them there -- I am behind that effort. And those are the people we're looking to promote to the PMC as leaders anyway.

To that end, we've been working out a way of handling when splinter groups want to take on specific tasks like these. We call them "working groups". The concept may be familiar. We started out with some formal guidelines that explain how the groups must be formed and to whom they report, and many of these processes are followed and documented, but personally I think that even as informal groups these units work fine.

The key feature is that there is always reporting back to the main group. They make plans and present them, and the main group has the opportunity to provide more insight, to join, or to dissent. Although the working groups may go off on their own to implement the plan, they don't do everything in secret or behind a gate. Anyone has the ability to shift in or out of a working group as his interest dictates.

This has been working well for documentation as well as code. Some of our larger initiatives have started out as branches created by others who want to work on a specific task together. The larger group provides some oversight, but the working group is mostly autonomous until the code is submitted for merging. Then others review the code as necessary.

I suppose it's easy to quantify the project in terms of output, but longevity has a lot to do with the social formula too.

Completely separate from the users of WordPress, the community of developers for WordPress used to spend quite a lot of time talking on IRC. At some point, because this relationship was not encouraged, the heart of the system died. Now on the WordPress IRC channel, some developers might idle, but it's mostly a desolate place where people come to ask questions that echo into the oblivion, unanswered.

I assume that the social structure for WordPress has moved elsewhere. Perhaps it's within Automattic itself, or in the halls of the many competent WordPress consulting companies that have formed. But it has changed over time.

I'm hoping that we've made some decisions early on that will affect how Habari lives and works long-term. We may individually have plans for making commercial moves with Habari in the future - not Habari itself but services around it - but the social network (not Facebook, but a network of real people) we're trying to build will hopefully stay strong until the project is obsolete.

Being a worldwide community, we rely on leaders even in different timezones. When I sleep someone is leading the community. Even when I'm around, I'm not always "present", and other people fill in. Part of that is related to how the project gives people more control, more involvement. Part is that the people actually care to do it. When the people who are involved don't care any more, they should move on. I hope that we can keep adding people who care enough to keep things going as much as I do.

I'm not really sure that answers any specific questions, but it's how things are, and how we've managed to survive this long, and hopefully what will keep us moving.

I've just finished a science fiction book by Vernor Vinge called "A Deepness in the Sky", and one of the themes of the book is technological collapse; how civilizations can only live so long and evolve so technically before they implode. The trading race that travels and trades between these civilizations sees everything and deals with everyone. Along the way, they record this knowledge and the knowledge makes them great and lasting. By adhering to a set of social rules and general beliefs, they are able to outlast their customer civilizations. It reminds me quite a lot of what I think organic communities need to survive, not so much that a strict process is followed, but that the entire race of people shares a belief that powers their way of life.

We had a discussion at work the other day, and again on IRC recently, about what to name our computers. At first this might sound like a silly thing, especially to people who use a single home computer, but for people with more than one at home or who use computers every day at work, it's something that you probably end up thinking about at some point.

All of my computers at home are named after "characters" in books. This computer is Defiant, named after a spaceship in Bill Baldwin's Galactic Convoy novel. My file server is Naruto after the manga character, and my notebook is named Runcible, after a much higher-tech device that is the center of the Neal Stephenson novel The Diamond Age.

I tend to be pragmatic about my server naming because there are just too darn many of them to remember, but many people and organizations give them more fanciful names. For example, A Small Orange uses characters from the show Lost to name their servers, as I noticed when editing some of my content on Hurley.

I've heard of some (extremely geeky) people using Star Trek ship classes and Star Wars planet names as computer names. One of the criteria, I suppose, for choosing a set of names is that you have enough for your entire network, because you don't want Moe, Larry, Curly, and Fred. The Seven Dwarfs might work well if you only have seven machines, but certainly doesn't work for twelve.

I wonder if anyone has any more imaginative name sets for their computers. Even if it's just one, you know you have to name it.

A few of the folks I "hang with" online are/were involved in the 9rules network. I am not a member, but I had tried to become one at one point. I've been following the recent actions of the network with some interest, and thought I would save my thoughts for later as they may be relevant for other communities in which I am involved and have influence. Some background on the current issue is probably in order.

Essentially, many people had joined the network for the purpose of being affiliated with other bloggers who created great content. Their goal was to enrich the web. These folks chose to participate in the network insofar as they posted new, quality content to their own blogs, which were syndicated specifically to the rest of the members. Although the network powers-that-be had created a site for interaction among members, these folks never saw participation in those forums as a requirement to their membership, simply their continued contribution of quality blog content.

Recently, the terms of membership changed so that you must participate in the forums to remain a member. The people who thought that their blogging contribution was enough realized (with different levels of reaction) that they would no longer qualify for membership and asked to withdraw. This accounts for more than half of the people who I relate with who are/were also 9rules members. What's bothersome to me, especially had I been a member, is the process surrounding the change of the terms of service.

It seems as though the people deciding that forum participation should be a requirement were the people who were already active on the forums. Members who did not see a value in the forums or did not see participation there as a requirement for membership understandably did not visit the forums to participate in the decision. Rather than send email to members asking if the change would be agreeable to the membership, the decision was made and notices of the change sent.

It is interesting that so many people had a different impression of what 9rules was all about and have left. Not only is that interesting, but also the reaction that the 9rules maintainers have had to the poor response to their actions. Take for example Christian's experience.

The responses in the comments there from Tyme and Scrivs, two 9rules maintainers, seem openly hostile. You can find examples of similar reactions from them on many of the sites who have decided to leave the network. It's natural that they would be upset that people would leave, but to react in such a way is very strange when trying to foster a community.

Moreover, wishing that the communication had happened privately when you operate a blog network is an outright pipe dream. Listen to yourself speak the words: "Private" and "Blog". Nuh-uh.

What might have been a better reaction to the growth of their community? A better effort to shape the direction of the community than alienating their long-standing members. The solution is simple.

When communities get large, they naturally segregate. By separating the forum participants from the non-participants, but allowing the groups to continue, both groups could thrive within the community. Instead, the two groups were created, and one of them was told to shove off. If one of the main purposes of the network is to help each other and be a community, this is a very strange way to accomplish that.

I suppose it's easy to stand somewhere outside all of this and preach, not having built my own blog network or managed their large membership. I am interested in all of these going on because practically all of the bloggers I know in real life were members of 9rules, and it's all I hear these days. Plus, being a leader in a (non-blogging) community of my own, I am interested in the metamorphosis of this network that was once well-respected by the people on the web that I myself respect.

Were I to create my own blog network (and I have no delusions that I have time for such a thing), it wouldn't be about creating content for the network site. It would be about connecting users better.

The web is too diverse to drop every blog into a single, strict category. It's also difficult to find the "key site" that pulls together the blogs dealing with a single topic.

For example, I hang around with a lot of Philly bloggers in real life. I write about hanging out with them. I write about my own experiences in Philly. While my site does have content about Philadelphia, you'll note that it's not primarily a blog about Philadelphia. Pigeonholing my site into a single "Philadelphia" category seems narrow-minded.

If I was looking for a list of bloggers from Philadelphia to see if they had similar experiences to mine, or simply to read about what's going on in my area, where would I go? There are a few sites I know of as starting places for sure, but there isn't a place that connects all of them together well. Even the ones I know of that connect them to some degree are all content-generating, meaning that sure, you have a blog of your own, but membership is based on your contribution to the aggregating site.

A better blog network would unite people with common interests. It would pool sites together like Technorati does under specific but varied tags, and give bloggers more control over which channels their own blog (and blogs they read) belonged to. You would be allowed to categorize content from your own site or others', create events and topics for discussion among the blogs that fit your reading criteria, and participate solely from your own blog: Content is for your site, indexing, relation, and membership is provided by the network as its sole features.

One of the things I really think would be neat is a way to forward discussion topics to people who have expertise or interest in what you want to read about. You could forward food topics to groups of foodie blogs, or tech questions to techie blogs via the network, and then watch the network for blogs that respond to your topic. Blogs that write about a chosen topic could see what other blogs in the network have also said about that topic, and contribute to the conversation on those blogs. The network site could map that interaction as output that outsiders could follow. It could be very cooperative, yet wouldn't require participation in a forum.

Well, it's something to think about for later when building up the Habari community, to make sure that if we refocus what the community is all about (which I hardly expect us to do, but you never know) then we need to make sure that we don't let go many of our long-standing respected members for lack of informing them of the changes and asking for their involvement.

Plus, if someone cooks up a network such as I've described, be sure to invite me.