speaking for the Lorax

a few weeks ago i needed dish soap. i was out, totally out, had balanced the bottle at improbable angles until nothing but funny noises and the occasional bubble would come out. no big deal, i was due to make a grocery run anyway.

i've used Seventh Generation brand dish soap for some time now. i don't primarily buy it for the "hoorah let's save the earth like the Native Americans would have done" business; i like how it smells, and it gets my dishes clean, and it doesn't destroy my hands even when i need to clean every pot and pan in the kitchen. all of these are good things, including the environmentalism, but i stopped in my tracks when i reached towards the grocery store shelf and saw this:

i picked it up. i put it down. i paced around the aisle. i calculated how many more dishes i could do with what i had at home. (zero.) i contemplated walking all the way to the other end of the store and buying the radioactive blue stuff that kills bacteria, skin cells, and anything else it touches.

in the end, i caved and bought the Lemongrass & Clementine Zest Corporate Shill. i wasn't going to write about this episode as it stood by itself, especially since the internet already has plenty of indignation over corporate tie-ins with the new Lorax film.

fast forward a week or so, and i was in Austin for the North American Summer School on Language, Logic, and Information. on my last morning, i got in a final bit of tourism, including going to the LBJ Presidential Library, which is right on campus at the University of Texas.

i didn't know that the museum was under renovation, and that only a handful of the exhibits were open. they still had a mock-up of LBJ's Oval Office, but 90% of the rest was devoted to an exhibit on the First Lady. the remainder was one little case of miscellany, a hodgepodge of gifts from various heads of states and dignitaries: swords, jewelry, ancient artifacts, cowboy boots, and — at the very end, almost an afterthought — this.

the entire original art of The Lorax is in the library's collection, but just this one spread was on display. the coloring is done in crayon, as if by a child instead of for a child, and the words are held on with masking tape. how humble, i thought, unassuming artwork for an iconic book, donated to a public collection. the antithesis of selling out an idealist character to the highest bidder.

i had the impression that this art had been lovingly and spontaneously donated by Theodor Geisel. i discovered later that the truth was rather different. i suppose "spontaneous" still holds, but apparently the donation was an extreme case of presupposition accommodation:

I was at a dinner for Democrats some years ago, and I sat next to Liz Carpenter, who was LBJ’s press secretary. Since Lady Bird was so interested in beautification, it seemed that environmental protection was a safe topic, so I mentioned that I had written a book on the subject. Liz seemed interested, but soon after left the room. When she reappeared she called me to the phone and said, “The President wants to talk to you.” I said “Hello,” and there was LBJ thanking me for donating the drawings for The Lorax to his library in Austin, Texas.
source: LBJ Library

so the fate of this artwork was made by executive decision. but the Chief Executive acted in the spirit of respect, and preservation. it's not so clear that any preserving force stands watch over the Seuss canon today. what's to be done? near-indefinite copyright terms don't seem to do a lot; as intellectual property, beloved characters can be passed around, traded, sold, and generally mismanaged for decades after the author, long passed away, can no longer say anything. it's hard to say whether limiting that would help, but perhaps there would be a more level playing field; the Once-ler couldn't buy an exclusive product placement in the story where he's the villain.

i don't have a perfect solution, but one thing is clear: The Lorax is an orphan with his creator gone. he's just crayon on paper, and taped-on, typewritten verse. someone needs to speak for him, and his kind, for like the trees, they too have no tongues, and everyone from movie studios to soap makers wants to put words in their mouths.

packing pixels for a new iPhone

i've never really been one to add grist to the rumormill, but i've been intrigued by the recent speculation over what the dimensions of the next generation iPhone screen will be, both in pixels and inches. i had an idea about this on my own last week, even before i knew that this was a hot topic. the coverage of the topic on Hypercritical e64 introduced me to the current theories. if you want to be totally up to date, go read all the posts in that episode's show notes; if not, i'll summarize briefly along the way. there are two prevailing theories, but i'd like to add a third.

theory #1: the stretched "16:9" iPhone

this is the theory posted on The Verge and "corroborated" by John Gruber. the notion is to keep the horizontal resolution and size of the screen fixed at 640px and 1.94 inches, but to streeeeetch the vertical resolution. the original theory was to take it to 1152 px to achieve the magic 4 inch mark, leaving the screen with a somewhat awkward 9:5 ratio. there are lots of aspect ratios on the Wikipedia uber-doom-chart of screen sizes (including 17:9!), but 9:5 isn't one of them.

when The Russians Used a Pencil picked up this idea and ran with it, they just assumed that the stretched iPhone would have a 16:9 native ratio (instead of the somewhat ridiculous 7px pillarbars that would result in showing 16:9 content on a 9:5 version). one problem: 640 isn't divisible by 9. that leaves a bit of a quandary. either Apple goes into totally new aspect ratio territory with a stretched screen, or has to alter both dimensions to get true 16:9.

theory #2: just blow it up

the other prevailing theory is to leave the pixel resolution of the screen untouched, but just make it bigger, and therefore less dense. people are quick to note that Apple left itself fudge factor to take the resolution down to 300 ppi without having to alter its marketing definition of "Retina Display". (given the "hey, remember trig from high school?" earnest excuses for the 3rd-gen iPad's pixel density, i don't think this is something Apple wants to compromise on, either.) doing a strict scale to 300 ppi would push the diagonal measurement to ~3.80 inches. not bad, but not exciting either.

theory #3: emulate the iPhone's big brother

here's my idea which, as far as i know, hasn't been entered into this discussion. (if i've just missed it, i don't mean to step on anyone's toes. and please do send me any links you find.) the foundation of the stretch theory is that it's easy to keep manufacturing screens at the same ppi — apparently it can be done on the existing equipment. if that's the case, why cut panels that are wacky new aspect ratios? how about a 1024 x 768 (a.k.a. XGA) panel?

does that number sound familiar? of course, it's the pixel dimensions of the original iPad. but what would turning the iPhone into a mini-iPad achieve? first of all, the physical dimensions. preserving the 326 ppi density, the screen would have a diagonal measuring ~3.93 inches, which does better than theory #2. in terms of pixel dimensions, it would be a gain of just over 172K pixels, or an increase of 28% in screen real estate. that's a pretty good boost, especially compared to the 20% uni-directional boost of theory #1.

the question is whether taking the cue for the next iPhone screen from the iPad gains anything other than pixels. i have no fancy mockups of case designs or interfaces (as demonstrated by the above size comparison graphic), but i think it's fairly safe to say that the iPad has proven that running iOS on a 4:3 ratio screen has been a success. a major qualm about a 16:9 screen is whether it would be possible to do anything but watch video in landscape mode, short of having to design one-line text input interfaces. but i do see benefits beyond just having a squatter shape.

  • developing from iPad ⟶ iPhone some developers would be able to take existing iPad art assets and drop them directly onto the iPhone. this is obviously a no-go for applications with complex interfaces designed to take advantage of the iPad's physical size — slowly do the five-finger pinch gesture on TweetBot for the iPad and watch how as it scales down, the tweets are perfectly legible but the buttons become an un-tappable size. however, some have surmised that games would have the most art to redo to accomodate a naive aspect ratio, but most games already have 4:3 assets and code for iPad.
  • developing from iPhone ⟶ iPad iPhone developers reluctant to put a lot of time into a dedicated iPad version (either in the form of a separate app or separate code in a universal app) are second-class citizens. the 2x mode of scaling iPhone apps looked bad enough on the first two generations of iPads, and it looks comical on the 3rd generation. but, as many who got launch-day 3rd generation iPads noticed, non-retina iPad apps looked pretty damn good with pixel-doubling and native text scaling. blurring the line between iPhone and iPad apps has its pros and cons, as does forcing active developers to have a 4:3 interface and assets. however, it may push iPhone users ambivalent about buying an iPad over the line if they know that all of their purchased apps will look good on their new device. Apple is trying to drive hardware sales, and with iPhones saturating the market as much as they have, this is the currently operational halo effect.
  • unification, not fragmentation it seems more than fair to presume that Apple doesn't want to introduce another aspect ratio to the iOS universe. taking a cue from the iPad for a new iPhone would accomplish that, and could even reduce the total number of aspect ratios to just one within a couple hardware generations. the question then is more a matter of taste: is 4:3 really the aspect ratio of the future, and not an aspect ratio of the past? for devices that primarily operate in portrait orientation, i see no reason why it couldn't be.

those are my thoughts. it seems just crazy enough that Apple would consider it. i suppose in a couple months i'll know how wrong i was.

we've already lost the filesystem

or: How I Haven't Learned to Stop Worrying and Love the Cloud.

there's a persistent background of fear in the Apple community. even when rationality ought to prevail (as it most certainly did in John Gruber's written and spoken coverage of the Mountain Lion announcement), paranoia rushes in to fill the void. "it's only a matter of time", the devil perched on your shoulder says, "before they take away the filesystem. for good. everywhere."

an aside for all those about to go Van Hœt on this: what we're talking about is the filesystem metaphor, i.e. that the stuff on your computer is stored in files which get organized into folders. this is separate from the filesystem qua filesystem, the method by which a computer actually stores, organizes, and finds data on disk. Hypercritical e56 is a nicely comprehensive review of these, and from 1:42:00 to the end deals with the actuality vs. metaphor distinction. to disambiguate, John Siracusa uses the term "file hierarchy", which i think is certainly apt, and points out that one of the major reasons that its demise might be imminent and even welcome is the fact that most people simply cannot grok it. this is certainly true. ten years on, my parents still haven't quite grasped where /Applications is in OS X. they had no trouble with the file hierarchy in Classic Mac OS — just bung stuff wherever you want it, as long as you don't touch the System Folder. so the question is, if the file hierarchy ceases to exist, will they lose anything? i think the answer is yes, but perhaps less than most people think, and for a different reason than most people think: namely, that we've already lost a good bit of the meaningful hierarchy.

the case of the missing calendars

last fall, like many people, i updated to iOS 5. also, i wasn't an early adopter of Lion — i waited until 10.7.2 came out and then did one epic afternoon of software updates. i mostly did this to try to ensure a smooth transition to iCloud. despite having to actually set up iCloud from the bleachers at a hockey game because i didn't believe that the full wipe and restore of my phone would take as long as iTunes warned me it would, everything seemed to go perfectly smoothly. until a couple months later.

one day i was idly playing around with the ⌘4 / heat map / year view in iCal and noticed that 2009 and 2008 looked a little … sparse. (my iCal universe begins on April 6, 2008, due to massive a hard drive catastrophe that happened then. back up, kids!) after digging a little deeper, i noticed that some calendars, despite professing that they were merrily synced to the cloud, had zero events in them. oof. for whatever reason, iCloud had been benevolent and only disappeared the contents of calendars that were no longer in active use; otherwise it would have been a code red disaster. as it was, it was an inconvenience that left a hole in my personal digital history, which i now try to preserve a little better than i did in March 2008. i filed it away as a problem to be dealt with later. perhaps i did that because i knew it would be no simple task to get them back.

backups are only as good as the files they contain

what i was up against was another concern of power users everywhere: (1) the cloud is canon, (2) the cloud is now, (3) the cloud is only now. in this case, iCloud was very sure that those calendars weren't supposed to have any events. that's how things are supposed to be now, because those are the instructions the cloud received, be it in error or good faith. and iCloud has no idea if that's how things used to be, or whether those calendars ever used to have any events in them. the fact that i had a human, fleshy, grey matter memory that i definitely put things there and used to be able to look at them was really of no concern to the cloud. as i learned in the 2008 hard drive crash, wistful memories don't bring data back from the dead, they just make you feel like crap.

but all was not lost. those now-cloudy calendars were once local calendars, back when the canonical version lived inside my apartment, instead of in North Carolina. and i have Time Machine backups, so they must be preserved. it's just a matter of … finding them.

sidebar: i have considered myself a power user for a long, long time — my entire adult life, certainly. restoring a few files from a backup should be trivial, not throw me into a rage. but when there are as many layers of pain as there were between me and those files, there was no other possible reaction. bear in mind that this task would be impossible for an average user, and as i'll point out along the way, near impossible for a third party trying to help an average user. for a power user, it was merely maddeningly difficult.

ok, let's do this! first, where do those calendars live? must be somewhere in ~/Library …which is of course now hidden in Lion. no problem, ⌘⇧G will get me there in no time. from there it'll just be a quick hop into the Time Machine, rescue the appropriate calendars, and— oh, hell. ~/Library/Calendars looks like this:



we have just exited the universe of the filesystem metaphor. there is next to nothing here that is human-readable. perhaps i was supremely naïve to believe that my Typology calendar would be named something sensible like Typology.ics, or at least be a folder called Typology.calendar. instead i was staring down 32-character hex hashes. (note the Finder's hilariously awful attempt to sort these by name. since it tries to use logical base-10 numerical sorting, clearly a file that starts with 127 should come before one that starts 0259!)

i was not deterred. i went digging and found that each folder had an Events subfolder, which contained each event in its own self-contained .ics file. an empty Events folder indicated that i'd found one of my raptured calendars. there was also an Info.plist file. i started cracking these open, figuring that they had to include important metadata like, you know, the name of the bloody calendar. rinse and repeat for my 33 calendars. some time and scratch paper later, i'd compiled a list of dead calendars matched with the first four digits of their hash. now, certainly, i could step into the Time Machine.

since i access my Time Capsule over wifi, this is excruciating in and of itself. two minutes "Connecting to backup volume …". another three minutes remembering that any previous states of this folder exist, during which i can't do anything else with my Mac. (a necessary design choice when Time Machine was first introduced. but please, Apple, make this thing behave like a proper full-screen app in Lion.) all the while i'm not being soothed by my slow drift through some sort of nebula or star cluster, and the all-important navigation bar on the right side of the screen has rendered improperly on my external display. this is well past the point of giving up for most people.

stepping backward through backups proves incredibly slow and massively unhelpful — my calendars are modified between nearly every backup. so i get to play guess and check with when it was that i made the switch to iCloud. i finally find it! here we go, time to bring back those calendars when i realize, son of a bitch all the local calendar hashes are different. 33 new sequences of hex digits, totally unrelated to my notes and the previous work i've done. i am no longer surprised that iCloud lost track of some of my data.

this is also the stage where the endeavor becomes impossible even for a user being assisted by someone else, say a Mac Genius. first, the user would have to take their Mac and Time Capsule to the Apple store. then the Genius would have to get to this point. then, together, they would have to go through every calendar folder through the Time Machine interface, which is about as fast as working with floppy disks, handcuffed by only being able to use quick look to ascertain what's what. i found out that quick look-ing the .ics files was faster than the .plist files, so i did that. i wrote down another set of 4-digit hex prefixes on my scrap sheet, selected those folders and finally, at long last, hit Restore. after clearing the iCal cache and forcing it to rebuild its database, my events were back. not in the cloud, but back, on my hard drive…somewhere.

i don't want to have to be lucky

there's no question, i got lucky in this scenario. the snafu happened in the transition from local to cloud copies of my calendars. i had backups. i had knowledge and a hell of a lot of persistence. but what about the person who buys their first Mac today and always lives in the cloud? when their data goes missing, who's going to be able to save it? it'd be like waking up one morning to find that your car was missing from your garage. you call the police to report it, but once you give them your license plate number and VIN, they tell you that they have no record of the registration and that in fact, the vehicle had never even been produced by the manufacturer. this is nightmare, Kafka-type stuff.

everybody, power-user or not, should want to be able to lay a hand on their data, in both the literal and metaphorical sense: "look here, i hold in my hand a drive that contains my data" and "look here, i'm pointing with my cursor at the representation of that data". if all our data lives inside apps, all our apps have to be able to talk directly to our incremental backups. a couple Apple apps do this — Mail.app, for one — but the vast majority don't.

losing a file hierarchy might be a pain for some power users. but plenty of those power users use a flattened system for the one place they have more data go in and out on a daily basis than any other: their gmail archive. gmail tags are a flat storage system (ironically, to be compatible with IMAP, which uses folder hierarchies, google had to hack a flattening mechanism on top of the hierarchy. actually, the same is true for iCloud — anything saved on an HFS+ drive necessarily lives in a directory, even if it's invisible, unaccessible, and miserably named.) i am all for organizing my stuff in the most efficient way. even though i'm a file hierarchy junkie, i usually cut through most of the layers by using LaunchBar. my files live in a semi-flat representation in my mind already.

fortunately, i don't have to conclude this by predicting only doom and gloom. iCloud is gravely unsatisfactory in terms of keeping my data safe, because it's dumb about backups and previous states. thankfully, we have an alternative: Dropbox. no matter what happens in Cupertino, it's a relatively safe bet that Dropbox is not going anywhere in the foreseeable future. and they provide two very, very important features. first, file hierarchy is their bread and butter. even on a device where the local file hierarchy is totally hidden, like in iOS, any app with Dropbox access lets you browse cloud-based files and folders. but most of all, they preserve previous states of everything, for a full 30 days even on free accounts. if something gets disappeared — through a bug, through human error, whatever — they will not deny that it ever existed.

so is Apple protecting our data? my answer on a file level, and John Siracusa's answer on a filesystem level, is a resounding no. this is sad, but it may change. at least, for now, there are many clouds in the sky.

The Followup: Back to Work e43

blog note: this is the first installment in what i plan to be a regular feature, that i'm tentatively calling The Followup. the theme is simple: i listen to podcasts, and as i'm listening i tend to have lots of thoughts. a lot of times i wish i could get right into the conversation. i don't have the luxury (or desire) to listen to live recordings of podcasts and provide feedback that way, and half of the benefit of the format is the ability to time-shift. hence, i have to write things up after the fact, or let them pass forgotten. even though i time-shift, i'll try to keep these fresh…at least to the extent that i try to not let my listening backlog get too long. this post is based on episode 43 of the fantastic Back to Work podcast by Merlin Mann and Dan Benjamin, which was recorded two weeks ago.

on with the show.

discussing questions

at right around the 15:00 mark of the episode, Merlin said this and my ears perked up:

i want to talk about the potential role of questions in mostly helping you figure out what the next question should be. and that's not to say that a question cannot have an answer, but i'm interested in the idea of questions as part of an iterative process.

i got excited because even though Merlin meant this in a very real-world, productivity way, this sounds a lot like some key concepts in the areas of linguistics that i've been doing research in lately. in particular i've been working with and adding to a framework that formalizes discourse, founded by the Roberts / Tonhauser / Simons / Beaver research group. in plainer terms, i deal with a logic or way of computing how the pieces of a conversation have to line up in order to make sense or be useful.

stack 'em up

one important piece of the theory is that every conversation has a Question Under Discussion, or in some versions, a stack of them. you can think of this stack either in the plain physical sense, like a stack of cards, or in the computer science sense. either way, there's always one question that's on top. the goal of whoever is participating in the conversation is to answer that question. that might be an easy job, or it may be a very difficult one.

kinds of answers

Merlin actually has a really good intuitive grasp of what sorts of questions have simple answers and which don't. semanticists typically say that the meaning of a question is the set of all its possible answers. one example he gave was "do you want lemonade with dinner?" – for this yes/no question, there are just two answers: {(yes) i want lemonade with dinner, (no) i don't want lemonade with dinner}. if you're having trouble picking one of those, it means you're just indecisive, not that there's anything faulty with the question.

on the other hand, Wh-questions (so called because they are introduced by words that, in English, mostly start with the letters wh) have lots and lots of answers. "where are my keys?" is represented by the set of every statement of the form "my keys are [in x place]”. when we discuss these answers, even in formal logic, we tend to make some sort of reasonable or sensible partition. {my keys are on the desk, …on the nightstand, …under a pile of papers, …at work, etc.} are the options we present, not {my keys are on Olympus Mons, my keys are at the bottom of the ocean, etc.} nor {my keys are 1 inch from the north edge of my desk, my keys are 1.1 inches from the north edge of my desk, …1.2 inches…, …1.3 inches…, etc.}, even though these are all possibilities.

once we have a sensible set of choices, the goal of the conversation is to find the right choice or choices. this could take a single step: if i saw the keys on the desk, i can say so, and the problem is resolved. if i'm looking at the desk and don't see them, i can say they're not there and, by doing so, refine the question. these are called complete and partial answers respectively. in discourse theory, whatever you say next has to give a partial or complete answer to whatever question is on top of the stack.  if you fail to do that, your response is considered irrelevant, and whoever you're talking to will probably look at you funny.

questioning questions

one of the interesting things about relevance (and one of the major new ideas in a paper i presented at WECOL in November and am drafting for publication now) is that you don't have to assert things — that is, make statements — to be relevant; you can also ask questions or give commands. here's where the linguistics meshes with Merlin's ideas: it's possible to iterate questions to ask better questions, but there are rules on how to do it.  the new question has to be relevant to the previous question. since questions are always defined as a set containing multiple statements, they can never give a complete answer, but they can go a long way towards giving a partial answer.

think of the two questions as a Venn diagram. each circle represents all the answers to a particular question, and the overlap are the statements that could answer both questions. this set of statements is the new, refined question. it takes a little bit of logical thought to get a good overlap, but that's just the process that Merlin is after. so there's a lot in common between sound, rational, productive work processes and the way every single conversation works. i'm guessing a lot of people haven't thought of it in those terms, but doing so might help, both in how we get things done and how we talk.

fence me in

one of the highly touted features of iOS 5 at its introduction was Reminders. the feature that made the WWDC crowd ooh and ah wasn't just an official Apple to-do list, or a fancy timed alarm system (neither of those would be particularly innovative), but the ability to set location-based reminders. buy milk next time you're at the grocery store? get there and *buzz*. or so we thought. then this came across the twitter: [blackbirdpie url="https://twitter.com/#!/waferbaby/status/124518378076520448"]

[blackbirdpie url="https://twitter.com/#!/dokas/status/124520733496979456"]

hold on. i have to go to the grocery store before i can remind myself to buy something there? what if i want to remind myself to call my family when i arrive at an airport halfway across the country that i've never been to before? well, there's one other option: you can set reminders up for addresses that are tied to one of your contacts. i guess that would be fine if it didn't impede your productivity, but even stranger, it tempts you to violate Apple's aesthetic.

the garden of Apple

anyone who's ever watched an Apple product keynote knows about the perfectly cultivated, mythical world that exists within their demo devices. every photo is in focus with smiles. basic word processing tasks become graphic design projects and suitable-for-framing posters. every item is tagged down to the last iota of metadata. everything is beautiful. in one sense, this is just to put on a good face and show the product in its best possible light. in another sense, you get the idea that Apple actually expects you to use the product this way.



on e57 of The Talk Show, John Gruber and Merlin Mann talked about the similarities between Apple and Disney, particularly in re: the insane attention to detail and upkeep that's required to keep Disney World the most magical place on earth. they mentioned the fact that the Magic Kingdom is never empty; it's staffed 24/7, even if it's only open to the public during the day. keeping everything just so is a literally constant effort, and as such is only possible when done in shifts by a team of workers. Apple may or may not be a 24/7 company (at least not on the design end; who knows when you take into account overseas production by OEM manufacturers). nevertheless, they've shown us that with their own product in their own hands, they can keep up the illusion of perfection, down to a perfectly manicured garden of contacts, faux and real, social and business.

however, Apple isn't in the theme park business. they are in the computing business, which inevitably means handing over their precious product to be maintained by us, the users. we have different tastes. we want to tinker, or hack, or just be plain lazy. we would suck at running Disney World, for the most part. nevertheless, by force of implementation or by mere suggestion, we are still pushed towards The Apple Way.

breaking the illusion

the paint begins to crumble and the facades of Main Street USA fall down to reveal the fluorescent-lit office buildings behind them when the inutility of iOS 5 location reminders comes to bear. the odds of gaining value by setting up a reminder to trigger at the location you're already in, or at the home or business of a friend or colleague, are very slim; chances are a plain or timed reminder would work just as well. what's the workaround? well, you can put that address in a new contact. but then Grocery Store is in your master contact list along with Your Mom (the lack of good nickname support and the notion that you would want to list your close family members as Firstname Lastname is a separate rant).

people do this kind of stuff all the time. people create contacts with first names only; people deliberately put where they know somebody from instead of their last name; people list their best friend as aaaSteve so he's re-alphabetized to the top. but you would never, ever see such a one-off, hacky way of squeezing utility out of the OS put on stage for demonstration. it would be quintessentially un-Apple.

building a better fence

geo-fencing is nothing new, but Apple is just now dipping their toe into it. and, if you still use iPhoto (i'm sorry), you know that Apple's idea of efficient place management is anything but. still, i'm a bit disappointed that i can't set up a reminder of the following type:

remind me to buy bagels at CTB on the second Tuesday of every month only if i'm in Ithaca, NY

i could set up an iOS 5 reminder at my apartment in Ithaca, which would probably trigger on the appropriate day, but that seems like a slightly odd way of doing it. or, if i target the actual bakery, i may never stumble into the arbitrarily sized (and presumably rather small) geofence that surrounds it. i might even have to get close enough to see the sign out on the sidewalk advertising the monthly special before my reminder would be triggered. in that case, a decidedly 20th century reminder would be more effective than my 21st century one.

fortunately, there is hope that we won't have to just build kludgy reminders and faux contacts, while we wait for Apple to catch wind of the fact that we're dissatisfied with the project. the technology that underlies the location-based reminders is a new OS service in iOS 5 that does low-power GPS tracking. and, perhaps surprisingly, it's not a proprietary API call. that means that third party developers are free to use it and put apps in the official App Store that use it. Foursquare already announced a new feature called Radar that uses it to send you notifications based on friend activity in your vicinity. this means that similar functionality, including arbitrary geofencing, ought to be able to be merged into a reminder app. Remember The Milk has already added location services to their Android app; their first priority for iOS 5 and the iPhone 4S was to get Siri working with RTM, but i can only imagine that they'll be adding location support next. and then i will gladly buy their app and subscription service over using a wonky Apple implementation. will i be upset if Apple steals their feature for the next version of Reminders? no, in fact i expect it; it should have been there in the first place. if they can build a better geo-fence than the competition, they will win back my fence-building business.