Sketched out some interface ideas for making a better overall experience for Metakaolin on mobile, right on my tablet instead of my usual pen and paper. Even harder to read my writing (I used my Cosmonaut, but without being able to rest one's palm a stylus isn't much help) but on the other hand it's a bit easier to share the ideas online. Still working out which bits to implement for the first "offline" iteration, but here's a handful of ideas I'm excited to implement at some point:

The first idea comes inspired by a great patch by Brian Mount. I'd like to add a "+" button that simply adds a single point in the center of the map when tapped, but when held lets you just sketch out shapes with your finger! This is a refinement from Brian's demo, since it retains the original editor's modelessness, which is its most important property. The interaction on desktop will likely need a modifier key to retain the intended quasimodal design.

The next thing I'm excited about is showing the current location for reference. The idea being that if you're out on site and want to adjust shapes relative to your device's built-in GPS reading it will be displayed live on the map underneath your vectors.

The rest is pretty basic adjustments to the layout and touch target size fixes. I'm not quite sure how well this design will scale up, off of mobile onto a large desktop screen, but I may take some ideas from the recent Android Action Bar interface element and unoverflow items out of the menu into the bar when there's more real estate. A few other items (i.e. the zoom control) would ideally only show up if/when needed (i.e. single touch device).

One key touch target adjustment is the editing interface itself. Currently the perceived affordances that would lend intuitiveness to the simple but relatively powerful interface are weak on desktop, and almost completely missing on direct touch devices where there is no hover feedback. I think by enlarging the width of connections in a bit of a creative way, I'll be able to tackle two problems simultaneously: making the lines easier to grab and refine, and making that interaction easier to discover in the first place.

The trick here will be drawing those "bumps" programmatically, but I think it will be worth the extra coding effort. The node side of things gets a little TLC too, better showing the temporarily sticky add vs. normal move state. After practicing with the large grab handles to sketch more real shapes on the map (instead of cartoon ships and trucks!) it's also clear they should be made as small as still practical and perhaps a bit less opaque so they don't cover the basemap as much. While I'm implementing a less "lines and circles" barebones display it'll be a good idea to add a soft contrasting halo around the shapes as well. This would serve both to increase the touch hit area and to make sure the drawing stands out above any basemap terrain/background color.

I'm not terribly happy with the native-app-mimicky appearance that some elements of the overall design seem to imply, as I believe the web is (or at least should be) its own platform. Even as it goes mobile and offline, I don't want Metakaolin to become a cross-platform app — it should be a web app. What that looks like and what that means, especially considering that this is manipulation software for which no browser provides any standard/native controls, is another topic that I still don't claim to be halfway qualified to write about yet. I hope, though, that the fruits of this concern can remain apparent as Metakaolin — and Shutterstem and others — continue to develop.

I started building Argyle Tiles to provide a beautiful and global satellite/aerial imagery dataset, with as few license restrictions as possible, because in a world where generating a custom street map has become almost trivial, I felt this complimentary service was still lacking. Seemed like it was high time someone did it, and tried to do it well.

Last week, MapBox released a gorgeously processed imagery layer as the newest part of their service offerings — they've gathered up all the great public domain data that was on my list and delivered it already. And they're not stopping there. I've long been a fan of their work (the open source tools MapBox has shared are a big reason OpenStreetMap data is now so easy to display), and I'm confident they will be able to deliver on their announced plans for MapBox Satellite.

In light of this, I'm scaling back plans for Argyle Tiles as a business.

I had already been struggling with how to deal with the encouragement I'd received: everyone was eager to see the product done. As in, "Let us know when it's done!" At the rate I was able to personally invest in the project, it would have been many more months before just a handful of major US cities were deployed, and the estimated cost per interested customer would still have been discouragingly high. Then how far out dreams of going beyond the available public domain data would still be! I decided to press on, though admittedly not in a particularly diligent or focused way; now I'm glad the burden is no longer on me. Between MapBox Satellite (beautiful and affordably priced) and MapQuest Open Aerial tiles (still available without charge), I no longer see much of a need for my independent offering.

I don't intend to shut down the existing URLs anytime soon, and may continue to dabble with the many interesting challenges of hosting terabytes of images and/or building a sustainable business. Most likely, I'll move the data out of expensive cloud storage to somewhere I can more cheaply (albeit less reliably) play with a much larger set. I'd also like to contribute the bits of tiling code and some of the (still-in-progress) parallel processing infrastructure to OpenAerialMap, which IMO has languished far too long and might benefit from a bit more of a "product"-like vision. I seem to remain all too adept at non-profit products, so perhaps pure open source projects are a better fit for my ideas anyway.

(Always happy for more consulting and freelance development leads, by the way. I love tackling hard problems, like designing custom maps or architecting CouchDB apps, working for honest people — like the continuing set of new clients I was blessed with this past year!)

Since putting my Printrbot to work in September, I've printed many things:

• Duplo adapters
• Kisbee case
• RasPi cases
• new filament feed gears
• 45 record holder
• rocket cookie cutter
• Printrbot marker mount
• Extruder fan mount
• "gridded globe"
• various calibration pieces
• and…
• more than a few messy nests when things go wrong (fiddlesticks to Betsy!)

All of these were from files others had made and posted online. Transmitting just the bits to wherever the atoms are needed is incredibly nifty, and it's neat to even see hardware companies get involved with its potential.

But it was really rewarding to finally sit down last week, and work at some 3D modeling software long enough, to print my own design! I used SketchUp to draw out a simple but effective version of a microwave turntable coupler that was missing from Room to Think's microwave:

It took a bit of iteration, especially with my calipers left at home. Since I couldn't figure out how to adjust things like a circle radius that won't just push/pull I actually started from scratch each time, but it was good practice and it's reasonably fast to draw out new parts.

(It certainly must be rapid prototyping when it is easier to just try a couple prints than get decent measurements!)

This type of thing might be a better fit with OpenSCAD for easier adjustment, but the SketchUp files and an STL export are shared on Thingiverse in case anyone else ever needs one close to this size/shape — it's a lot cheaper to print a second copy, once the unpaid CAD work is done!

I take a long-term view of 3D printing.

Not the stupid journalist swoon line of Everyone Will Print Everything Soon. Everyone needs to print their own iPods in the future just about as badly as everyone needs to print their own grainy ABS miniatures in the present. I don't see a demand for it, I don't see a benefit, and I don't see it happening.

So I should say: I take a long-term view of owning a 3D printer.

Like a welder or a sewing machine, there's an enjoyment in keeping crafts alive. There is an eventual return on investment in the equipment itself as well — perhaps over more than one generation. And the mere fact that plastic printers, CNC mills and laser cutters are now being designed with affordability and openness as the first motivation is awesome. I think this means a lot of good in education and economic development (both in overbuilt or underbuilt economies).

It's been interesting to see what people are sharing and printing on Thingiverse. A majority of "things" currently available there for 3D printing are either: limitless small printer kit modifications such that one wonders if the goal of assembling a 3D printer is to spend subsequent weekends assembling it better, or: dis-glorified Happy Meal® toys. Some of the models are terribly cool — who doesn't want to watch a scale B-17 bomber or a miniature London Bridge materialize hypnotically before their very own eyes! — but you know those machines at the zoo where you could put in a bunch of quarters and go home with a hollow elephant, freshly molded from pink plastic?

Gradually, the open source three-dimensional printing community is accreting a collection of replacement pieces, and of speciality parts, and of customizable components with applications beyond printing for its own sake or that of souvenirs. Artists are finding their way within the new medium, too, working wisely within its limitations to create things of real aesthetic value.

It's humbling to be a tiny part of this, to experience its realities firsthand at some level, and to dream about how (perhaps) to make it matter more.

In the meantime…it's fun. And that matters too.

So you're using CouchDB because it has a great RESTful interface for managing data. PUT a JSON document in with various options, GET it back later through several means. Did you know that how you DELETE can also affect how your document is persisted?

Let me to explain.

Door number one: DELETE

You PUT a document {"_id":"mydoc", "some_data":42} into your database. You fetch this document directly via GET /whatever_db/mydoc, and the simplest way to "get rid of it" is to DELETE /whatever_db/mydoc. That's a bit oversimplified because you do also have to include the MVCC revision token, but modulo that, it's pretty much what you'd expect from a REST API.

Door number two: _deleted

The other way is to make a document stop showing up is to PUT/POST it with a special field: {"_id":"mydoc", "some_data":42, "_deleted":true}

Door number three: don't forget this

The third way is usually the wrong way, and it's not really "deletion" in the normal sense. You can POST document info to a database's _purge API to erase CouchDB's memory of it. The data is still on disk until after database/view compaction and similar disk storage caveats have been taken care of, but the data will cease to exist as far as the API is concerned.

Wait…deleted data doesn't normally cease to exist? To delete a document, its wrong for CouchDB to actually remove it?!

Right. The CouchDB wiki explains it this way:

Deleted documents remain in the database forever, even after compaction, to allow eventual consistency when replicating. If you delete using the DELETE method above, only the _id, _rev and a deleted flag are preserved. If you deleted a document by adding "_deleted":true then all the fields of the document are preserved. This is to allow, for example, recording the time you deleted a document, or the reason you deleted it.

Syncing _changes is foundational to CouchDB's data model; not forgetting deleted documents lets masterless replication bring each instance into a shared state.

Which one should you use?

The choice depends (mostly) on how you're syncing between databases:

• With filtered replication, you might want to add _deleted:true alongside the original document data
• For normal/plain/unfiltered replication, you can simply DELETE
• If you are NOT replicating, _purge has its uses

Simply DELETEing a document could break filtered replication. If a filter function only makes changes visible based on, say, an application-specific "type" or "user" field, these fields will not be present in the final {"id":"mydoc","_deleted":true} stub left behind by a simple DELETE. Consider this filter function, equivalent to the one in the filter function guide:

function(doc, req) {
  if (doc.name && doc.name == req.userCtx.name) {
    return true;
  } else {
    return false;
  }
}

This filter only exposes revisions if there is a "name" field and it matches the session's user information. Revisions resulting from a DELETE request will not have any "name" field. That change won't get passed along — so the document will be left in the target database as-is! In order to propagate deletes, either the document's other fields should be retained in its _deleted version (by using PUT/POST instead of DELETE) or the filter function would need to return true after checking if (doc._deleted), before assuming any other fields.

Consistency

Even if you're using filtered replication, leaving full documents of data which is no longer needed might be undesirable. Remember that the final form of a document will eventually propagate to all databases. Especially if your documents are large or the frequency of deletions is high, there's no sense wasting bandwidth and disk space just to work around a naïve filter function.

Note that simply propagating all deletions to avoid the filtering issue has its own drawbacks, though. If you're using filtered replication because the target has limited storage space, or to keep private data private, copying the last version of every deleted document to every replica is not a good solution. At best it would be a waste of resources, at worst it could leak sensitive data — especially if some parts of your app are simply flagging original contents as deleted, while some of your filters are assuming that any delete is safe to propagate!

A hybrid solution might be appropriate: if you know which fields are relied on, across all of your replication filters, you could store those in the final revision while omitting the others. This enables filter functions to remain picky about what they pass, while increasing space savings after compaction and slightly mitigating the risk of an inadvertently propagated delete.

When you're consistently aware of the implications, any method can be used to control the final state of a document — just make sure its last words are the most appropriate epitaph.