Welcome to the session, Safari in the Enterprise. We're, uh... Put up a little slide. That's me. Here at last. I wanted to wait outside a little bit and make sure that people had enough time to come in since the last session went a little long, so pardon the delay on this. Here's what we're going to cover today. A little Safari history and coming of age, building applications that just work from an IT perspective. I want to give you some development recommendations as well as some debugging techniques, common things that folks run into when they're trying to get their enterprise application up and running. And then we've got some special guests here to come up and talk about them dealing with Safari and their organization, what they look at as far as their IT requirements for browsers and their experiences supporting Safari, as well as PeopleSoft here to talk about their experience certifying Safari as well. And then wrap it up with how to partner with Apple, how you can make sure that your enterprise applications work, the ones that you author and the ones that you buy as well. So let's get going. Amen.

First of all, I want to start off with a little road map. We need to set some context for Safari. And just to outline, where we've come from effectively. And the first question you might be asking yourself if you're an IT organization is, oh, yeah, not another browser. I've got to make sure that I test on this browser and why are they going and doing this? And frankly, it's because it's too important for Apple to leave to other vendors. We know that the thin client is dead, or the fat client is dead, and thin client is the current distribution method for all applications these days in an IT organization. So the browser is really your eye to the organization, and we want to make sure that we've got something on our platform that is the best that's out there. Of course, not all IEs are created equal, as you've probably found out. A lot of IT shops would go and standardize on IE. We'd support IE on Windows. We'd support IE on the Mac. And yet there were still plenty of differences there as well.

So what we wanted to do is create a good target on our platform for IT application developers as well as internal developers. And of course to support our developers and our customer community, we need to have something out there that you can leverage in your application if you're building your own app that needs these sort of web application services. Go ahead, you can use our WebKit APIs, build an application that takes advantage of the same sort of architecture that Safari uses for its rendering and its JavaScript.

And to, of course, add the innovative features that you expect out of Apple Computer. A clean browser, a nice browser with features that you expect. Something a little more innovative than just putting up HTML in a window. Thank you. So here's what we delivered. Open source core. Nifty drop in here.

JavaScript core, web core, those are open source libraries created as wrappers around KHTML and KJS, which we sourced from the KDE group. And those of you out there, KDE is, if you aren't familiar, is the windowing environment for Linux. And they use these same core libraries in their browser, their window viewer, and their file viewer, all sorts, all over the place, actually.

It's sort of their main interface for viewing content in their OS. On top of it, we wrapped WebKit, which is a higher level Cocoa API, also a C API. And on top of that, we just built this thin veneer that's Safari. If you look at the stack here, it's pretty true to how much is really Safari. It's about 20% is actual Safari code. And then the rest is WebKit and the WebCore and JavaScriptCore. any changes we make at that low-level JavaScript core, WebKit core, we push back out to open source. So you're free to go to the website and pick up that. Other companies have actually built browsers on Mac OS X around that. And you're welcome to contribute bug fixes or features or all those things as well. We also delivered impressive performance. Our latest iBench scores on the website at dabble.com indicate that we're by far the fastest browser on the platform. With Tiger coming out, we're of course going to rerun those benchmarks and ensure that we keep that place.

standards compliant. Number one, we wanted to make sure that we gave IT folks a target to shoot for that wasn't a browser name. And so we adopted the W3 standards as what we build to. And the W3C is the standards body for CSS and DOM. And we support DOM2, CSS1, CSS2.1, as well as the latest version of Safari that you can download, whether it's the Panther version or the Tiger version, some nifty CSS3 things that still haven't quite been vetted out. And of course, we have to match the reality of the web. The web is a big place and it's not full of standard code. There's plenty of extensions that we've had to add just to make sure that the browser worked with commercial sites that you use every day. We still got some distance to go on that, but we've added some compatibility extensions that are found in all other browsers that aren't part of this standard, just to ensure that we would work properly.

And finally, we created an extensible browser as well. You can create plug-ins. Obviously, the Netscape, we support the Netscape plug-in model. Java applets we support. We added Live Connect with Safari 1.2 and Java 1.4.2, which was great. And we just announced this week a new Cocoa plug-in model as well. We've also extended the Netscape API while working with our partners, other browser vendors that are building plug-ins as well or using plug-ins to make sure that the Netscape API is still alive.

and supported on multiple browsers. So here's a timeline that's pretty... Pretty indicative, well, exactly indicative of what it is. So beta went in Macworld when it was first released to the public. And then we released 1.0 at WWDC. So basically a year ago we released 1.0. 1.1 came out in the Panther OS release. And then 1.2, a significant update as far as I'm concerned, was released in February. And then all along we've had system software updates to provide security patches and compatibility fixes. So, effectively from 1.0 to now, the browser's a year old, and I'm pretty proud of how far we've come in that year.

So going forward, what can you expect? We're gonna focus on consumer sites like we've always done and enterprise applications. It's clear from our requirements that the browser has to work in an IT organization, that it has to perform relative to other browsers, other browsers on other platforms. It needs to support the same applications and we're gonna make sure that it's the best, that the Windows users are gonna be drooling over the Safari implementation. That's definitely a focus. Increase performance all along. We always want to make it faster. And compatibility. Obviously we're going to step outside the standards every once in a while and adopt something that we have to and then push for it to become a standard because we're part of the W3.

And a lot of the features that you've probably heard about here, if you've gone to any of the WebKit features, you'll find out are available in Safari 1.3 on Panther, which is great news, as well as Safari 2.0 in Tiger. here. So let me invite Mark Cianca. He's Director of Academic Information Systems at University of Santa Cruz up, and he's gonna share some of his experiences with Safari, with IT, with all that good stuff. Mark. - Thank you, Mark.

First of all, I want to welcome a rather august crowd here. I know it's an afternoon session, and I'm pleased to see so many people awake at this hour. That's always a challenge for a speaker. I'm here not as a technical expert. I want to make it very clear I manage technical experts. So my promise to you today is that I'm not going to use any management speak, but you should know I'm also not going to teach you how to code a Gronkulator because that's not really what I'm about here. What I am going to talk to you about today is really the customer's perspective in talking about use of Safari and support for Safari within the enterprise. UC Santa Cruz is a campus that's undergone significant growth in the last 10 to 15 years, and we have some internal business initiatives that have to be met in a way that the institution deems to be very cost effective, and web-based deployments help us meet some of those initiatives. We have some external business constraints that we have to meet as well whenever we're talking about enterprise applications. I'll also talk to you a bit about why we chose to engage vendors directly and how we chose to do that, the process, the outcomes, and take you forward into where I think we are today. And based on some of the news I've heard here this week, especially about enhancements to WebKit, what I see is a very bright future for Safari in the enterprise. I want to talk to you a bit about UC Santa Cruz, first of all, because all university administrators have a chronic inflammation of the marketing gland. So whenever we get up in front of a crowd, we actually talk about summary facts of our institution. We're about 15,000 students now. We're a Tier 1 research institution. We are poised on the edge of joining AAU next year, which makes us among the elite universities in the United States. We are ranked first in the nation in space sciences. So those of you who wonder how the heck they figured out how to make the blur in the Hubble telescope work, that was our team at UC Santa Cruz who did adaptive optics. We're second in the world in physical sciences as well. We're heavily into research, we're heavily into science, and we're heavily into supporting faculty who like to live their life at the edge of technology. So that's the kind of environment that we support at UC Santa Cruz.

I'm on the stage today because we are currently most of the way through a very major enterprise application implementation. We are currently in an enterprise-wide deployment of PeopleSoft's ERP suite and specifically their enterprise portal and their application called student administration, plus the Cognos business intelligence suite. Those are the big elements of this implementation. We're moving from an environment in which every user of the system had a nice telnet session into to a 3270 environment onto the IBM mainframe, which is a remarkably fast environment, but a remarkably uninviting graphic environment for users.

The critical success factors for our project were defined pretty early on in the project. Whatever solution we found for our end user environment had to be platform independent. That is to say, we couldn't favor PCs over Macintosh, over Linux, over anything, we had to support a heterogeneous environment and that was defined as a very critical factor for our success. Perceived speed was going to be very important for us because moving from 3270 we had users who were accustomed to lightning fast speed but who had very little tolerance for anything other than environment. And I had this other little kicker I had to take care of which was minimal to no deployment costs. While I love them dearly, I have computing coordinators on campus who get quite edgy when new systems come online and they're required to support end users in a major deployment process.

We want to minimize that or completely eliminate it. Some of the deployment challenges that we had is that we've been in a rolling phase deployment for quite some time now. We started a project, maybe I shouldn't bring this up with PeopleSoft in the room, but the first we actually started with a different vendor. The product that we bought was actually acquired by another company and that product was killed. So then we turned to PeopleSoft and we're hopeful that the Department of Justice sees its way to win a particular lawsuit for us shortly here. As we move forward with PeopleSoft, the other challenge that we've faced is that their core technology stack in the applications that we've licensed actually run on two different versions. So that's another consideration that we've had to look at. administration stack is on PeopleTools 8.1, and their enterprise portal is on 8.4. It may not mean a lot unless you use PeopleSoft, but it is something of a challenge in the way that the browser reacts to the software. And our business intelligence suite was actually licensed fairly recently, and we demoed that product on OS 9 at the time, and using Netscape 476, because that's all they certified for. This is the environment we're moving from. Any of you who've used a 3270 screen before know what this looks like.

This is a typical student screen that we look at day after day after day in the old environment. But what we're moving toward is this broader portal-based environment where staff, faculty, and students will be able to access self-service, administrative services, and functionality through a portal environment that we're pushing to them today. So that's at UC Santa Cruz. How we prioritized our deployments was pretty interesting. Many of our users assume that if an application is browser-based, then there's no real deployment issues. And we've found, of course, that that's not quite the case.

In fact, it's quite the opposite. We know that there's not parity between browsers, even on the same platform, let alone between platforms. And I think sometimes that's a good thing because it pushes browser development continually if you've got feature sets that are available for some but not for others. But the other thing that happened and that really kind of engendered this relationship with the vendors was that we began a consolidation of our IT environment at UC Santa Cruz about a year ago. We were charged with consolidating a very confederated environment and bringing it central. To do that, we undertook a very large data collection effort just to find out what was out there and who was doing what. Another issue that we looked at was that if we encountered platform differences that were too great, we had options that no one wanted to look at. One of those would be to use Citrix, for example, to ensure common experiences for both Mac and PC users. So those are some of the things that we looked at. When I think about vendor relationships, I actually have two working tenets.

First of all, from my perspective, the sales cycle is always open. This means that I always have the opportunity to negotiate with all of my vendors at any point in a license relationship that we have with them, because at some point in the future, we're likely going to be buying more software licenses. So for me, the sales cycle is always open. The other tenet I always assume is that sales staff always over-promise and typically under-deliver.

So we've all been through a cycle where we hear from sales staff, yeah, we can do that. But what they fail to mention is behind that answer is, and it'll cost you $2 million of customization to get that code to work for you, or you're going to have to buy an infrastructure that will cost you 25 full-time employees just to keep that environment up and running. The other thing that we have long known is that sales staff almost never use Macintoshes to demo their products. So one of the things that UC Santa Cruz has instituted is a requirement that any vendor who now comes in and demos an enterprise application has to demo on a Macintosh.

You see a lot of scared sales guys coming in to do demos. But if it doesn't work for a sales guy, it's certainly not going to work for us. So we need to ensure that the products we're looking at from the get-go can be used by a Macintosh population. Well, why is that important? And just this is another little bullet point that I want to point out. When we first looked at Cognos, it was marginally acceptable, but there was a Mac solution, and it meant we didn't have to use Citrix. And that was another big plus for us. So a challenge in getting vendors to understand why we were asking them to demo on Macs was to be able to show them the value of having a product that worked out of the box, so to speak. So like I said earlier, we had this consolidation going on. And as a part of that, actually a colleague here in the audience was part of an effort to undertake a large part of data collection about the campus. And what we learned was some very interesting stuff. If you can see that graphic very well.

This is just a simple bar chart that shows you all hardware, non-academic use hardware, on the UC Santa Cruz campus. There's just over 7,500, 7,600 machines that are accounted for here. And in this environment, 41% are Mac, 43% are Wintel, 13%, almost 14% are Linux or other flavors of Unix. And the rest are, you know, the odd K-Pro that's still running or B-Box or Nextcube or whatever's out there that's still running from 1982. So that's the entire distribution. When we narrow it down a bit and we look simply at laptops and desktops in use, you begin to see that Mac becomes the dominant platform.

So we've got just over 45% Mac users, 43% Windows, and 10% Unix, Linux, whatever, on, again, desktops and laptops. But where this becomes significant for us is in the distribution of administrative users' hardware. These are the people who are banging on machines all day long as administrative support staff in the business function of the institution. Thank you.

So when I get to this point, 57% of my users are Mac users. That means the predominant population that I have to be able to support is Mac OS based. 41% is Wintel. We've got 35 machines that are something else, Linux probably. And then just a smattering of machines that are unidentified in this survey. This becomes really, really important. If you look at the blue column, these are users who are accustomed to calling the help desk.

If you look at the purple column, these are people who are pretty self-sufficient. So whatever I introduce has to continue to provide them with the ease of use and the look and feel that they're accustomed to in using their machines day in and day out. So when we landed on PeopleSoft, that had the promise of providing them with that kind of experience. But this is the kind of number that I now show to vendors when I say, listen, you've got to support Mac. That's my primary population. And because it just so happens that my office also supports Help Desk, this becomes really important to me in terms of workload. So we all had early Safari experiences. Mark showed you a timeline. Well, here's what we learned with PeopleSoft. It worked, but it's slow, baby. It was really, really slow. 1.0, 1.1, PeopleSoft performance was marginal at best. We had some display issues. Intense table structures didn't work very well at all. And the sad thing was, Cognos didn't work at all.

In fact, looking forward to the updates to WebKit, that's really when we'll begin to use Cognos on Safari with some confidence. Right now we've got people using alternate browsers. Navigation was crippled. I couldn't do slicing and dicing on data cubes. And it was frustrating. So we asked for some help.

We have a terrific account exec at UC Santa Cruz, maintains good contact with us, is the kind of Apple rep that I look for who's always wanting to know, what are you dealing with, what are you facing? We approached him a year ago when we first started to use Safari and said, you know, this has got some promise, but it's nowhere close to being where we need it to be.

He then fostered some introductions internal to Apple, and we met up with Apple's Enterprise Alliances Manager in the late summer and actually began a process that has led to us being where we are today. We talked about our project objectives. We actually sat down and looked at Safari using these applications and said, okay, what do you see? How are they coding? What's wrong with this picture? And so we actually got some really great help internal to Apple simply by saying, we know your sales cycle is always open with us, so you all come and help us out. So what we discovered is, well, first of all, Apple had already approached PeopleSoft about doing some certification work for Safari. So we were able to jump aboard a train that had already left the station. The good news there is that we, in the third quarter of this year, have got some certification coming on the portal tool set. That's the 8.4 tool set. It will be certified for Safari. And coming up this fall, for our student administration application, that version of PeopleTools will also be certified for Safari. That means that a majority of my Mac users now work in a supported and certified environment for use of PeopleSoft. We've also brokered a collaboration between Apple and Cognos. Cognos is now updating their software based on some recommendations received in their interactions with Apple so that as they upgrade their BI suite from version 7.2 to 7.3, we should be able to address most of the parity issues and features between the PC experience and Mac users on a Safari. I'm most interested in the updates to WebKit because then we get drag and drop, and my cube users will go crazy because then they get feature parity with their PC users.

All right, so where we are today. I actually feel like we've got some empowered IT managers who have watched this process play out and who are now feeling a lot more emboldened in their dealing with other enterprise vendors and talking about Macintosh support and Macintosh certification, particularly using Safari. We've got in our sites right now, Oracle for use of their calendar application. It's part of their collaboration suite now. Doesn't have feature parity on Macintosh, and that's something that Oracle can take care of for us. Checkpoint, VPN. Chrono software is a time and attendance system. And then we're also eager for this upgrade that's coming at the end of the fourth quarter because that really then allows all of the folks who are using our student administration system to just bang away and be oblivious to the tool they're using and focus more on the services they're providing to students, faculty, and staff. So that's where I'm at on this. I'm going to turn it back over to Mark. He's actually going to talk to you a bit about specific developer recommendations he's got that will help folks like me in dealing with end users.

Mark? Great. Thanks. Thanks. Thanks. Put you back to sleep here. This is a developers conference, so I wanted to make sure that I had some recommendations for folks that are out there building new sites, sort of what to shoot for when you're going to support Safari when it's part of the stack that you support out there and give you some guidelines, because I don't think there's a really straightforward example out there of how to go and build something that's supported by Safari. And it's really, it's quite simple, so let's just start in. It's designed to standards.

Like I said in the introduction, The W3 defines the standards for HTML and the DOM. Hopefully those aren't new words to you. If they are, it's the structure of a particular page. The DOM addresses the particular functions, JavaScript functions that access the pieces on that page. The W3C also defines the standard for CSS, cascading style sheets. That's the layout and the presentation portion of it. So designing the standards vis-a-vis the W3 is the best way to build for Safari. And the specifications are available at the W3C website. Really quite straightforward to go and read what they have. There's also slews of self-help and documentation associated with supporting standards out there. And the benefit is that it's supported by modern browsers as well. My typical message is not, hey, Safari's great, make sure that you support it. It's really Safari does great with the standards. Make sure that you support the standards. Put the power back into your hands. support the standards, the browser vendors will have to do the same. And they actually do. IE, the one that you all know and love, and Netscape, Mozilla, and even iCab, or anybody familiar with iCab out there, does well with the standards. So build to the standards, support all the modern browsers.

Make pages that are well-formed and valid, another very important point to make. Ensure that your HTML is well-formed, meaning if you've got a begin tag, make sure that if the specification requires, you've got an end tag. It's faster. It lets the browser, it keeps the browser, actually, from having to second-guess what you've got on your page, what you're trying to do. Instead of having to put the end tags around and tidy up your code before it draws it to the screen, it's already there. It has to work less. So it's faster. It's a little less fragile, because when we start interpreting what you want to do, sometimes we get it wrong. Sometimes we crash.

Ensure that your pages include a valid doc type. This is critical. A doc type is your way of communicating to the browser what's the standard that this particular page supports. What's that DTD that should be fulfilled by the content on the page? A doc type is very important. If you don't have a doc type in your page, Safari will degrade to a standards minus minus type implementation, sometimes called quirk or quirks or compatibility mode, where we do a lot of second guessing, and you'll find out that we might make things look a little different than they look in IE.

Ensure that your pages are valid. There's a standard out there. Ensuring that it's valid against that standard is another way of ensuring that you've given us a doctype, you've told us how it should be, make sure that you've checked it to ensure that it is. And there's a validator for HTML at the W3, which is great. It's a website you can go and you can upload a file or you could point it to a URL. You can also download this. It's all Perl and run it on a machine internally. And we'll have a recipe on the developer site up shortly on that. And you can also validate your CSS at the same website.

And it's really quite nice. It'll give you a page that shows you exactly what's wrong in your code. And then you have tools probably built into many of the editors that you use for doing validation and checking. So make sure you explore those and find out what they support as far as validation. Validation is extremely important.

Be browser agnostic. How many times have you seen a page where it's actually looking for a particular version of a particular web browser? The best thing to do is to avoid all that user agent, sometimes called browser sniffing logic, if at all possible. And there's ways to get around it using object detection.

If you've got a page that has some complexity in it that you're afraid that certain browsers can't support, it's pretty straightforward to go and see if it's supported without looking at the version of the browser. If you're browser sniffing, then you find that you'll have to constantly update your sniffing code to make sure it goes and supports the particular functionality that you think is on the margins. Object detection, basically it's just checking a particular function before you go and call it. And if it returns undefined, then you know it doesn't exist and you can branch around it and have some other code that will function appropriately or degrade nicely. Once that particular function is supported in the browser, it'll just work, should just You should test it. But it should just work. And you won't have to go and update your sniffing code.

Number one, use the W3 standard way of accessing page objects on a page. This is probably the number one issue I run into when I'm working with developers, trying to figure out why their particular site isn't working. Get element by ID for folks trying to access an element on a page in dynamic HTML is the way to do it via standards, and all the modern browsers support this. I'll show an example coming up a little bit later about how to actually do that.

and get involved. Help us keep the standards relevant. You can do that by pushing the vendors, joining the W3C, just really staying on top of it. There's many good sources for vendor type, sorry, for standards-based information, and here's some I'm putting up here. Dave Hyatt, the last one, is an Apple employee. Great source. They've got all sorts of recommendations, example code, stories about why standards are important they feel there's a real business case for supporting the standards, independent of the sort of the WYSIWYG things that you can do. Thank you. And last but not least, buy standards-based products. Push the vendors to make sure that they're supporting it. They'll come back to us and say, there's a bug in your browser. You say you support the standard.

Here's a standard call. It's not working. Please fix it. And we're happy to do it. We want to be the best standards-based browser on the platform. So. Great, so I just want to run through one more set of things, just some debugging techniques real quick. If you've got a page that doesn't work, a site that doesn't work, run through some of these.

Turn on exception logging is probably the first step that you want to do anytime you're going through a debugging process with an existing site or a site that you're creating. And what it does is it displays the JavaScript and parsing exceptions into the console on the Macintosh. And it's getting better, I promise. If any of you out there, how many have seen the debugging menu and tried to debug? Okay, so it's getting a lot better. And actually, Kevin here in the front row is working to make sure that that's a lot better. And if you load your 1.3 preview or the 2.0 version of Safari that you see in Tiger, you'll see that we've got a pop-up window that provides that same sort of functionality that you used to see in the console but only better. It's not quite Venkman, but we're working on it. To turn it on, you use the terminal. Type in a bit of code. This is also available on the website, how to turn it on. Basically, turn on our debug menu. Once you get the debug menu turned on, then you can select log JavaScript exceptions and they'll show up in the console application.

Another good thing to check for on websites that aren't working is for browser sniffing. I talked about this before and we have a workaround for taking a look. You can pretend to be another browser once you've got the debug menu turned on. a good practice is to go to the site with Safari, see what it looks like. Go to the site with a Windows machine, see what it looks like.

Go to the site with Safari, choose the Windows MSIE setting from the spoofing debug menu, and then hit the site again. And if the site just works, then you know it's the server that's looking at the browser and saying, "I don't support you," or "I've never heard of you before," and then rejecting, sending you back the wrong code, branching you in the wrong direction. This is another great way to find out if something just works and you have to change the server.

Look for the two browser trap. This was another extremely common issue that we've had with websites out there, especially legacy sites, sites that were built to support Netscape or IE. And it was accessing elements on a page with document.all, the IE-specific way of doing it, or document.layers, the Netscape 4.7 way of accessing elements on a page. Here's a sample code.

Here's what it traditionally looks like. Somebody checks to see if it's IE, and if not, assume that it's Netscape. We don't support either of these methods, document.all or document.layers. And that's actually something we thought about doing at one point, but we kept getting so much Windows code as a result of supporting some of these compatibility features that it made sites actually work a lot worse. So supporting the standard was a good thing. Basically, you need to ensure that there's a getElementByID case, basically a W3-supported case of accessing elements on a page. And here's an example right here. put it at the very top, if w3 getElementById, all the modern browsers will fall into that case and get handled and then there's if then else code that degrades nicely for older versions of the browser.

Here's a quick fix that I came up with to fix a site recently that had thousands of pages with document.all on it. It's kind of a useful hack. You can just go and define document.all. If it's not defined, go ahead and define it. You can create functions sitting off the document on your own. And this just calls getElementsByTagName, throws all the elements in there, and then this document.all function is defined for all the subsequent code on a page. It's a really nice hack. Just to bring the site up, see if it actually works with this hack, then you can go and do the right thing as on the previous code example.

Another good thing to try if a site's not working for you is to validate the page. I told you before the W3C has validators for CSS and HTML. So you can go to them, take the source off a particular page that's not validating, and upload it. See what it says. It'll point out all sorts of things that are wrong. And here's an example here saying that it's not 4.0 transitional. So this page evidently had 4.0 transitional in its doc type. And here's all the errors that it gave. And it was quite extensive, actually, for this site. I don't remember which one it was.

Respect the cross-domain frame security rules. It's a mouthful, but it's pretty common in portaled environments, universities and such, where you've got pieces that you're pulling from all sorts of different organizations, little portlets that you've built to support a student system and then some other system over here, and you want to combine them on a page. Well, there's a rule for frames, and it's pretty much the same sandbox rules that are out there for Java. It's that in one frame, you can't access the code elements on another frame if they don't come from the same domain. And so we found out that a lot of folks were running into this sort of issue and merely serving up that portlet from the same domain, they were able to work just fine. The other functionality that they were expecting just worked. So yeah, here's the line saying that. And here's a typical error that you'll see in the console. If you've turned on the debugging to the console, you'll see this in there. And it's pretty clear that this is what's happening. I've run into this quite a bit.

Check the default cookie policy. There's some defaults in Safari that catch people by surprise because they're not what they're expecting necessarily based on a Windows browser perhaps or Netscape's preferences. Sometimes it's just the defaults that are gotchas. And the default cookie issue is generally found on the same sort of sites, ones that are using portals where they're trying to write a cookie from one particular domain and one from another one. And these things are important, the fact that we can block these cookies from a privacy perspective. Our users really enjoy this particular feature, and it's probably bitten quite a few people. And the default is extremely conservative. Here's a picture of it. What it basically says is only accept cookies from sites that you navigate to. So if you have a page that has a couple frames on it, and you're writing out a -- trying to write out a cookie in one frame, and that URL isn't the same URL that's in the top banner that the user went to, then it's not going to write out that cookie. And subsequently, you'll go to another page and things just aren't working because you were depending on that. So this is another great thing. All you need to do is turn on except always in the preferences. And if it just starts working, then you know that that's the particular gotcha.

Check for pop-up blocking. This bit a lot of people. It's an extremely popular feature of Safari. Everybody runs with it on, and traditionally a lot of portal-type applications, homegrown application sites that you build in IT will have pop-up windows on page load or on page unload. It applies to the window.open function, and it blocks those irritating pop-ups that you get when you go to commercial sites, keeps those commercials from coming out. Our customers love it. A lot of them turn it on, and then they end up saying, well, your particular application's not working. So this is a great thing to check. And it's basically associated with window.open, and it prevents any user, it prevents any opening of Windows or calls of that function that's not elicited by a user action, clicking on a button, doing some sort of action. Window.opens aren't allowed in unload handlers or onload handlers, And that's traditionally where these pop-up advertisements come in, and sometimes you'll see this in your code. And once again, it's a default. You can turn it on, you can turn it off. In the preferences, there's the checkbox for it. There's also a setting underneath the Safari menu as well.

And last but not least, turn on the keyboard link navigation. A lot of folks are used to using IE and tabbing around elements on a page, and they go to Safari and they see that that doesn't work, and they complain, they say, your website's not working or Safari's not working. Well, it's really there, but it's off by default. Our preference is option tab, and we can talk about whether we should have done that or not, but the preference is to use the option key instead, and this is something that you can change as well. So through the preferences again, choose the radio button that says tab between links. And once again, you've got the same sort of functionality that folks were used to having in IE.

Great, so that's sort of the debugging techniques. I want to have Jesper Andersen come up and talk a little bit about his debugging techniques, suffering through Safari at early versions, but working wholeheartedly with us to make sure that we got their applications running smoothly. Jesper. - Thank you, Matt.

I am responsible for all the tools and technology at PeopleSoft, so I appreciate the opportunity to speak to all of you here today. I thought it would be a good idea to kind of give you an overview of PeopleSoft. Thanks to Larry and his evil empire, we've got great brand recognition these days. Over the past year, it's really grown from a brand perspective. But in case you didn't know, PeopleSoft is now, since our acquisition of JD Edwards, which was about a year ago, just over a year ago. Now the second largest provider of enterprise application software in the world. We have about 11,000 customers, actually closer to 12,000 customers nowadays. The kind of software we run for these customers, the customers vary between small customers and very large customers.

But just to give you a perspective, we have the largest companies in the world run our software. And the software is truly mission critical. The kind of software we build and sell to our customers and support and help our customers with are used for things like payroll. So if our software doesn't work, people don't get paid. It's that simple. And that's never popular in businesses. I'm sure you can appreciate that. As an example, I know in the Apple community there are many contractors. We have a lot of staffing companies that use our software. And obviously, you know, they use our payroll types of applications.

and they're certainly very critical in nature. The kind of applications we have, obviously, we're dominating the space of human resources or human capital management, as we call it. Financial management is a very strong area for us, so general ledger, accounts payable, accounts receivable, traditional ERP applications. We are doing well in CRM, customer relationship management.

We're doing well in supplier relationship management. With the acquisition of J.D. Edwards, We acquired one of the leading manufacturing application vendors in the world. Most people associate manufacturing with SAP, our big competitor from Europe. It's not a well-known fact that J.D. Edwards, from a manufacturing software perspective, actually have more installations in North America than SAP. So by acquiring J.D. Edwards, we acquired a large install base, and I think everybody would agree that's mission-critical software as well.

We have customers in 150 countries across the world. That means globalization is very important to us. That means working in many languages, having the ability to essentially support different types of applications with local legislative types of flavors of our applications is very critical for our customers. Also PeopleSoft's always been known for our cross-platform support. It's been a true north for PeopleSoft ever since the day we started. We are by far the enterprise application vendor that supports the largest multitude of operating systems, databases, browsers as we'll talk about today, application servers, just to give you an idea, an operating system. A very large portion of our revenue comes from very large companies that are running mainframe.

IBM, ZOS, the operating system is important to us. the MVS, slightly older operating system on mainframe, any flavor of Unix you want. Linux, very important to us today. We primarily are running with Java infrastructure at a mid-tier, and that means we ship our applications with WebSphere and with WebLogic, the two leading Java-centric application servers. And obviously, we have a pure internet architecture, which we're pretty proud about. We were the first company to truly run all of our applications in nothing but a browser, where most of our competitors still had flavors of their product that were heavy, if you like, in nature, either thick Windows clients or at least Java applet types of clients.

Many of them still do, whereas we already, ever since 2000, ran in a pure internet architecture. And that obviously means, given the critical nature of our applications types of applications that if you're having a pure internet architecture we stress browsers and have been stressing browsers ever since 2000 and so that's obviously key according to the subject we're talking about today.

So where are the Macs in our world? Macs are very important to PeopleSoft. Higher education, and Mark was one of the representatives from one of our customers in higher education, is an absolute key area, key industry for PeopleSoft. And I think it's fair to say we dominate that industry. Higher education means payrolls. It means student administration systems. And Mark showed you one of the kind of screenshots of one of those applications. but there's an awful lot of functionality that's going into those areas. It's not just managing the students. It's also managing all the employees at the university, their payroll, their benefits, their training programs, all of those kind of things. So that's an important area for us, University of Santa Cruz being one of our good customers in that area. But it spans the world, Ivy League, universities, all the big universities in North America are pretty much PeopleSoft customers. Healthcare and pharmaceutical is an important area for us and for Apple. Companies like Genentech has an awful lot of Apple computers in their labs and use PeopleSoft as well. So another key area where Macs are important for us as an enterprise software company. Government, key. I can't mention all the different government agencies that use our software, but I can let you imagine who they are. And there's an awful lot of Macs in that area. I think also if you think about higher education, one of the things that's key there is, and I'll talk more about that, whether you're a power user or a transient user, whether you use one type of our application or the other application. Financial services and in general the service industries is an area where PeopleSoft traditionally have been strong, whereas maybe SAP has dominated more the asset intensive industries and the manufacturing types of industries. But those are some of the areas where we see an awful lot of Macs. And so it is very important and has always been very important for us to support Macs in the right kind of way as a first class citizen of the PeopleSoft infrastructure. structure.

So given that, why is Safari important? Customer demand should be obvious based on what I just talked about here. But also, if you think about the user experience, and both of the talks about that before, prior to Safari coming out, we were forced to work with Netscape and work with IE. And it was frustrating for our users for the same reasons that the two previous speakers talked about.

But it was actually equally frustrating to us as a development organization because when Microsoft came out with newer versions of IE they do develop you know smart new utilities great features that we can take advantage of in in our development and in our you know hunt for better and better applications but it's no good when those same features are not available on the Mac because IE on the Mac was always lacking behind and that forced us to cope to code to a kind of common lowest common denominator and and were always forced to compromise and were always, or weren't always, but were falling behind in certain areas, you know, to some of our competitors who just coded for that one platform. And that was a real challenge for us. So when we first saw, you know, Safari 1.0, we just, that was like a sigh of relief. That was, thank God that Apple is going into this area. And actually even more important for us that Apple was so committed to standards like Mark was just talking about W3C. Absolute key for us because we use things like DOM and cascading style sheets heavily in the way that we code our application. There's just no way to make browser experience interactive if you don't. And so the fact that Apple made it very clear from the get go that they were going to code very clearly to the standards was huge for us. If Apple had not done that and we needed that strong support, we would have had to either fork our code everywhere or code some kind of an abstraction layer over these kind of things. And that would have caused performance problems and that would have just absolutely been a nightmare.

So PeopleSoft technology, just to give you an idea about our infrastructure and our architecture so that you can understand how we use the browser. I talked about the pure browser-based type of applications that we have, the pure Internet architecture. You know, from an architecture perspective, we're a true N-tier type of application with often a large database sitting at the bottom with all our transactional data of our customers. But really importantly, we're a metadata-driven architecture. And what that means is the applications that we develop at PeopleSoft are developed in a developer tool, if you like, where our developers and our customers that are extending or modifying our applications define the applications. All of that data about the application is stored in the data as metadata. And that means that our tool set, people tools, as Mark talked about earlier, interpret that metadata and creates the screens that customers interact with. That architecture is the right architecture for an enterprise application. And it is hugely important when you're dealing with as many technologies as we do. So, when we moved from a client-server type of architecture to a web, pure internet architecture, it was easy for us to do because all we had to do was change the tool set to instead of generating a Windows client, generating HTML clients.

Now, that was in 2000 we released it. So you can imagine we started like in 98, 97 even kind of thing. And, you know, after a few failed attempts in those kind of areas, we got it right, you know, initially just with thin HTML because there wasn't XHTML and DHTML and all of those things. We've since then enhanced it to take advantage of all of these things. And it says XHTML here because we use that a lot. But really, a lot of the DHTML JavaScript things are what we are using today.

It's probably also worth pointing out, and I alluded a little bit to it earlier, the difference in users and what their expectations are of a PeopleSoft application. So in the case of Mark in the University of Santa Cruz, it's important for him that we have an application that is really primarily used sometimes by self-service users. That's students that are sitting at home or in the dorm or wherever they might be. They have a normal browser and they access the University of Santa Cruz website to see what kind of courses they're taking, just like they're accessing Amazon.com or eBay.com or wherever they're going. It is normal self-service application.

And that's one type of user. It's kind of the infrequent user. They don't access it very much. Happens once in a while. And they use their Macs in their home for that kind of thing. But we also have power users. Imagine you are a data entry or order entry clerk or imagine you are one of these types of users that sit in front of your screen all day long. You do not want an Amazon.com experience with that. You do not want to have your hand on your browser or on the mouse all the time and point and click and you certainly don't want the screens to refresh every time there's something you want to pick. These people come from mainframe environments, and the screen Mark showed you earlier may not look pretty, but it's very functional. It's tap, tap, tap, look ahead, click down, Bing, select. They've been used to data entry in that kind of world, and it's fast, it's efficient. And so our applications have to mirror that.

If our applications don't match that, our customers aren't happy. That's a power user. Some of those users never use the mouse. They just want to be able to look ahead, tap ahead, all of those kind of things. And so we must support that same kind of interactivity in our application. That's a very different user model than the self-service type of user we talked about before. Accessibility is key for us, right? Especially in the government kind of area I talked about at universities. It's important everywhere, but it's a requirement, a legal requirement when you're dealing with the government. So the ADA Section 508 compliance requirement is very important. The readers that need to be able to apply to the screen to magnify must work within these kind of applications. And obviously ease of use is key and was one of the things that really attracted us to the Safari browser as well because of the visual appeal in the normal kind of tradition of Apple that people have come to expect.

Browser needs for the application. So I won't get quite as technical as Mark got with all of his debugging techniques, but it is a developer crowd, so a little bit of tech speak. Some of the things we kind of ran into early and had to interact a little bit with Apple on, you know, JavaScript event handling. We do use frames. We try to not use it a lot, but we do use it, for example, in our portal, as Mark said. So event handling as you're changing between frames is something we had to kind of work with Apple a little bit on to get to work. Live Connect is a protocol that allows communication between JavaScript and Java applets. And so although I said no code on the client, sometimes we're forced to integrate into environments.

A good example of that is CRM in a call center where some of our partners have developed like floating toolbars where it immediately will show if a call is coming into a call center where you can click a button and pick up the phone. Those kind of technologies aren't pull technologies. They're push technologies, and they've used Java Applet technology for that once in a while. So Live Connect is the protocol for communication between Java Applets and JavaScript. And that was another area we had a few challenges in. Unicode support, obviously I mentioned that earlier, absolutely critical for us at PeopleSoft. Accessibility we talked about. But also like a non-technical requirement. One of the clear needs we had and one of the things that Apple supported very well was just interaction with a browser development team. You know, it was critical for us that we had easy access to the core Apple developers that were able to help us. Sometimes they were able to help us because there were issues in the Apple side of the house. Sometimes they were able to help us because we'd done dumb things. We hadn't stayed true to the standards. Things had worked just fine in IE or Mozilla or Netscape, the kind of things we support, so we had to go modify our code at the request of Apple and at the right request.

So what did it mean for us concretely to support Safari? You know, we took the initial what works, what doesn't kind of testing, we I think kind of late last year had a press release where we announced our intent to support Safari between our two companies and immediately on, I think it was our website or like the Yahoo websites, you know, some Mac user wrote, great, big deal, I'm already using PeopleSoft's application using my Mac. And well, he was able to do that because it was one of these self-service applications. We didn't find a lot of challenges there.

So in the initial step of initial what works, what doesn't work testing, we brought up our PeopleSoft applications, and they worked OK. It wasn't a big deal. Even with 1.0, they worked just fine. It was when we shifted over to those power users I was talking about that it started getting a little more challenging. So that was where we started finding some things. Apple had already completed the, or close, I think, to completing the 1.1 browser when we were deep into our testing of those things. And although, and one of the things I didn't mention earlier that we're very proud of is Apple is a big user of PeopleSoft applications as well. So Apple had PeopleSoft products on site where Apple could, you know, see some of those issues for themselves.

But we didn't think it was fair to the Apple Safari browser team to, you know, have to troubleshoot some of the issues we jointly had on the live system they had. So occasionally, if there were things we couldn't get to work, we had to spend some time writing some simple HTML test cases that we could then ship to the Apple developers so that they could troubleshoot what might be the issue with the Safari browser. And I talked a little bit about code changes. Both of us had to make code changes from time to time. A couple of examples around that at PeopleSoft was the way we do hover over functionality, where you hover over a subject and then kind of text can be seen, we coded that in a non-standard way. Did not work with the Safari browser. Not Apple's fault, supported the functionality, they supported it in a standard way, we hadn't coded it in a standard way. So we have to go back in our code and modify our code. Another way was the way we did file downloads. If you're clicking to something and there's like a Word document and you wanna save it to your desktop, again we'd done that in a non-standard way. And working with Apple forced us to change our code, which I would say was to the better, because now it is in a standard way. And I'm sure there were a few areas where Apple had to change their code as well. You know, areas around hotkeys that are absolutely key for us, for a power user to be able to bind F1, F2, F3 to specific functions, didn't quite work with, you know, the 1.0. So some of the enhancements that we had that we needed to get from Apple didn't quite make it into 1.1. 1.1 was too close to the cutoff, So Apple put them in scope for the 1.2 release. And so we were testing all the way through this very closely with the Apple team with some of the pre-release Safari builds that we were getting directly from Apple and really had a good cooperation from that perspective.

We had to wait for Safari 1.2 to formally certify our release. That meant we missed our release window of 8.4.4, which was at the end of last year where we really wanted to do it. And that's why the formal certification was announced just recently with our PeopleTools 845 release, which we just shipped this month a couple of weeks ago. After we had done everything in my organization in tools and technology where we were running various tests and automated testing and everything, we obviously had to do a full technology and application QA of the Safari browser. And the reason for that is in PeopleTools, we have certain hooks that the application teams can use themselves that give them more free range to do, if not pretty much what they want to do, we kind of give them HTML areas. So an application like CRM, Customer Relationship Management, uses that a lot to be innovative in things like online marketing where they have to have flow of events. And so while if you stay within the declarative aspects of PeopleTools, you are guaranteed certification of the browsers that we certify as an application developer.

We did have to do testing when you kind of stepped outside that as an application developer. We had a customer program, early customer program. Apple was one of the customers in that, but we had another couple of customers that were working with us on our beta versions to try out as power users that everything worked. And that was how we got to support the Safari browser. New releases of PeopleSoft technology. So we will continue to support the versions of Safari that are coming out with Tiger and 2.0 release and those kind of things with the 8.4x code line of PeopleTools. but as Mark was talking about earlier, we're actually very encouraged with the ease with which we were able to adopt the Safari browser again because of the use of standards that we're even going back to our older release of people tools the what we call 8.1.x code line and certifying with that. That's important for things like student administration because student administration is only available on that older code line of people tools until the end of this year and even when that comes out we know that it will take our customers a while to get upgraded so we thought it was important to certify it with an older version also.

Lastly, just kind of want to say that, you know, this was a team effort. As you can see here, this was the team I had on it at PeopleSoft. Not a large team. This was not that tough. I would tell all of you if most of you are Mac people, so you're already probably supporting it. But if you don't and if you have a large website or applications and you are, you know, worried about how much effort is this going to take, it is not that hard. The reason why I had to have, you know, even a team of this side was just because of the critical nature of the applications that we have that I talked about earlier. We had great support from Apple directly from the development team, a couple of technical contacts. I'm sure they were working other things all the time as well, but they were available to us 24-7. So we got all the support we needed, super response, and it was a great, believe me, from all the fires I'm fighting on a daily basis, this one was not even really on my radar screen. I think I had one call with my Apple counterpart during the whole kind of cycle that we had.

So I think it was a very successful outcome. We've just today actually with this conference announced a couple of press releases in not only the availability but also the intent we have. We are now available on PeopleSoft Enterprise which is the product line that was the traditional PeopleSoft that I talked about. But we're also busy certifying our Enterprise One product line which is our former JD Edwards It's one world product line on Safari as well. That will get us more into the manufacturing and the mid-market space as well. And again, we're doing so because we're encouraged by the ease with which we were able to do this. So I would say as a conclusion, you know, this was important for us. This just completely underlines our mantra, which is, you know, we need access anywhere to our applications for our customers. And with this, we have ensured between Apple and PeopleSoft that Mac users get the best-in-class user experience of using PeopleSoft applications. So I appreciate your time, and we'll be available for Q&A as well. Thank you.

All right, so I just wanna wrap it up with a quick overview of, you know, what are you gonna do on your side with, if you have the same sort of issues that Mark Cianca had, or if you have an enterprise product and you want to work with Apple to ensure that it's supported, whether you're writing it yourself or it's something that you need to support your organization. And just sort of number one is to make sure you've joined the Developer Connection. Obviously you're all here, so you've all been part of it, but make sure that QA folks, Make sure that other folks that are using the Safari browser in their day-to-day lives are part of this so that they can feed us bugs, give us feedback, help us get this right. You know what the site looks like. Log in. Just a quick add for the folks that have access to the Safari site, to the ADC, have pre-release views of Safari, pre-release views of Mac OS X, which includes Safari. So if you've got a site that you're trying to get up and running and you want to find out how things are going vis-a-vis the fixes that you've submitted to us, being part of the ADC is a way to download and test those early versions of the browser, see how we're doing. Let us know if we broke something along the way. Sort of join in the co-development effort to make sure that we've got the best browser out there. And so when we GM, we don't release something that's not going to work for you.

File bugs against Safari. Here's the screen. Bugreporter.apple.com. Don't use the bug button. Go and create a real bug for us. That's the quickest way to get something addressed. Your submissions drive our priorities, and the more concrete they are, the better off. Don't assume that somebody else has submitted the same bug you're submitting. If you see something, please go to our website, make sure you log in, give us a bug report, log it against Safari. We want to knock these down. We want to make sure that we're the best browser on the platform. Here's the URL to go and do it if you're not aware of where to go. Thank you.

And finally, I just want to say the anatomy of a good bug submission is a really good, succinct description and your priority of the problem. We need to know that it's something that we can reproduce in-house, so something that's separate from that enterprise app, so we don't have to log in and do the debugging ourselves. If you can narrow it down to a specific function or a specific issue, then it allows us to, gives us the tools to get it addressed much faster, get it out in a more timely manner and inflate what you need. And finally, Safari version OS information. What version are you running?

What's the OS? What's the version of WebKit? Just more details is always better. And of course, whether it happens on another browser, if this is something that works fine in IE or works fine in Mozilla, let us know. There's some things that are compatibility fixes that we do because they work in other browsers, not necessarily because it's a standard-based thing. We need to know sort of what the breakdown is. The popularity of these particular quests help drive these features that come in the next version of the browser. And that's it. So for some more information, I've got some URLs up here.

DeveloperConnection, connect.apple.com. You all know where it is because you got your tickets there. Internet developer site. Within the developer documentation section of our website, there's a whole internet section. There's a Safari section off of that. It's got a lot of good information. There's a lot of good web development, best practices content up there, ways to go and implement new features that we've added to Safari. WebCore mailing list, if you're thinking about grabbing the core of our web kit and building your own product on top of that, if you're an application developer, there's a mailing list associated with that. If you're just a web developer and you're trying to figure out the best way to do something and you want to work with your community, then we've got lists.apple.com has the web development list.

Subscribe to that. Get on there with your web development peers. Ask the best way to do something. It's a great community to go and fix your issues. And then finally, the Safari FAQ, which basically was the root of most of this talk, has a lot of gotchas associated with supporting Safari that a lot of folks aren't used to when they're using another browser. This is a great resource to go to. We keep it up to date with the latest features that we add, try to add some examples. It's sort of a good one-stop shop when you see a new Revit Safari. it.