Sodium DreamsAmazon Kindle Exposes Passages You Highlight to the Mothership
“We show only passages where the highlights of at least three distinct customers overlap, and we do not show which customers made those highlights.”
That’s a good start, but it’s not entirely reassuring. There’s a very clear analogy here, I think: the titles of books in your living room bookcase are in plain view to a guest in your home, but I would bet you’d feel your privacy invaded if he were to start thumbing through volumes to tally all the dog-eared pages and highlighted paragraphs.
Nothing scares me more as a developer than being intimately aware of how companies collect personal and social data. It’s a bit like being a dairy farmer who doesn’t drink milk. I know a little too much about what’s going on behind the scenes. Our social values have evolved in a pre-digital era, and we simply don’t know how to deal with online databases, permalinked profiles, and the dissemination of personal (but not necessarily private) data.
We know anonymization doesn’t work. We know that behind the publicly accessible overview, there are database rows and access logs that are potentially revealing. But we haven’t confronted these issues as a society, and we haven’t cultivated a code of ethics for privacy in the digital era.
A Conversation Between Me and Seven Solaris Boxes
- Me: Hi, there! I need to manage user accounts across all of you.
- Solarae: Ha ha ha, good luck, fucker.
- Me: Aha! But I have a secret weapon. Kerberos!
- Solarae: Gahffffffk! Nooo! I refuse!
- Me: Dammit. I said, "KERBEROS!"
- Solarae: Mrfgk. Fine.
And if it looks anything remotely like a 7″ iPhone, I’ll eat my hat.
Cupertino Kremlinology
In preparation to try my hand at Apple prognostication, the standard disclaimers apply: I have no inside information, I am engaging in idle speculation, and I am fully prepared to eat my words. Okay. Let’s get started.
I’m not interested in what unreleased hardware will look like, since it’s safe to say anything designed by Apple will be simple and breathtakingly beautiful (as usual), and will solve the associated design challenges with kick-you-in-the-pants obviousness.* The interesting question I keep coming back to is whether a tablet device will run the iPhone OS, and by extension, run iPhone apps.
First of all, since the rumored tablet would presumably have more in common with an iPhone than your mom’s MacBook—multitouch screen, accelerometer—it’s safe to say it would not be running Mac OS X. Apple has already created a mobile version of OS X—the iPhone OS. Furthermore, it’s clear that Apple has designed Cocoa Touch from the beginning to have enough headroom to grow into a device with a larger screen. (Which might explain why the SDK took so long.) Evidence of this includes the UIWindow class, which exists even though iPhone applications display only one window. I bet Cocoa Touch on the tablet will allow multi-windowed applications.
I would also wager that the device would be able to run existing iPhone apps without any trouble. I’m almost positive, however, that they won’t run full screen. App developers have spent too much time optimizing their UIs so widgets are relatively finger-sized. The interfaces simply won’t scale without usability problems.
Given that size is less of a constraint in a tablet device, I expect the hardware to be powerful enough to support multitasking. This, combined with the presumption that the tablet would run iPhone apps at their native size presents an interesting UI possibility. I envision a dashboard-like layer where a limited number iPhone apps run as widgets on the tablet.
Picture this: iPhone apps launch on a translucent layer where a pair of widgets run side-by-side on the screen. A simple swipe will switch between pages of running apps that don’t fit on the first screen—just like having multiple pages open in Mobile Safari. Capping the number of simultaneously running apps is as simple as limiting the number of pages in the widget layer.
Apple would be crazy to launch a device without the momentum of the App Store behind it, and the only way hit the ground running would be to let existing iPhone apps run on a tablet. In the end though, Apple has spent far more time thinking about these problems and refining the solutions than all of the armchair product-designers and rumormongers combined. I may be wildly off predicting the app switcher, but it’s a fairly safe bet that whatever we see next Wednesday will blow us away.
* I won’t speculate on text input other than saying that I don’t expect to see Inkwell, Mac OS X’s pen input software, anywhere near this thing. Considering there’s no page dedicated to Inkwell on Apple’s website, it’s easy to guess how Jobs feels about this technology.
There’s a Price for That
Wolfram Alpha, the hilariously useless search tool, has an API. What sets it apart from Google, aside from choking on input every once in a while, is that Alpha’s API costs money.
You can get your first 1,000 requests for as little1 as $60 a month! It’s only eight cents per additional request beyond that! But wait! There’s more!
If you’re a “student, hobbyist, or individual developer,” 25,000 requests will set you back $1,200. (Seriously folks, that’s $0.05 for every search.) If you’re a small or medium business, though, you’d better be ready to part with two grand for the same level of access ($0.08 per request). Never has market segmentation been so blatant. They also don’t tell you how to get your nickel back if the query was a dud.2
Somehow I don’t think an API that has more in common with a casino slot machine than a scientific research tool is going to take off.
The pricing model I’m excited about is 280 North’s Atlas beta program. Here’s a slick web app for building slick web apps, and they’re not afraid to charge for a beta. No one has the balls to charge for beta these days, but these guys decided that $20 is a perfectly reasonable price to pay to test drive an online Interface Builder. And it is resasonable—reasonable enough that I wish I had a good reason to try it out.
I’m glad people are starting to move away from the broken economies of the ad-supported web. Both companies understand that in more and more cases, successful web ventures need to charge in order to be profitable. The trick, however, is to have something people are willing to pay for.
Verizon Expects You to Bend Over and Take It
I bet you still can’t wait to drop AT&T, citing reasons such as “lousy coverage,” or “slow downloads”, or “screw you, Ma Bell.” But you know what? These decisions are all trade-offs. There’s no magical carrier that offers excellent coverage everywhere you need it, and supports your favorite phone, and offers reasonable pricing. You make a choice based on which network meets most of your requirements.
Of course the recently publicized news about Verizon’s charging for accidental data use shouldn’t come as a surprise to anyone. In fact, I’m surprised that there isn’t news about more wireless providers employing the same tactics. [UPDATE: Seems like AT&T does the same thing. As an iPhone customer, I wouldn’t have noticed.] It’s well established that carriers charge a 4900% markup on text-message costs. Until there was a huge public outcry, every carrier regularly ate up an additional fifteen seconds of your voice minutes with redundant voicemail instructions.
We know the carriers are money-grabbing robber barons that treat customers with hostility and contempt. Stop whining about wanting to switch to the carrier that supports the right handset or has the best coverage. Voting with your wallet in this case is pointless because some greedy carrier is going to have their hand in it no matter what. The carriers won’t change for anything short of a revolution.
Half a Be
or, the sad truth of the eternal present tense.
Now that we’ve all either upgraded to Snowy Leopard or are patiently awaiting Windows 7, let’s extend a moment of silence for the operating systems that didn’t make it.
Inciting text for hopeful developers can still be found in the Amazon.com review of Programming the Be Operating System. While the review carefully—and, in retrospect, with good reason—avoids any claims of longevity, it makes no frivolous assertion of the powerful features of Be’s erstwhile chef-d’œuvre:
There’s not yet a big market for creators of programs that run under the Be operating system1, but its special capabilities may prove irresistible to experiment-minded programmers.
In 2001, Be, Inc. dissolved—it ceased to Be—but Amazon’s rosy marketing prose continues to remind us of good things long gone. Indeed, certain parts of the OS still have no equivalent in today’s systems. I studied their file system in great detail because it was so far ahead of its time. But the Internet does strange things to radical ideas. Some creations are buried and long forgotten because they are too novel, only to resurface when we’ve grown the capacity to comprehend their grandeur.
A Subversion filesystem has its data spread throughout various database tables in a fashion generally understood by only the Subversion developers themselves.
Why text messages are limited to 160 characters
Via marco:
Via Rocketboom:
Alone in a room in his home in Bonn, Germany, Friedhelm Hillebrand sat at his typewriter, tapping out random sentences and questions on a sheet of paper. As he went along, Hillebrand counted the number of letters, numbers, punctuation marks and spaces on the page. Each blurb ran on for a line or two and nearly always clocked in under 160 characters. That became Hillebrand’s magic number — and set the standard for one of today’s most popular forms of digital communication: text messaging. “This is perfectly sufficient,” he recalled thinking during that epiphany of 1985, when he was 45 years old. “Perfectly sufficient.”
While that’s a cute story that makes for a good article, it sounds like the real reason for the 160-character limit was more because the data channel’s packets had 128 bytes available for this sort of use and they restricted the character set (to a subset of 7-bit ASCII, I believe)
While the story may feel apocryphal, or even embellished, the typewriter exercise was crucial usability testing. Had someone not taken the time to count the number of characters in hundreds of messages, engineers would have simply said, “we can fit 128 ASCII characters in 128 bytes. Simple. Done. Next.”
It is very much like one of Andy Hertzfeld’s stories of the development of the original Macintosh at folklore.org. Bill Atkinson was developing drawing routines for QuickDraw and thought the functions for rounded rectangles would be too computationally intensive for the CPU. Steve Jobs wouldn’t hear it, insisting that “rectangles with rounded corners are everywhere!” He pressed the matter, taking Atkinson for a walk around the block pointing out every rounded rectangle he saw. It turns out that when Atkinson wrote the code, he was able to optimize it to the point that rounded rectangles drew almost as quickly as plain ones.
The point of this aside is that usability very often requires creative engineering solutions. When a system has certain hard limits, the trivial implementation imposes those limits directly on the user. Any creative limit pushing has a big impact on a product’s ease-of-use.
Simple is hard. Easy is harder. Invisible is hardest.
— Jean-Louis Gassée (via brier via lkm)♥
