Daring Fireball: Complex
daringfireball.net
daringfireball.net
When the Lynx and Game Gear came out, it had to have a bigger, color screen. It had to have more buttons. It had to have a bigger storage unit.
And yet, Nintendo made calls - we could do these things, but battery life would suffer. And no one can play something that's dead.
And then, when Sony decided to go after the Game Boy Advance with the PSP, Nintendo said "let's make a new device, not a better Game Boy." Even now, I submit only two games get everything out of the hardware: Phantom Hourglass and Chinatown Wars. But things like Nintendogs and Brain Age make such good use of the touch screen - the zigging when the obvious zag was to support more colors, more storage, and more functionality (MP3 playing, Skype support, etc) to compete with the PSP - that they've outsold the PSP 2-to-1. (And let it be said, the PSP is a massive, massive success that no one talks about - you try selling 40 million of anything.)
I'm really excited about the Pre, but if its battery life isn't better than the iPhone's, it'll die and it'll die quickly. Users can live with well-designed compromises.
It's worth noting that Nintendo is an outright slaughterhouse in terms of sales. In the top 50 weekly VG sales, they have 18 in-house games. 6 of the top 10 (10 of the top 15) are for Nintendo consoles. Only one other company has a game on the list that's sold 5,000,000 copies. Nintendo has 13. Things like that are why I laugh at people who say the 360 isn't that far behind the Wii, because the Wii is in a universe unto itself.
*That was in high school, of course, where people have those ridiculous gaming arguments. Now I'm in college and my superathlete roommate just bought Pokemon Diamond on eBay.
There are lots of reasons for success of Apple but the thing he stated isn't one of the major ones. Apple loves to work in vacuum with no user feedback whatsoever since SJ likes to say that 'people don't know what they want until they see it.' To have a truly evolving system, you need to have a user feedback loop and Apple has one of the worst feedback loops in the industry since they almost never act on feedback and when they do, it takes them years.
And guess what? Nobody foresaw anything like what the iPhone ended up being. Most people couldn't get past trying to fit a phone into a click-wheel iPod.
Do you seriously think the iPhone would have been better if Apple had asked people what they wanted?
That has nothing to do with the article's argument that Apple's secret is evolution of simple systems.
As for your point, each approach has its virtues. What works for Apple probably won't work for the rest of us. Apple has hundreds of brilliant designers that create three different pixel perfect designs for each piece of new UI. Three different teams (and all brilliant at what they do) working against each other... how many of us can afford something like that?!
I still contend that Gruber's argument about Apple's secret being simplicity and evolution is bullshit. He probably came across Gall's law and decided to spin it into an article about Apple.
You'll notice that Gruber mentions the period in the 80s where Jobs was still an employee as a period which saw similar results. This is not something that requires a huge team. Back with the original Macintosh there was a similar effect. I would hope you've seen the computer's initial unveiling - it's on YouTube - because that's a video that inspires me to this day. Younger, tuxedoed Jobs reveals it, begins using it, and the audience begins half-screaming, in a near-frenzied way. They can't believe that they're seeing what they're seeing. And that's the startup Apple, that's the two-man operation. Back when they didn't have as much in terms of resources, they still focused on creating that simple core, because that's what people care about.
You think simplicity and evolution is a bullshit concept? Not that I know anything about you or the stuff you've worked on, so apologies if this sounds ignorant and facetious, but that's at the core of making anything. That's a "secret" that I stumbled upon independently. I know a lot of programmers who came upon that - and I find that I respect their work much more than I respect the work of people who don't "get it".
Look at NewMogul. Do you think that if that site was started by Paul Graham it would be as small as it is right now? No, not because Paul Graham necessarily has a publicity advantage, but because if he were making it he'd most likely go about making it tied in with Hacker News. HN is his simple core model, and NewMogul could be seen as an expansion of that initial concept. As a concept of its own, it's failing - if you wanted to make a huge site for business-interested people, cloning Hacker News is not a smart idea. So the failure comes down not to the design, because the design is quite pretty, but to the concept, which is not simplistic enough to work.
Apple went Exupery on the shuffle too, reducing it to the minimal feature-set.
So maybe Gruber should have said that UI is simpler, but not the iPhone. If iPhone is so simple, why aren't other big companies as successful at creating new phones? Clearly, things are not as simple as some people would make you believe.
Also, a jump from Razr or Palm (for example) to iPhone is much bigger than that of iPhone 1.0 to 3.0.
Had Apple released a Razor-like iPhone and then iterated to iPhone 1.0 system over a year or two, I'd buy Gruber's argument. But iPhone was clearly 'from the future' when Apple presented it and everyone else was scrambling to catch up. So Gruber's argument is not really serious.
Other companies aren't as successful at making new phones because they're reluctant to abandon everything they have to create new systems and models. Their minds are stuck in a single pattern. Nobody making those mock-up sketches for the iPhone thought that Apple would get rid of a numberpad. Nobody. Every indie designer making a mock phone kept the numpad there. You can't necessarily throw lots of people at a concept and expect it to be better. It takes a certain moral bravery to get rid of everything and start anew.
We advise startups to launch when they've added a quantum of utility: when there is at least some set of users who would be excited to hear about it, because they can now do something they couldn't do before.
I'd guess they omitted Flash because the iPhone is too low-powered for it to look good; the iPhone needs optimized native apps. Since "looking good" is a huge part of the iPhone experience, it makes (painful) sense to drop that feature. Same for Java.
It seems they couldn't justify omitting Javascript too, but I bet they would have loved to, as it's 78-90 times slower than a desktop iMac: http://arstechnica.com/apple/news/2007/08/iphone-benchmarks-...
It might sound like I'm criticizing the iPhone, but I'm not: it's how Apple managed to create a cool experience for users in an incredibly compact size (they are tiny.)
The result is that when Moore's law does enable reasonable processing power in a device that small, Apple will be in the best position to exploit it, in market position, in design tradeoffs, and in engineering knowhow.
"PB made a point in a talk once that I now mention to every startup we fund: that it's better, initially, to make a small number of users really love you than a large number kind of like you."
It's possible to get people involved with a product if they're not excited about it. There's still growth involved. But the difference between that and a project people actively fall in love with is extraordinary.
"Excitement" is a benefit, not a feature. This distinction from advertising is obvious, but hard to drive into engineering (even when it's me).
Until my current project I always thought that excitement was something that you simulated to get users. The guy who built and marketed Zoints, the start-up I did work for in high school, would IM me and talk about these campaigns he wanted to run on forums where Zoints employees would become forum members to talk about how much they loved the network (it was a social network for forums, essentially). And I thought, Oh, this is how you generate excitement. Then I started demoing Cirqueti to people in January, and suddenly I was getting absolutely ridiculous feedback. Things like, I'd talk to somebody about it on IM, and they would go to their college and talk to their professor or their class about it. One guy keeps bringing friends onto his IM account to ask me questions about it.
It's insane, and it's a terrific feeling, and more than that it's genuine. I love it, because it means I don't have to lie or oversell what I've got: from the initial reaction it doesn't at all look like that'll be necessary, and I can focus on just making it better. And the best part of that is it's not marketing. Like, this isn't some cynical attempt to gain users. It's much more honest, because they're doing it on their own. I've seen that with a lot of web sites, in particular Facebook, which ran no ads on competing web sites (unlike TagWorld, which people thought was a big potential competitor, and which would advertise everywhere). I love it. It shows that if you've actually made something good, then you don't have to worry about advertising and you can just be yourself and do your own thing.
Recently, my 7 year old son asked me "Dad, can you call people with an iPhone?"
(We don't have one, but he sees the commercials on TV.)
Say what you will about Rails, but people using it can develop things pretty incredibly quickly, and there's not an enormous learning curve. That's simplicity.
But maybe that's not the trick - it isn't that hard to make an overgeneral, loose platform, that isn't specialized towards any particular usage. Maybe the particular platform isn't that critical. Maybe the trick is just to provide access to something that is really cool and exciting (that simple core idea). Developers are clever, they'll work out how to get on the bus.
I'm not sure if this applies to Rails.
I'm not entirely sure what you're saying, though: could you elaborate a little?
USABILITY To elaborate on the other idea: it's much easier to make something usable if it has a specialized purpose. Fewer features, fewer interactions/interdependencies, fewer controls, fewer things to go wrong - it's gonna be simpler to use. e.g. ipod shuffle. That is, not being able to do things makes it easier to use.
The big problem with a platform is that you don't really know what the specific use will be, nor the exact nature and parameters of it. A platform, by definition, is general, and not specialized to one specific purpose. And you won't even know the nature of the general use. Except, perhaps, that it will want to be part of whatever the cool, exciting thing you have going is - that's a predictive organizing principle.
Therefore, for a platform, rather than trying to guess at the kinds of uses it will have, maybe just say: (1). what is the cool, exciting thing that we enable? (2). how can we let developers build something that has that cool, exciting thing? That is, an API that gives them access to whatever they need to do that. It doesn't need to be great access, they just need to be able to do it somehow.
This is "overgeneral" in the sense that you can not only do the things you want to do, but you can also do things you don't want to do. This looseness makes it harder to use - if it was an exact fit to the problem, it would be a delight to use. This extra power gives you "enough rope to hang yourself".
RAILS On reflection, I think Rails is a much later stage in the development cycle: webapps are in a more mature stage, and by that I mean that people now know what kinds of things they want to do, and most importantly, what kind of defaults are useful. At an earlier stage, we didn't have enough collective experience to know those things. This knowledge is to do with how webapps appear to users externally, as well as what architectures and internal approaches have been found to work. Webapps are becoming an understood art, when previously, it was a bit of a black art.
Rails represents a systemization of webapps; no longer ad hoc, many design decisions are now captured in a mechanical tool. It is specialized to the task.
Unfortunately, the cost of developing from the base case as described in the article is very high - and reflected in Apple's prices.
Even that is somewhat misleading. The original Macintosh operating system was designed specifically for singletasking on the original Mac 128k hardware--a design choice that hamstrung Apple for years afterwards, and became the root cause of Apple's need to completely replace their operating system. It's not that Apple gave up on incremental development and started on quixotic missions to the next big thing. It's that the system architecture of the Mac OS was years past its prime and Apple couldn't fix it iteratively anymore.
The other advantage to this approach is mental. If I knew how much effort it took to get to this point I would have never started.
Gruber's a Mac fanboy, but he's also one of the most critical Mac users I know, along with John Siracusa. When Apple does something bad, Gruber is vocal about it. He's still critical of a lot of OS X's interface, and writes about it often.
"Shit sandwich."
So, yeah, Gruber knows when to call a spade a spade.
Vi vs Emacs? The former lacked extensibility, so it kept being a "phone". Until the mighty Vim came along...