Welcome to the session Safari in the Enterprise. We're, 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 in 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.

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, 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, we want to make sure that we have 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, 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.

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 web core and JavaScript core. 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 DOM 2, CSS 1, CSS 2.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 CSS 3 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 interesting.

So going forward, what can you expect? We're going to 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 going to make sure that it's the best, that the Windows users are going to 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. So let me invite Mark Cianca. He's Director of Academic Information Systems at University of Santa Cruz up and he's going to share some of his experiences with Safari, with IT, with all that good stuff. 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. 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 that.

We 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 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. Student administration stack is on PeopleTools 8.1, and then our 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 and to build a 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 we, 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.

So there's a lot of stuff that'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 data. And that's the 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.

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.

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 it. 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, minus. 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? this 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 doc type, you've told us how it should be, make sure that you've checked it to ensure that it is. 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 can 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 work, 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 and why they feel there's a real business case for supporting the standards, independent of the sort of the WYSIWYG things that you can do.

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. 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 any time 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. So 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 MSI E 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 get element by ID 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. W3, get element by ID. 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 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.

Well, 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 window. 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, Mark.

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, they use our payroll types of applications. And they're certainly very critical. And they're certainly 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 manufacturers. We have the largest 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.

We have customers 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. Also, the MVS, slightly older operating system on mainframe. Any flagship. Any type of driver 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 and the different types of applications, that if you're having a pure Internet architecture, you're going to be able to de-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 it's a great opportunity to be able to use the software that's available to us.

So 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 people are very interested in and they're very interested in and they're very interested in. 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.

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 marks talked about that before. You know, 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 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 lagging behind.

And that forced us to code to a kind of common, lowest common denominator. And so we 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, 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, 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, just absolutely been a nightmare.

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 and 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. It 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. You 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. 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.

Right? Data 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.

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 and all 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. And 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, you know, 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 J.D. Edwards 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 want to wrap it up with a quick overview of, you know, what are you going to 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.

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 API. 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-- 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.