5 ms·

The answer is not perfect -- the questioner might be correct that Jobs doesn't have a handle on the tech side of things. But I did think that the answer was coh

The answer is not perfect -- the questioner might be correct that Jobs doesn't have a handle on the tech side of things. But I did think that the answer was coherent. He concedes that, without going into details, OpenDoc may be the better option technically, and surely in a sort of contrived case it would be possible to come up with situations where it is. I can't speak to the accuracy of the claim given I am not familiar with whatever the actual arcane debate was at the time, but I immediately infer from context that this is the questioner mad that Apple is giving up superior technology in favour of broader adoption technology. Then he says that it's actually not about the tech, it's about the extent to which the tech enables a good end-user experience. The printer anecdote is imperfect, but it is him highlighting a point he referred to many times in his career, which is that tech (and especially tech specs) is just a means to an end and people just by the end. Like how 3.x era Android phones often had more RAM or nominally higher clockspeed but were substantially less responsive to their contemporary iPhone competitors. I do think he dodges the second question entirely, but the second question is, in so many words, "You suck at your job. Care to comment?" so, like, what is the ideal answer to that? Crucially, he correctly senses that many in the audience empathize with the aggressive tack taken by the questioner and he admits that it's a fair tack and he has no real defence. If someone tells me "you suck at your job", I think I'd be more likely to respond to validate their anger than to actually take it to be a factual claim in need of rebuttal. If anything I'm shocked that Jobs had the empathy to read that correctly. I don't see it as RDF so much as it is an honest and coherent and adequate but imperfect answer.

rusk 6y ago
OpenDoc was if I recall correctly, Apple's answer to Microsoft's OLE/ActiveX/Whatever-it's-called-now and from what I recall it was a superior technology. I believe the core premise was to allow documents to not so much be embedded in one another as to make the document central to the work, rather than the application and the various (application) tooling would become involved when needed. I remember when I first made the switch to Mac around 2005 I did notice the experience of copy/paste between applications was inferior, but I didn't miss it that much. Looking back, I guess that maintaining that level of app integration is a huge amount of work, and there was a huge amount of overhead in managing a doc that in fact is being edited by multiple docs. I don't think I ever thanked anybody for embedding a doc in another doc. I think compared to where we were turn of the century we expect a lot less from copy/paste and I don't think anybody really misses it. Thinking about it now, from what I recall of Microsoft's "Longhorn", which was to become Vista it was trying to get this level of deep application integration to work was probably what set them behind and caused them to release a crocked OS and really put them on the back foot really until recently. I was just a kid at the time so I apologise to anybody more familiar with the story if I'm getting this all completely wrong. I suppose what I'm trying to say is that Steve was probably right about this in the end, and that developer made a fool of itself.
- Schiendelman 6y ago
  I worked on Longhorn. There were two things I remember that led to the delay: - Trying to make every component of the OS describable in a manifest, such that you could change/update/remove it on the fly. They seem to have gotten there finally in Windows 10. - Trying to rewrite all the native code in C#. Some components got there (including mine), but rewriting all of these libraries and applications at once made the OS so slow that we got to a point where it was unusable and had to take a partial reset.

rusk 6y ago

OpenDoc was if I recall correctly, Apple's answer to Microsoft's OLE/ActiveX/Whatever-it's-called-now and from what I recall it was a superior technology. I believe the core premise was to allow documents to not so much be embedded in one another as to make the document central to the work, rather than the application and the various (application) tooling would become involved when needed. I remember when I first made the switch to Mac around 2005 I did notice the experience of copy/paste between applications was inferior, but I didn't miss it that much. Looking back, I guess that maintaining that level of app integration is a huge amount of work, and there was a huge amount of overhead in managing a doc that in fact is being edited by multiple docs. I don't think I ever thanked anybody for embedding a doc in another doc. I think compared to where we were turn of the century we expect a lot less from copy/paste and I don't think anybody really misses it. Thinking about it now, from what I recall of Microsoft's "Longhorn", which was to become Vista it was trying to get this level of deep application integration to work was probably what set them behind and caused them to release a crocked OS and really put them on the back foot really until recently. I was just a kid at the time so I apologise to anybody more familiar with the story if I'm getting this all completely wrong. I suppose what I'm trying to say is that Steve was probably right about this in the end, and that developer made a fool of itself.

Schiendelman 6y ago
I worked on Longhorn. There were two things I remember that led to the delay: - Trying to make every component of the OS describable in a manifest, such that you could change/update/remove it on the fly. They seem to have gotten there finally in Windows 10. - Trying to rewrite all the native code in C#. Some components got there (including mine), but rewriting all of these libraries and applications at once made the OS so slow that we got to a point where it was unusable and had to take a partial reset.