Mile Zero
no matter where you go, there you are
Jan 28, 2010
Yesterday I did something that I arguably should have done a long time ago: I redirected pretty much every tech blog in existence to localhost on my work laptop, effectively blocking them completely. Previously, I'd done something similar using the BlockSite plugin for Firefox, but it'd been too tempting to route around it in Chrome or IE. Not good enough: I needed them gone completely. Nuke their domains from orbit, it's the only way to be sure.
I took this step in part because I agree with Anil Dash: I want to believe that I'm better than a consumer for a constant drumbeat of materialism. It's ironic that the digital computer--an infinitely-adaptable, do-anything Turing machine--has spawned an entire subculture primarily concerned with packaging those machines into an infinite array of disposable, plastic packages. Maybe I can't always resist buying more crap, but that doesn't mean I should spend my waking hours planning the next splurge.
It's also in no small measure because tech bloggers are, generally, incredibly silly people. (I know: "this food is terrible. And such small portions!" But stick with me.) I've complained here for a long time about the low quality of games journalism. As I started reading more gadget news sites a couple of years ago, gradually it dawned on me that the lack of good material in that one area was just symptomatic of a sector-wide lack of perspective. The whole thing's rotten: the completely interchangeable writers that substitute "snark" for "opinion," the rumormongering, the wafer-thin technical expertise leading to "analysis" that isn't, the constant churn through the hype machine. For me, the result is a kind of low-grade irritation, and I hear that happy people live longer.
My worst nightmare, actually, is that one day mainstream journalism--in its increasingly desparate grope for cash and readers--will model itself on Gizmodo: high turnover of largely forgettable, badly-written posts cadged from press release wire services. I like to call that the "no self-respect or job security" future, personally.
(Which reminds me--Dear mainstream journalism: we need to talk. I know it's hard, enduring this rough patch of reasonable profit margins, compared to the ridiculously exorbitant profits you enjoyed back in Ye Olde 1990s. But whenever some new tech gizmo comes out, every two-bit visionary and "innovation editor" on earth shrieks to the high heavens, insisting that this time Product X will "save the industry" from extinction at the hands of the blogging hordes. It's funny: I could have sworn we already had a way of digitally distributing news to readers on a wide range of technological platforms, including video and interactive graphics and audio clips of elected officials sniping at each other, but I can't seem to find it now. Maybe it's buried under all these browser windows that I've got lying around, left over from Twitbooking and Facetorrenting and all that other stuff the kids are into these days.)
But the sad truth of it is that the tech news deluge works. It's strangely addicting, this gossipy flood of trivia. Indeed, that's the psychological quirk that powers the entire Gawker network--pump out as much content as possible, crank up the volume, and people will find it oddly compelling. I do, at least, to the point where I wasn't very good at stepping away from it. But when I reflected on what I was actually getting out pounding the refresh button, I felt a bit like a rat at the opium feeder bar--mangy, irritable, and poorly-nourished. Prone to metaphor abuse, too, apparently.
So I'm cutting myself off. And with the time I'll gain, I hope to pick up a new hobby, or rekindle an old one. Maybe I'll finally code that pocket synthesizer I've always wanted, or get back into the online bass scene. Maybe I'll finally get past the first chapter of the book I keep starting. Or even get some actual work done! These are strange new times indeed.
Jan 21, 2010
As an example of what Android's doing right, it's hard to top Locale.
- It's approachably awesome: You don't have to be a nerd to see the value of automatically putting the phone on vibrate whenever you get near your office. Ditto for the ability to change ringtones based on time of day, or turn down the screen brightness when your battery gets low. This isn't some overhyped toy like augmented reality, it's a useful improvement that an average person can appreciate.
- It rewards creativity: Want to silence the phone by flipping it over? Turn on Bluetooth only when at home during certain hours? Lower the in-call volume when specific contacts with loud voices call you? Locale can do that (out of the box, no less).
- It's extensible the Android way: Locale leverages one of Android's most unsung features: the Intent message-passing mechanism. That makes writing a Locale add-on as easy as exposing a couple of preset Intent filters in your package manifest. Thanks to that kind of extensibility (a key part of the Android experience), you can get plugins that send SMS and Twitter messages, react to headphone or docking events, turn your computer on via wake-on-LAN, or hook into your to-do list for location-based reminders ("Buy milk when near the grocery store").
- It reaffirms the value of multitasking: Locale is only effective because it's always running, even when you're doing something else. You can't fake this functionality with a hack like push notifications. And despite the conventional wisdom about multitasking and battery life, Locale uses very little juice. In Android's battery usage stats, it's typically the bottom of the list, dwarfed by the demands of the screen and wireless radios. That's partly smart scheduling (Locale requests its updates in ~10 minute intervals batched with other programs, and evaluates low-power conditions like time before more expensive options like GPS), but also simply because the energy consumption of multitasking systems has been grossly overstated.
When I first started using the ADP1, Locale was one of the programs I tried and uninstalled, thinking that it was nice but overkill for my needs. As time went by, my alternatives for settings automation succumbed to either developer neglect or ridiculous feature creep (nonsense like task killers or banner ads), and had to be removed. So when Two Forty Four AM, Locale's developer team, recently released a for-pay 1.0 version, I gave it another shot, and was pleasantly surprised. During the past year, they've refined it into a polished, sharply-focused utility that's well worth the $10 asking price.
Reviews of Android phones often fault the platform for missing some single application that the reviewer has decided they can't live without--a specific Twitter client, for example, which says a lot about the priorities of tech bloggers compared to normal people. In my opinion, though, Locale really does provide the sort of functionality that ought to be a deal-breaker for other platforms, and it's a must-have for Android users. After all, isn't this sort of automation kind of the point of a "smart" phone?
Dec 17, 2009
It's officially too cold for words in DC this morning, which means that as of yesterday anything I own with a touchscreen just became utterly useless. Consider this a triumph of frostbite over functionality, brought to you by product designers who live in eternally balmy climates instead of the real world.
At least the Android Dev Phone is usable, if clumsy, thanks to the trackball. People scoffed at the trackball, the menu button, and the chin they rode in on, but those people have to take their gloves off to check their e-mail. Which is not to say that it's any fun using the trackball through a pair of gloves (it's way too small), but it's possible. Gloved typing on the physical keyboard also works surprisingly well. And by surprisingly well, I mean "badly."
The Zune HD, on the other hand, is basically just taunting me. See, it's got a button on the side, the express purpose of which is to directly trigger a screen overlay for controlling playback and volume. I guess it would have been too much to ask for actual buttons to control those things, particularly the commonly-used song skip functions. Of course, these days, even players with physical controls probably run them on capacitive technology anyway, so you still can't use them. I'm pretty sure that's just spiteful.
And then there's the Kindle, which doesn't use a touchscreen at all. Great! Someone gets it! I can read with gloves on, just like an actual book! Here's what they don't tell you about the Kindle, or any e-ink reader: cold temperatures slow the already-slow refresh rate. It goes from being subliminal to seriously annoying as the temperature gets down below freezing. What's that? Paper? What am I, a neanderthal?
At this point, my options are to either go Amish, or move to a place with a milder winter and a functioning public transit system. Frankly, it's a tough call.
Dec 16, 2009
When I was doing research for the Audiofile articles, one of the surprisingly discoveries I made was the degree of overlap between audio sampling and other kinds of scientific sensors. In retrospect, it's obvious that the theory behind accurately measuring an audio signal thousands of times a second would be much the same as taking a measurement from something like a temperature, voltage, or orientation sensor. But it takes a moment's thought to make the transition from audio-as-sound to audio-as-voltage (or audio-as-binary-stream), which is the paradigm shift that makes it possible. It's not just a microphone or a speaker--it's an I/O port.
Audio inputs and outputs are everywhere, but they've fallen out of style for digital interconnection, which is why it's so cool when someone uses them in unconventional ways. One of my favorite examples is the re-release of Bangai-O for DS, which lets users trade custom levels through audio files (they sound a bit like picking up the phone on an old modem). That's really clever--particularly since it takes nerve to ignore the console's built-in wireless connection (a good thing, given the way Nintendo has reliably squandered it). Sharing MP3 files over the Internet is cheaper, easier, and longer-lived than any centralized, developer-provided solution could have been. It even degrades gracefully (you could send creations by mail via cassette tape).
Another great use of audio hacking showed up on Make recently, with a point-of-sale system that plugs into a smartphone's microphone jack. You see something like this and you think "well, of course!" It reminds me of the old IR blasters that were available for PalmOS back in the day--plug a stubby, square rectangle into the headphone jack, load up some .wav files, and suddenly you've got a universal remote control. Both inventions play on the realization that almost every device has a high-quality digital sensor with a sampling API and a standard pin configuration, as long as you stop thinking of the headphone jack as "for music only."
Tricks like these are not only fun for digital audio nerds like me, they're also a reminder that audio is a big part of our software heritage. After all, the original sytem hackers were audio people: phone phreaks who exploited flaws in the network signaling to get free long-distance calls. It's been a long time since those days, and since you had to physically place a handset onto an acoustic coupler to go online (that was even before my time, actually), but audio remains a powerful (and evocative) tool for storing, transmitting, and even hiding information. I can't wait to see what people will invent (or revive) next.
Nov 12, 2009
The Myth of Android Fragmentation
Of late it seems to have become fashionable among tech writers to complain about the "fragmentation" of Android hardware, and to blame this for perceived weaknesses in the platform, or to explain away their preference for something else. With several screen sizes, input methods, and UI customizations available, these writers say, Android developers face the insurmountable obstacle of rewriting their code for each new device running the OS.
Take, for example, Crunchgear's John Biggs, who's entirely typical of the tech pundit conventional wisdom. In a post on the size of Apple's App Store, he claims:
In Android's case you have multiple "branches" of the OS for multiple devices. HTC and Motorola have their own UI tweaks and these branches for programmers to recompile for multiple devices. This, obviously, is a big issue for mom and pop shops run by a few developers and even worse for the 14-year-olds out there building apps in their basements.Yeah, all that recompiling would be a real hassle--if it were true. It's not, any more than I have to get a special version of every Windows program to work with my specific model Thinkpad. In fact, the "fragmentation" claim is a myth, and one that's frankly idiotic if you think about it at all. To understand why, let's take a detour into programming metaphor.
As much as anything else, programming is based on metaphors of nested abstractions. Take your browser, for example. The programmers of Firefox don't have to write code that manually changes the electrical current in your network cable or wireless card. Instead, they can take advantage of the layers in the TCP/IP stack and write at a higher level of abstraction--using concepts like packets and ports. Even better, if you're writing a Firefox plugin, you can build on their work at a higher level of abstraction: HTTP page requests. These high-level program calls get translated down through the layers until, eventually, some code somewhere takes care of the actual electrical signaling. But for the programmer, all that is abstracted away. Abstraction is the miracle that makes increasingly complex software development possible.
Programming for Android is no different. In fact, abstraction is a major feature of the platform. Almost all Android software is written in Java (which was originally pitched to programmers as a highly-abstracted, cross-platform language) and compiled to a virtual machine instead directly to ARM code. That's why you can actually run Android applications on Ubuntu without recompilation. Technically, they're hardware-independent by design (the downside being that execution speed--until Google adds Just-In-Time compilation to the Dalvik VM--is relatively sluggish).
Even when it comes to interacting with hardware like the screen or input devices, Android provides libraries and abstractions to handle this kind of thing. One platform has a trackball while another has a d-pad? To an Android program, they both look like identical directional commands. Different screen sizes? There's no need to recompile: programs just ask for a resolution and adjust to fit, or use the platform's excellent XML-based layout kit and let the OS scale UI elements to fit ("wrap_content" and "fill_parent" attributes, combined with a RelativeLayout, can do impressive things). Again, this isn't a new idea. Hardware abstraction layers and flexible layout tools are a given on every modern OS--you didn't think developers wrote windowing and display code all over again for every video card on the market, did you? Of course not.
I'm no big-time developer on par with something like Twidroid or ShopSavvy, but I've had no reports that Underground is having problems running on different Android devices. And I'm not aware of any developer who's complaining about having to compile a completely new build in order to run on new Android devices. They may be fixing isolated problems (cameras in particular can be tricky), or adding code to take full advantage of features like the Motorola Droid's high-res screen. But for 99% of applications, and 99% of developers, it doesn't even enter the picture. Given the design of Android's abstraction layer, the fragmentation myth makes no sense at all. There's no evidence for it. It's literally something that the pundit community just invented out of thin air.
The irony of this myth, of course, is in the rhetorical strategy behind its deployment. When Biggs and his fellow tech pundits typically evoke the "fragmentation" of Android, it's usually in contrast to development for the iPhone, which supposedly has only one hardware configuration to target. Nothing could be further from the truth: after all, the iPod Touch (which accesses the same software as the iPhones) does not have a camera or GPS (the original iPhone also lacked GPS functionality). The iPhone 3GS exposes several hardware features missing from the other models, including video recording, digital compass, MMS, and better 3D hardware. And among the entire range of products connected to Apple's application store, there are at least three variations in CPU speed and architecture.
The iPhone is hardly unified--indeed, it's split by the most of the same distinctions bemoaned on Android, and they're solved by developers in exactly the same way: a robust hardware abstraction layer and careful, defensive programming. To claim fragmentation in either case would be absurd. But for the tech punditry to make that cognitive leap, they'd have to know what they were talking about. If the current state of affairs is any indication, there's little chance of that happening.
Update: In a hilarious coda to this, one of Wired's front-page articles this morning is "Android's Rapid Growth Has Some Developers Worried." "Some" developers, apparently, means three people from two companies, one of which explains in comments that he was misquoted and that "I honestly haven't had a lot of trouble with the fragmentation issue on Android, apart from some differences in the way Android 2.0 handles font sizes vs. earlier versions."
Tech writers: hacks, plain and simple.
Nov 02, 2009
I'm not a fan of centralized software distribution in general, but I have to admit that I've grown to enjoy checking on the most recent additions to the Android Market. I'm probably not going to install anything I find there, but it's neat to see what people are working on. Too many days, however, browsing through the "just in" section requires scrolling past screen upon screen of cookie-cutter entries churned out by application mills somewhere: a thousand local TV station website wrappers, ringtones and contact images, individual calculators for obscure engineering functions, keyboard skins, and vast other numbers of useless pseudo-programs.
Indeed, most of these aren't even really "applications" as you'd normally think of them. They're content, or content wrappers. But thanks to the new "mobile app" model, the confusion between program and data is growing. It's hard to imagine that this is a good thing.
But first, some context: sometime between the first and second World Wars, a mathematician named Alan Turing came up with a fairly interesting idea: if you had a machine that read in a string of inputs from a tape, and acted on them in series, you could perform complex mathematical operations mechanically. More importantly, you could build a machine that (if it were first given a set of action codes) would emulate other computing machines. He called this the Universal Turing Machine, and it was kind of a big deal. In gratitude, the British government had him chemically castrated to "treat" his homosexuality, and eventually drove him to suicide. It's not one of the proudest moments in history for Britain, computer science, or humanity in general.
To this day, when discussing programming languages, we say that they are "Turing-complete"--that they're capable of simulating a Universal Turing Machine, and in turn, any other Turing-complete language. Which is pretty cool: if you've ever used an emulator, you've seen a demonstration of a UTM at work. Effectively, it turns a computer from something like a calculator, where its functions are essentially mechanical operations, into something more like a box of Legos: an infinitely-adaptable, reconfigurable toolkit for doing mental work.
Which brings us back to the mobile app store model. In this case, the platform is still a UTM--you can still write emulators and multi-purpose programs for Android--but it's being presented to the user as single-purpose. Applications work in their own little silos, and content is distributed as if it were code, even if there's no technical reason why it has to work this way.
Take, for example, Snaptic's AK Notepad, one of the most popular notepad applications on Android. Desktop users could be forgiven for thinking that a "notepad" is an editor for text files, but AK Notepad is not (it does support a clumsy import-export process, but I can't imagine using it regularly). Instead, it keeps its notes in a proprietary database that no other application can access. Want to switch to another, better tool for jotting down your grocery list (or another, more involved project)? Good luck with that.
And then there are, of course, the multitude of web-site wrappers, like those local news "applications" that have flooded the market. They're nothing but a WebView with a preset URL. They're bookmarks. And in doing so, they've taken a real UTM-type application (the browser) and turned it into a single-purpose tool. It's the equivalent of asking you to download a complete version of Firefox just for a single website. The same logic is at work for the e-book applications, which pack their own reader software for each title--here, at least, the existence of prior standards and alternate distribution portals means that standalone reader software has a chance.
I bring this up not just because it's kind of a shame from a net-neutrality, open-platform, generative-computing standpoint, but also because I feel like it robs people of one of the joys of computing: the feeling that the software is a toolkit, to be applied to any given wad of data depending on the task at hand. One program may be better at text display, another better at formatting, and yet another may provide a no-distraction writing environment. With code and content separate, you can use whichever is best for the current task, and you're not locked into a single tool. The new mobile paradigm fuses the two into a single conceptual blob, and any task becomes limited by a single piece of software. It seems like a tremendous step back for computing.
Or maybe I'm just cranky from the flu, and annoyed to find myself staring at a spammy directory of Fox affiliate stations across the entire midwest where I expected some kind of software. It's hard to say.
Sep 28, 2009
Last week, Google sent a cease-and-desist letter to Cyanogen Mod, one of the rebuilt ROM images available for Android phones. Cyanogen was designed to be faster and more stable than the prebuilt images, and incorporated features like SD card partitions and new process schedulers to make that happen. Several of the project's innovations have even made it back into the main Android code. But Cyanogen also distributed closed-source applications like Google Maps in the ROM, so Google has effectively shut it down until the authors can work on a solution.
It's depressing, but Google is legally in the right, and their actions may even have side-benefits for the community (like an uptick in interest for alternative applications). Be that as it may, it's also illustrative of a real advantage that's keeping me on Android for now: the juvenile, terrifying, but ultimately beneficial presence of the XDA Developers board where Cyanogen got its start.
XDA got its start as a modding board for older Windows Mobile phones. The way the ecosystem is set up, it's up to hardware manufacturers to determine whether or not older devices get an upgrade when Microsoft releases a new version of Windows Mobile. Sometimes they do, most of the time they don't, mainly because the upgrade would require a ton of testing for not a lot of profit. XDA sprung up to fill that gap--they dump the ROMs of newer devices, wedge the new software into "cooked" images, and figure out how to get them onto older phones. HTC, the primary manufacturer of Windows Mobile devices and of the original XDA, takes a benevolent view of all this.
Contrast that with, say, Nokia. I think Nokia is awesome, and their phones are fantastic. If their devices were "future-proofed" in the same way, I'd still be using a Nokia now. But the Finnish company is not nearly so tolerant of the homebrew underground--they'd rather sell you a new phone. So when they come out with a new version of S60 that does something important, like upgrading the web browser core, they don't make it available on older phones. And because Nokia keeps much stricter control of the firmware update process, the community can't do it for them. The result (ironic for a company that's proud of its green image) is that consumers who want new features have to buy all-new phones.
So while it is unfortunate that Android homebrew is suffering a legal setback, it's also a reminder of how much these developers contribute to the ecosystem--perhaps not in a front-facing, consumer-accessible sort of way, but as a push for the platform to remain open, hackable, and sustainable. Most consumers probably don't notice that kind of thing, or even know that it exists, but I think it's ultimately a win for them--if only because it keeps developers, who are huge nerds, excited about the platform. It's certainly held my attention.
Sep 24, 2009
The default Android homescreen is a generally pleasant piece of software. It's easy to rearrange, hosts widgets for quick access to information, and has a fun parallax effect when you pan between "desktops." Add a handpainted Legend of Zelda wallpaper, and you've got yourself a classy launcher.
That said, I have two minor issues with it. First, if it's killed by the system (say, because the browser is hogging all the RAM), it can take a few seconds to restart itself. Second, it clears the activity stack when you load it, so the Back button becomes useless for multitasking. The Activity Stack/Back button combo is one of the best things about Android: together with the pull-down notification bar and the powerful Intent system, it lets users address incoming events without losing their place. Take, for example, this typical activity path:
- Launch Twitter client. Follow link to:
- Open blog post in browser.
- Get a message via GChat. Click notification to open chat window, type a reply, and press back button to return to the browser.
- The blog post links to a YouTube video. Click to open in YouTube client.
- Mid-video, receive incoming e-mail notification. Jump over to the e-mail application to read and reply, then press the back button to return to YouTube.
- Press back to finish reading blog post.
- Press back to continue browsing Twitter stream.
A better way would be if there were a way to augment the Home button as a kind of "quick launch" key, one that doesn't destroy the Activity stack. That's what my first Android program, Underground, does. It's not a full Home screen replacement, but a color-coded list of your favorite applications triggered by the Home button for fast, effortless multitasking. Think of it as a subway system for your phone.
I'll be putting it in the Android Market in the next day or so, but in the meantime you can grab the installation package here (don't forget to enable "Unknown sources" in the "Applications" section of your device settings). It's small: less than 50KB when installed. I'm also making the source available, in case anyone feels like tweaking it.
After installation, there won't be an icon in the application drawer. Instead, press the Home key. Android should ask what program you want to use to respond to the event, Home or Underground. Choose Underground to start using it. I also recommend clicking the checkbox to use Underground by default--don't worry, you can still get to the old Home screen, and you can always reset this in the "Manage Applications" section of your device settings.
When you start it for the first time, Underground has three items onscreen: a sample link to the web browser, "add new," and "home." You can choose "home," or press the hardware Home key again, to return to the default Home screen. To put your own favorite applications on the list, choose "add new" and pick one from the list (be patient: it takes a few seconds to find them all the first time). You can also long-press on a list item to change its tag color or to remove it from the list. Most importantly, just tap on an application's name to switch to that activity--Underground will quietly remove itself from the stack, so that the Back button will return you directly to your previous task.
That's all there is! Simple, fast, and effective multitasking in a memory-conscious package, without removing what was already great about Android's Home. I'm not much of a designer, so I've left it pretty simple: bold colors, nice big fonts, and liberal use of the platform's long-press interaction model. But that doesn't mean it couldn't stand some improvement: feel free to leave feedback here in the comments.
Notes on Programming for Android
It's extraordinarily impressive how easy this project was. Granted, it's a Java API, and after a couple of years in dynamic languages it feels like a real regression to go back to strict static typing, no first-class functions, and a million subclasses. And of course, it's not like this was an incredibly ambitious project. But for all that, Google has made working on Android about as simple as it could be. I've particularly grown fond of the XML-based layout tool and the package resource system, which makes it easy to build little chunks of UI (like tagged list cells) and pass them in to the view builders. If only S60 had been this easy!
And of course, it says a great deal about the openness of the platform they've built that I can literally take over from the preinstalled program manager (and that I was able to refer to its source code when I got stuck on a few tricky bits). All in all, it was a great experience, and I'm looking forward to working on a few more Android projects when I get the chance. Suggestions?
Aug 20, 2009
Android's swelling collection of "augmented reality" applications got a boost the other day when Layar hit 2.0. Layar's probably the most advanced example of its type, combining live video from the phone's camera with data overlays for local points of interest. Part of what makes Layar so interesting compared to its competitors is that it has an open API for developers to create their own overlays. I'm sure you're as excited as I am for the eventual branded or ad-driven layers.
This kind of thing is a deeply attractive technology just because it's so visceral--people love to consider the implications of digitally remixing (or obscuring) their surroundings. But the current fashion of doing so in a literal sense is probably a dead end. At the very least, it prompts a vision of annoying tourist hordes wandering around the city holding cell phones in front of their faces, like superstitious villagers waving the cross at their surroundings to keep the evil eye at bay ("evil eye" is actually not a bad term for the abuse of AR tech). Worse, to restrict the term "augmented reality" to that kind of hallucinogenic literalism misses the point, and squanders the potential of AR as a sixth sense by cramming it on top of our visual range. I'd argue that we've had augmented reality for a while now--and that it comes wrapped in a more appropriate level of abstraction.
Take Astrid for example. Astrid's another Android program--in this case, it's a to-do list/reminder system. On its own, Astrid lets you set timed tasks, tag events, and synchronize your reminders with Remember the Milk. But if you combine it with Locale, Android's location-sensitive alert system, now you can have reminders triggered by physical proximity, like entering the grocery store or coming home from work. Although there's no camera involved, and no sexy floating map, this is also augmented reality. Indeed, if you look through Locale's plugin selection in the marketplace, there's a wide range of intriguing possibilities: from waking your computer when you walk through the door, sending an HTTP request at certain locations, or keeping people posted of your location via Twitter or SMS.
Not to mention the concept of networked notation: really, I should be able to "tag" my current location and read tags posted by other people (see also: GeoBuzz or, to some extent, Ushahidi). This includes recommendations/warnings for nearby businesses, event recordings, historical information, and helpful hints ("Don't try the brown acid!"). It's the virtual equivalent of a message board, wherever you go, but sortable, searchable, and omnipresent. And that's the kind of sixth sense that's actually useful, because it gives you a local's situated knowledge no matter where you go.
If this still sounds kind of boring compared to the Virtual Light fantasy that Layar and other visual AR programs are pitching, that's because it is. But it's undeniably more effective than waving a phone around and hoping to spot a clue. Likewise, if I'm in Paris and looking for a good bakery, being able to see the relative position of my destination doesn't help me when the AR overlay neglects to mention that it's across the Seine. What I need in that situation is a good digital map--a less futuristic, but undoubtably more versatile form of augmented reality (and one that's available to anyone with a smartphone right now).
A while back, BMEzine ran a story (subsequently picked up all around the Web) on living with magnetic implants (note: link contains disturbing images). In this scenario, crazy people have neodymium magnets embedded in their fingers, giving them the ability to "feel" electromagnetic fields from computers, security sensors, and power cables. The author describes it as a relatively subtle perception, but one that gives access to a rich array of new information. To me, that's the model we should be using when building augmented reality applications. It's not about giving you a window into a garish world of digital overlays, but about simply providing context and knowledge in a given area.
Sometimes the best technologies are a lot less flashy. The cyberspaces of Gibson and Stephenson are a lot cooler than the textual Internet, but in a pinch I'm pretty sure which one would be more adaptable and innovative. So it goes with the augmented reality craze: when the dust settles, I think we'll find that we've been doing this in better, less literal ways all along. We're symbol-using creatures--abstractions are our friends. Let's use them.
Aug 10, 2009
Is the Pushbutton Web Good for Activists?
The denial-of-service attack that took down several social networking sites (including Facebook, Twitter, and Livejournal) certainly seems to have caught some attention, especially after the revelation that the attack was primarily aimed at a political writer called "CYXYMU," which I assume makes more sense in Russian. Evgeny Morozov calls him the first digital refugee, and points out the very real danger that other digital activists could be silenced this way--not by direct attack, but by removal from social networks for terms-of-service violations (you know, for all the bandwidth they're "using").
It's in this environment that I've been thinking about PubSubHubbub, an HTTP/RSS-based push distribution system. Anil Dash calls it the start of the "Pushbutton web." Here's how it works, as far as I can tell:
- A content site publishes an RSS feed per usual, but includes in the metadata addresses of several "hub" sites that subscribers can use.
- After fetching the RSS for the first time, clients can send a message to one of the hubs asking to be notified of further updates via HTTP POST.
- Hubs take care of the dirty business of keeping up with feeds. Publishers can notify their hubs of new content by HTTP ping.
- When hubs are notified of new content by the publisher, they take care of sending it out to clients--thus distributing the publication bandwidth across many hubs, reducing load on the original content publisher, and reducing latency compared to polling models.
What interests me about all this is that it's potentially a really smart, high-level proxy/federation system, one that's built for the modern web, and that might have real implications for activists. Under PubSubHubbub, any given node in the distribution network can play multiple roles--a publisher or hub can also be a client, and vice versa. As this develops, it might be possible to build hubs that are capable of talking to each other to locate publisher feeds, thus adapting to outages or blocks--similar to the way that peer-to-peer protocols may share lists of working leaf nodes with each other upon connecting to the network for the first time. At the very least, it will be possible to enable realtime communication/distribution on a decentralized platform--one that's harder to block with a single rule, and can't necessarily be shut down by DOS attacks on the central distribution point.
Of course, right now, none of this is part of PubSubHubbub's plans. Right now, this is a technology for making sure that your shared items in Google Reader get pushed out to FriendFeed as fast as possible--thus fulfilling the golden rule of Web 2.0 technology: all the interesting stuff will be invented primarily to buff up the shiniest service (Twitter, Facebook, etc.) in the room. Indeed, this particular pushbutton protocol may never develop the way I'm hoping it will--and it probably doesn't solve the problem of DOS attacks entirely (seems like the original source is still vulnerable)--but it looks to me like the Internet zeitgeist is taking steps in the right direction. Potentially, that's good news for prospective digital refugees.
