packing pixels for a new iPhone

in

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

in ,

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:

~/Library/Calendars

~/Library/Calendars

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

in

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.