This is based on last year’s equivalent, but much of that turned out not to be true, so I might as well repeat myself. Second time’s a charm, and all.
Sources of Inspiration
Mostly the same as before:
Its sister OS, OS X. Smartly, the two share a lot of the underlying architecture. iOS happens to have received some more modern frameworks first since they had a chance at a clean slate, but other than that, iOS has more of a mobile/”console” focus, and OS X is more of a traditional desktop OS.
Other mobile OSes; in particular:
Android, of course. One feature that comes to mind is allowing multiple users on Android tablets; a cynic might argue that this would be against Apple’s hardware business interests.
Windows Phone 8 / Windows 8 / Windows RT. Brief tangent: Phone 8, unless Phone 7, is NT-based, so while its UI looks much the same, its core is now much more similar to ‘regular’ Windows. Also, Windows RT is really just Windows 8 running on ARM instead of x86, with consequences like virtually zero Desktop apps being available.
Blackberry 10. Its one and only selling point: well-separated private/business spaces.
There’s more, like SailfishOS, Firefox OS, and so forth, but I don’t see much innovation coming from them.
iOS’s own jailbreak community.
Now, keeping in mind that I have virtually no personal experience with other mobile OSes, I do have plenty with Windows 8 (in various settings, including on a tablet), as well as with some of what I deem to be more interesting jailbreak tweaks.
Let’s start thusly: iOS 6 disappointed me. Part of it goes back to what I wrote last year:
With each successive release having been a little more mature than its predecessor, iOS 5 has perhaps reached roughly the point of satisfaction that 10.4 Tiger had: plenty of features, not all of which you’ll use every day, and some you wish it had. But unlike Tiger, you’re largely stuck with what the OS has to offer. Extensibility mechanisms are few and far between. Apple has shown no sign of willingness to change that, and each passing year proves them more right in their conviction that they won’t have to.
And yet, 10.5 Leopard felt like a much bigger (if somewhat controversial — glass Dock, anyone?) leap than iOS 6 did. It’s not that it made the experience worse (to me, Apple Maps worked okay from the start, though I’ve found Street View to be far more useful and far less glitchy than Flyover, which isn’t really available here anyhow); it’s that people are using iOS devices more and more, in the “post-PC” way Jobs predicted, and in various ways, the OS hasn’t grown to accommodate for that. Hence, like I said, a bit of a repeat of last year.
Inter-app Sharing Workflows
Various design choices make carrying a bit of information from one app to another fairly cumbersome: typically, only one app will be actively running in a multitasking sense; only one app will be visible; mechanisms like Springboard, the app switching bar and the Notification Center are less about temporarily interacting with an app than they are about switching to it and fully bringing it frontmost; and each app lives in its own sandbox, including file management, so accessing a file you’ve created in another app isn’t as easy you might expect either.
iOS does provide a means of opening applications with URL schemes, enabling several sharing workflows. 3.0 and 5.0, respectively, added APIs to show sheets for sending off e-mail messages or tweets, so you won’t have to leave the app at all. And 3.2 introduced support for an Open With feature. The main limitation with these is that (the middle one excepted) they’re “push”-type workflows: you’re sent from one app to another, and then never back. Rather, what you frequently want is to “pull” information from another app, returning to where you had left off afterwards. The original app lacks a means of getting any result.
For some cases, app developers have become inventive to work around this:
Writing Kit, a word processor, advertises its built-in browser and Quick Research abilities.
Many apps rely on Dropbox for sharing files with each other, effectively eschewing the local system entirely in favor of one whose API affords them more flexibility.
Some apps now have a “Launch 1Password” button on their login screen specifically to make password look-up less awkward.
Techniques like x-callback-url or Audiobus (even adopted by Apple’s own GarageBand) help.
But those aren’t desirable hacks, and many cases simply cannot be handled well at all. Tools such as 1Password and TextExpander come off as more cumbersome than their Mac counterparts through no fault of their own. Moreover, when integration is available, it is often limited to hardcoded, specific apps; you’d have a hard time launching a TextExpander competitor now simply because so many third-party apps have already been integrated with TextExpander itself in particular. You cannot, as an app, offer your services to other apps.
So, wanted: a means where app A (e.g., a word processor) can ask the OS for available apps of a type of service X (e.g.: text expansion), where app B in turn can register itself to offer just that, and where A can launch B with the special “bring me back my info when you’re done” parameter. Workflow-wise, it may make sense (and be less confusing to the user) to show the app’s relevant bits in a sheet; in particular, no navigation in the app’s UI should be possible.
Defaults
The built-in apps are hardly bad (unless you count Reminders, the UI of which clearly only happened in some nightmare of mine), but Apple won’t and shan’t try to cover all situations — they’ve made a conscious choice to make their apps simple, leaving plenty of room to allow third parties (or themselves, as in iPhoto vs. Aperture) to offer something more advanced. Some may prefer using the GMail web interface as their mail client, iCab as their browser, or Calvetica as their calendar. There’s APIs for accessing some or all of the same data, but there aren’t ones to set defaults. Most jarringly, opening a web link in some app will still launch Safari, unless the app happens to provide its own means of choosing a different browser.
This doesn’t affect me much, but one scenario where I recently saw this as a problem is wanting a locked-down browser for a kid without relying on Safari’s own rather limited Parental Controls, but rather by using a third-party browser that’s designed around kid use. Making that the default browser, and preventing app installation as well as launching of Safari itself through Parental Controls, ought to do the trick.
And if this capability were to arise, it would encourage third-party developers to build alternative apps we can’t even dream of yet.
Plug-Ins / Bundles
I know plug-ins go against Apple’s “everything is an app” grain that they’re apparently carrying over to the Mac as well, but they’ve already violated that principle in a few ways:
Apps can provide their own preferences that show up in the Settings app. This is effectively just a hierarchy of data, rather than a means to run code, so it’s limited (e.g., you wouldn’t be able to provide a button), but it is nonetheless arguably a form of hooking into the system.
iOS 4.1 added a VPN API, which to my knowledge is sadly still undocumented, but (by necessity) has code of yours running system-wide.
In addition to wanting an OpenVPN plug-in (sigh), there’s various obvious places where plug-ins would help:
You can already search for your app in Spotlight (and, to my knowledge it takes advantage of keywords developers can provide in the App Store, so searches don’t have to be exact matches), but being able to search its data (and to tap on an item to launch the app straight to that very item) would be great.
5.0’s Notification Center has two widgets for Weather and Stocks, which scream for extensibility, but alas, that currently requires a jailbreak. Here, too, the problem of default apps becomes clear: if you prefer a third-party weather or stocks app, tough.
A “Quick Look” of sorts — tapping an attachment in Mail works for some formats, but what if your app could provide viewers for additional ones?
Safari Extensions. Performance considerations aside, these should port just fine, so they can actually sync through iCloud.
Search
The silo nature of “files belong to an app” isn’t for everyone, but it’s presumably here to stay. One thing that should alleviate the pain is system-wide search (see above). OS X has had this since 10.4 (though it really didn’t start working well for me until much later); resource constraints (e.g., battery life) aside, this arriving in iOS is hopefully just a matter of time.
In a sense, this will be more useful than on the Mac, due to so many native apps being available: search for a name, and see phone calls with them, their Facebook, LinkedIn, whatever profiles, your e-mail exchanges, replies and direct messages via Twitter, games you’re playing with them, and appointments you have with them. Search for a genre, and get the Wikipedia article as well as the iTunes songs or movies, or the books in iBooks or Kindle. Search for a subject, and get e-mails, articles, even news.
While the phone app got some nice improvements in iOS 6, such as being able to set a call-back reminder or send a predefined text message response, it’s mostly the way it’s been since 1.0. It feels, perhaps to evoke familiarity, too much like a 90s’ era telephone brought to a touchscreen UI, ignoring technologies and capabilities like the Internet. It doesn’t even integrate with VoIP (though third-party apps have some limited hook-in abilitiy, such as being able to run in the background).
Eevn without a long-needed overhaul, though, there are improvements one could wish for:
Better look-up of unknown numbers. Apparently, US versions of the iPhone can at least resolve the area code to give you a rough idea of who it might be; this doesn’t seem to work in Germany. In addition to area code look-up, it could also try and perform a Google search. In the case of businesses, this may often be enough to provide a best guess approximation.
There’s various smaller stuff — Mail ought to have OS X Mail’s better threading and junk filtering support; important toggles like Airplane Mode require far too many taps; Settings has gotten far too nested (maybe add a search field?).
You’ll also note that I skipped the current prevalent discussion entirely; that of 7 supposedly featuring a Jony Ive-inspired flatter UI. There’s not much for me to add to that discussion, really. Lastly, the discussion of whether Apple should add a Gatekeeper-like “allow me to run non-Store applications” switch is complex enough to warrant a separate post.
I think it’s a terrific OS. Let’s make it even better.
I assume they really mean “firmware updates” or “OS updates” or something.
What is being updated? Is there new stuff? Fixed bugs? Security?
It took iOS far too long to get OTA updates, and it’s high time Android gets them, too.
“Any data not saved on a micro SD card or PC may be erased; i.e. contacts, images, etc.” Pre-iOS 5, updates were sort-of-reinstalls, too, but at least there was a built-in update facility. This reads like it doesn’t even offer that.
One obvious, low-effort way to make the list of steps far less absurdly long is to merge the “United Mobile Driver” and “Mobile Support Tool” into one download (namely, the latter), and have it automatically “Ensure your Driver is Up to Date”, rather than having the user check something far easier for the computer to figure out.
I’d love to see, one year in, statistics on how many people bothered to even attempt this. The process looks sufficiently intricate and technical that I wonder if the average user will even bother (will they even know about the option?).
I was on an airplane, and there was high-speed Internet on it. That’s the newest thing that I know exists. And I’m sitting on the plan and they go “Open up your laptop; you can go on the Internet”. It’s fast, and I’m watching YouTube clips; I’m in an airplane! …and then it breaks down. And they apologize: “the Internet’s not working”.
The guy next to me goes: “Pfft, this is bullshit.”
Like, how quickly the world owes him something he knew existed only ten seconds ago.
What may have seemed over the top in Louis’s skit seems a lot more real now.
Regardless of how you feel about app stores, software repositories / package managers, stealth background updating, there’s no question the process of discovering software, keeping it up-to-date, and disposing of it if need be leaves much to be desired on most platforms.
Dependency tracking, for example, is great when it works, but frustrating if not impossible to deal with for mere mortals when it doesn’t. A central my-way-or-the-highway authority, as epitomized by Apple’s App Store1, leads to high quality (except when it doesn’t), but may also keep out programs you would have been interested in. Tools like Adobe ARM, Google Omaha and soon Mozilla’s equivalent constantly take up resources, open potential security issues of their own, and may make decisions against your will (what if you preferred the old version?), yet possibly still in your interest (what if you would have overlooked that security patch?).
A whole book could be written about this mess. It’s a situation where Desktop Linux feels, at least superficially, way ahead, and Windows dead last. To add insult to the injury of having to manually find and update software on Windows, it’s also the most likely OS where you might wnid up downloading something malicious.
However, that’s not the problem I had. I know, for the most part, which additional software on top of the OS itself and my own stuff I care about. However, I don’t necessarily know (and I certainly don’t care to keep track) whether each of those apps is installed and current on all machines I happen to be responsible for. That problem is irrelevant for most — why would you have more than one, or at most two (a desktop and a laptop), machines?
But perhaps you, like me, also take care of other machines — in my case, colleagues’ workstations, in-house servers, and servers at a remote data center. Plus, of course, all those virtual machines. In that case, you may be quick to say “well, why don’t you just use Active Directory, group policies and IntelliMirror to deploy the newest stuff”. I could, and I do, but it’s a pain, and it doesn’t really help at all for the fourth category: machines that aren’t local.
And did I mention it’s a pain? It’s not just Adobe who keep reinventing how Windows Installer is supposed to work; Microsoft themselves seem quite confused on the concept, too. Try deploying .NET Framework 4 via group policy, as a pure, single, simple .msi file (batch scripts are cheating). Or try keeping Adobe Flash Player up-to-date. Or, really, close your eyes, spin a giant wheel-o’-apps, point at one at random, and then figure out how to deploy it. This technology came 11 years ago with Windows 2000, and while it may save time in large organizations when granular control of who gets what matters, it simply doesn’t work well on a smaller scale.
Let’s scrap the idea of central deployment and instead get back to considering each machine individually.
What if we could have a Linux-style package manager in Windows? There are a few, actually. One, NuGet, has been generating some buzz lately, but is focused entirely on extending Visual Studio with libraries you want to use. Not what we’re looking for. With Raktajino-Packagemanager, we’re getting warmer; this one, however, is meant to be used for servers. I stumbled upon it because it was pre-installed on a machine from a hosting provider; perhaps it was written by an employee of theirs.
Npackd comes very close. By Linux standards, it’s rather limited: you can set a path prefix for all installed packages, and add additional repository sources. Packages can depend on each other, but there’s no customizing a package before installing it.
I’ve been using this for a week or so on my regular work VM, and have been 1) extending the somewhat limited selection using my own repository, and 2) pondering to what extend I could use this, at the very least, for that fourth category: servers. The default repository already comes with vital tools such as Process Explorer, for which I had previously used a batch file to keep it current; now, no more need for that.
A few issues are in the way:
This may be a question of lacking maturity, but I would have expected its otherwise conceptually sound repository format to handle standard cases like “here’s a http URL pointing at a .msi file — figure out how to install/uninstall it automatically” well. Rather, most packages seems to have some odd wrapper code.
For some packages like CCleaner, the default install it uses is unacceptable. It installs some Bing Toolbar or whatever. It could come bundle with the world’s best additional software, and I still wouldn’t care because I didn’t ask for it, it’s from an untrusted third-party, and I never explicitly opted in to trust it to do that. Worse, with each update, those defaults are reset. So, for such packages, even though it offers them, Npackd is absolutely not an option. I suppose it’s possible that modifying the package to remove the option by default would violate the license, which really wouldn’t help CCleaner’s case.2 On a related matter, I’m not sure how to handle an install like WinSSHD’s. What if you have a commercial license with serial number? Would each upgrade remove this?
What is touted as “multiple program versions can be installed side-by-side” is really an anti-feature for my needs (your mileage may vary). It works by placing each version in its own directory. I’m really not sure how much of an advantage this is in practice, given that it’s no real sandboxing — multiple versions presumably still share the same registry keys, and the same user application data. But in my case, it’s a major detriment: I have scripts that access 7-zip from the command-line, hard-coded to find its path. AnkhSVN, a Subversion add-in for Visual Studio has various hard-coded paths to diff and merge tools, such as WinMerge. Both 7-zip and WinMerge are provided by Npackd’s default repository, but even if I manually tell the scripts and AnkhSVN where to find them, I cannot rely on its update mechanism, because that will break paths each time. I can see the appeal, but in its current state, I wish the whole mechanism were optional. Better yet, it should allow for smooth “point to latest version” linking. With WinMerge, I’ve set up a junction point3, which makes AnkhSVN succeed to “discover” it once more, but this will break with the next upgrade. I can’t even seem to write a tool that automatically generates junctions, though, because the directory structure is not consistent across packages. Setting a PATH is also not much of an option, it appears. This goes back to my point above about the wrapper code; Npackd ought to not let it up to package maintainers where individual files are placed.
Some minor issues mostly related to batch processing:
There’s no option to install multiple packages at a time,
…nor to export a selection of packages and import that to another machine (much less synchronize such lists),
…nor to update everything that’s out of date, rather than just individual packages,
…and lastly, aside from a pony, I’d also like a Windows Service to keep packages up-to-date without any user intervention (or admin privileges).
Ignoring the troubling side-by-side feature for a moment, I’d consider Npackd a net gain. There’s a command-line tool I haven’t played much with as of yet, and that may well be enough to let me accomplish the above four. Find a selection of packages, write a batch script, and push it to multiple servers.
Steve Jobs, the pioneer of the computer as a jail made cool, designed to sever fools from their freedom, has died.
As Chicago Mayor Harold Washington said of the corrupt former Mayor Daley, “I’m not glad he’s dead, but I’m glad he’s gone.” Nobody deserves to have to die - not Jobs, not Mr. Bill, not even people guilty of bigger evils than theirs. But we all deserve the end of Jobs’ malign influence on people’s computing.
Unfortunately, that influence continues despite his absence. We can only hope his successors, as they attempt to carry on his legacy, will be less effective.
Stallman is sober proof that idealism can be taken too far.
I agree, but there’s more to it than that. Jobs was an idealist, too; it’s just that the two have very different ideals. Design and freedom. They don’t contrast, but they do conflict. Give someone free reign, and they may be more inclined to do what they want. Ask someone to design something, and restraint and limitation — antitheses of freedom — are likely part of the result.
Stallman’s social interactions famously tend to be strange, if not distasteful, and there may or may not be medical explanations for that. At some point, however, you have to realize that putting differences aside and giving someone their final peace isn’t just an expected gesture of society; it’s a smart one.
They have been a part of my life for decades. Even when I worked for 15 years for Bill Gates at Microsoft, I had a huge admiration for Steve and what Apple had produced.
But in the end, when I think about leadership, passion and attention to detail, I think back to the call I received from Steve Jobs on a Sunday morning in January. It was a lesson I’ll never forget. CEOs should care about details. Even shades of yellow. On a Sunday.
To one of the greatest leaders I’ve ever met, my prayers and hopes are with you Steve.
Robo makes the point that Jobs’-return-era Apple starts off product lines in an experimental, prone-to-radical-changes manner, then eventually goes to refine it and iterate more subtly from there:
There's another Apple product pattern. It's been around longer, and it's longer-term. That pattern is this: Apple (and by "Apple" I mean "after-Jobs-came-back Apple") enters a new market, or makes an-after-Jobs-came-back model of an existing product for the first time, and we start counting there. The first few product generations tend to be more experimental, and very different from each other, but eventually Apple finds what works and they stick with it, and the design changes become much more subtle refinements.
The iBook and PowerBook G3 hit this point comparatively early — they both had curvy initial models, but with the PowerBook G4 and iBook they found what worked, and they spend the next decade refining their squared-off metal and plastic notebooks. Nowhere was the "early experimentation" phase more evident than with the iMac. The iMac G3 and G4 and G5 were wildly different from each other, but by the time we got to the G5 that phase has ended and the "where did the computer go" iMac stuck around for the next seven years and counting, getting nips and tucks more than ground-up rethinkings.
The iPod (classic) took four generations. Apple went from a mechanical scroll wheel to a touch-sensitive scroll wheel to a model with the buttons all in a row under the screen, but by the time they got to the click wheel they had it. They added a color screen and video playback and a metal front, but the iPod classic is still largely the same concept seven years later (again, and counting). It's, well, classic.
I think, with the fifth model, the iPhone has (coincidentally, or not?) ended its G3-G4-G5 phase. The potential shapes of the iPhone are more limited than that of the iMac, so the experimentation phase wasn't as crazy as the iMac's, but I'd still consider the weirdly plastic 3G/3GS the oddball iMac G4 of the range. :D I think the iPhone 4's antennae design was a watershed moment, analogous to the PowerBook G4 Titanium, and I think Apple will stick with it, and refining it. They'll make it a tad thinner, or narrower. But I think the multi-piece, squared-off, antennas-on-the-outside design is here to stay for the foreseeable future. They're not going to suddenly switch to a two-piece, curved-at-the-edges, iPod/iPad-style design — except maybe as a new low-end, prepaid-targeting model that would take over for the (two-piece, curved-at-the-edges) iPhone *3GS*.
All very true.
The 3G/3GS design felt like a desperate attempt to massively improve reception over the metal cage issues with the original, far more attractive iPhone. The 4 (and now 4S), then, came up with a superior compromise between thinness, sturdiness, battery life and reception. I don’t think anyone near Steve suggested “let’s eschwer the classy aluminum back with a glossy plastic one, for that will be cheaper“1. It was about reception.
But there are several things with the iPhone that never did change. They got those right (or, rather, they saw the results they had been hoping for) on first attempt. The layout, for instance: with the exceptions of additions like a flash and front-side camera, and the replacement of the volume rocker with two distinct buttons, everything has remained virtually the same. Dock connector at the bottom, a speaker each to its sides, silent switch and volume buttons on the top left, headphones out (with bizarre limitations on the original iPhone) at the top left, lock button at the top right, camera at the back’s top right, and, of course, earpiece (and front camera, where applicable), screen and Home button, in that order, on the front. It’s iconic, and as far as Apple is concerned, is just right.
Not much experimentation going on there. They sure prepared well.
And not only has the placement remained virtually the same: so, too, have the dimensions. It’s always been 4.5 inches tall. It’s lost some width: originally at 2.4 inches, the 4 and 4S models went down to 2.31. And, par for the course with “thinnovating” Apple, it’s lost depth as well; from 0.46 to 0.48 (3G and 3GS) to eventually 0.37 (4 and 4S) inches. These changes are relevant for case manufacturers2, but — having to pick a compatible case aside — hardly for the user.
What’s changed even less is the screen. Its quality may have changed, but its size of 3.5 inches never did. Only its resolution has famously been doubled3 to enable the marketing term “Retina Display”, going from 480x320 to 960x640. At 3.5 inches, that’s 163ppi, or now 326ppi. That’s a lot of density.
The resolution change worked because, in legacy apps, you simply treat each pixel as a 2x2 grid of pixels, and it’ll look just as it would have on an older iPhone. In newer apps, you use higher-resolution pictures. For vector art and fonts, you get those changes for free. The frameworks pretty much do it all for you, perhaps at first often resulting in a mix of original-resolution and double-resolution. And developers were quick to supply higher-resolution artwork.
Consider a different resolution change: to show 720p movies while maintaining the 3:2 aspect ratio, they could bump the resolution further up to 1080x720. What would happen with existing graphics? If you scale them up, their pixels cannot be easily matched; a 2.25x2.25 grid could, at best, be interpolated with anti-aliasing. Jagged lines, or blurry overall image. Anything vector-based, including text, would once again be exempt, but it would still make for a terrible experience. And this time, developers likely wouldn’t be as quick to adjust: for one, the iOS platform has reached more saturation, where updates just aren’t as necessary any more, and also, Apple would leave the impression that they’re going to keep changing the resolution whenever they feel like it.
What of a screen size change, though?
This has come up not because there’s indication that Apple plans to change it. Nor has there been user feedback that I know of that says “I love my iPhone; if only its screen were bigger!”.
It has become a topic because of the competition. Neither Windows Phone (which hasn’t been shy to establish a high minimum requirements) nor Android appear to specific a minimum screen size, much less one that exceeds the iPhone’s 3.5 inches. An increasing number do exceed it, however. If there is an explanation of “this size works better for the user, because:”, I haven’t seen it. Rather, my money is on Marco’s speculation:
Android phones have been one-upping each other with screen size a lot recently. It’s an interesting tactic that seems to be working, at least relative to other Android phones. When comparing phones side-by-side in a store, the larger screens really do look more appealing, and I bet a lot of people don’t consider the practical downsides.
And, as a corrolary:
[People accustomed to large-screened Android phones] may view the [iPhone’s] smaller screen as a downgrade.
When, as a manufacturer, you have two major operating systems to choose from, and the device becomes mostly a commodity, reducing your product to ‘bigger is better’ is almost inevitable. (Unless you’re actually creative.) It happened with 90s’-era PCs and MHz numbers; it happened with 00s’-era cameras and Megapixel numbers; it’s happening with 10s’-era smartphones and, apparently, screen size.4
An angle to consider here is that manufacturers may not even realize the weirdness of changing the screen size. Apple appears to treat it as a constant, rather than a number of a spec sheet (though, to be fair, it’s exactly that on their Specs page). PCs surely kept increasing their typical screen sizes for quite a while. The Mac (1984) shipped with a 9-inch display. The LC, my first Mac (1992), had a 12-inch one. The first iMac (1998) had 15 inches. And just last week, we were discussing whether to get 22- or 24-inch displays. An iMac can now (since 2009) be had with a 27-inch display, and while that seems almost obscenely large to me, it’s clearly appealing to some.
Screen resolutions, too, increased. 512x342. 512x384. 1024x768. 1920x1200. 2560x1440. And so, too, did the amount of space in our GUI. Mac OS’s menu bar height has never changed much5, but what used to be 5.8% of your room to work with is now, on the biggest iMac, a mere 1.5%. Similarly, while icons have gone from 32x32 to 48x48 in some places (such as Windows Explorer’s default icon view, starting with XP), the resolution has increased greatly; the area an icon takes up has changed from 0.6% to a tenth of that. Andstudies link such increased space with enhanced productivity.
But when Apple chose to ship the original iPhone with a 3.5-inch screen, did they do so because 3.6 inches would have been prohibitively expensive? I find that hard to believe. My explanation has always been one of practicality.
[I]t turns out that when you hold the iPhone in your left hand and articulate your thumb, you can reach almost exactly to the other side of the screen.
There’s a lot of things I can’t do with just one thumb on the iPhone: type several words of texts, do pinch-to-zoom or other multi-touch gestures, or precisely move objects around.
And yet, so much can be done just like that, in the tram, standing, the other hand gripping a pole: skipping to the next track in iPod, swiping through the list of unread e-mails, picking one, scrolling down and — if important — moving it to a different folder, and even simple search queries in Google. I bet the people mocking the Mac for shipping with a single-button mice didn’t see single-thumb-operating a telephone to listen to music, read messages and look up stuff on Wikipedia coming.
A bigger screen would take away this possibility. As illustrated by Dustin Curtis, you can barely reach the center of a 4.21-inch screen. It eschews simple for forcedly immersive. It makes you deal with the device, all of a sudden.
For humor’s sake, though, let’s consider the two ways a screen size change can occur.
One way would be to keep the resolution as-is, and simply make elements bigger. This assumes preserving the unusual 3:2 aspect ratio, and square pixels6. According to Apple:
The comfortable minimum size of tappable UI elements is 44 x 44 points.
Below, you can play with a few different screen sizes (in Safari 5.1 and Chrome 14, anyway), and see the effect on pixel density and, consequentially, individual pixel size.
(I can’t calculate, by the way. According to Apple, the pixel density should be 326ppi, not 330. And according to various sources, the physical size should be 6.9mm, not 9.6. While the former could be explained by the iPhone’s screen not being exactly3.5 inches diagonally, the latter discrepancy baffles me.)
This approach makes pixels larger again, somewhat negating the benefits of the Retina Display, although we’d have to go all the way to 7 inches to approach the original iPhone’s 163ppi. Advantageously, it makes the display more accessible to those with poor eyesight, and makes controls easier to interact with to those with large hands. As far as detriments go, it’s less likely to fit in your pocket, and a single hand of yours is less likely to, as explained above, reach controls edge-to-edge.
A case could be made, then, that Apple should offer this as an option. There’s precedent: one revision after the 12.1-inch white iBook design was introduced in May 2001, they added, in January 2011, a 14.1-inch option at the top end with nearly identical specs, a bigger screen at the same resolution (1024x768), and a higher price tag. This carried on until May 2006, when both screen variants were replaced by the 13.3-inch, 1280x800 MacBook.
But I’ll believe it when I see it.
Changing the resolution
Instead, let’s discuss changing the resolution. John Gruber’s latest seems to focus entirely and implicitly on maintaining the resolution, which strikes me as a Strawman:
If anything [bigger screens are] surely easier to make, as the pixels are less dense.
Changing the resolution opens up new possibilities. We’ve seen this first-hand with the iPad: it being 9.7 inches, and being 1024x768, has arguably led to entire new classes of programs. So far, though, all evidence points to in-between devices being unpopular: neither 5-inch ones such as the Dell Streak nor 7-inch ones such as the Galaxy Tab have enjoyed anywhere near the same success as the ~3-4-inch and 10-inch form factors. They’re neither here nor there.
Perhaps a slight tweak in that direction would work, though? Let’s keep the pixel density (and aspect ratio), rather than the resolution, the same this time.
At around 4.5 inches, we can already display the equivalent of a typical 13-inch laptop screen. Slightly above that, at 4.7 inches, we can display the full 720p resolution of 1280x720.
For existing apps, changing the resolution presents us with challenges. Unlike with a desktop environment, the iOS UI is designed around a single-window/full-screen approach. At most, you have a status bar at the top; other than that, everything on the screen is controlled by the current app.
For games, this has long been common. Making a game full-screen is a common choice if only to provide an immersive experience. You can run Tetris and Sudoku in a window (I frequently do), and perhaps even a casual round of Portal, but for most games, it wouldn’t work well. For other kinds of programs, however, the assumption used to be that, given a certain amount of screen estate, the benefits of seeing multiple stacked and/or tiled windows outweigh those of coherence.
The iPad is unusual in that it provides what used to be a common resolution of laptops just half a decade ago, and of desktops half a decade before that, yet limit this to just one window. Palm webOS, BlackBerry PlayBook’s Tablet OS, and soon Windows 8 follow this approach, whereas Android Honeycomb 3.0 disagrees with it, allowing multiple “fragments” to co-exist. But even if Apple were to increase the screen size and (proportionally) resolution, it wouldn’t diverge sufficiently for such an environment to work well. And after all, they’ve already made this design choice, towards the other direction, with the iPad.
That leaves us with two other ways for an increased resolution to work: expanding the status bar, and giving the current application (which, in the context of iOS, might as well be synonymous with current window) more room to work with.
In fact, much like the Mac OS menu bar, the status bar would grow automatically. Even if the height were to remain the same, more width would allow for an increased amount of icons, or perhaps more text, such as the date in addition to the time. While jailbreaking tends to go overboard, it does provide some inspiration of what could be done: icons for new mail, the weather, or unread notifications. An iOS status bar icon takes up 16x16px, plus a few pixels for padding. Since each 0.1 inches of screen size nets us about 27.5 more pixels, that means even one such bump would give us an additional icon. Not bad. This is all assuming a portrait orientation; the landscape orientation already has far more space regardless.
You could also grow the status bar vertically, but I see neither the pressing need nor a practical approach. Increasing the icon size seems unnecessary. Adding a second row adds visual complexity. Right now, the information density and quantity seems close to just right, and growing it horizontally would help with the latter.
In-app layout
Lastly, the application itself. This appears easy in some cases: just give Safari a larger viewport, and perhaps a sixth toolbar icon. Just give Mail additional e-mail summaries, more text rows, and, too, a sixth toolbar icon. Embiggen iPod’s album art, and take another of the toolbar buttons offered in “More”.
Not so fast.
Much as we’d like to believe technology is perfect7, Cocoa Touch does not in fact have anything approaching a flexible layout manager, where you tell it “have a navigation bar with a fixed height at the top, a table with just however many rows will fit underneath, and finally a fixed-height toolbar at the bottom” and have an iOS-typical navigation/table view/toolbar UI. Elements are largely positioned by the pixel (though, in the case of the Retina Display, a distinction of “device pixels” is made, so you generally don’t have to worry about that), and entirely differently for the iPad. This can be tedious, but leads to a pixel-perfectly-designed result. There’s a concept of “springs and struts”, which allow for some flexibility, but by and large, positioning is fixed.
By contrast, some UI toolkits favor a more automated approach. They tend to deal in percentages and multipliers, not pixels; in relative, not absolute positioning; in an automatic flow, where whichever control comes next is positioned after the current one. This may not always lead to exactly what has been intended, but has lots of advantages, such as localization: a lot of software is written in English first, then translated to others. English words, however, tend to be relatively compared to other languages’ equivalents. The layout may have fit exactly for the words ‘tram stop’, but ‘Straßenbahnhaltestelle’ doesn’t just sound much wordier and take up more syllables; it also clearly takes up more space.
Apple hasn’t ignored this problem, and in 10.7 Lion, has introduced Autolayout. (See where I stole that word example from?) However, its release notes call it “not finished yet”, and it won’t be available in iOS 5.0’s SDK (yet).
It is quite likely that a future iOS SDK — perhaps 6.0’s — will include this, and it will allow for more scalable UIs. In some cases, it may eliminate the need for iPhone/iPod touch and iPad UIs to differ at all, but I remain skeptical of this. Developing with each individual device in mind — custom-tailoring for it, if you will — should ultimately benefit the user more than having something rapidly available everywhere. It would still be leaps and bounds better than the almost pointless letterboxing / scaling ability of the iPad to run iPhone applications (there’s a reason you almost never hear of it), though, and, perhaps, if cleverly combined with fixed elements, may lead to a richer and faster-to-develop experience for everyone.
Even then, however, many current applications would require significant changes to take advantage, and otherwise once more will suffer letterboxing or scaling. One makes for very awkward, sort-of-Fitts’s Law-violating user interaction. The other, which unlike with the iPad cannot be done in a grid of two-by-two pixels8, would look and feel ugly.
One answer to “why do Android phones keep bumping up their screen size, when iOS doesn’t?” may be, as posited by some, a contest to out-spec each other. Another may be: because they can. Right now, iOS can’t, and as the library of apps grows, which it rapidly has, the longer they wait, the less likely such a change becomes.
Or if they did, they were probably looking for a different job afterwards.↖
Who I assume are currently scrambling to regain money lost on the alleged iPhone 5 design that never was.↖
Technically, quadrupled, depending on whether you count each dimension.↖
To computer afficionados at large, probably the greatest vaporware of the past decade (if not of all time1) was Duke Nukem Forever. There’s an amusing list of things that happened between DNF’s original announcement and what appeared to be its final nail in the coffin twelve years later, with items like:
Steve Jobs was still running NeXT when Duke Nukem Forever was announced.
Every movie, animation, and video game from The Matrix series was filmed, released in theatres, and has made it to DVD.
Britney Spears’ entire musical career as a pop star has taken place during Duke Nukem Forever’s development.
World War II and the entire Manhattan Project have taken less time than Duke Nukem Forever’s Development. Yes, even the complete development of the atomic bomb took less time.
Now, as we all know, DNF did end up getting released, two further years later, and was critically panned. I haven’t played it myself, but the consensus appears to be that it would have been a so-so game had it been released in a remotely sane cycle; all the build-up and hype, however, weren’t remotely justified.
But it’s not for lack of trying. If anything, Wired’s article gives the impression that DNF’s original producer Broussard was apparently trying to hard. That article, too, prematurely pronounced DNF dead. Perhaps everyone would have been better off?
To Mac users, or at least Mac developers, a less crass example of vaporware is TextMate 2. It is, as Marco Arment said, a textbook example of the second-system effect. It tries to fix too many perceived flaws — and perhaps perceived mainly by its developer, not by its users — of the original TextMate, and in doing so fails to see the light the day. Or at least has. Thus far.
Hard to believe as it may be, there’s been a mailing list post that we’re not supposed to link to (which may be moot now?), and, a few days later, a blog post without such a disclaimer.
There will be a public alpha release [of TextMate 2.0] this year, before Christmas, for registered users.
If it were me, I’d publish such a vague, yet limited deadline to force myself to actually have something to show at that point. An alpha doesn’t have to be a whole lot; it doesn’t need to be feature-complete, it certainly doesn’t need to be stable, and even more so, it will probably come with no liability in terms of data loss whatsoever. And yet, it’s something. Maybe just enough to get people excited again. Consider that, at some point, it was controversial that 2.0 will require Leopard. These days, almost half a decade later, I wonder how many even use TextMate on anything older than 10.6 Snow Leopard, let alone 10.5 Leopard.
It’s not so much that TextMate 1 doesn’t work. It does have its flaws, though. No split view, undo being per-character, and synchronous I/O easily locking up everything and making remote-editing of files not worth trying come to mind.
So, as far as I’m concerned, I’ll go with the “cautious optimism” from another troubled software project. (I’ll leave it up to others to argue how that turned out.)
One Ben Cooksley, KDE System Settings Maintaineris not amused that GNOME now has an application called System Settings as well, and has launched a “formal complaint”:
As you may or may not be aware, the name “System Settings” for an application is currently in use by KDE. A recent renaming by your GNOME control center developers to this name creates a naming conflict.
[..]
As KDE occupied this name first, it is ours as a result [..]
Someone explain to me how this is any better than Apple holding a trademark on “app store”.
Someone from Ubuntu then goes into more detail about these alleged “severe problems for users”; “numerous problems for users on both sides”:
To be more specific about the problem, installing kde-workspace to a GNOME installation results in 2 indistinguishable apps named System Settings and 2 named System Monitor. On Ubuntu at least, if I want the GNOME version, I have to remember to click the first System Monitor but the second System Setting which is awfully frustrating.
You’re installing two desktop managers side-by-side, and your biggest problem is that two applications (with the same purpose1) bear the same name?
This thread also delivers on the predictable, usual debate over just what constitutes an operating system:
So far we are running the same OS (for most of us it is Linux, but it can be Solaris or *BSD). DE != OS.
Yes, I’m sure drawing that distinction (whatever it may be: Linux, contrary to this quote, is a kernel, not an OS) makes users feel right at home.
I very much doubt users will be any less confused when confronted with “System Settings” and “System Preferences”. We should work on shared groundwork so that our settings are interoperable. If a user has to set his language in two different applications just because he happens to use applications written in two different toolkits, we have failed miserably.
[..]
You just can’t expect to own generic names across desktops.
Granted: GNOME’s “System Settings” and KDE’s are each likely to focus on their own respective perspective, but from a user’s point of view, these differences are entirely technical, and should neither exist nor matter.↖
I’d like to propose introducing a special keyword, en(n+)d. Using this keyword, we can rewrite the above example like this:
module MyModule
class MyClass
def my_method
10.times do
if rand < 0.5
p :small
ennnnnd
I.e., for each block1 to close, insert another n within end.
It’s so crazy, it almost makes sense. Per Tay, perhaps the best argument again this:
Yeah, I don’t like this change. Mostly because that huge chain of ends is supposed to look ugly; it reminds me that my code is far too nested, and should be reworked and written properly.
I’d prefer bad code to look ugly.
Hiding bad code doesn’t make it go away. (Huge try/catch blocks, anyone?)
Indeed; there are likely plenty of PHP developers who would panic if their precious MySQL extension were to be deprecated. But how many more would rejoice?
It doesn’t even understand the notion of prepared statements1, so even if it weren’t for the scores of my-first-database-bound website tutorials that inevitably lead you to SQL injection hell, you’d have little choice. You’d have the choice of mysql_real_escape_string and brethren, but that’s a terrible idea.
A language may not always be able to enforce good practices, but it should at least advocate them. Leaving an API in that requires bad practices is irresponsible.
If it weren’t for the inevitable hand fatigue and inpracticality of playing on the tram, this would be perfect:
Arthur Nishimoto is a graduate student in the University of Illinois at Chicago’s Electronic Visualization Laboratory, who developed a real-time strategy game to be played on a wall-size LCD screen.
Unfortunately Sony missed the entire point of a CAPTCHA. Instead of using an obfuscated image which is difficult for computers to recognize the characters, they include the CAPTCHA’s unobfuscated characters in HTML and use CSS and JavaScript to make the characters appear slightly distorted.
It wouldn’t even have been that hard to come up with compelling and honest argument for Web apps (e.g.: always up-to-date, run on multiple platforms, no installation required). Instead, they come up with ones that apply equally (loading times? “peak times”? If anything, those apply less to a locally installed app), and ones that are just downright bizarre, unlikely scare scenarios (“reload if device becomes unresponsive”? “may crash on first attempt”?). And that’s ignoring the benefits of a native app, such as better integration, more comprehensive offline capabilities, and curation.
Clearly, Google has a lot of catching up to do on this whole be-a-dick-about-patents business. Haven’t they read the memo? No, seriously; they may have a problem of being too non-evil on this one.
Me, I’ll go with Stallman on this one (bet you didn’t see that one coming): limit copyright to five years, period. While we’re at it, let’s do the same for patents. It still gives creatives, inventors, businesses plenty of headstart, while at the same time allowing for the general public to benefit.
That is: Apple released a product called Final Cut Pro X, which they market as a major upgrade to version 7. But both technologically and spiritually, it’s more of a new product than an evolution, and unfortunately, that’s not universally regarded as a good thing. Accusations are made, refunds are demanded (and, in some cases, granted — despite a sales-are-final policy), petitions are signed (crickets), and everyone is suddenly an expert on video editing; particularly as it pertains to demands of high-end cutters.
The new version lacks a ton of features from distant-cousin predecessor; as I understand it, in some cases (like multicam editing), the latter was even good at it compared to the competition. To a point, it’s history repeating itself. Over and over. The closest parallel in Apple’s own line-up is iMovie; version ‘08 sported a radically different look-and-feel compared to version HD, and many were none too pleased about what was nowhere to be found any more. (A timeline, for example. A video editing program without a timeline seemed downright blasphemous.)
Or, looking further, there’s products like the iPod nano: it replaced the hugely successful iPod mini, came with 50% less capacity and no more accessory port, and was far less sturdy. (Plus, no more colors.) The iMac came without serial ports or ADB, and didn’t even have, gasp, a floppy drive. Mac OS X, as it initially shipped, had no CD burning or DVD reading (this was in March 2001), was unbearably slow and unstable, and broke with many of Mac OS Classic’s conventions. (And while I personally didn’t mind, a friend of mine wouldn’t stop whining about the excessive pinstripes.)
Adobe InDesign 1.0, too, was not very popular among the existing base of Quark XPress users.
Here’s what these examples have in common:
Years later, the newer choice is well-established, and virtually nobody still cries for a way back to more innocent days.
Some, if not most of the issues get resolved, one way or another.
New capabilities make up a little for it.
For its first two or three years, a sizable group of people wanted Mac OS Classic back. (Remember how Kuching discussion there used to be about the oh-so-flawed Dock? Now, look at Windows 7 and Ubuntu’s Unity desktop.) Now, it’s firmly entrenched as an excellent OS all around. The iPod nano eventually got far more capacity, as was inevitable, and colors came back, too. Nobody cares about floppy disks any more, and the iMac’s reliance on USB was, we can safely say 13 years later, prescient. Quark did a great job destroying their huge market lead and handing it to Adobe on a silver platter; they, meanwhile, kept improving InDesign quite a bit. And as for iMovie? Features in versions ‘09 and ‘11 like precision editing make it quite popular. Now, it even runs on an iPhone, making for a unexpectedly powerful, versatile video editing capabilities on a phone.
So what of FCP? If you only skim the reports, I can’t blame you for the impression that it’s heavily dumbed down and entirely worthless for professionals. Its lead, however, is Randy Ubillos — who also created the first three versions of Adobe Premiere, and the Macromedia project “KeyGrip”, which later became the original Final Cut Pro. In other words, it’s probably not a case of having the wrong guy in charge. It may however be one of priorities. Says Gruber:
I think Apple plans for Final Cut Pro X to grow from where it is today to eventually meet the needs of high-end pros. What this release shows is not that Apple doesn’t care about the pro market at all, but rather that they don’t care enough to prevent Apple from releasing a version that pros can’t yet use.
Agreed. I’m torn on the “care” phrasing, but given that Apple has idiotically even stopped offering the old version altogether, I may have to swallow it.
There’s a bigger, more systematic story here, though. Apple doesn’t really want a Pro distinction. People have been calling the new version “prosumer”, also pointing to the fact that it replaces Final Cut Express’s precious price point. And Apple doesn’t want an Enterprise distinction either. Here, people point to the discontinuation of Xserve.
It’s true: consumer products make for more volume. In that sense, bean counters in Cupertino may prefer them. But I think that’s a minor concern. The big one is empowering the user. Rather than convincing, as Microsoft, IBM and HP may have been wont to do, corporations why iPhone deployment makes sense for them, Apple release a product which employees and bosses alike wanted, badly, no matter what the head of IT thinks. It’s not so much “Pros” that Apple doesn’t care about. It’s interaction and compatibility with the existing world of workflows and policies. They’d much rather create the next big thing to wow you than worry about whether it works well with what you already have. That sucks if you rely on the present tense a lot, which chances are you do. But it rocks if you can spare 20% of your time living in the future, slowly yet boldly sarin to move away from the crufty conventions we keep on creating year after year.
The next time someone argues that Apple doesn’t care about the Pros, consider this: they care about creating the next generation of Pros.
The liberal fights with a fencer’s foil. Mincing the opponent’s argument, the liberal tries to score with quick, precise jabs using intellect, wit, and facts.
The conservative fights with a samurai sword. One heavy-handed hit and he cuts his opponent in half. No facts needed, just the adroit use of ignorance to persuade the masses. ‘My opponent’s gay!’ Or ‘Family values!’ Little nothings that score a bigger hit with the masses than all of his or her opponent’s jabs, which might sting, but aren’t fatal.
So, I wrote my own nanoc filter to do simple footnotes1, roughly in the vain as the wp-footnotes plug-in I had used earlier. The code is relatively simple and generic, so here goes:
class FootnoteFilter < Nanoc3::Filter
identifier :footnote
type :text
def run(content, params={})
content_add = ""
i = 0
newcontent = content
content.scan(/<footnote>(.*)<\/footnote>/) do |match|
id = "footnote-#{@item.identifier}-#{i+=1}"
newcontent =
newcontent.sub(/<footnote>.*<\/footnote>/,
"<a href=\"##{id}\" id=\"#{id}-back\"
class=\"footnote-link\">#{i}</a>")
content_add +=
"<li id=\"#{id}\""">#{match}
<a href=\"##{id}-back\"
class=\"footnote-backlink\">↖</a></li>"
end
if content_add != ""
content_add =
"<ol class=\"footnotes\">" +
content_add +
"</ol>"
end
newcontent + content_add
end
end
Put that somewhere in your lib/ folder as, say, FootnoteFilter.rb, and reference it in your Rules — for instance:
compile '*' do
filter :erb
filter :kramdown
filter :footnote
layout 'default'
end
Now, have a footnote2, simply by wrapping the text inside <footnote> tags.
For what it’s worth, I don’t agree with the “Radical Right-Wing Agenda” heading. It’s not so much that conservatives are becoming increasingly libertarian; it’s that, alas, pretty much all mainstream politicians are. There’s nothing inherently conservative about you’re-on-your-own ideas, though they are, of course, further away from socialism than from paleoconservatism.
But, what’s wrong with this picture anyway? If you ask the mayor, nothing!
[City Mayor Crocker] told them that, after all, “if an auto owner allowed their vehicle insurance to lapse, they would not expect an insurance company to pay for an unprotected vehicle after it was wrecked.”
He has a point, though he probably doesn’t know what it is. There’s no logic behind emotion; no ratio behind compassion.
We may not think of insurance agents as among the more humane jobs, but Crocker’s analogy is off — this would be akin to an agent driving to the wreck as it’s happening, and still deciding not to help in any way, which has much more to do with their profession than with whom they’re getting paid by.
But as a self-professed Christian (original page apparently deleted by now), one would assume the mayor does know a thing or two about such values. Perhaps it was the fact that homeowner Cranick was suddenly willing (and thus able) to pay “whatever it would take” that made him undeserving of compassion? Would the story have been different had Cranick in fact been too poor to pay the annual fee?
