So Innovation Behind Apple dot com, it's kind of a big title. But basically you know, what we're gonna do today is talk about some of the things that have gone into the new site that we launched this week. And just give you a little bit of background on sort of some stuff we've done in the past, and you know, try to have a little bit of fun with it. The team's gonna present a bunch of demos today, I'm gonna give you guys a little bit of background.

Here's what we're gonna cover. I'm gonna go through a sort of brief history of the site for the last ten years or so, thousands of slides, no I'm just kidding. We're gonna do a little bit of a backstage tour talking about our new search, talking about how we're integrating QuickTime into the DOM with age, and trying to you know, take more advantage of what we can do with QuickTime. And then we're gonna talk about how we're trying to actually do some really compelling UI elements using open standards. And then lastly we're gonna talk a little bit about the tools that we're using to do these things.

So little bit of history on the site. Basically you know, the theme here is Evolution's a Good Thing. You know, one of the things I've been reading a lot about in terms of the response to the redesign of the site is you know, people are saying oh they haven't changed anything in seven years, it's you know, it's been that long. There's been a lot of change, but it's been sort of invisible, or it's been us experimenting with elements.

And so I was gonna you know, highlight a few of those things and kind of poke a little bit of fun at ourselves with some examples. First, this is actually the first Apple website I worked on, which was you know, really hard code, because basically it's a giant jpeg with an image mount, you know. So things were really hard back then.

But then you know, as we started getting into you know, what Apple dot com is gonna become, and having our first online store and other stuff, you know, you're dealing, at the time we were dealing with the classic Netscape and early IE days where you know, you're trying to hack a table any which way you can.

And you know, so I, we went back and found some really fun code examples of some stuff that we definitely don't aspire to do any more, but are just kind of fun, you know. So you know, here's a page we had up for Think Different, and you know, this is like the most extensive use of non-breaking space that you know, I could find.

And there's some other just really fun you know, you know, inconsistencies in here and some other stuff. So you know, that's kind of a fun thing.

In two thousand with the introduction, or sort of the debut of the fact that we were gonna do OS X, we redesigned the site to have the classic tabs that everybody thinks we have that were the same for seven years. And actually they changed a few times, but they're kind of subtle, so you'll see some examples This was the first incrination of them with the sort of giant red apple, and the tabs here are much taller.

And it's kind of like going back and looking at you know, OS X zero, or even Jaguar after getting so used to Tiger, or now Leopard, you know, like oh my God, you know, those elements are you know, there's so much color and everything going on, you know, it's just interesting how far the design's evolved there too.

But around this time you know, like I said, we were kind of hacking tables every which way you can, is you know, we just had inline styles and all kinds of stuff absolutely everywhere. So it's impossible to read, and you know, don't take notes about this at all, of course it's just to show that you know, we had some stuff that was really hard to read, and really hard to work with, and stuff still wasn't really necessarily evolving fast enough. But we were, at this point, this was about 2002, you know, 2003, we'd been on OS X for a little while.

And you know, in that intervening time really what we were doing was we were experimenting a lot with what we could do with QuickTime in media, and doing some full screen video, and some things like that. But there wasn't a whole lot happening with browsers yet, because you know, Firefox hadn't really happened. Safari came out around that timeframe, and that's when we really started to look at you know, how do we get into things like CSS and really start evolving what we're doing in the base you know, content on the site.

So we actually did some stuff with CSS initially, but it was kind of a baby step in the sense that we were basically removing a lot of the inline styles, and kind of replacing them with a set of classes that did kind of the equivalent, but we weren't really taking advantage of it yet.

A couple of years later, and you notice now the tabs have changed, there's a blue apple and they're a little bit different. You know, we introduced this thing called iPod, and around the same time we were you know, starting to get into a few other things we could do with CSS, and again, still doing some stuff with QuickTime. The home page here had a QuickTime VR that kind of transformed from being a QuickTime VR into the image at the end of the little presentation. Couple years later, you know, iPod's starting to take off, we're on Windows, and we're doing a little bit more with CSS.

But again, poking fun at ourselves, you know, here we thought you know, more was better, so we had you know, a green and a purple, and a blue and a pink CSS to manage swapping out colors and stuff on the site. And you know, making some progress. The next year too, this is I think about two thousand four, iTunes is really starting to take off.

And we started to do some stuff that was getting a little bit into manipulating X amount, a little bit of data. Here we're taking an actual sales feed from the online store for music as part of the hundred million song countdown that we did. And so this was kind of fun, cause this was kind of a dynamic page, it was updating. We had you know, lots of traffic cause you had people were sitting there reloading and reloading and reloading.

But along with this we actually started to see some changes under the hood. Even though things kind of look a lot the same, at this point we're actually starting to break the CSS down to some global elements, some page elements, you know, some area elements. And you know, getting into having some really core basic trivia things.

This takes us to about 2005. Here we're doing some fun with some dynamic HTML. We had a home page that was you know, scrolling iPods and some other stuff. Doing some stuff, managing video on the home page as recently as last year. You know, this is just a month or so ago. And you know, now we've actually moved on to having some discrete global scripts and styles.

And you guys can go look, this is the stuff that's kind of up on the site now, so if you're curious you can go look at the actual CSS classes that are live on the site. You know, so we're doing a lot with layout, the team's done a lot to really develop a good grid, and it's really impressive the sort of progress they've made over the last couple of years. So, and this is kind of what the new finished site looks like.

So you know, even though this is sort of the most dramatic visible change, you know, there's been a lot of change over time, even though the tabs have been there you know, pretty consistently. So that's pretty much it. We're a little ahead of the schedule. Douglas is gonna you know, tell you all about what it took to improve our search. So, Douglas?

Okay. I'm not sure what Dan is trying to say, he used two of my code examples in the earlier slides. So I guess that's why he made me a manager and I deal with budget and those types of things now. Anyway, and before I begin, not everybody on our team could be up there, up here, but we had a monumental effort in terms of what we launched on Monday.

I think we covered more of the site than pretty much any other company could handle, particularly when most of our HTML is, we're not driven by content management systems, it's static. So I'd just like to acknowledge the team. Scott, Kevin, who had, Kevin actually is, was the hundred billion song winner. We brought him from Kansas. David and two other people who aren't here, Stephanie and Johnson. So thank you. All right.

So, search. Dan asked me to look at search at the end of two thousand two. Basically up to that point search was largely an afterthought. It was just, yeah it's there, you know, guess it works. So I went and took a look at it, and the first thing I did was I took ten of our top products and I ran searches against it.

And the results were one item managed to just eke itself into the top ten results on the first page. So we were at less than ten percent accuracy. So had a little discussion with our IS team, who managed the search. Search was custom CGIs paired with an old version of Verity. And I guess I sort of already belated the point, but if Ralph C was beef, we were vegetarians.

So, and search was slow, and the user experience design was also an afterthought, nothing particularly inspiring. So the IS team gave us sort of free reign to go out and look at options, and of course at this time, beginning of 2003 there was this little company called Google, and they were doing some pretty cool things in search, and most of us used it. And of all the companies that were invested in the search, they had these things, these GSAs, Google search appliances.

And so we got one of those, we tested it for a month, and I believe on an initial crawl we had relevancy, good results, about seventy percent plus accuracy. So we were pretty happy. Speed was clearly an improvement, and what we saw in the way we thought about implementing it was the potential for more flexible custom designs on some sub-collection types of search, which I'll show you an example of.

So we rolled this search out, I believe it was June 2003. And there's nothing dramatically inspiring about the design, but fundamentally it was working. You would actually search for something and you would find what you were looking for. The one key element that we did is we introduced a featured result based on keyword matching.

So in this case we're pulling in the snippet of HTML, and it was just a logo, or a box shot, a little bit of intertext, and then sort of key links off to the things we figured you'd most like to do. And that was pretty well received, and people liked the search cause it actually worked. So, and then to customization, two WWDCs ago we actually launched the Dashboard widget site. And as part of that we decided to customize the sub-collection search. And basically it's all fundamentally the same except for the wrapper, but it was very well received with the site.

So, search sort of stayed in its Google search appliance fashion for about three years, and then we started talking about a redesign of Apple dot com. And in part of that discussion, and how we plan to change the navigation. We decided that search should become a core element of navigating Apple dot com, and decided to elevate it up into the tab bar which you've seen.

So in discussing that and making it a strategic part of the navigation experience we knew, we had to do something really great, so we started asking questions. Could we actually make search better than the Google implementation we have now? And if so, you know, what questions came up, and what would we have to tackle? So the first one was could we improve our meta data to enhance our search options? Could we make Google work really hard?

Could we launch simultaneous queries on one search term, and bring back categorized results? Could we merge in other results, like from iTunes, from the online store, which were basically running their own search engines? Could we provide more results in a page without actually having to commit more queries?

And could we enhance the user experience and design? Could we actually bring in our A designers and have them help us achieve something really great? And then lastly the biggest challenge was could we come up with something that actually avoided search all together? Could we something that was sort of a spotlight like shortcut, and we'd sort of drive that based on site analytics, what was popular, and also certain specific keyword targeting that we wanted to do. And then lastly, we wanted if at all possible, to make it fun, make it feel Apple, something engaging, something you'd actually want to play with.

So here is the example of the search results page that we rolled out this Monday. And what you'll see is we're still doing the featured result, we thought that's a powerful element. What we added to it was a complementary result. We've got search results coming back categorically for the most part, we devout to our products, but in certain other areas we bubble other elements up.

We have again, multiple categories, and I'll show you a little bit more about that in a second. And then just a teeny bit of personalization, your most recent searches, some other things that we plan to do in the future. And then just scrolling down the page, you see those additional sections. Downloads, we're actually pulling in the iTunes results from the store, and a few other sections, so. And I believe, let's go to a real demo.

So here's the, are we up? Go to demo please. There we go. So this is essentially the same search, this is Aubrey by the way. Mister Anderson, yes. That's what he goes by. So what you see is actually each category here on the right side is actually an individual query to Google. So we're actually running six queries to Google, which is based on the metadata that we've put into pages. And then we're also making the query out to iTunes. And with the categories you can isolate them, oops, I always do that.

So you know, little enhancements, like if you want to actually, if you're really searching for something and you just kind of want to go through each of the top results of the category, you can move through them. Oops. And then on iTunes we're pulling in, I think we're pulling in a hundred results, and those are grouped into the available sections that the iTunes search service allows us to see.

And so in this case there's some podcasts and there's some music, and just like the iTunes interface, you can move through them. Did I see something called boosicle?

It's possible. All right, well I won't go all the way through.

Anyway, and then so you see most, you can run, these are the most recent searches that I was doing. You can provide feedback, that actually goes into a database that we can see how people are responding to it. I actually haven't looked at it yet, it's been kind of a crazy week.

So, and a couple of other things. So if I run through a couple of these searches, you know, movies are actually a very popular element on the site, the movie trailer site. And so somebody comes here and sees the navigations, like where'd my movies go? So maybe they search for it.

And so we're getting the feature result back, and you can see where else we talk about movies, since it's pretty much an important aspect of our overall strategy. And then you see related store results, downloads, and even some iTunes results. Oh look, the Goofy Goober Rock album, SpongeBob.

So, and the nice thing is we're pulling in, for our own search we're pulling in data from, we do have a number of content management systems for different areas, downloads, retail, things like that. So there's this movie Once that I've been wanting to see, I've heard a lot about. And so if you actually commit a search for that, we actually grab that out of our content management system, and make it a featured result, so pretty cool.

So that's the search results. Now sort of going back to our original site and what we were trying to accomplish, the results give us the categories driven by content and description meta data, we have Google committing multiple simultaneous queries, we're merging in results from iTunes and the online store, we're providing more results inlining the page without having to make an additional query, and I think we've got an enhanced user experience and design that fits the needs of what people would want to do.

So now going beyond that, and avoiding, considering avoiding search all together, what we really wanted to get to was giving the user the ability to have quick findability of items, even possibly the sense of predictability, like we're actually thinking what they might be looking for in advance, and encouraging a little bit of exploration and fun. And so that's where we came up with this dynamic shortcut model.

And so if I go out to Apple, and someone comes to the site, and I don't know, there's this thing we're launching that people are pretty interested in, iPhone. And so we're literally doing dynamic query. Someone types in iPhone, and there's the two things that we'd most like them to potentially do, go learn about it or watch the ads.

So maybe another example is one day this user heard about this browser that you know, some data browser that Apple's doing on the Windows side, but they can't quite remember what the name is. It's like Safarini, or something like that. So they come and they start typing, oh, there it is. Ah, it's Safari. But maybe they've heard something else, that oh it's just a beta, right? Or you know, well it's a new type of browser.

Or well I just, it's got something to do with the Internet.

So -

Aww.

- How about Steve Jobs?

- What are you trying to say? ( laughter ) >> Keep going.

No dice.

Ah, there it is, there's his movie. And I did it again.

So pretty cool. One of the key technology challenges for the shortcuts is they are dynamic, they are a significant load, and our IS team basically demanded that we build something from the infrastructure standpoint that did not basically trespass on the Apple dot com serving environment.

And so that was one challenge. And then the next challenge was this obviously had to be ridiculously fast. It had to be, it had to be as good if not better than actual spotlight in the OS. So that was a challenge, and we kind of started, and we were pretty far down the mountain, and within four weeks we got to a pretty impressive place. And that's where I bring in Mister Anderson. Thank you.

Ah, there I am. So when I first heard about the search idea, a ton of thoughts went through my head, and most of them were just sort of about predicting people's text. This is what we just were showing you, and how to begin to guess at what the user might be thinking as she typed.

And we came to think that we probably could do that, and did a bunch of demos. And we thought we could try a few things, and react in real time as the user searched. Used this thing call AJAX to search asynchronously, which was perform search as you type without reloading the page, begin to show best guesses and narrow it down the more text we got, and then try to enhance the experience and not be annoying. We didn't want to sort of throw something up at the user that would be bothersome, we wanted to try to like help them.

So we thought all right, well we should think about all the products we have, and relate them to a bunch of keywords, right? Should be pretty simple, we'll have a list of keywords, we'll look at the people typing, and if we see one of those keywords, we'll guess at the product or at the iTunes hit, or whatever it was, and show it.

There were so many keywords. We, our initial list I think we had six hundred, seven hundred, and the, we originally thought that maybe we would run it off of a static XML document where you just have it, we'd have JavaScript go out and read a document, parse it in real time, and it wouldn't be that slow, and then there'd be no server hit, it would just be like another request. But the document grew and grew and grew, and before too long it was four hundred K, five hundred K, and there was still tons of stuff coming.

So that clearly wasn't gonna work, we needed it to be, we liked the maintainability of having it all sort of in one source document that people could kind of edit and we could make sense of, but it had to be way, way, way faster. There's no you know, sitting for five hundred K to load while people are searching, that was pointless. So the first guess we had was maybe we'd put a CGI in the middle because we already had infrastructure to do that. So we had a CGI written to kind of pre-parse the text based on whatever letters you threw at it.

And that basically worked for a test, it was really good for proving concept. But it was immediately super hard to maintain. It was still relatively slow to sort the source file, but we tried it as a big flat text file, and, so it would parse faster, and it was still just not really happening. And we also ran into a problem of generally limited semantics, where your search would only match on the keywords.

But sometimes to be more effective we thought it should match in the description, in the title. And so the CGI, that general approach broke down pretty quick. So, I'm slightly out of order. So then we tried JavaScript and pared down XML files, which would hit sort of XML files by section, which were sort of pre-sorted in general, but that was also still terribly slow.

But we liked, once the files were in XML, we liked the maintainability of that, and the idea of you could have the structure of the, what your searching against is kind of indicated in the file, and that it started to make sense We were able to build some business rules into the formatting of the file, and that seemed like a good deal.

But slow. So then I started playing around with a PHP, which we put in front of the XML. Essentially the PHP would read and cache the XML file, which we already liked, but it would only have to read it once, or maybe once per session. We got to maintain our sort of cool editing workflow in the XML, PHP sort of like pre-sorted it based on you type IPH, PHP did the quick search through the XML, sorted it down to a tiny little XML snippet, which it threw back at the JavaScript, which it would parse and show you.

And that actually, everybody was pretty encouraged by that, and it was, it seemed pretty fast until we started load testing. The, it wasn't interestingly the file read or the memory requirements, it was literally CPU load on the processor just under I think thirty concurrent users or something? It brought an XServe to a halt, so not sustainable.

So we started brainstorming, thinking of other possible approaches. We thought about putting it in a SQL database, and MY SQL came up. And we did a quick test, which we've since refined, where the core data would be pulled from our XML file, which we like, thrown into MY SQL as a sort of temporary holding place to cache. Php would sort of do a normal SQL query and cache that as well.

So the more people that used it, the faster it would get. So if you search for IPH, the next person doesn't have to hit the database again, they can go to the cache layer. So rather than having thirty concurrent users slow it down, thirty concurrent users in many cases will speed it up. And then we did the same thing. PHP formatted it real quick as XML, and sent it back to JavaScript. Eureka! Fast, scalable. So what we have now, the current solution has a farm of PHP machines running against a dedicated MY SQL instance, and that seems to work.

Hello. Hi, Mike Czepiel, I'm a web developer on the Apple dot com team. And on a daily basis I get the pleasure of working with some really amazing designers, bringing their prototypes to live using HTML, CSS, and JavaScript, and putting them on the web using web standards technology we've all come to know and love. Increasingly they've been trying to integrate video seamlessly with their work, and today I'd like to share with you how we go about doing that on Apple dot com.

Obviously when you go talk about video on the web, you have a lot of, you have several solutions, but most of them have proprietary closed source, and they require that you invest in a particular tool set, follow certain methodologies, and just basically you're following a particular vendor's workflow. We embrace the open web and try to stick with the standards that we've been using. We were all born and raised on view source, and we like to embrace that. And we use those technologies.

One of the great things about doing that is that by using the open web, we're able to plug in our own video, we're not chained to any particular implementation, any particular movie container format. So when we go to show our products off in the best light, we want to use the best, the highest quality video we can, and of course being Apple, that means that we're gonna choose the best QuickTime.

Unfortunately you don't typically see QuickTime used in this manner. Usually you'll see a page dedicated to QuickTime, and it's just gonna be, the sole purpose of that page is to have a QuickTime video just in place. So you don't usually see much JavaScript interacting with it, which is how you, we'd want to accomplish this.

Thankfully, QuickTime since around 2000, around QuickTime 4.1 actually had JavaScript, had a JavaScript API that you could interact with. You're not gonna find many references of this available online, just because when it first came out I don't think the situation was you know, too conducive to actually do anything really amazing with JavaScript. There was enough difficulty just getting your JavaScript to where it crossed browser, crossed platform, that you know, controlling QuickTime movies was probably the furthest thing from your mind.

Thankfully, the situation's gotten a lot better, and now you can actually do some really amazing stuff thanks to you know, improvements in browsers, development technology, the tools, and tireless efforts of the open source community to make libraries and really smooth over any of these differences. So now that the situation's a lot better, we can actually start playing with the QuickTime API, and do some really awesome stuff with it.

Unfortunately, the QuickTime API really hasn't changed since two thousand. So right off the bat we want to go and start making QuickTime fit into our workflow. We want to make it feel like it's a real part of our libraries. We use prototype and Scriptaculous (assumed spelling) for our JavaScript typically on Apple dot com. And so we wanted to make QuickTime just feel like any other part of that library, anything else that you know, that we'd be using.

So we actually made our own script, kind of in parallel to the official AC QuickTime dot js that's available officially from the QuickTime group. And just to give a modern invocation to how we actually will package up QuickTime on the web, and use in our site. The official version actually uses you know, document write, as you can see on the bottom here, it's a kind of inline, put your QuickTime into the page.

Typically we're working with a DOM tree in this day and age, so we want to be able to use you know, a pen. So we made our script actually package up a movie as an element, a node that we could then append later on into the DOM whenever we felt like it. And this worked pretty well, and we've been using it for about the past year.

Unfortunately you know, we made, we did all this work up ahead to make it easier to work with QuickTime, get into the page, but that really hasn't made the designers any happier. You know, they want a nice interface, but not the same interface we're talking about. They obviously want a nice graphical user interface integrating QuickTime, and we haven't gotten any further along to that goal.

So while we've got it on the page, we still need to be able to talk to it really easily. It's a lot easier getting on the page, now we want to be able to talk to the plug in, and we want to be able to do that in the same way, have a custom class that just feels like a part of our library.

So we've start, we decided to abstract the plug in, use our own custom class that basically will act as a proxy to the plug in, so we never really will talk directly to the plug in if we don't have to. This helps us deal with any sort of cross browser issues, or the plug in being unresponsive at any point in time, or, it really just makes our lives easier.

Like right off the bat, when you go to actually put a QuickTime movie on the page, you're gonna actually, you're gonna end up with two objects, or an object, an embed depending upon which script you use, just because depending upon the browser you use, you're either looking at an active X control or a Netscape style plug in.

You need to eventually figure out which one of those is the one that your browser cares about. The easiest way isn't actually browser sniffing, which you know, you don't want to do. It's actually just hit one of these, and figure out which one responds as the plug in. You might need to do this in a loop, you know, because initially when you load this, the actual plug in's probably not gonna respond correctly off the bat anyways.

And you don't want to be writing this code constantly every time you work with QuickTime. You really want this to be a part of your library. That's the reason we're making libraries, to make it easier to work with QuickTime. So right here our custom control is gonna make it real easy.

We're gonna create an API like this, where we just kind of pass it to node, and it will work out all the details and become the expert as to what movie object it's talking to. So this makes it real easy to talk to our custom controller on our page in a really high level and not worry about which DOM element we're actually referencing.

And as you can see, it looks pretty much like any prototype Scriptaculous you know, library that you'd be used to. This helps us get around other problems, such as the plug in may take some time to be responsive, so again, this is gonna sit there and kind of ping it.

And additionally lets us tie in custom events, or register callbacks. So with prototype obviously we're usually working with callbacks similar to like Scriptaculous is on you know, after finish before start sort of deal. If you're working with the YUI, Dojo, or anything that supports custom events, you might, if you're working with a custom controller on your own page, is one actually implement your own API to fire off custom events that you can then observe.

We want to be able to talk to the plug in in plain English, so whenever we're working on higher level components, we don't want to be dealing with getting the rate of something. It's just nice to have that, a nice common vocabulary of common things that we're gonna be doing, that really makes sense when you see them in code.

Obviously being on the web there's gonna be non-technical people you know, mucking around in your pages, and you don't want to scare them off with any more syntax than you really need. And so this is a nice way to make it really easy for everyone to see what's actually happening in your page. And you can create all sorts of convenient methods for common operations that you might be doing with QuickTime.

We also might want to have certain side effects. So for instance if our controller is keeping track of whether the movie's playing at any given time or not, this would be the place where we do this. So when we send a message that we want passed along to the plug in, this would be where we actually perform other operations.

We also with our custom plug in are able to, or custom controller attached to the plug in, are able to handle exceptions that might arise, or be thrown by the underlying plug in. So we can do certain things like just assume that if the movie's playing, and, or we ask if it's playing, if it throws an error we'll just assume that it's not.

And what's great is because we've put in this layer, if we don't want that to be the assumption that we always make, we might want to cache whether it's playing and return that, and assumed that well if it was playing and we ask and it fails, maybe it was always playing. And this you know, is the place where you tie in that sort of custom behavior.

We can also do some really cool things like cache values. So for instance, if we're in a loop and actually polling the movie to find its status, we can actually you know, cache the value. So if it ever fails when we're trying to find out what time it is, we're not gonna, for instance, we're updating a progress bar, we're not gonna go and shrink it back to the beginning just cause it failed and we're gonna assume zero.

We're gonna figure out where we last knew the movie was, and just append the delay that we have as we're polling to figure out where it should be. And it's kind of a rough guestimation, but usually it works, and it helps keep things look really smooth on the page.

So I'm sure you've all seen Apple dot com, but I'm gonna go to the demo right now and show you a bit of what we have. So here's an example of us using a QuickTime plug in, and our custom controls on the Mac page. This is an example of, this is what we call the front row component, which basically is a way for us to switch movies.

And we've integrated a custom controller which is what the designers are really going for, cause they just want this to look like it's a native part of the page. They don't want it to cry out that it's QuickTime in any way, shape, or form, it's just got to be really seamless.

So we have a placeholder graphic, which can be clicked to play. You click it, and you notice that there's a progress bar that actually indicates the loading progress of the movie, although I thought these were cached. And as you can see it's actually monitoring the movie in a loop, and updating the play head. There's a play pause that gets updated, and this is actually a physical manifestation of the custom controller class, where we just gave the custom controller, since we're doing this quite a bit, a custom render method, which basically renders in the DOM using the Scriptaculous slider.

And we just attach in certain events so that we can tell when the movie if you know, paused, when we want to play the movie. And additionally since it's polling, and it's not actually tied directly to this, we can actually pause the movie indirectly through QuickTime itself, and you'll notice that the play button still reacts correctly. So it's just part of make it really seem like a seamless native part of the page.

Additionally, you can obviously drag, and we're just capturing all the events on the Scriptaculous slider, and just passing that along to our plug in to update the you know, we soft pause this so you can job through the movie easily, and this just picks up where you left off.

We can also now set URL. There's a whole API available to you for changing, manipulating the movie object in the page once its loaded. And so one of the things that we do is we actually let you, yeah this was cached, and now it's just gonna take a while to load. Well, should be able to set the movie, and maybe it will actually start playing.

Yeah. Are they? Looks like same deal here. Okay, so here's another example, you're on the iTunes page with shorter videos that load quicker, except for the Ratatouille one, which is probably long. And so you can see that it actually will swap between the movies and play them, and you still get the loading progress. And it's actually recalculating, and it's doing the whole translate to pixels method that's in the Scriptaculous slider to ensure that the scaling's correct between the movies, which may differ in length.

And additionally one of the nice things is we lost the ability recently to detect the end of a movie, you used to be able to do that QT next and then point it at JavaScript link, and we've actually lost that because of security concerns. So one of the only ways that you can really do this now to have something occur at the end of the movie is to just poll the movie, and when it ends you can fire an event.

So in a lot of cases we have these nice little end states that the designers want to flip to, and so we're able to do that now, so that when the movie actually ends, there was a custom trailer we have that was monitoring it, realizes that, fires the event, and we get you know, the custom end state.

We actually have some really awesome designers, like I said, and some really hard working people in our group that put a lot of work into some of these. Some, one of the most impressive ones I realize on the underlying QuickTime stuff, there's a custom done widget, or component, is the Leopard site, which actually is really neat, because it's you know, got popups, and yet it still integrates QuickTime really nicely.

Probably best to make this wider. And still lets you, you know, navigate in place. And it's just a really seamless integration of QuickTime. And actually it's really interesting is a lot of the comments that I was reading initially about this in various places online after we did the redesign were people mistaking it for some other technology. And so I'll take that as compliment that we were able to fool people a bit.

Yeah, so in general QuickTime is definitely the way to deliver really high quality video.

And it works really well, the API's there, it's been there since two thousand, the state of AJAX development, JavaScript development, DOM scripting is such that you can actually start to really leverage these in your pages. So I would urge you to do so and take a look at that.

Additionally I'll plug the session after this, in the same room, is actually gonna be put on by the QuickTime engineers, and they're gonna be talking about some of the future of the plug in, and some of the really cool stuff that they've been working on, and I'll talk a bit further in depth about some of the browser issues that you might run into. Other than that, I'd like to bring Aubrey back on stage I think, back to the slides.

- Oh man. You know, I think I'm gonna start always wearing gaffer tape on my shirt, that's kind of hot.

So the title was too complicated. Essentially we're trying to get down to the core of what makes a compelling element on the page.

A compelling element is like an on brand experience, it's gonna be exciting to use, it's gonna be interesting. Mike's QuickTime stuff completely rocks it. We want to show with elements, and not tell, so we're not necessarily gonna list a lot of text and have you just kind of like have to deal with it.

We want to do more with a smaller footprint, and to create sort of a unique experience with every widget that really talks about a brand experience. And that's sort of a maybe a bland way to say it, but Apple dot com really is like the flagship on the web for the Apple brand, and it needs to be experiential.

So that's what Flash if for, right? Apple, especially with this revision, Apple dot com has been really committed to using the DOM and using standards based implementations for everything possible. Things like video obviously we're gonna run to a plug in, but even the way the plug in is implemented is leaning very heavily on trying to play nice in the DOM, use the new deal.

There's also some serious benefits to maintaining standards based. You don't have to rely on plug ins to make compelling elements, you, it's indexable, you can search it, you can, you know, Google will index it, it's just HTML. We also recognized a huge benefit with the way things are implemented at Apple, where you have designers over in one building, and coders over in another building, being able to separate the presentation layer from the code is huge in a big team.

And to, for like Mike or me to be able to sit there and buzzing away on JavaScript totally in the abstract, and then just send it along and let people style it in CSS and make it look awesome is really a win for everybody. And the other thing that we're still working toward, but it's, the beginnings of it are already evidence, we want to be able to degrade gracefully, so that you don't end up with the situation like with a Flash widget where if you don't have Flash installed, you don't like it, whatever, you get the broken puzzle piece.

We want to be able to degrade down to just plain old HTML, which is what we do now. If you turn off JavaScript and look at Apple dot com, you still have an essentially compelling experience. It's lessened in terms of the whiz bang as you would expect, but it still works, and it doesn't look terrible.

So how do we accomplish that? You've probably seen Flash on the Apple site in the past, and indeed there's still a team of people who comp, design elements up in Flash, and just to sort of demonstrate how things will work, show them around, especially up to the management level, and get a, just a feel for what we're going for.

So we had to figure out a way, kind of evolve a process to take an idea that was comped in Flash, and move it into standards based implementation. We leaned pretty heavily on prototype for that, and there's just sort of a general compatibility between ActionScript and JavaScript, they're similar.

So what we're doing is, oh I lost my place, sorry. Occasionally with a Flash comp, sometimes we're one to one on features there, we're looking at something, and we can just bring it right over, because it works the same. Other times what we need to do is fairly complicated, DOM wizardry, like where the layering model is different Occasionally we're able to port different math and using algorithms just one to one, copy paste. Toolkits are your friend in making compelling elements.

We've been using prototype a lot, but we've always looked at J query, Dojo has a ton of potential, and is, I urge you to look into that as well, especially the 0 nine stuff. We're gonna talk about different toolkit options a little bit later. In general we are happy.

We've noticed some interesting things about performance, there are in a lot of cases gain in performance over a Flash implementation, and something in standards based with JavaScripting the animation. There's some sticking points like opacities is expensive, you need to kind of manage the way you use opacity in leverage, like p and g opacity wherever possible.

But in a lot of our widgets we've noticed generally when we ported them over to JavaScript based animation it was faster and cooler, easier to interact with. The other cool side effect is that as computers get faster, the performance of a standards based element gets better all by itself without you having to do anything. It, as your laptops get faster, the interpretation of JavaScript on the page is better, and things just speed up. So I want to show you a quick thing here.

As just an example, I'm gonna begin with a page load, because we're looking at this element right here. Oh, these alone. What am I? A? We got it. Hey, cool. The first thing to notice, this component here is moveable. The first thing to notice is on page load.

We wanted to kind of indicate quickly unobtrusively that it does something. So what we did is the little slide in, which gives you an immediate sense that there's more to the story on the left and the right, which is always a challenge with the horizontal scrolling situation. This component acts like any sort of mature widget. There's multiple functionality, different ways to interact with it, and even little Easter eggs you can kind of throw the scroller.

Other things to notice are these kind of little drawer widgets doing more with less, packing more content, creating something more experiential. And then of course these are all links, they're just real HTML. Or not. Okay, that's it for me.

Yeah we're back up there now.

- Oh, are we still going?

I didn't really script this or anything. Pretty much we've been using Apache obviously for searching, or for serving up content, content is really hard to beat in our situation. I can talk about tracking subversion. We recently switched over in the past year to basically any of our new developments ends up in subversion makes it really easy across our entire team to be working concurrently on the projects. Prior to this it was a bit messier, a bit more difficult to actually work with I think, cause people you know, swapping files back and forth, and Apple shares, whatnot. And thankfully Subversion I think really makes it a bit easier to coordinate.

I mean they're, when you -

But I don't think we'd be able to do any work without Firebug at this point.

If you want to talk about some of the server side stuff.

On the server side, as I mentioned, for search we're leaning pretty heavily on PHP and MY SQL. The, we had to sort of make a dedicated farm for those just to get infrastructure happy with their use.

But we've been really, really happy with that implementation, and the speed and scalability is really terrific. It's just -

I mean it's just one of those great rewards to using open source software. And we've also, as I mentioned, standardized in general for Apple dot com on Scriptaculous and, for doing the core of the eye candy, and prototype to kind of back it all up, and make objects, and extend other people's objects.

And that's helped a lot too, because people aren't just sort of rewriting and rewriting and rewriting per implementation. We have just a common core of things that you can implement or extend, almost like a real programming language.

Everyone that I think we were working with pretty much knew prototype and Scriptaculous, they were familiar with it, so it was real easy for us to just get the ball rolling, and start rolling this out across the site.

Here you go.

Thanks guys. So in summary, you know, evolution's a good thing. You can evolve stuff even if it's not a visible change. You know, work on improving the underpinnings of everything you're doing. We're trying to you know, come up with ways of making sure that the content can drive navigation, you know, search is a good example of that.

You know, the up time is a really important thing to us, you know, them talking about the tools, you know we really looked at MY SQL hard, and looked at the libraries, and are these things gonna be things that are gonna you know, be a drag on our pages or be a boost. And you know, we want to pick things that are gonna be really good and smart, and keep the site running. We want media experiences to be seamless, so we need that seamless degradation of stuff.

We want you know, the UIs that we put on these pages to be really compelling and open center spaced. And you know, there's a really you know, a great selection of open source projects out there to help you. And you know, there's stuff we're always constantly looking at. And we didn't mentioned Moo (assumed spelling), we've been looking at Moo a little bit too. You know, the Moo effects guys have been doing some really interesting examples too. So you know, there's definitely a lot of stuff out there to explore.

Couple of things real quick to wrap up. We're kind of doing this one more thing at the end of the sessions to sort of remind people about some things to consider. Since iPhone's coming so soon, there aren't very many things you have to consider to make you know, your site work great on the iPhone.

But here's a few things that we want people to sort of start thinking about, and understand. You know, column layout's great because you know, you can double tap and zoom right into something, so you know, having elements that are boxed nicely is gonna make it easier for people to navigate around.

Size of the page matters, you know, we're looking at, we have a lot of rich graphics here, we're looking at some ways of even trying to be smart and leaner about some of that stuff. Because if somebody's on edge of network, you want to you know, try to make it not a painful experience to get to the content they're looking for. CSS media queries are gonna be a way to help people with some of that, because you're gonna be able to selectively maybe swap between elements.

Couple of specific things that are about optimizing for the iPhone. There's a thing called the view port which basically lets you define the width of the content you're looking at. And what that does is on page load helps you zoom you know, to the right proportion so you see a nice full page. Understanding how double tap's gonna work, there'll be some more documentation about this stuff on developer's site later. Text size adjustment, they're doing some automatic boosts, but there'll be some ways of controlling text.

And then just understanding how events, and how QuickTime content needs to be encoded and embedded in your pages to work on the phone, so. And you guys you know, will be able to look at Apple dot com for some good examples of the stuff in a month or so. So gonna bring George back up here to do the wrap up, and lead us into Q and A.

All right, thanks a lot everyone. So as Dan mentioned, optimizing your content and your AJAX applications for designing specifically for iPhone. For information regarding that as Dan mentioned, there'll be documentation on ADC, as well as Mark Malone who's sitting down here in the front row is going to be your WWDR internet technologies evangelist contact.

There's some useful URLs here for information about getting down into browser user agent detection, some useful hints on what's going on in the W three C working group regarding HTML five, and some of the stuff that we're involved in here at Apple, as well as the CSS three media queries. On the media side, essentially your contact is gonna be Allen Shafer, his contact information is listed above. And there's going to be additional information regarding how to optimize your QuickTiming coding using H264 baseline, and helpful ref movie maker application tools available as well.