I adore Settlers of Catan. I’m a rather late convert to the game, but I’ve become keen. Most weeks I host a game of Seafarers with six players, but this week I got invited elsewhere and we played two simultaneous games. All good fun, but in the course of it there was regular joking about trading resource cards between the separate games.

I have proceeded to take the idea entirely too far, and so here are some Rules for International Trading in Settlers of Catan.

It’s the very first draft, it’s certainly incomplete, and there are sections where different mechanics are documented that could be applied. However, I think it should be playable in some combination, so if you’re so inclined, or just wish to offer further input, here it is.

(At some point in the near future this text will move to my wiki to be revised.)

The Scenario is this: You have multiple simultaneous games of Catan running at the same (presumably quite large) table. The games are operating independently, but the players of course interact socially.

This idea is to add a practical, fun mechanism to the game of Catan to allow interaction within the game; namely trade. This is non-trivial.

Requirements

• Two (or, I guess more) simultaneous games of Settlers of Catan
• The Seafarers add on.

It is not be necessary for both games to use Seafarers; in non-expanded games the Ships and Chits can be shared between players of both games, and only used to establish International Trade (see below.) Alternatively, Rules for International Trade can be added to simultaneous games of Seafarers.

Aims

• Allow players in one game to trade resources with players of another, independently operating game.
• Reward players for international trading
• Do not obsolete local trading.
• Do not introduce an overly unbalancing aspect whereby a player could bypass their entire local community and only trade with other nations.
• Don’t break the game in any other way.

General Gameplay Mechanic

The idea is this: The two games are played side by side, with boards aligned. Between the boards is a section of water (from the Seafarers expansion). The exact distance between the boards would have to balance the cost/reward of establishing international trade.

At any point in the game, a player from one game may build a Trade Route (using Ships, from Seafarers; costing 1 sheep + 1 wood per ship) from a coastal Settlement on their Catan island and connect to a corresponding coastal Settlement of another player on the other island. This establishes an International Trade Route.

Once a trade route is established, trading between the two boards may occur.

The only economic transaction enabled is trading. Local economic mechanics (such as rolling a 7 and losing cards; similar to a recession) remain localized events.

Establishing International Trade Routes

• Player builds ships from one island to the other
• Distance should be non-trivial (maybe 5 ships?)
• Players from one Island may not build on another game’s Island (not least because of colour conflicts between the playing pieces)
• Two players, one from each island, may establish an International Trade Route together by both building shipping lanes extending from their Island and having them meet at some point in the sea.
• There is no restriction on the number of International Trade Routes that may be established.

Upon establishing an International Trade Route, the player establishing the trade route should receive a reward of One Victory Point. This is represented by a Catan Chit (again, from the Seafarers set.)

At this point, I have varying ideas about the mechanics of trading. Either:

1. International Trading is only available to the player that established the route, with any player in the Other Island.
2. International Trading is only available to the specific players whose Settlements are connected by the route.
3. International Trading is available to all players of both games as soon as the first International Trade Route is established.
4. International Trading is available to all players of both games as soon as the first International Trade Route is established, but trades may only be initiated in the direction of the Trade Route (e.g. Where Island A connects to Island B, players of Island A may initiate trades with players of Island B, but players of Island B may not initiate trades with Island A until a player from Island B has himself build an International Trade Route to Island A.)

Aside: What if Island A is connected to Island B is connected to Island C? (Answer: Probably nothing.)

If a mechanism is chosen whereby only the owner of the route may trade, that is benefit enough in itself. But, that may limit the feature, and it’s unreasonable to expect all eight (or twelve) players to establish separate International Trade Routes given the amount of coast available.

If the establishment of Trade is shared between all players, then there are two options for rewarding the building of the Route:

• The initial Victory Point represents the Nation of Catan ‘purchasing’ the trade route from the Player; after this purchase, the route serves all Players equally.
• The initial Victory Point is a bonus, but an additional mechanism exists for the Owner of the Route to be rewarded when other Players use his Route for Trade; a Tax.

Tax is interesting. It would have to be balanced carefully, else other players would be discouraged from International Trade except in cases of desperation, and the Route Owner may accelerate to Victory by only trading with the Another Island. On the other hand, where there are two competing Trade Routes, Players would be able to choose which Route to trade over based of the favourability of the Owners.

Tax would take the form of receiving a bonus for every trade that occurs (either per trade, or more generously per resource traded.) That would be indicated by accruing Catan Chits… which in turn would drastically devalue them. Where normally a Chit corresponds to a whole Victory Point, rewarding one Chit-per-Trade would be incorrect. You would end up with a Chit:Point ration of perhaps 5:1, or 7:1. That might affect the use of Chits elsewhere in the scenario, or simply require more Chits than the game provides.

Performing Trades

Local trading normally occurs spontaneously after the dice roll and may be mixed with any amount of building. In larger games there may also be Special Building Phases to allow construction between turns. As per the trade restriction rule for regular Special Building Phase, Players may not Trade Internationally between turns.

In a nutshell, an International Trade operates exactly like a local Trade, but the Player initiating the trade may extend his request/offer to players of Another Island connected by an International Trade Route.

Since the two games of Catan are operating asynchronously, some structure needs to be in place to specify when international trade can occur. These are the current possibilities:

1. An explicit International Trading action, occurring immediately after the dice roll. The two active players (that is, the two players whose turn it is on each separate Island) may take it turns to initiate trades involving all players on both Islands. As per local Trading, only the active player may initiate trades (though other players may approach them socially.)

** The downside here is that you require synchronised dice rolls to act on.

** If the rolls aren’t synchronised, then International Trading is skipped for that turn.

** That may end up being unfair on some players who miss out on trades. Or, it may balance out over multiple rounds with different players missing International Trade windows at different times.

1. A dedicated International Trading Round — performed once per turn cycle. Rather than relying on synchronisation of individual turns, trigger an International Trading round once per turn cycle; that is, after every player has taken a turn, invoke International Trading before starting the next cycle.

** When one game reaches the end of a full cycle of turns, if any of the players on that Island wish to trade, they may wait for the end of the current turn on the Other Island and then proceed with a full round of trading.

** A ‘round of trading’ would mean that each player, starting with the first player on the island that invoked the International Trading Round gets to invoke a set of trades with all other players in all games. Each player in turn (clockwise around the table?) may offer/request a trade.

I think I favour the former ‘trade if possible’ scenario on the assumption that enough opportunities will come up.

Disrupting International Trade Routes

International Trade may be temporaily blocked by placing The Pirate adjacent to a Trade Route. Whilst the pirate is blocking an International Trade Route, players may not trade resources with players on the Other Island.

In a full Seafarers expanded game, each board will have its own Pirate, operated by its home Island only. Rules for moving the Pirate operate as normal; the local Pirate may be moved instead of the local Robber, and may be moved to block or unblock the International Trade Route at the independent whim of the Players of each Island.

Aside: Politically, an entire Island could choose to unite for Protectionism and maintain a block on International Trade (requiring a second route to be built out of the range of a single Pirate to overcome the policy.)

In a game where the Seafarers set is shared between games for the purpose of enabling International Trade only, either Island may use a local Knight or local 7-roll to move the Pirate to block an International Trade Route or to move the Pirate away to restore International Trade.

However, in games where the Seafarers set is shared for International Trade only, moving the global Pirate is an optional action additional to moving the local Robber; this is to prevent it being used as a way to avoid moving the Robber from a particularly effective hex on the local Island.

International Waters/Ungoverned Territory

A further modification of this, to add further incentive for building the initial shipping route between Islands, would be to add extra land mass (probably Gold) between the two Islands. Players from both games would be allowed to settle on these Gold isles, and they would behave the same as Gold in Seafarers—when the hex is rolled, each Player with a Settlement gets to choose which Resource they receive.

2010 is the first new year in a while where I don’t feel like I’m washing up off the back of a big wave of change.

2009 was a mostly stable year. I’m in the same place (San Francisco), in the same job (working for YDN is the longest time I’ve spent on a single team in my nearly three years at Yahoo), and my friends in the States and back home have been that way for a while now. I ended the year feeling that things were ordinary, and actually recounting it to friends in England felt really quite dull. I hadn’t seen most of them in 12 months, yet little is really going on in my life.

This time last year I’d just been laid off, rehired, and confronted the very real possibility of deportation. Given that, I’m happy to be reflecting on an uneventful year. The Christmas break has me rested, and with nothing big carrying over from 2009, I fly back to California next week knowing that I’m not returning to chaos, but a stable, sane foundation.

In the Bay Area there’s a certain pressure to be doing. There is an intensity of talented, inspirational people around you. They’re always thinking, building, hacking, creating, always doing something. It’s infectious, and at various points in 2009 I have felt quite desperate with myself for not being part of that. A few small, never-emergent failures—they may yet be resurrected one day—but never really pulling anything together. Ideas are free flowing; that’s a good thing for sure, but I look back and realize that whenever I had the urge to produce something, I had too much in the air already.

The temptation is to respond to this clarity and stability with ferocious intent and planning. I’m resisting. There are a number of interesting new things I want to build. There are existing commitments to microformats.org that could always use more time. There are a couple of old projects I’m curious to revive. I’m resisting because I don’t know which of those various efforts is most important for my time right now. I’m committing to nothing, because committing to doing anything still finds a way to take up my time, producing nothing.

Picking any project is not the game. Picking the right project at the right time is the game. Once I’m back home, back in my routine, I’ll know what I really need to build. And I’ll build it because I can, and because I’ve left myself the space to do so. I’ve learned, slowly and unproductively, how to keep myself in the right state of mind to produce interesting things. A bold declaration of vapourware isn’t it. When I do start a new project, a repository will appear on github.

On a different tack, I do have one new project. I’ve elected to participate in Anton’s Project52. It’s a writing challenge; specifically a blogging challenge, but we’re all just writing now, aren’t we? Personal publishing fascinates me. It’s turned out to be a far more subtle, volatile experience than I ever expected from that first installation of my b2evolution blog in July 2004. I’ve been through different balances of personal verses impersonal, articles verses links, as well as changing expectations of the content I want to write. My opinions on how others should interact with my content, and how I should interact with theirs has changed over time too: Comments! No comments! Some comments!

In 2009, the blog on this domain—benward.me (née ben-ward.co.uk)—received six (count them) posts. All were long, and all I’m still very happy with. I drove myself into this low-output hole by imposing an expectation on myself that all my posts had to be huge, grand articles. I still want to write like that; I still want to tick the boxes of whatever I think is ‘proper’ writing at the time. But this year I found new outlets: A wiki, and Tumblr.

Tumblr is an interesting, odd beast. On the surface it’s a blog host. That’s what drew me to it. It was a blogging platform with a super-simple, clean interface. Their bookmarket for quoting articles, photographs and video was outstanding, and it encouraged me to just link to things, or embed video. It was quick-fire and having been thrown off Pownce, I learned to love it. Last year, whilst I wrote only six article-length posts over here, I posted 494 items to Tumblr. Things that interested me, spontaneous thoughts, quotes and comment. In the end I wrote a lot.

The thing is, though Tumblr is described as a ‘micro’ blogging service, with its lack of comments, incestuous linking strategies and lightweight follower/subscription model, the ‘micro’ is really only relative to people like me, who through their own fault turned blogging into something big. At the origin of the permalink, Jason Kottke wrote a single paragraph, the post didn’t even have a title. Tumblr isn’t microblogging; it’s blogging.

Whilst I love Tumblr; for helping me relearn to write, for connecting me with people, I also have some discomfort. I dislike that the data is locked away behind a very limited API. I dislike the ‘reblogging’ model of conversation (and have been reading Tumblr content in a regular feed reader for a while now), but mostly, I found that the separation I made between this site and my Tumblr blog started to break down.

I’d quote something, and start annotating a response. Suddenly that response was three, four, ten paragraphs long. Suddenly I’d written an article, and it was posted on the ‘wrong’ blog. When I started, I thought a separation between long form writing and short form writing was obvious, but in practice I seem to spontaneously morph between them. Keeping two separate sites is therefore wrong for me.

I’m going to merge my content back together (on this domain), but I’ll put tools in place to ensure I’m participating in the Tumblr community as well; I like it, I just need better control of my publishing. The difference between long-form and short-form content will be left to spontaneity, which was probably always the best way to do it anyway. The merge of old posts will happen soon, and I’ll expose more granular feeds to accommodate anyone that only wants six posts a year.

My wiki isn’t public yet, but it does exist. Along with rediscovering the joy of posting short stuff, I’ve acted on my old post Practical Publishing ; the separation between publishing chronological content (where accuracy and opinion is rooted in time), and revised content (where you aim to keep a document current as time goes on.) The wiki software I’m running needs a bit of work to roll it into my site, and to expose relevant major edits to chronological consumers, but it’s getting there. I’m writing on it, even though you can’t see it yet.

In shaking up my writing tools, Project52 makes a lot of sense for me. Merging it all back together, there will be short posts and long posts. There will be wiki pages of documentation and state-of-the-art. By producing (at least) one article of original content each week (either a post, or a wiki page), I hope to find a good balance to my output, and kick myself into finished some long unfinished draft articles, too. In my tools I’m embracing flexibility again, so I hope that will leave me free to write. I’m excited about it.

Happy new year. I hope it treats you well.

Earlier today I took a certain amount of pleasure ripping into Jon Dowdell’s disingenuous Adobe on HTML5 post from last week. However, I happen to think that there are some useful points to be made about the relationship between Flash and HTML5, and how one affects the other.

It doesn’t look good for Flash. But Flash isn’t going to die.

Firstly, consider some background. Flash has been around for a very long time, providing a platform for games, vector graphics, animation and media playback. It offers massive market penetration, and of course there is only one Flash player, so it purports to offer a consistent experience across platforms.

However, Flash comes with a number of significant downsides. Firstly, that ‘consistent experience across platforms’ might also be written as ‘inconsistent experiences on every platform’. By taking most of its user interface conventions from Microsoft Windows, the experience of using Flash on a Mac is not the same as using any other app in OSX using native controls. Simple stuff like the behaviour of keyboard chords in text entry controls are different, the text selection colour doesn’t match the system selection; low level stuff.

Similarly, the Flash plug-in itself is cited by Google and Apple as being a massive cause of crashes in their browsers, crashes that the browser maker gets the blame for, but is really caused by Flash. In Google Chrome and in OSX Snow Leopard, plug-ins are sandboxed away from the main browser process. Mozilla lists Flash as the biggest causes of Firefox crashes on Linux.

To top it off, for all the claims of ‘Accessible Flash’ over the past year, Flash content is still only accessible on Windows; on Mac OSX, Flash has no integration with VoiceOver. Screen readers are only supported on Microsoft Windows through the MSAA API.

The iPhone shipped two years ago without Flash support. At the time, some said it was a ‘missing feature’. 24 months later, the iPhone seems to be doing just fine without Flash, and users seem very happy. Adobe have stopped making vapourous comments about having ‘Flash for iPhone’ waiting in the wings.

There are two distinct threads to a Flash vs. HTML 5 discussion. Those are ‘Features’ and ‘Philosophy’. Let’s tackle them separately.

Features

HTML 5 is gaining mind-share because of a handful of key new features that it offers: <video>, <audio> and <canvas>.

The first two are quite self-explanatory, they are new elements dedicated to providing video and audio media directly in the browser, and provides a DOM API for controlling the media from JavaScript. Note, the idea is that the media is played back directly by the browser, not through a plug-in like Quicktime or Windows Media Player (which is how video used to work, before Flash).

This affects Flash because over the past few years, perfectly timed with the rise in available bandwidth to stream audio and video, it provided a solution better than the Quicktime/Windows Media/RealPlayer mangle that came before it. Before, to embed video in pages you needed to provide multiple codecs, depend on bespoke media player UI appearing in your page (all of which was different sizes, and so would break your layout), and half the time your visitors had the wrong version of the plug-in anyway.

Flash stepped in with a solution: Support for more platforms than any one of the other bespoke players, and you could design your own playback UI around it, too.

Flash won video from under the feet of Apple, Microsoft and Real by building something that was better, and bypassing their squabbling over codecs.

But, it’s just a better, bespoke solution. It’s still vendor dependent. Flash provided the use-case for ‘embedding video with author-defined playback controls’. The purpose of standardisation is to take that feature and define it, such that anyone can implement it. From there, comes video and audio in HTML5.

Flash also provides vector drawing tools. It’s another useful use-case (graphing, interactive charts, etc.) Again, the standardisation process for HTML is about taking the use cases from real content on the web and defining it so many people can implement it. canvas (via. Apple) is the implementation for that.

Three major pieces of functionality. Putting them natively into the browser responds to the needs of web developers. That’s what the standard is for. Does this mean that HTML 5 ‘kills’ Flash because previously Flash-only functionality is now native? No. But it means that those major use cases no-longer require Flash. There’s plenty of other, less trivial functionality that Flash supports for which widespread demand does not exist. But of course really common features of web pages are going to be supported in Open Web technology.

Additionally, you may cite sifr — using custom typefaces — as a use-case for Flash. That falls outside of HTML5, but is covered by an increasingly well supported CSS3 feature, @font-face.

Philosophy

I’ve avoided linking Jon Dowdell here as a major source because although he titled his post ‘Adobe on HTML5’, his blog also states that his opinions do not represent his company. His post is representative of Adobe’s general philosophy toward the web, though.

As far as Adobe are concerned, Flash is part of the web. It’s not just an optional, bolt-on plug-in for proprietary content. To Adobe, Flash is as much a part of the web as JavaScript or CSS. They regard is as a legitimate part of the stack.

“the “HTML5” publicity helps marginalize those few who still argue that images, animation, audio/video and rich interactivity have no place on the web. Flash will be able to deliver on those heightened expectations, regardless of what each separate browser engine does.”

The second part of Adobe’s philosophy is that consistent support for functionality on the web is non-negotiable.

“we really do need the ability to predictably deploy advanced capability across a range of device brands and browser brands”

This philosophy is wrong. One: Flash is not part of the web. The web is the Open Web and anything closed and proprietary is just riding on its back. I don’t mean that bespoke plug-ins are unwelcome or even ‘wrong’; they provide all sorts of useful functionality. I do mean that if you are a single-vendor creator of a proprietary, patent and license encumbered, undocumented, closed-source plug-in then you have no claim to be part of the infrastructure of the web. The infrastructure, from TCP/IP upwards, is open.

The consistent support aspect also flies in the face of techniques used with every part of the Open Web stack: Graceful degradation, progressive enhancement, and the fight against the misguided demand for pixel perfection are all battles that have been fought and won since Designing for Web Standards.

The web is about content. Everything above that is dressing (perhaps think of the web as fresh bread, perfectly coated in balsamic vinegar and olive oil). The fact that older browsers cannot render all the features of your page but can still provide the content to users is a feature. It’s the most important feature.

The Flash philosophy is opposite. Flash is about a complete experience (singular). It’s about every detail being precisely bevelled into place for every viewer. The consequence of this approach is that it resists the availability of content. The goal of perfect consistent rendering can only be achieved through a single version of this single vendor’s bespoke plug-in. If you need a feature of Flash 10, Flash 9 users must upgrade to see any of your content, not just the new feature.

The Flash approach is anti-content; anti-web. Adobe present the idea that Flash is a superior offering because the entire suite of features, in one big blob, is a compelling development offering. But the reason to write on the web in the first place is to make content available broadly.

In recent years, through multimedia, fonts and and vector drawing, we’ve seen more and more blocks of content moved into Flash, in the absence of a robust standards-based mechanism. HTML5 redresses that by supporting those use cases. HTML4 supports pictures. HTML5 supports moving pictures. HTML5 supports what people publish on the web.

Fuss

What is the fuss about? HTML5 doesn’t compete with Flash as a product, (you could never produce an implementable specification for so much functionality in one go). It just takes some specific, common use-cases for web content and supports them.

Yet, people on one side are crying for the absolute death of Flash, and clearly some from Adobe are on the defensive to outright dismiss the HTML5 effort.

Critics may be motivated by any number of those negative user-experiences this article opened with, but Flash won’t die. If HTML5 takes away one use-case that Flash fulfils, Adobe Flash will add new features that browsers don’t have. That’s what plug-ins have always done. Flash can and will iterate faster than browsers and can deploy wider all at once. That said, some of those existing use cases — namely video playback — are extremely lucrative for Adobe. Video took Flash from ‘optional’ to ‘essential’ for a certain slice of web content. The video sharing industry is dependent on Flash.

Adobe will lose their exclusive grip on that. But, what did they expect? That a massively profitable industry would tie themselves to a single vendor?

Flash offers only one advantage to video on the web, and I think this one will be genuinely interesting to see turned into a marketed feature. The HTML5 method of embedding video looks like this:

<video src='http://example.org/video/foo.mp4'></video>

There’s the URL to your video file, right there in the HTML source, downloaded in raw form. What can Adobe offer publishers? Two ‘features’ of software that run absolutely counter to the principals of the open web: DRM and obfuscation.

That could be interesting. The survival of Adobe Flash Video online will require them to take the closed, anti-content consequence of Flash’s model, and instead embrace it as a feature for media companies that fear distribution of their content.

Really, I think this whole issue is overblown. Maybe it’s all fuelled by scare-mongering from individuals Adobe, maybe it’s over-eager Open Web evangelists eager to see closed and proprietary scraped from the face of the web. In reality, it’s just the pragmatic, ongoing evolution of the web offering useful new functionality.

Social Web FooCamp was a full two weeks ago, and even now I’m not entirely sure the lessons of this meeting have entirely sunk in. Surrounded by some of the smartest people in the industry (and other influential oddballs), FooCamp provided a backdrop to see friends and rivals come together and share.

I was there for my work with microformats, and as someone who periodically pops up to suggest improving the user experience of OAuth.

People

MySpace, Facebook, Yahoo, Google, OAuth, Portable Contacts, Activity Streams, Open Social and OpenID. All under one roof. Everyone quite keen to move in positive directions. An exciting mix.

It was quite something to spend two days in these surroundings, participating in the conversations that determine what happens next. As is my nature though, perhaps the biggest value came through observation and listening. And to cut to the chase, herein lies my principal learning of Foocamp:

The Open Stack needs a Product

Foo had many, many sessions on the Open Stack; OpenID, OAuth, OpenSocial and Portable Contacts. Some of them concerned with user experience, some with data portability and distributed identity, some with the processes of open development itself. Every single one of those sessions at the very least mentioned Facebook. But more often, the sessions were outright dominated by Facebook Connect.

A session on building a start-up on the Open Stack was turned into a discussion about Facebook’s product, and what developers wanted from it.

Note the emphasis on Facebook’s product. The way in which we classify the technology of the open, social web and compare it to Facebook Connect is massively flawed.

Get this clear: Facebook Connect, from inception through API through user experience, is a single, self-contained, beautifully packaged product for developers. And it’s awesome. Facebook has the combination of detailed, well maintained user data, a huge user-base and excellent user interface design for the Connect experience. It ticks every box.

Compare to ‘the Open Stack’. There is no product. These are technologies — wonderful technologies — with which you could build something with the functionality of Facebook Connect. But at time of writing, there is no mature offering. The branded products from Yahoo and Google are not as strong as Facebook; they’re less mature in every way. Problematically, though, the tools have a stronger brand than the implementations.

It’s this that causes the Facebook/Open Web comparison to fall down so quickly. The open technologies are right and true. Using the same open auth and identity protocols is a massive win for developers. But what are you actually implementing?

The open stack itself doesn’t contain any data, nor provide any service. It is just the mechanism to provide those services. You don’t solve anything by ‘integrating OAuth’. OAuth isn’t a service. The publicity has to shift to actual service providers, where the end users are involved. Because really, it’s touching those end users that drives developers, not beautiful snowflakes.

We’re all imagining a world where you can implement OpenID+OAuth+PoCo and seamlessly integrate with Google, Yahoo! and any other social network using the same code. But that doesn’t exist yet. Only the foundations of it exist. And without the data provision from actual products, there’s no implementation to focus the open stack discussion on.

Not broken

Whilst it all sounds a bit bleak, nothing here is broken. Facebook has a massive head-start in the marketplace. Yahoo, Google, MySpace et al are playing catch-up in terms of the APIs and the user experiences of their own sites. Is Yahoo! Updates as rich an experience as Facebook? Not yet, no. There’s work happening everywhere to compete, across all aspects of all services. As such, of course Facebook is the more compelling option this year; it’s obvious that’s the case.

Further, as evidenced by Facebook’s Open Stream API launch last week, their strategy has been formidably well planned. Over the past twelve months they’ve been hit with sticks by openness advocates for being locked away in their walled garden, but their priorities have been elsewhere. They’ve been building a rock solid foundation that, once in place (now), they can start to open up and offer good data from the start. They have the luxury of the market lead, and they can use that to release better, more complete services. That’s their reward for being first, and they’ve earned it.

So, the feeling I come out with is that we should stop thinking about Facebook in the context of open standards (except where they implement them, of course). It’s a broken comparison. It’s hard, because the competitors have everything in the air at once, but it’s down to them over the coming months to turn their adolescent, open-powered APIs into compelling products. The part OAuth plays in this is just to continue becoming as transparent to users as possible.

It’s not the job of OAuth and OpenID as part of this ‘Open Stack’ to take on Facebook in mindshare. The roles of these APIs (PoCo, Open Social and Activity Streams included) is to be expected and taken for granted in any new implementation. These are the bricks on which houses are built. But people don’t buy bricks, and so our eyes need to focus on the products of this work.

The other point to stress here is that whilst the open stack needs stronger implementations, they don’t have to be ‘NotFacebook Connect’. That’s only one use for these standards. The big Open Web offering could be somewhat different. Better, even.

Be excited. The struggle of Open standards vs. Facebook is a fallacy, they’re just efforts a little out of sync. This year, with maturing, big products powered by open technologies, we’ll see things built that extend beyond the achievements of Facebook’s walled garden age. MySpace, Google, Yahoo! et al are all moving together toward something quite special. Developers will be able to take on exciting new, provider agnostic apps with this technology. Just accept that the second generation of competitors need a little time and encouragement to build out.

Oh, and don’t be surprised to see Facebook active in all this, too. In the end, they’ll be as open as anyone else.

Microformats.org is an interesting beast to work for. An informally arranged organisation of volunteers, overseeing a broad array of subject areas and points of interaction. 2008 was my first full year of administrative involvement with the group, for what value of ‘administration’ there really is.

This post is on my personal blog because there is no official line of policy at microformats.org. What I write here is just personal intent and what we achieve in the next twelve months is down to shared passions and collaboration, not the will of one person.

There are shared priorities, of course. The past few months have seen a surge of work on the awkwardly named value excerption ; a mark-up pattern and parsing rule derived from hCard. Honestly, I didn’t know ‘excerption’ was a real word until I started leading the work on this. Thankfully, naming is not as important as a good spec.

Basically, value-excerption in hCard got implemented in parsers globally, so we’re trying spec it more fully to reflect that. It’s a pattern for structuring data values, so in the process we can extend it do something to offer solutions to some long standing accessibility and localisation complaints. The work is sporadic; two weeks here, a month off there. That’s just how it happens. Being absent from Yahoo! this last month has helped me pull it together into a massive public test effort.

My other big task in 2008 was redesigning the microformats wiki, bringing it into line with the look and feel of microformats.org, adapting Dan Cederholm’s still-lovely design. It’s a piece of work I’m proud of, and besides being able to junk vast quantities of MediaWiki’s questionable and bloated default mark-up, it of allowed me to put microformats into the wiki mark-up itself: Each page is now an hAtom entry, with an hCalendar event for the last-modification date of the page.

This Year

I don’t care to dissect last year too heavily. It’s this year I’m excited about. There’s work coming to completion, there’s ongoing work that’s nearly ready to break cover, ongoing infrastructure improvements brewing and a desire to see a big step up in microformats toolkits for developers.

1. First up, I want to see the value-excerption work seen out within the next couple of months. Testing is going really well right now; it’s an effort beyond the scale of anything else we’ve done before. Knowing the accessibility and localisation issues we’re trying to overcome, it’s vital that we get it right. We can’t afford to push something that doesn’t solve the problems and complaints of authors as well as we can. I’m taking suggestions for a beer or red wine magnificent enough to open when we call this one ‘done’.

2. Secondly, we’ve built up a number of issues and enhancement requests against the core microformats — hCard and hCalendar. They’re stable, useful and are helping to change the web, but iterating stably is an important step to take as the community and formats mature. Just as HTML5 is not versioned like a piece of software, there won’t be an ‘hCard 2’. This is the web and we won’t be breaking existing pages or forking our specifications; that’s absurd. We will evolve. I would like a period of active editing and hope to see hCard and hCalendar ’Second Edition’ published this year.

3. Recipe and Audio formats. Two new drafts in 2008. Bearing in mind that many popular and quite stable formats like hReview and hAtom are actually still in draft, that’s a very significant step — it takes a lot of research and brainstorming to put together a good draft spec. These subjects have much stronger, stable momentum than some previous microformat proposals have had, so I’m confident they’ll move smoothly. Structured publishing of music and food is highly Relevant To My Interests. I worked with publishing some of the hAudio draft in my previous music round up. I think it’s getting there.

4. I’ve spend some off-time brainstorming on a new effort myself; ‘embed’. No dedicated wiki page yet as I’m still compiling the initial data to get it rolling. There’s nearly enough to push it though; a few more sites to grab examples from to get people thinking. It’s deriving some concepts from the oEmbed format Pownce supported, allowing sites to describe their ‘embed codes’ for reuse around the web. I want to be able to reuse linked content in an activity stream, and deriving embeds from mark-up rather than writing drivers for every site on the net. It would make reblogging the embedded content more graceful, too. More robust use cases coming soon.

5. Microformats have issues, feature requests, bug reports, tasks to do. At present we track them on the wiki along with the specification documents themselves. Personally I find it a nightmare. Tracking and triaging issues through versioned documents in various structures is harder and less transparent than I’d like, so fixing it would be nice. The wiki update last year has the facility to hook spec ‘issues’ links up to other systems, and I’m spending some time experimenting. Community feedback needed here, plus considerations to be made regarding self-hosting something like Trac or offloading to an external tool. It could happen quite quickly, since I don’t think there are many sane arguments defending the wiki method; it doesn’t scale.

6. Wiki rewrites. I’m good at writing. I’m too verbose for sure, but I communicate well. I’ve taken great pleasure in applying this to more recent microformats output and I like to think I do a pretty good job of improving the experience of interacting with microformats documentation. Many pages on the wiki aren’t as well written. I don’t mean to criticise other authors, I refer more to the way in which over time important pages like the process and how to play page have been edited and added to so many times that at this point, I fear they’ve become impenetrable to a new visitor, and if they can’t follow the rules and I want to see effort go into reworking those pages to be higher quality documents, more approachable and easier to reference when they need to be enforced.

7. Support transformation efforts. In 2008, I’ve noted a couple of repeat proposals and desires for using microformat specifications in other contexts than HTML. Being in HTML is part of what makes something a microformat, so we’ve had instances of proposed forking. Versions of hAudio exist republished for use in RDFa, there’s an entire page on the microformats wiki called jCard — putting hCard into JSON for interchange. Per-specification duplication is, in my view, wrong. Duplicating specifications leads to fragmentation, confusion, incompatibilities. If people have use cases for transforming a microformat into RDF, or JSON, or anything at all, the core spec needs be the same. What we need documented are consistant rules for transforming HTML into any of those other languages. ‘Transforming microformats into JSON’ could be a single wiki reference page for all current and future microformats, explaining how to convert different microformat patterns into JSON. Not a ‘jCard’ and a ‘jCalendar’ and ‘jAtom’, with an ‘rRecipe’ for RDF and xResume for raw XML. Just one set of rules to handle the transformations that are useful. Within that, defining the parsed object structures of the microformats goes most of the way to serialising into another language, and that’s a job for parser authors to settle on the best way to turn microformats into objects consistently.

All of the above is a reasonable ask, I think. It’s ongoing progress in an evolutionary approach in development of standards and infrastructure. My big wish for the year is perhaps a bigger step.

The next level: API Kits

Consider existing services: Google Contacts, Yahoo! Address Book. Standalone data providers, whose APIs offer high level methods to access the contacts held within.

A popular use case for hCard and XFN is contribution to the distributed social ecosystem. Data about people and social relationships is published all across the web, but consuming it is prohibitively hard for most developers.

Whereas someone developing for the YAB or Google data stores can download wrappers around the high-level methods those APIs offer, consuming microformats remains at the parsing level. There’s no Person::getFriends('http://ben-ward.co.uk')-like method returning an array of vcard objects. If we’re serious about evangelising consumption of hcard in social networks. We need high level, task centic toolkits, not just raw parsers.

A higher level means providing solutions to common problems and use-cases, rather than a solution to ‘microformats’. A ‘Distributed Contacts API’ that follows XFN links between hCards, handles crawling pages and/or interaction with the Google Social Graph API. Ultimately, you make one call to a high level function and it just happens. I want to see microformat-based tools that boom!.

I think XFN and hCard offer the two most appealing toolkits: Distributed user profiles (‘Distributed Profile API’) to the profiles information described with hCard, linked with rel='me' and the aforementioned ‘Distributed Contacts API’ for obtaining the profiles of other people you link to as friends.

I’m thinking that methods like these are needed to make it trivial for social applications to start consuming microformats more ambitiously:

Person::getProfile('http://ben-ward.co.uk', callback)

Get all profile info for the person at ben-ward.co.uk, and fire the provided callback function when completed (you need callbacks for all of this since it’s both asynchronous handle and crawling the web is going to take a little time).

Person::getConnections(
    'http://ben-ward.co.uk',
    [ 'friend', 'acquaintance' ],
    callback );

Return the profiles of all the people connected to the person at ben-ward.co.uk connected with XFN ‘friend’ or ‘acquaintance’ relationships.

Methods like these make it simple for developers to start using the huge wealth of published microformatted data to enhance and power their social applications. Right now, getting to those methods is a lot of labour. We need to build it once, and we need to do it in the open. I would love to be in a position this year that we can evangelise microformat consumption with as much strength as we do microformat publishing. OAuth and OpenID has a lot of evangelic traction because libraries exist to implement it in many languages; ‘You should use OAuth, here’s some code you can use!’ is rather more convincing than ‘You should consume microformats! Err…’.

We can’t legitimately push sites to consume hCard with an effort barrier so high. If a stable API kit exists that a developer can just drop in to their codebase — like the wrappers for OAuth — then we can make a strong case to see the open web realise a little more of its potential. I’ve written about the dream of a distributed, microformatted web before at Digital Web. I want to see if become real, rather than just ‘possible’.

You can see this sort of thing in practice already on a tiny but beautiful scale. If you have an OpenID, and an hCard at that same URL, go sign up on User Voice. You’ll auth using OpenID, and when you bounce back to complete your profile, User Voice already knows your name and email address. That information comes not from attribute exchange through OpenID (which the Yahoo OpenID provider doesn’t support), but through reading the hCard from my URL. I wondered for a moment what was going on. And then I just smiled. It’s the future, now. I want to see that user experience available at low cost to every developer.

So, there’s my forward looking. I see the above as pretty concrete ideas. Of course, there’s far too much to lead myself. So, who knows. I hope that others in the community will feel inspired and that we’ll see this kind of work happen. Just as much, I hope to see the visions of others. This community is diverse. I think I’m one of the most passionate about the actual core of the community (perhaps more so than any particular microformat itself), but there wealth of thoughts and ideas amongst all our membership. If you’re one of those, I invite you to write up your vision for the year.

Microformats are a huge deal. Where do we go next? More formats? Reinforcing what we’ve got? Appealing to new groups of publishers and developers that haven’t heard of us yet?

If there’s enough posts along these lines I’ll link them all together on the microformats.org blog.