Ben Michael Ward is a Web Developer in San Francisco.

This is his website. View the homepage or archives. You can also follow him on Twitter.

Browsing older entries. Show the whole archive.

Designing for Location: Privacy, trust, frequency, accuracy? Oh my!

One reason I signed up for Project 52 was to complete and publish content I had drafted last year. This article is derived from a draft I started last summer, and has been broken up into three parts.


Designing for Location: You are here. Ish.

‘Old Globe’ by Kenneth Lu

This is a write up of my talk ‘Designing for Location’, delivered at Chromatic last year. The slides (pdf) and original notes are also available, but this series of posts hopefully serves to cover everything I said without the context of seeing me speak.

Who am I to talk about location? Well, let’s be clear: I am not as qualified as many others. In June of 2008 I joined the Fire Eagle team at Yahoo! Brickhouse. In that time I learned a great deal from supremely talented co-workers, who worked out the detail of the Fire Eagle implementation. I was part of the team that launched Friends on Fire —a social location application—in December 2008. After that, Yahoo shuffled around and I moved to the Yahoo Developer Network to do other things. I returned to the Fire Eagle team to develop the second Friends on Fire release at the start of 2009.

That is all to say, I have experience, but I’m indebted to the Brickhouse environment for teaching me so much, so quickly (in particular, Tom Coates and Sam Tripodi). Brickhouse contained the most talented, inspiring people I’ve ever had the pleasure to work with.

I’m writing this up so thoroughly not because I’m an authority on Location Services, but because there’s still a lot in my head to get out. I got given a chance to talk about it, and though I stopped working on Location Services full time, the field still immature and I figure that perhaps documenting this set of thoughts is valuable to someone.

I’m going to publish in three parts. First, the introduction and state of obtaining location, followed by the state of location display, and finally an overall “Using Location”. This is part one.

“Location is complex.”

A simple mantra that accompanied the launch and initial explanations of Fire Eagle. Introducing location to the web is a complex problem full of edge cases. The common problem you’re trying to solve is very simple: You want to attach a location to another piece of data; add an extra dimension to your application, and do something exciting and insightful for your users.

But, actually getting that data, in a useful way, is not so simple. Technical and social obstacles exist that make location harder at the moment.

Do you speak Geo?

Does your application speak geo? What inputs does it understand? There are human forms of location (city names, countries, names of places) and there are data forms of location (co-ordinates, database IDs). Which ones can your service handle?

Not all your users will have a GPS in their pocket. How accurately is their location recorded? With so many different methods of obtaining location, accuracy varies, and so can usefulness.

Your application is going to be flooded with locations of both precise accuracy, and approximate values. Precision from buildings, streets, to locations the size of entire cities. Can your application perform something useful just knowing the city a user is in?

Did the user intend to explicitly ‘check in’, or are they just passing through? Are they in motion? What happens if your user provides no location?

Your depth of understanding location formats affects your interface. If you can’t parse all forms of postal addresses, how are you going to communicate that limitation to users? Chances are the quality of that parsing will vary from country to country too, since international address formats are varied. Your interface needs to be robust enough to communicate this variance.

User location is not just about where, but also when. What’s the context of your location consumption? Is your application only relevant when provided with fresh data? What happens if you get a location update that’s a day old? A week old? Preemptively from the future? You’ll find a lot of user’s won’t update their location very often. If you discard locations too aggressively, your dataset will be reduced too far, and only a small slice of you users will see any benefit of location in your application.

And, of course, you have to persuade users to actually share with you in the first place.

This huge variance affects all aspects of your application. How its represented in the page, how you communicate with your users, how you perform data analysis.

Grey Areas. Edge Cases. Multiple facets. This is location on the web.

Original Location UI

Location data has been used on the internet for much longer than the new trend in social-enabled, GPS-enhanced, API-powered services.

Often, websites ask about city and country information, sometimes postal codes, to provide localized content.

Generally, these are commerce scenarios: Localized product listings, directions to local support offerings, addresses for shipping and tax calculations. The functionality depends only on broad locality, and is only relevant to the service for the duration of the user’s session. As such, low-fidelity input from users has worked quite well.

The second major use is in shared, personal profiles. Long before we called it social networking, bulletin boards had simple user profile pages and inevitably asked for a ‘hometown’.

This labeling is somewhat important. Your ‘hometown’ is a single, static piece of data, often historical. Systems that instead asked for your ‘city’ exposed a problem: Locality for persistent profile information goes stale. When people move from place to place they don’t update their user profiles (understandable, given how many separate profiles they have).

The result is that you can only reliably store manual input for data you don’t expect to change. This doesn’t stop sites collecting ‘city’ anyway, but does mean that a large number of sites hold inaccurate information.

This level of location interaction is generally focused only on the city and country level of detail, which helps to simplify the input.

At the simplest, input for persistent locations consists of a text field, and is generally not validated. The result is that the data tends to be illustrative in a profile, rather than a reliable pivotal piece of data. People input Manchester, Manchester, UK and Manchester, United Kingdom all to refer to the same place. This inconsistency, multiplied across all possible locations means that this field is hard to work with as query data. Flickr did something very interesting, where in addition to regular free-text inputs, they also requested an Airport code (e.g. SFO or LHR). By asking for an approximate but reliable and unique location identifier, they had the option of using it in data processing without disambiguation. Also, it’s a vague and quirky enough piece of data that users won’t feel violated in sharing it.

The other forms of obtaining a location are crude: Clicking a map (or series of maps at increasing precision), or picking a location from a drop-down menu. Maps can work quite well, but are laborious, whereas picking your country from a drop-down list is rightfully regarded as one of the worst pieces of user interface ever conceived. The problem being that applications need precise input.

Lists fail most spectacularly when handling synonyms. For the purposes of almost all web applications, the United Kingdom, Great Britain, and England refer (inaccurately) to the same country (Gary Gale can clarify this, if you like.) ‘United Kingdom’ is most common, but some web applications use other variants. In a list, you have no way of knowing which name the application expects until you start scrolling.

Modern Location UI

With the hardware to identify location becoming commodity, and social and informational applications becoming more sophisticated, location interface has too.

Through mobile phones, users now have access to raw data about their location, and have been given software to share that location with applications. Furthermore, content on the web has been located, with geotagging of photographic, video and text content far more widespread.

Location gathering is no-longer just about city or country level, nor is it just about one-time queries whilst the user is active. Apps can work with location even when the user is away.

This generation of web applications uses persistent location, shares it with people and services, and attaches it to all sorts of content. It’s used to filter content, and enhance personal analytics. The means of collecting that location are now broad:

GPS hardware is contained in all new smart-phones. The iPhone, Palm Pre, BlackBerry, Androids and so forth all have location gathering hardware and expose it through simple APIs.

When GPS is unavailable, companies like Skyhook and Navizon map the wireless networks in urban areas. The signal strength of networks visible to your computer or mobile phone are processed to compute a location with remarkable accuracy. Clarke for Mac OSX and Fire Eagle, Firefox, and the CoreLocation Services API on iPhone and Mac OSX Snow Leopard all make use of Skyhook’s service.

Location can also be obtained from databases of IP addresses, again with surprisingly good accuracy—postcode level or better—within urban areas.

Manual input has become more sophisticated; Google Maps focuses on auto-completion and linking string queries with search for street addresses, venue and business names.

By contrast to the breadth of location sources, Four Square has a specific usage, and so only works with venue names; no other kinds of location input is supported.

Co-ordinates are rarely used in a visible way, since alone they’re incomprehensible to humans. However, they represent precise location points, so where interfaces such as Flickr’s Organizer application uses drag and drop to precisely place content on a map, co-ordinates are the data created.

All of these can provide quite precise location points. Other applications, especially queries, are more about specifying areas.

Yahoo! Local includes a beautiful piece of user interface for editing a location range, illustrating the centre-point of a search and highlight circle for the search range. The radius slider can be dragged to expand of refine the area. It’s simple, illustrative and directly manipulatable.

The next article will document the different methods of displaying location back to users.

Tagged

Posted in

Unsubscribe/Unarchive

The evolution in the use of email is quite interesting. Choices we make to balance our communicative overhead, choices others make in the kinds of information they prefer to distribute via email over other mediums, how we react to those changes and learn from reactions. Email is a valuable case study of internet behaviour as it’s been with us since the start, and it’s never going to go away either. No matter how strongly the bleeding edges of the technology industry push different forms of communication; wikis, Waves, activity streams and so forth, people will always have a need for medium to long form, considered, chronological communication (and even if it’s not the most efficient, they’ll do it anyway.)

Every change we make to our email behaviour, whether it’s organisation, tools or simply trying to email less, we are trying to find an effective balance. I’ve just come out the other side of one change, and am spending a few weeks making a strong, conscious effort in response.

At this point, my email inbox tends to receive the following: Notifications (from services), content summaries, status changes, reminders; pushed information, newsletters, aggregate news; actual communication, enquiries, conversations, planning and social synchronisation.

My email clients of choice is Mail on Mac OSX, and Mail on my iPhone. Previously I used Gmail from Google, but I quit the service because I found the browser-based user interface clumsy, and the application as a whole aesthetically ugly. Mac OSX’s user interface is elegant, the display of email good for reading, and the desktop client remains robust. My email is on an IMAP server (because that’s how email should be accessed), and I can fall back to my service provider—Fastmail —for a clean and functional web interface if I’m ever away from my main machine. I have also developed a certain wariness of storing too much of my data with Google for free, and prefer to pay for the excellent service I now get.

Gripes with Gmail as an application remain, but Gmail did massively inform my email behaviour. Most importantly, archiving rather than deletion. I carried over that practice to my new host, and now have some four years worth of email archived on my machine, and backed up around the world. I can, if needed, find pretty much any piece of mail given the right parameters. Not that I will ever need to see most of that mail again. But archiving is easy for a while, and my compulsive nature makes thorough archiving desirable.

I organise my mailboxes annually. Each year I archive everything from the previous year into an annual parent mailbox, effectively removing all the top-level mail folders from my account hierarchy. I start each year with a bare ‘Inbox’, ‘Drafts’, ‘Sent’, ‘Archive’ folder set, and then the categorical mailboxes get recreated when the first relevant piece of mail comes in. Some get recreated within a day, others never come back. For what it’s worth, I’ve always found a simple tree structure to be entirely sufficient for organising email; I never proved multi-dimensional tagging to actually be useful in Gmail.

Although my archive routine is simple, it is slowing me down. Huge amount of archived data, most of it useless. So I have all of my domain renewal notifications? Why? To keep a record of when my registrars have been in contact, so that I know exactly when I was reminded of particular actions. That is an example of me choosing the simplicity of the archive action instead of making a good-value decision about what is worth archiving. I’ve now accrued too much information to effectively dig through.

So, my first email goal from now on is to archive less. To trash messages that are of low value. Being an archivist, completist and pedant is an unhelpful email trait.

Years of signing up for services means that I get a regular stream of automated or blind-mailed content from services. This email I do delete. But because the effort of performing a delete action is so low I have tolerated an increasing quantity of mail for years. The processing cost is low, but occurs frequently and at irregular intervals. The problem is exacerbated in a mobile environment, where a ‘new message’ notification triggers a significant interruption. That interruption would be appropriate for valuable, personal communication.

As well as notifications, I receive a small amount of actual content by email as well; most notably the daily Snowmail email from Channel 4 News in the UK. Unfortunately, that content is only distributed by email, and is not published as a blog. This is content I read, of value, but is not content that should be pushed to me, it’s content I should pull up at my convenience.

My second email goal is to reduce the amount of email I receive in my inbox to be 95% personal communication. This has meant that every day for the past two weeks, I’ve actually taken the extra time to find the unsubscribe link in the footer, or edit the communication preferences of whichever service is sending notifications, and permanently disable it. I suspect it will take months to clear all of them, since some services are very infrequent in their mailings, but already I’m finding that if my iPhone vibrates, then the message I’ve received is now most often of actual interest.

Newsletters require more work. Email is the wrong delivery mechanism; they should not be push content in the first place. So I’m going to experiment with subscribing a blog-by-email address to the mailing list in question, so I can convert the content into an RSS feed and have it consumed by Fever instead.

There is value in email, and that value is communication. Over years, service providers and publishers have taken advantage of email’s ubiquity to adapt it for push, notification and automation. Better solutions to those use cases are emerging (or already exist), so this is the time to reclaim the inbox, reduce your email throughput back to what the medium is really good for. I’ve already seen that a little bit of persistent effort can greatly increase the quality of email as a tool.

Tagged

Posted in

Re: The End of Time

Back over Christmas, there was an infuriating Doctor Who finale. James Aylett wrote a dissection of Russell T Davies’ ‘The End of Time’, and since he’s also a writer, it’s a nice insight. Seeing as Russell is moving on, it seems like a fair moment to make a big indulgence in it all. I like Doctor Who, I really do. But, RTD has missed a great many great plotting and story opportunities with his awful writing over these five years. The finale was a bombastic clusterfuck; something that deep down, we all knew would happen the moment he announced his retirement. Items of canon and historical note were thrown in, mutilated and cast aside as quick as they arrived.

Anyway. I managed to contain my nerdish need to rant about it to just one long comment on James’ blog. (Well… also Twitter.) You should read it and follow up there, if you’re so inclined (there’s a good discussion between James and Tom Coates to read, too.)

My comment is also copied for posterity below:

This post continues on another page.

Tagged

Posted in

Cross-Game, International Trading in Settlers of Catan

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.

Tagged

Posted in

2010; 52

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.

Tagged

Posted in