Waffle is a weblog.
The author of Waffle, some guy in Sweden, also occasionally writes stmts.net.


(Waffle passed out from exhaustion in March 2012 and is now coming back online.)

Lately on Waffle

On the Apple TV Touch Concept, Design and Products

By now, I’m guessing most of you have seen the very nice-looking Apple TV touch concept art produced by Martin Hajek. This is a very high quality concept and could propel him to well-deserved stardom, but let’s please get into how it should on no accounts be allowed to become a product.

  • The Apple TV is shown as having a diamond-cut chamfer around its top and bottom edge and coming in black, gold and white. While this is in line with their recent design motifs, it’s far too flashy to be next to a TV. Even on the black version, the chamfer is a prime source of glare. Distraction is not a good property of a set top box.

  • The whole concept hinges on a small touch remote and there are several problems with this. Possibly to look like it’s a natural successor to the Apple Remote, the touch remote is curved. The last big iPod nano was curved in the same way and even had curved glass, but it was to feel smaller. It’s a reasonable choice for a portable product that you’ll carry with you all day. A remote needs to be somewhat portable, but you won’t carry it around for longer stretches and you won’t move it outside of the room. Additionally, the iPod nano did not have touch — touch on a curved display will be less accurate unless the screen is also curved. A flat display would work better.

  • The touch remote is just slightly bigger than the Apple Remote. Do the math and you’ll have to hold it closer than an iPhone to your face to be able to read that text.

  • The touch remote is touch and not tactile. Part of remote design is to design shapes that will trap the finger’s grip in optimal positions where you will know in which cluster of buttons you are and be able to reach and press as many of them as possible without looking. The touch remote has one such button: the home button. The consequence is a remote where nothing is “one blind press away”.

  • The idea of the touch remote combined with the above shortcomings means that you will need to take your eyes off the 40″+ TV in front of you, pick up a small remote, read small text and navigate on it. How is this better than using the TV in front of you? Not to mention the potential confusion about pushing the home button on a remote and not having the TV screen change.

  • With touch sensors, a display and Bluetooth or Wi-Fi (the concept has an IR window, but it needs to get info from somewhere), the touch remote will need to be recharged more often; that means either plugging it in, swapping batteries manually or placing it on a charging mat. I know some people will have the discipline to keep it on the charging mat, but many won’t, and now running out of batteries has become a much more haunting prospect than for every other set top box or TV.

  • The touch remote and the Apple TV unit itself will be significantly more expensive to make than the current version of the Apple TV. If it worked perfectly, that wouldn’t doom it, but even then, many people would ask why they’d have to buy an expensive remote instead of just using the Remote app on their iPhone or iPad, or why they can’t just use the Apple Remote that already works and that they might already have.

Product design is not easy. Developing a concept is not easy either, but product design means doing a concept, living with the consequences, occasionally tossing away something you’ve worked on for a long time and constantly iterating to solve the problem better and better until you can ship it.

Point One

iOS 7.1 makes the Calendar as usable as the iOS 6 Calendar, although not by default, because we couldn’t have that. Actually, there’s a lot of that going around. The setting for button shapes has many interesting results because it was bolted on and developers have not have time to make adjustments. Reduce White Point is a spectacular setting that also spectacularly screws up the contrast on several of the most iOS 7-ish apps, including my favorite weather app, Shade.

iOS 7 is a historic fact at this point and they’re not going to go back. But they are having to evolve it out of the supposed already-perfect sprung-from-Jony-Ive’s-forehead state and make changes. Dulling the green is a welcome first step; making the dialer transitions and interface work better than in iOS 6, as opposed to significantly worse (as in iOS 7.0) is another. Most of the other changes are stopgaps. If they will break down the problems and solve them better, iOS 8 will be great. If they’ll maintain their holding-it-wrong stance and keep the stopgaps, I think it’s time to stretch my legs and find another mobile platform.

Hard Core

Brent Simmons, who has written more Cocoa apps than you have, sold them to both more users and more companies than you have and spent more time implementing sync for them than all of their other features combined, just posted that he’s dropping Core Data for the syncing version of Vesper (no relation).

Core Data is a distant spritual successor of the long-gone NeXT-era EOF (Enterprise Objects Framework) project. While EOF dealt in object-relation mapping, Core Data is an object persistence layer and works with a variety of persistence stores, atomic or incremental, most of which are either SQLite or fools’ errands.

Quoth Brent, [original emphasis]

So now I’m not using Core Data with Vesper. I hope the people who (quite rightly) like Core Data are not disappointed. I like Core Data too and recommend it.

Consider the below not as criticism of Core Data but as a description of what I personally like. Also consider all the things I’m giving up: faulting, NSFetchedResultsController, the Core Data modeler (I’m using a plist instead), and plenty more.

Brent is clearly happy with Core Data. But he’s also clearly not using it, after wrangling with it for a while. I’ve beta tested several versions of NetNewsWire over the years when Brent developed it and I’ve been hearing Brent thinking out loud on this subject on the beta discussion list for many previous rounds. It’s not the first time Core Data’s been considered heavily, including development, and dropped. (It did make it into some NetNewsWire versions, including NetNewsWire Lite 4.0.) But Brent has detailed his propensity to create things which have the “mark all as read” problem, which is a tall order for an object database: having to materialize the object out of the store just to flip a flag and save all of it back.

So maybe Brent is just a walking pathological scenario. Let’s try someone with even more experience: Delicious Library author Wil Shipley, who’s been writing Cocoa since NeXTStep 0.8x in the 1980s and who knew Craig Federighi when he was on the EOF team. Even Wil’s been fighting Core Data. Not the hard parts. The easy parts. The ones where you get stuff for free and it’s supposed to just work.

Which reminds me: Core Data is also a supported engine for iCloud syncing. It’s supposed to be no more complex than just using Core Data on its own, so imagine everyone’s surprise when it was just as complex as using Core Data on its own. Uncountable apps made the tentative move to iCloud Core Data, and most receded painfully after endless complaints. Apple supposedly made amends and encouraged everyone to “try again”. I’m not sure if that silence you’re hearing is the sound of everything working fine or the sound of no one jumping at the chance to go through that again.

Of Apple’s fixes’ own admission, Core Data sync didn’t work because it was a black box with no ability to debug it. It would be unfair to zing Core Data at large with that epithet. But if it’s something that seems true about Apple’s frameworks, love them mostly as I do, it’s that they’re constructed as if to impress on their user how privileged they should feel because of the difficulty of the bar that they set to solve the problem at, and the complexity of implementation they have used to convincingly solve the problem.

Or to put it another way: Cocoa is so very prone to have heroic solutions that require you unerringly to write heroic or at least merely mistake-less code.

Key-Value Observing. Cocoa Bindings. Retain/release. The thing they invented – ARC – to solve retain/release. Weak referencing self in blocks or creating memory leaks. Auto layout. I consider myself a decent programmer, but I try to work out the complexity involved in completely implementing all-frills NSDocument loading and saving and I get winded. There are operating system kernels with lower cyclomatic complexity.

It’s true; other platforms do suffer from not having quite a few elegant solutions present in Cocoa. (Oh, to have every object solve key-based archiving/coding abstractly, so that you can get universal coverage with your own serialization engine; NSCoding is the most underappreciated piece of design in all of Cocoa.) And it is very neat when it all works. But what about when it doesn’t? What is the cost of demanding if not eternal vigilance, then at least that a fair chunk of your cycles go toward keeping your code at the level demanded by your harsh mistress?

All platforms demand the ability to walk and chew bubblegum at the same time, because nothing’s ever free and most things that are worthwhile won’t be trivial. The role of Cocoa shouldn’t be to appeal to the lowest common denominator. But it has a steeper learning curve than almost any other platform other than idiomatic C++.

There’s nothing inherent about Objective-C that makes complexity come to the fore. The community doesn’t have any problems creating simple frameworks that solve problems. Indeed, it’s interesting how the most popular code seems to be conveniences that sidestep problems in the frameworks as well as alternative frameworks that do less than the Apple-provided frameworks. Less.

I get it. Apple, and NeXT previously, rolls. The baton is passed on, forever, in the name of not reinventing something.

It’s always easy to demand a revolution (and with all this civil unrest, ’tis the season). It’s doubly easy for the guy who thought Apple were working on a new language to want some variant of that to come to fruition after an increasingly embarrassing number of years.

And yes, it’s way too easy to blame the frameworks and the platforms, and to conclude in the reverse that the existence of alternatives does not cast shadows on the things that they are alternatives to.

To all this: OK, sure. But what about the pain? Basic features are still painful for people that have been successful Cocoa coders for ten years. They’re not sufficiently saved by the ripening of frameworks as much as by their own accumulated ingenuity. Cocoa is still being developed, features are added, but rarely does something hard get easier.

Two codas: Brent’s commentary and objc.io issue 10, which is all about syncing and Core Data, rife with stories from the field.

« Newer posts · Older posts »