New technology creates new social phenomena, etiquette problems being one of them. Caller ID is not a new technology, but at some point in the past few years, its ubiquity—especially with cellphones, which have better text displays than landline phones—has created one of these etiquette problems.
Traditionally (where by “traditionally,” I mean “ten years ago”), when Alice calls Bob and gets Bob’s voicemail, Alice leaves a message at least saying “it’s Alice, call me back.” But over the last few years, we’ve seen a different approach. Charlie calls Bob, gets Bob’s voicemail, and just hangs up. Charlie knows that Bob has caller ID and will be able to see that Charlie called—Charlie figures that’s all the information Bob needs to return the call.
Bob may have the same approach as Charlie, in which case this is fine. But Bob may figure that if Charlie had anything that needed a response, then Charlie would have left a message. Bob doesn’t return the call and eventually hears again from Charlie, who indignantly asks “why didn’t you call me back?” There’s a mismatch in expectations. Neither one is right or wrong, necessarily, but the mismatch can create friction.
Or perhaps it’s just a matter of etiquette that we as a society haven’t quite sorted out yet. I was talking about this at dinner with some friends who are all around my age—we all agreed that people should leave messages. There might be an age component to this.
I’m documenting this publicly just in case anyone ever runs across the same problem I’ve been having.
I occasionally plot out routes on Google Maps and save them under My Maps. Curiously, there is no convenient way to get My Maps onto my iPhone. This leads to the slightly ridiculous situation where I would need to print out maps to bring with me.
Google Earth for the iPhone purportedly will access My Maps, but I couldn’t get that to work, because I sign into Google through Google Apps for Your Domain; there’s a web-based sign-in inside Google Earth, and when I attempted to sign in through the GAfYD (launched through the Google Search app, which otherwise works great), it would throw an error.
I have discovered if I log into Google Earth through the non-GAfYD interface, using my full e-mail address and the usual password, it works.
From what I understand, there’s only a limited ability to show personal maps in in the Maps app on the iPhone, and this can only be done via some hackery. Google Earth seems like the best option for accessing personal maps.
In The real reason why Steve Jobs hates Flash, Charlie Stross wrote an analysis of Apple’s recent moves, and where he thinks Apple is headed (oddly, he never quite says what “the real reason” is). He’s looking 5–10 years down the line. I’m thinking about the next 1–5 years, and how (or if) we might get to the future that Stross envisions. Continue reading
It is widely rumored that Apple will be introducing some kind of tablet gadget about half a day after I write these words. It is also widely rumored that a key aspect of this introduction will be deals with major print-media publishers, who will be offering electronic versions of their books and periodicals on the mythical tablet.
Ben Hammersley has been writing about electronic media and the future of journalism, but more from a different angle—from the original act of creating stories. But I don’t doubt he’s been thinking about the production side too.
What tool will that be and where will it come from? I doubt it will be Adobe’s GoLive, although that might work. I suspect (assuming all these other suppositions are correct) that Apple will be announcing their own software, taking another dig at Adobe. If all this is correct, it’s going to become an important software market.
And while Apple gets dinged (often justifiably) for a walled-garden approach to their products and services, in this case a win for Apple would be a win for the public interest. A publication format based on existing standards lowers the barrier to entry for other players; if Amazon decides they want to support this new format in the Kindle, they’ll just need to ensure they’ve got a standards-compliant HTML engine on it, and publishers will just retarget the Kindle with the same output. The formats may involve some kind of quirky or proprietary wrappers, but these would get laid on at the last step in the production process. It would be trivial to re-wrap the same payload for multiple devices. For any of these devices to succeed, of course, is another matter entirely.
I’ve gone on a bit of a kick lately and tried out four different ones. There are one or two others that I haven’t gotten around to yet. I hope to eventually, and will report on them in this space when I do.
Executive summary: Rubitrack for iPhone and Cyclemeter are clearly oriented towards performance cyclists; right now I’d give the nod to Cyclemeter. GPSies seems almost like a toy, but might be of use to hikers. Motion-X is for GPS otaku.
Multitasking is an obvious shortcoming on the iPhone right now. Multitasking is possible: some of Apple’s own apps run in the background, and there are jailbreak apps that allow apps to run in the background and for the user to switch between running apps. But Apple does not allow app-store apps to run in the background at all, presumably because of performance and battery-life problems.
I believe that multitasking on the iPhone can be broken down into two functional categories: apps that you want to run persistently in the background, and what I’m calling “interruptors”: brief tasks that only take a few seconds to complete, and where you don’t want to break out of your current app. I’m concerning myself with the latter case here.
A jailbreak Twitter app, qTweeter, has the kernel of an approach to presenting these interruptors: it pulls down from the top of the screen like a windowshade, and is accessible any time.
This approach could be generalized to present multiple apps in what I’m calling a pulldock. There could be one pulldock that pulls down from the top, another that pulls up from the bottom, to present up to eight interruptors.
I envision these interruptors being stripped-down interfaces to existing apps or services, such as twittering or text messaging, that would appear in some kind of HUD-like view superimposed over the running app. Interruptors should be lightweight enough that they wouldn’t overburden the phone. I can also imagine new ways of passing information between a regular app and an interruptor—such as launching a camera interruptor while in the mail app as a way to take a photo and insert it into a mail message, which would save a few steps.
Here’s a screencast:
Yeah, there’s a lot of “umms” and sniffing in there. It’s the first screencast I’ve ever done. The visuals were done in Keynote using the template from Mockapp.
A couple of nights ago, Gwen used the phrase “Googling for something on America’s Test Kitchen” instead of “searching for…”, which just reinforces that Google has become a synonym for search.
Google search results are often polluted by irrelevant links to commercial websites like bizrate and dealtime, though. Wouldn’t it be nice if there were a way to avoid that? There is: use Give me back my Google.
It would be even nicer if you could search via GmbmG right from the search field in your browser. And in fact you can, but you’ll need to set it up first
Safari does not let you customize your search field out of the box, but there are some hacks like Glims that add this capability. Once you’ve done that, you’ll need to add GmbmG to Glims as a custom search engine and teach it the specific search syntax that GmbmG uses. It is: http://www.givemebackmygoogle.com/forward.php?search= search key
Firefox or Internet Explorer 7+
These browsers support something called the “open search description document,” which makes adding a new search engine dead-simple. I have no idea how this works in IE, but in Firefox, just install this plugin (which I created, not the creator of GmbmG—the plugin is currently listed as experimental, but it’s perfectly innocuous, I promise) and it will add that site to the list of search engines your browser uses.
Years ago, Apple promoted the Mac as a “digital hub” for media. Today we take for granted that computers can be used as hubs for media.
Two of the numerous points covered in Apple’s recent demo of version 3.0 of the iPhone OS was that Apple was finally giving developers access to the port, as well as unblocking bluetooth. These points have largely gone unremarked, but in the long run, I suspect they’ll be especially significant. I think Apple is positioning the iPhone to be a mobile hub.
Right now, the iPhone/iPod Touch has a sharper display, more processing power, and better input affordances than many of the gadgets that we deal with on a day-to-day basis. I predict that some manufacturers will take note of this and start producing headless products that will only work with an iPhone snapped onto the front to take care of these functions and/or provide new functions. This could be a nice moneyspinner for Apple, because of their “iPod tax” on products marked as compatible, and because it would make the iPhone that much more appealing, thus increasing demand for it. It could also be a profitable niche for manufacturers to exploit, since they could sell a product that is more functional than conventional equivalents but cheaper to build.
Car stereos: A car stereo with no faceplate, but simply a bracket and plug for an iPhone strikes me as the most obvious category. Many aftermarket car stereos already have detachable faceplates anyhow, and this would be a logical extension of that idea. Giving direct access to music on the phone would be the obvious benefit, but it would allow tidier integration of phone functions into the car, and add navigation as a lagniappe. A custom app might give simplified access to phone, nav, and music, and perhaps would have a radio controller that communicated with an actual radio in the car stereo over the port.
Bike computers: There are already a numberofinterestingapps that can use the GPS chip on the iPhone to track performance and routes over a bike ride, but these are hampered by some of the phone’s limitations. One is that there’s no way to continue logging GPS data when the app is not running, for example, when answering a call. I’m not sure if 3.0 will change that. (A friend who works at Apple suggests it will, but I’m skeptical. All that would really be needed would be a simple background daemon that logged GPS data at regular intervals, allowing the actual app to pick up where it left off.) Apart from that, a bike-mounted cradle for the phone would permit wheel and heart-rate monitor data to be fed into the phone through the jack and could provide extra battery power to the phone—so far, the only way to get heart-rate monitor data into the phone has been through a specialized product that uses wifi. This is a clever hack, but bluetooth or some kind of low-power radio communicating with the cradle would be more appropriate.
Cameras: I’m not the first person to observe that serious cameras could use an interface more like an iPhone’s. Snapping an iPhone directly onto a camera back would be ungainly, but tethering it over a wire could make a lot of sense, making it a tool for managing captured photos, backing them up, appending metadata (including GPS), and transmitting them.
Trackpads: Again, there is already an app for the iPhone that allow it to function as a trackpad (or as a tenkey input, etc), but again, these work over wifi. Apple has done a lot to make the trackpad on laptops not only a tolerable alternative to the mouse but in many ways a superior one. I can imagine a keyboard with a snap-in slot for the iPhone that turns it into a trackpad, giving those advantages to people using desktops.
What is not clear so far is whether a new port connection can trigger an app on the iPhone. This would be helpful—if not necessary—to create a seamless experience. Ideally one would simply snap one’s phone onto one’s car stereo in order to put it into car-stereo mode—the phone would recognize what it was connected to, and an application would have been registered to automatically launch when that connection is made.