At the 23:50 mark the slides follow the familiar model seen in Apple media events today.
The approach: in 3-4 concluding slides, concisely reiterate key selling points, compatibility, price, and the availability timeline. I've always found this approach to be particularly effective -- I'm highly likely to unambiguously remember these most important bits given that they are presented last.
What is fascinating to me was seeing how passionate he was on a product like it was his life goal while talking, and a few years later totally focused on another completely different thing.
It is impressive to me since I am having hard time to let go my little hobby projects and start another one, while he is doing it on much higher level with the same passion. Respect on that.
He actually wasn't that passionate about enterprise stuff, but could clearly make it look like he was in important events like this. I think at this time, he was getting tired of NeXT and was looking to sell the company so he could focus on Pixar, or something like that. He was really tired of the computer business. I remember seeing an interview with him from around the same time period where the interviewer asked him to talk about NeXT's enterprise stuff and the response was something like "You don't really want to hear about that right? It's not really that interesting."
That was the 1995 Cringley interview. About 54 minutes in. "You don't really want to hear about NeXT, do you?" was the exact statement. And he claims that innovation in the computer industry is in software within seconds.
I think Jobs' response was more about disarming the perceived courtesy. While polite to ask Jobs about what he was doing with NeXT in 1995, the highlight of his career (and general interest) would be with Apple and to a lesser degree, Pixar.
Kind of like talking to a rock legend about their latest album, when most people care about their breakout period.
> What is fascinating to me was seeing how passionate he was on a product like it was his life goal while talking, and a few years later totally focused on another completely different thing.
> It is impressive to me since I am having hard time to let go my little hobby projects and start another one, while he is doing it on much higher level with the same passion. Respect on that.
What a trip to see Steve Jobs not only try to sell something pre-iPod-success, but something as technical and relatively pedestrian as a web framework...And he does it well, without the use of a primetime-polished slideshow or catchphrases.
The one visual that sticks out to me in this video: the silhouettes of people arriving mid-speech and leaving early.
In early '96 having a RAD MVC web framework backed by an ORM was really pretty groundbreaking (even moving codebases relatively seamlessly between an OpenStep desktop app and WO was possible), though yeah, this was Jobs going after the Enterprise audience rather than consumer electronics, very different vibe.
The QA is really interesting. Most of the questions I felt he handled well and showed that he has knowledge of the domain. Two questions in particular stood out:
Q: How can I, as a developer, get my hands on the expensive software suite?
A: Come talk to us. We can accommodate developers who are willing.
This may have been some early input for him to think about sdks and the philosophy of providing developers with tools early on.
Q: What is your view of transactions on the web?
A: We don't think it's a technology problem. It's more of a social/business problem
He was clearly wrong on this one, with the advent of cutting edge technology companies like PayPal and Stripe that followed.
Transactions on the web exist, there are improvements to the UI but it is a social problem (I am afraid of my credit card being stolen) and business problem (Don't worry, trust us we won't let anything bad happen to your credit card).
He made it sound as though it is technologically trivial, as long as society and businesses would get behind the movement. I don't think that is the case from a security standpoint and also designing an api that would allow for widespread adoption.
> He made it sound as though it is technologically trivial
This is a guy who built three operating systems and countless revolutionary apps under his watch. Many of which given the constraints back in the day would've been incredibly complex.
Hmm I was more impressed by PayPal's business tenacity than with their technical ingenuity. Along with the entrenched credit card companies they had to deal with fraud and organized crime.
No, he was right. In 1996 people were just scared of using their cards online. No one big was doing it yet, consumers didn't trust anything about the end-to-end process. There are more risks now than there were then, if anything (given how many trojans and hackers there are targeting cards now), but people are used to it now.
Paypal didn't bring any particularly new technology, they just bought confidence and bigness.
So, about the 10x programmer myth, productivity etc...
Steve mentions that it took about 3 weeks with 3 programmers to build this app. The tools & technologies have evolved and today we can build this kind of thing with a tiny fraction of this effort...
To me that's the kind of thing that really matters after all: evolving technology & tools, not the "10x programmer myth", or those "how to be more productive" tutorials. The tech evolution has a much bigger impact on productivity than those individual productivity recipees.
Those programmers were arguably 10x or 100x programmers, not run-of-the-mill. They made a choice to work on new technology, solving a hard problem. And then put in the effort, probably with little handholding, and managing the uncertainty.
These are traits not found in the average or even median programmer.
I can see close to 10x productivity gains depending on my work environment. If I have three meetings spaced throughout the day, a ton of quick interruptions, and I am trying to learn something new, forget it. If I get to focus on that one thing, then I can be pretty productive.
I also think that the 10x thing is more to do over the longer term (rather than "look at what I bashed out in 2 hours"). I probably don't code as quickly as I used to, but I am a lot more thorough, and having made plenty of crappy mistakes designing my code in the past, I am in a far better position to know what will make my code robust, and maintainable time a month or two down the line.
And, 100x cheaper, if taking consideration of free cloud offerings.
These profound factors keep me working everyday, although I haven't made my millions yet. There was an article about Nokia or Ericsson around early 2000, saying that people tend to overestimate the impact of technology in short term but underestimate in long run. It's the case.
You are talking about the days when Apple was about to close its doors after the Copland failed experiment and NT was picking up steam against UNIX based workstations.
In 1996 it appeared NT was going to conquer the IT workstation desktops.
It must have been painful for him to give up on NeXT's beautiful hardware. To see his beautiful software running on lesser computers probably did hurt.
I would really like to know how cutting-edge this was at the time. It seems incredible to me how little has changed in how we make dynamic web applications.
It moved from Objective-C to Java under Apple. Apple discontinued shipping it with OS X Server Snow Leopard, but the frameworks are still available/free. The community picked up where Apple left off with the open source Project WOnder.
It is a full stack development framework. Enterprise Objects Framework(EOF) is the ORM or Model layer like Cayenne or Hibernate. WebObject components are the front end View layer like you might get from Tapestry.
I have yet to find a web framework that rivals its Controller layer, DirectToWeb (D2W). D2W sits between the Model and the View. It can generate Views automatically using information from the model and with customizable direction from a rule system. It also provides controller actions with customizable callbacks.
Out of the box, WebObjects can reverse engineer your database, constructing a full model of it, and D2W can then construct a full blown Create/Read/Update/Delete interface to it with no coding required. If you don't have a database, you build a model and WebObjects can generate the SQL necessary to create the database for you as well.
It's still pretty amazing, despite being treated like an ugly step child by Apple. It still powers the billion dollar iTunes store as well AFAIK.
I was a WebObjects Developer for 2 years from 2007-2009, the company I worked for still uses it for their massive health-care-related web apps. It's a really cool framwork to use, as it incorporates so many aspects that are usually provided by different libraries.
The developer community is small, but very active. Every year they hold a "World of Web Objects (WOWO)" conference right around WWDC in San Fran.
Project Wonder has done amazing work to bring Ajax and many other "Web 2.0" features to WO.
It does still power the iTunes store, and the Apple Store. A friend of mine that worked at our sister company landed a job with Apple working on the iTunes store, and AFAIK, he's still there doing that today.
I used to work at Apple many years ago in a past life but IIRC:
Project Wonder was definitely at the core of iTunes Store. They had your typical monolithic web application and used most of the WebObjects technologies.
The Apple Store was different. They had dozens/hundreds of micro services which used WebObjects only in the front i.e. to handle request/response and routing. They may have even switched it out by now.
Interesting. I remember reading the Project Wonder mailing lists and the creators and maintainers of it were certain that Wonder wasn't being used by Apple for anything "public facing", but they strongly suggested it was used a lot internally.
I've always wanted to work for Apple... care to share any thoughts?
I used to sell WebObjects projects during the dotcom boom and the ORM was a big selling point. There weren't a lot of frameworks or web dev options back then.
Looking at options today, I feel like a kid in a candy store.
Web Objects was the first web framework I worked in, back in 2001, and I didn't really understand it at the time, but it already had built and running in production many of the features that I subsequently came into contact with via supposed innovations in other stacks. The J2EE 1.3 spec for example added "entity beans" and unleashed hideous vendor implementations like WebSphere on developers. The impact of all the anti-patterns that spec inspired are still visible in the development world today - I'd say it is indirectly responsible for the rise of Spring and Rails.
WO also had the added benefit of being a full-stack solution. The way the J2EE spec was built up of sub-specs really contributed to the fragmented Java framework universe. Developers then had to get used to spending think-time reasoning about the way the pieces and "tiers" fit together and less time building coherent apps.
From 1996 to 2005 dynamic web applications concatenated and sent back strings. After that we started sending back strings and concatenating. Sadly half the web hasn't caught on to the "new" way.
> Sadly half the web hasn't caught on to the "new" way.
s/Sadly/Gladly/
There's something gloriously simple and effective about the page-is-a-page metaphor. Solid, unambiguous URLs that do what they say on the tin. It's not the "old" way, it's the native way.
There is nothing glorious about clicking a button then watching the screen flash and slowly reload eventually revealing a tiny change. Simple I'll give you. Effective, yes, if the user can suspend reality and pretend the state change happened instantly.
How about a URL that unambiguously specifies the state of all parts of the page? Paste that in a browser and it pulls up the page with all its dynamic parts set as before.
That's an absurd example. Why did you assume that I am arguing the extreme case? All I'm saying is that the page-is-a-page metaphor is legitimate, efficient and comprehensible. It should not be dismissed simply because some over-engineered client side framework looks cool.
Obviously "tiny" changes can be performed with client side code without breaking the page-is-a-page metaphor. Look at Facebook -- a good example of an extremely mature application where the page-is-a-page metaphor remains fully intact.
And of course not all websites fit the metaphor, in which case you obviously should not use it.
Indeed it is absurd that we have known how to refresh part of a page for a decade now and yet half the internet still refreshes the whole page. I'd say this has to do with developers still relying upon server side frameworks they learned years ago.
This has nothing to do with looking cool. Your server generated dynamic full page can look great. Didn't you see Steve Jobs's Dodge site? This has to do with user experience, in particular performance. The problem with Steve's site is that a slight change in search criteria resulted in a two second full page refresh. It made me want to shop for a Ford.
Sure their are cases where full page refresh is fine. Shopping isn't one of them. Reading a news story that spans 10 pages isn't one of them. Most of what I use the internet for isn't one of them.
And then there are web applications. Without partial page refresh these feel like shopping for a Dodge in 1996.
There is nothing glorious about clicking a button only to have nothing at all happen because a fragile dependency system is broken, making the entire site less usable.
I use Ghostery to block a lot of tracking JS. This includes things like FB stuff. The number of sites that break because a call to "FB.init" throws an exception is astonishing.
It's ridiculous how quickly people (by which I mean developers) have forgotten the concepts of graceful degradation and progressive enhancement.
There are very few use cases where a web application simply cannot function without javascript.
Many developers "in their right mind" did exactly that. For a pretty long time, this was the way people manipulated spreadsheets in an automated fashion unless you wanted to buy expensive products from third-party vendors.
PostgreSQL may be the worst/best compromise. The Press FAQ provides an audio file the pronounces it post-grez-que-elle, keeping enough of both pronunciations to be a linguistic spork. Considering it's roots with Ingres, it makes sense, but it also feels like a layered pun.
Once interviewed a guy who kept talking about knowing "Squeel". Had no idea what he was talking about until he mentioned "Squeel Server". Cue banjo music...
Mine was the first time i tried to buy a SCSI drive in the US. The sales person didn't even understand what i meant, when i said "es see es i". Then he pronounced "sceuzy" and i was amazed :))
I once requested the "Wi-fi" key in a hotel, at St. Malo, France. The receptionist gave me a weird look and, after I explained myself, said «Oh, le "wee-fee"».
This was 1996. WebObjects was far ahead of anything I used at the time. I started using WO and EOF in 1999 and it had stuff like scaffolding (D2W) at that time. When did RoR introduce this?
Also of note is that Seaside uses the concept of continuations to manage multi-page flow which is a very fitting abstraction for this problem, and that most languages can't afford to do. That means they can code complex behavior as if the line between client and server did not exist.
By that time, NeXT's core product line had morphed from being a series of Unix workstations to being an implementation of the NeXT APIs that ran on top of several platforms, including Windows.
While I don't have personal experience, from what I've read, IE on Mac was a fair bit different from IE on Windows. IE 5 for Mac, released in 2000, used something called the Tasman engine: http://en.wikipedia.org/wiki/Tasman_%28layout_engine%29
> At the time of its release, Tasman was seen as the layout engine with the best support for web standards such as HTML and CSS.
> The Macintosh Edition introduced a new rendering engine called Tasman that was designed to be more compliant with emerging W3C standards such as HTML 4.0, CSS Level 1, DOM Level 1, and ECMAScript.
I vaguely recall reading somewhere that back while IE for Windows was giving web developers prematurely grey hair, IE for Mac was a much nicer browser and much more comfortable to support as a development target. I think it ended up getting less time/thought/effort from Microsoft eventually. Also, Safari was released in 2003 (beta in January, default browser in OS X 10.3 Panther, in October).
Interesting that he dismissed interpreted languages for non-trivial code, as if it were obvious that the performance wouldn't be good enough. But wasn't Perl already being used for CGI scripts in 1996?
I'm sure you could make it work, but back then fewer engineer-hours had gone into making interpreted languages fast, and hardware was slower. It was also common to run a website on one machine.
The approach: in 3-4 concluding slides, concisely reiterate key selling points, compatibility, price, and the availability timeline. I've always found this approach to be particularly effective -- I'm highly likely to unambiguously remember these most important bits given that they are presented last.