Good morning. Thank you for coming. This morning's session is Solutions for WebObjects. My name is Robb Beaul. I'm a systems engineer with Apple iServices. Today's, this morning's session, we're going to talk about examples and case studies of how WebObjects has been used to bring information to the web, streamline business operations.

So what do we want you guys to take away from today's session? Robb Beaulieu, Well, we want you to know that WebObjects is being utilized in extremely innovative ways. We also want you to realize that WebObjects solves myriad business problems, from integration-intensive portal apps to visually rich consumer applications to business-to-business apps with enormous returns on investment, etc., etc.

We also want you to realize that WebObjects projects have high success rates. For those of you in the audience that are looking for WebObjects solution, when you pair a great developer with WebObjects, be prepared for extremely great things to happen. And finally, we want you, the WebObjects developer community, to retell these stories to your prospective customers. And so with that, I'd like to introduce our first speaker, and it's with pleasure that I do that, and Brian Fitzpatrick.

Good morning. My name is Brian Fitzpatrick. I'm a senior consulting engineer with Apple iServices. I was tapped to head the VRWay project last year for the VRWay International Company. And my history is I started doing web programming back in 1994, back in the Paleozoic era of the internet, with shell scripting, Perl scripting, and eventually I moved up to some other people who consider themselves to be competing technologies such as, oh, I can't really mention the names like Active Server Pages or ColdFusion. I found WebObjects four years ago, and I said, wow, this is the most incredible thing I've ever seen. I've been rolling around on a skateboard, and I've got this great Rolls Royce to drive around in.

So I... I got my stuff together and came to work for Apple. In July of last year, my boss came to me and said, Fitz, we have a client for the big project. I said, well, that's great. I said, I love big projects. He said, they want to do quick time VR tours of Europe, different cities. I said, well, we can do that.

He said, we want to do WebObjects to do quick time tours of cities in Europe and image maps. We want to do image maps of Europe, of different countries, so that users can click their way down from a world map. all the way to a street. I said, well, I said, we can do that.

He said, on top of that, we want users to be able to add comments and reviews of all the VRs that they see. He said, and we also want to have a chat room. I said, not just a chat room, one chat room for every VR. I said, well, we can do that.

He said, oh, and we need a back office application for users, for the people that work at VRWay, to import QuickTime VRs, image maps, tie them all together, tie one city to the next, tie one country to the next. And we need it all in three and a half months. I said, John, using WebObjects, no problem.

This is a screenshot of the front page of the VRWay experience, as it's called. This is a company that's international, however they are based in Switzerland. When a user comes to this page, they can, by clicking the VR across the top, which is just a static image, it's a randomly generated image, they can find themselves right there. For example, here it would be in Barcelona, Spain. Or, they can click their way down through a series of image maps. Europe is what's implemented at the moment. So starting at Europe, and then they can click their way into Italy.

and then down to a city, for example, the city of Rome here. You'll see several highlighted blocks. They can click on one of those highlighted blocks and what you get is a street map with a bunch of little orange dots that are numbered and they're described in detail below whether they're an inside VR or an outside VR, what they describe, what kind of a VR they are, whether they're a plaza or a street or maybe a shop or something like that. There's also a little white triangle so you can navigate laterally, sideways, up and down if you want to go look at a near part of the city. And finally, you find yourself looking at a fountain in the square of Piazza Navona from your own house.

Now, we used WebObjects, QuickTime, Mac OS X, the old version of Mac OS X, an Oracle database, and Apache to make this happen. The client said, for our baseline 1.0 release, we want to scale to 600 users. So we got some testing software. We stress tested these applications. Not only did it scale to 600 users, but we found that four G4 app servers, these are older G4 app servers, not the new screaming dual processor 3 gigahertz processors, four 500 megahertz G4 app servers saturated a 32 megabit per second link.

The WebObjects application tied the VRs together. All navigation is mediated through the application. So when you click on a VR, on a hotspot, in a QuickTime VR, that hotspot request is intercepted, sent back to the WebObjects application, which can do whatever it wants with it. In one case, it might link to the next part of your square you're going to, a link down the street.

It might link into a shop. The VR way experience is being modified as we speak to add more and more shops and stores, so that when you click your way down to Piazza Navona in Rome and you see a shoe store there, well, you could click inside the shoe store. You could go into the shoe store, look around, look at some shoes, maybe even purchase a pair of shoes.

The country region navigation is static images, but the image maps, the image map tags in the HTML are all built by our WebObjects application, tied into our model. So what that enables us to do is we can turn on new parts of a city, we can turn on a new country, all from another WebObjects application. No sweat.

The navigation and the VRs are added on the fly. So they send a photography crew out to San Jose. They go around, they take 360 VRs of all different parts of the city, they come back, do a little post processing, and before you know it, they're in the experience. Reusability.

In some of the previous technologies I used, I wound up doing a lot of code reuse, which consisted of cutting and pasting. People on my team, in fact, I know one of my lead guys is here, he knows that my mantra was cutting and pasting is not reusability.

Taking HTML and SQL and all that stuff mixed up, pasting it on another page, not reusability. WebObjects component model, where you can have a component as large as a page or as small as a character, enables us to factor out parts that we wanted to reuse from one page to the next. We had whole widgets that held QuickTime VRs or image maps that we used from our front user application to the back office application.

So, a lot less code to write, a lot less code to maintain, a lot less headache. Widgets. Simple widgets. Some of our components were a pop-up menu, for example, a list of countries, a list of cities, a list of types of VRs, maybe a shop, maybe a street, that sort of thing.

We had this chat problem was a particularly hairy problem to address, so what we wrote is a framework that wrapped this procedurally oriented chat commands into an object oriented framework. In our application, we just say, you know, new chat room, this is the name of the chat room, and go. And that was all there was to it.

Using object-oriented design enables us to really come up with an application that can be maintained. An application that can be changed. We came up with 1.0 and they said, "Wow, this is great. We're quite impressed, but our graphic design guys came up with this new stuff here. How long is it going to take you to get in?" We said, "Well, no problem." We handed it off. Never had to change a line of code because of the way WebObjects use templates.

They came to us and said, "We've got this 1.0 thing. We have this VRWay experience. This is great. We want to add another feature. We want something like MapQuest. We want to go to a hotel and say, 'Okay, we're going to put a link on your page that links back to us, opens a little pop-up menu, and allows users just to see stuff about your hotel, for example.'" Because of the way we factored down all of our widgets, made things small, reused components, We knocked this out in record time, like a month, month and a half. Absolutely unbelievable turnaround on this. And it required very little change to our existing widgets. And on top of that, we managed to reuse all the stuff we'd already done. Less code to write, less to maintain. That's the way I look at it.

Less than ten people knocked this whole thing out in less than four months. A series of five applications and four frameworks. And it works great. And you can go there today. It's www.vraway.com. Now I'm going to introduce you to the next presenter, which is Bob Frank, who is one of my colleagues in Chicago. He is a senior consulting engineer with Abalyze Services.

The basic architecture has, I'm sure this design pattern is fairly familiar to those of you that have done WoW work before. There is a few core frameworks that contain their common EOs and some other core components, and a variety of separate frameworks that use each of these core frameworks to produce individual services. And as you can see from the UI screenshot, each panel was basically a different service. And all of this is wrapped inside the basic application. This is very flexible, and this is a very powerful design pattern.

The key features that they have implemented, as I mentioned, was webmail. They also have integrated security through the entire application. I'll talk more about that in a few slides if you are interested. It's a Kerberos-based security system. They have an address book, a calendar system, course schedule from their student information system, classified ads, and all of these are their main features that they were able to deliver to their students.

This comes from a variety of heterogeneous data sources. First and foremost, a variety of several different Oracle databases. They have some data coming in from XML feeds and some data derived from a Lotus Notes application. Their mail is provided via IMAP, and of course, outgoing mail is taken care of via SMTP, and directory information is provided from LDAP. All this is integrated together using that basic architecture.

Their development environment, in the university environment, they have a variety of different machines, and we had a lot of different people working on this project. It was cross-platform. Development took place both, the majority at the university was on Mac OS X server, and there were some developers using NT. For syncing up all the developers' work effort, they used CVS. If you don't know what CVS is, you should learn, and if you do know what it is, I recommend that you all use it.

It'll save you a lot of pain. The basic application was, CVS is a core source code versioning tool that allows different developers to work on the same code and manage changes. The basic design that I showed you in the architecture slide is a central application with a few core frameworks. What this really allows, in a variety of different ways, in addition to rapid development of new services, is it also allows a lot of parallelism.

It allows developers to work on different feature sets and to produce new features, I think, more quickly. This is particularly, I thought, from a developer's point of view, an interesting feature. They had an integrated bug tracking system that they developed, and this was integrated into the entire application. They had a lot of work to do. They had to log this exception and feed that back into their bug tracking and feature tracking system. Additionally, they leveraged these core frameworks to produce this type of application and several other back office administrative applications.

This was a joint effort. The technology demonstration in the spring was primarily an AIS-led effort. And then for the entire development range was primarily a University of Michigan-led effort with some AIS consultants, some on-site training provided by AIS. There was also additionally, the University of Michigan took advantage of some training provided here in Cupertino.

I think that was some of their

The development environment. They have a development integration server that is both the application, the wall application, and the Apache web server on the same box, and the various data sources on separate boxes. The only difference between their development integration server and their staging and deployment servers is that in the staging and deployment arena, they are on separate boxes.

A moment ago I mentioned that they were able to integrate Kerberos into their system. Kerberos is a very powerful authentication and security technology. The University of Michigan is using Kerberos pervasively through all of their services across the university. This allowed them to leverage a variety of other services inside their student portal. So for example, on the web-based email system, their authentication is provided using Kerberos. This allowed, this Kerberos integration with the portal allowed them to then access the individual user's email and then present that over the web pages.

Their UI provided a configurable approach to providing different services on their front page, and some of them were in this mini type of a view. The left-hand column allowed you to have short summary pieces of information. For example, you have a lot of unread messages. This type of UI allows them to provide summary information on a front page from a variety of different full-fledged services. Additionally, this calendar view did not lend itself to being compressed into a narrow column. They provided a wider approach to it.

Another interesting feature on the entire application was that they were able to integrate a help functionality into the entire application. Each service has the option of providing help with some sort of small amount of help for the local features in that mini panel. Or, if you need more in-depth help, a tour or so forth, they can take you to a full-blown help system. This provides a great deal of upfront support for the users of the system and cuts down on the calls that they receive to their support lines. Additionally, since it's fully integrated, it allows them to easily augment it when new features are added.

Another system that I think was very interesting was a calendar system. This integrated with their student information system to pull down calendar and schedule information from their student information system. This means that if you have a class scheduled at a certain time and day, it will display in the student's calendar. Additionally, they were able to use this basic system to have personal calendar information entered. I think that this allows you to have all of your information available from any web browser on any system that you can get access to in the university system.

A simple screen that allows you to add event. They spend a lot of time working on cleaning up the user interface. This web-based personal information system includes several other features, and I have a few slides to show you what it looked like for that. Basically, it allows them to have the calendar, which I just showed you, and an address book, and the to-do list. The long-term goal of this system is to provide integration with other desktop PIMs, so you can do importing and exporting.

Their mail system is the, I think, the most look forward feature for the students. It allowed them to have simple web-based access to their email system. Previously, for the most part, they were using text-based systems. Some of them, as far as I know, were using some desktop clients, but with a desktop client, they were limited to a situation where they had their machine that their software was installed on. And with a web-based system, they're able to, once again, access it from anywhere in the university. This is a shot of what their UI looks like for viewing an individual message.

and Composing a Message. Additionally, another feature that they wanted to add, allow the students themselves, not outside vendors like you would find in a traditional classified ad in a newspaper, but just the students themselves to utilize the system to exchange products or sublet apartments or resell books at the end of the semester. This is not an auction type of a system. This is a simple marketplace for students to exchange whatever they want to.

This is a screenshot of what the To Do system looks like. This basically allows them to go ahead and keep track of various events, very similar to what you'll find in the other personal information manager systems. Portable Bookmarks allows them to be able to keep track of There are favorites from not just one browser and one computer, but we'll actually follow them wherever they log in in the system.

And this allowed the university to insert links into their students' bookmarks as well. An additional enhancement that might occur in the future would be on a per class basis. If a professor has some sort of information that is relevant to the research for that class or a particular session of a class, they'll be able to provide it in an automatic way to the students. Go ahead and log on to your homepage and here it is.

Their long term goal is to continually add more services as more areas of the university want the ability to add specific features and to be able to integrate on a general level with The existing course materials that have already been built in. For example, with the calendar, there might be a desire in the future to add more services based around course information or course materials.

and none of this will require rewriting of much of the system because the infrastructure is already built into the core systems. And now I'd like to introduce David Black, another consultant with Apple iServices, to talk about logistics management, a very good success story with a large logistics management company that we can't use their name today. Dave.

Thanks Bob. Alright. Welcome to WWDC. It's Wednesday, or hump day. Alright.

All right, there we go. Logistics management. It's the business of moving stuff around. It's also the physical aspect of a supply chain management. And most companies, what they'll do is they'll just outsource all of the warehousing, all the shipping, and everything, and they just basically become the smart brain trust of their company and then let some other company do all this other stuff. So this particular company provided all this. And anyways, they asked us to come in and do the work for them. So let's hope.

So what are the critical requirements of providing software to a logistics management company? In the logistics business, information is absolutely paramount. It is what gives each company a competitive advantage. If you use some of the systems out there from various shipping companies that you might mail order something from, you'll see just how valuable it is for you to see where your packages are.

Well, when you're trying to manage a supply chain and you're trying to get time, the delivery of different products, it's very critical for the companies who are actually shipping things to actually be able to have those views into that tracking data. So anyway, basically these systems had to be accessible. And that's probably the first reason that they came to Next when WebObjects was around, because it was really the first solution that gave web-based access into legacy systems.

And so they... were able to, at that point, be able to give access into maybe a shipping dock in the Philippines or to an import/export desk in Turkey somewhere. So anyway, accessibility was their number one reason at that point to go with WebObjects when they did. Secondly, they needed scalability. They needed something that would scale up. I mean, these were big databases. They needed interoperability.

They had to tie into the customer systems. They had to also tie into their own legacy systems. They also needed rapid development. They did not want the typical, you know, one year of planning, one year of development, then, you know, one year of deployment and bug fixing. They wanted the stuff to be turned around in three months, you know, to six-month cycles. They also wanted rapid adaptability.

These applications needed to basically be able to be replicated for each customer that they had. Some companies will basically put all their customers into one database. This company actually wanted to have a separate database for each company. Because I guess if one company left, they could just throw the database away. So anyway, let's... Okay, so the environment that they had, we used Solaris for test in our production applications. We used Oracle on HPUX. Development was on Windows NT.

We did version control with CVS, and while I was there in the last few months, we were actually trying out CVL, which is a nice graphical user interface for CVS, and it seemed to work really well, integrated with Project Builder. Now we don't need that anymore with our new Project Builder. It's built in.

We also had two to eight consultants on site, and these were consultants either from Apple iServices, or we also used a variety of subcontractors. All right. While we were there, we developed some common frameworks, and I'll just run through these really quickly. We had security authentication, personalization, and what we had was called a logistics kit. And so starting off at the very bottom here, we have our WebObjects and EOF libraries that you can buy.

We had our security framework, which was basically a framework that we could bolt onto any of our applications that would communicate with an authentication server and basically communicate back to the application that a person did have access into this particular application. We also had a personalization framework, so that once a person was in the application, it basically controlled things like access into certain administrative screens or gave them different types of views into things. We were able to store permissions.

Form fields would turn on and off. We were also able to put things like mathematical constants. A variety of things were in this personalization framework, and based on the customer and some other things in their particular use case, we were able to really give them a fine granular level of control in the way their application behaved. There was also what we called a logistics kit.

This was a collection of common code, utilities, widgets, and other things that we could use to control our application. We also had a lot of software. We had widgets. We had calendars. We had date formatters. We had all sorts of stuff in there, and it was just kind of a grab bag of different things. On top of these three frameworks, we were able to then build our custom application logic for whichever application they needed us to do this for. Let's get into some of these.

Shipment tracking. This is probably the most... typical application of any kind of shipping company. Basically, if someone is shipping something, they enter it in that it's gone out off of the dock. At that point, everyone can start to see where it is in the process. It's tracked through its entire process from going from point A to point Z. And this particular application that we wrote, it gave, it integrated really nicely with some of their legacy systems. They actually had in some part of their environments, C++, Fat Client.

That would, they would use to enter some of the data. We also did some web integration with this with barcode scanners, a little bit of JavaScript. You just fire the thing, it gets field to field. It's pretty cool. We also were able to customize this application and put it into new customer space very quickly.

If the customer had no customer requirements, we could just turn it on in a day by creating a new database for them. And our authentication framework actually told which database that the application would be pointing to. So within the context of one session, we could actually be going from one database to another dynamically.

We had a return tracking application that basically managed the whole process of people sending back merchandise that was broken, things like RMAs and what have you. We also did what's called a consolidation management system. This posed some really interesting challenges. Let me tell you real quickly what consolidation management is. Basically, when a company has, let's take maybe a wireless phone system provider, they get a contract to install 12 cell sites in a city.

The company installing this needs to be able to coordinate the delivery of parts from all over the place into one center and then immediately have them sent out as one big package to the cell site. So this system actually, it's kind of like just-in-time compiling. Sorry. Anyways, so this system actually allowed them to do this.

It actually saved this company probably millions of dollars in warehousing costs because they were able to time in a very precise way when stuff arrived. They were able to hold shipments back from different vendors and things and get it all to deliver at the same time. So anyway, this was also interesting because we had to integrate with a database that was not supported by WebObjects.

They wanted to build an app server based on progress and build a fat client. They wanted to build a client interface for that. And so they came to us and they're like, you know, progress doesn't have a database adapter. How are you guys going to tie into this? Well, we found a Java API library for progress, and it was just a matter of hooking into it with the WebObjects framework layer. And so essentially we created our own, instead of using our enterprise object framework, we were able to just tie directly into these Java APIs.

So, you know, when we were doing this, we were able to do it. And a lot of people are worried about, you know, what kinds of databases WebObjects support. This actually shows that you can use libraries from those vendors to be able to actually get at the data and be able to talk to other systems without actually having to use maybe our database connection layer. So that was a little bit of an interesting problem.

How did WebObjects help us there? It was just great. I mean, it was, it actually, if you look at what I just showed you compared to some of these other things you're seeing, these applications were not sexy. These things were business applications. They were all about money. They were all about getting visibility into these systems.

And so we basically... were able to do this really quickly, be able to meet all the requirements. But the most important thing to me was it was fun. I mean, WebObjects just made this kind of development great. I've been doing this type of work for probably about five years now. And I, well, let me digress here. Five years ago, I was at Nortel Networks. We were doing some work with a product that I won't mention, ColdFusion.

And... Excuse me. So anyway, we were scaling some of these systems there. Really, these systems just kind of got out of control. Everybody started wanting to use these things, and our databases were getting huge. We were getting a huge user population. We were having to buy hardware. We were throwing everything we could at this application. And it was just getting insane. So it just stopped scaling.

We were getting four second per page response times and what have you. So we started looking at WebObjects, which was also considered the standard at Nortel at that time, though our department didn't seem to agree with that. So we started playing with it. And I mean, immediately, out of the box, we were just blown away. I mean, it was like, this does everything right. I mean, I can forget.

The whole user interfacing, I can forget this whole database thing, I can focus on the business in the middle rules, and I'm not really Mr. Web Architect, but hey, I'm about to develop a system that's perfectly three-tiered, and maybe I'm new to this, but it's still going to be pretty darn good. So, we started playing with WebObjects, and it was cool, and they came to us and they said, well, you can do this little application in WebObjects, knock yourself out, so we did.

And they said, well, we also need you to do a little bit of cold fusion. who said, "Sorry, we're going to Apple." So anyways, basically I love WebObjects. It's a great application to work with and I hope you guys have an opportunity to play with it if you already haven't been playing with it some. Alright, that's it. Thank you all very much.

We've got a really cool presentation now. I mean, my stuff wasn't sexy. This guy's stuff is really sexy. This is Ricardo Florres. Thanks. Thanks, bud. Thank you all for coming. Again, my name is Ricardo Florres, and I'm the Consulting Engagement Manager for Apple Eye Services Southwest. As you've probably surmised by now, Apple Eye Services is the consulting arm of Apple Computer.

I'm here to talk to you about Build Online by Modern Postcard. Modern Postcard is a small company located in Carlsbad, California. Small in size, large in revenue. And what they do is they create postcards for individuals and for corporations. Sounds very simple and kind of a niche, but you'll see that it's much more than that.

What Build Online is, it's the result of their request for us to build them a web portal that will allow their corporate and individual customers to jump online and create dynamic web pages that allow a level of customization that we were unable to find any place on the web.

When they got this idea, and I'll show you a demo in just a few moments, we spent about two weeks scouring the internet trying to find something that did what we envisioned the way we envisioned it, and we couldn't find it. We found a lot of things online that did postcards. But not really. what we intended to do.

The goal, obviously, is to make money, and that's a common thread that all of our presentations have. Yeah, they're cool, they're sexy, and yeah, they were fun, but if they're not driving revenue for the customer, we're not there, and the project ends. So that's obviously the goal, and for modern postcards, market penetration is the key to actually driving revenue, and they penetrate a number of different markets. Individual selling cards is obviously a key component for them, and there's a big business, and people just printing cards of their dog or their daughter or what have you.

The real estate community is really significant because you probably get a lot of cards in the mail, postcards from realtors either pushing themselves, pushing a property, pushing Remax or Century 21, what have you, and a lot of those people use modern postcard for their services. The artistic and design community is one of their biggest focal points, and the reason is, if you're an artist, and you create a piece of work, and you pour your lifeblood into this, and you're trying to distribute this to the masses, you want something that really represents what you've done. The look, the feel.

The depth, the texture. If it's fuzzy, if it's jagged, it's not going to work for you, and so they have the highest end technology that can produce a postcard with whatever you want, however you want it on the front side. And also from a gallery perspective, if they're actually presenting something, they want to present example or examples of the artwork of the artists, that's what they do, and so it looks great. And so they do a significant amount of work for artists, for designers, and for the artist and design community. But where the real revenue is, and where the real push is, is the art.

is obviously the corporate community. And the best example I can think of to give corporate postcards is when you buy some software and you crack open the box and all those cards fall out. Say, register your software and get support and look at all these other cool products that we make.

Those are postcards and they're not the postcards on the little revolving kiosk on Hollywood and Vine that says welcome to California and now go home. They are revenue postcards. They're postcards that drive money to businesses for their goods and their services and that's where the real money comes and so that's where we were really focusing doing this effort.

So we had a number of requirements that we had to do for the development of this product. Some of them pretty generic, some of them very specific. On time and rapid development, a good thing to have. Application scalability, another good thing to have, but we took it one level further. The demo you're about to see is a 5% solution. We anticipated full community revolving around this application you're going to see with a bunch of other features that we were just trying to flush out right now.

But this is minimal compared to what we're going to have in three to five years. It's also driving a significant amount of revenue at this point. And we had to make sure that all the objects, all the frameworks, all the code is going to be usable because we're going to scale this extremely quickly and we're not going to have time to go back and reverse engineer or take components out. We must move forward, so scalability had to be at 100%. So we're really taking the object approach doing this to make sure that all the objects and all the frameworks are going to be reusable.

A streamlined UI was important because we had an existing solution that they had online when we got there. It wasn't very elegant. We introduced some tracking mechanisms that showed that their usage was low and also it wasn't driving people back to the site for repeat business. Corporate licensing was very low, so it really wasn't hitting their target space and we've been able to do that and I think you'll see why. We had to interface with existing back-end systems. Again, always an important thing, but we had some unique challenges. Modern Postcard had several disparate databases.

And they were all linked together and so we had to actually go and touch these databases and make sure that we traded data back and forth in real time as people go into the order screen, put in their name, their address, blah, blah, blah. We had to make sure all that goes into the database, matches with existing records, updates when appropriate, and then spawn to all the other data sources.

Not an ideal solution, but it's the world that they had when we got there and so that's what we integrated with very seamlessly. And yes, we're trying to get a better singular solution and that's coming, but that was the world that we had. And so we had to go in there and say, "We're not going to tell you what to do. We're going to integrate with what you have," and that's what we did.

But the real rub of this whole thing is real-time preview. What real-time preview is, it allows anybody to go online and create the postcard and actually get a finished product online. The problem they had was, if I go online and create a postcard and I say, not exactly what I want, I want to move this here, move this there, do this, do that, what I would do is I would jump on the phone and call one of their highly paid design experts and say, can you move that to the left a little, can you change the text to red? And this guy's making dollars per hour going, yeah, sure, no problem, fourth phone call, fifth phone call, and the margin of those postcards keeps getting driven down because he's billable to a postcard that we hope this person eventually purchases.

So the margins were very low. What this has allowed us to do is, and the requirement that we had was, 90% of the time, we wanted a customer to jump online and do the tweaking on their own dime and their own time, and when it's finally what they want, they can hit order, and then it goes to the design guy, and then he makes it camera ready. And shoots it.

So it's really streamlined, it increases the margin of every postcard, and it's also kind of cool for the customer, and very quick and easy for the customer, so it drives them back to the site, which was another key component that we had. So the real-time preview was the most challenging thing we had to do, and the most important. It's what separated us from the pack.

So how did we do that? Well, we had three key components. The first one is obviously WebObjects, Apple's core development tool. The second one was Flash 5. We had to do some very dynamic things. Which, again, had not been done. And we talked to Flash. Flash said, that can't be done. But we did it. And I'll show you what and how. And, of course, the last part of it was the Apple iServices Consulting Engineers. So this, if we can get this to work properly, will be built online. There's the mouse. There's the mouse.

Okay, this is the log on screen and when you log on, if you don't have the proper software, that being a current version of IE or Communicator, it'll tell you. If not, you go to this screen. Note first the tabs on top. You go wherever you need to and it shows you what tab you're using. What you saw there was a list of categories. We picked faces and you look at blown up thumbnails of the faces so they're not little tiny. You can see what you've got.

When you select one, it gives you a full size blow up. We chose the attractive young lady with the tongue ring. And if you like that, you hit select and it brings you to the desktop workspace. If not, you go back to the categories and select another face.

Once you choose the face, it puts it on the workspace and you notice that you have the control panel there on the left hand side. This is really where the magic of the application occurs. You can go by the click of a button on any of those control mechanisms, choose what you want to do. We clicked that we wanted a header and once the header comes up, you have full word processor capability to actually go and edit that.

So we highlighted it, we put in new text, you can make it say anything you want. Doesn't have spell check. It's coming in phase two. But other than that, you can do whatever you want to. So here we put in text. With a click of the button, we change it from black to white. Those are the two colors that the customer required.

So that was in the requirements. We're going to go in and we can change the font and it dynamically changes the font. You'll note that the picture doesn't change and the response time is extremely quick. We'll go in and change the font again and boom, in a matter of one or two seconds, the text font is actually changed. Other control mechanisms, right now the text is upper left on the header.

By using the grid mechanism, we click, we want it bottom center and boom, it goes to bottom center. The picture didn't change, the font didn't change, the color didn't change, the point sign didn't change, the location is the only thing that changed. Want a logo? Click on a logo.

Want to change the location of the logo? Change the location of the logo. The text doesn't change, the font doesn't change, the picture doesn't change. You can actually go ahead and change the whole back end picture by selecting, there's two sizes, a custom postcard or the generic postcard. And this is the deluxe one, actually blows it up.

And this doesn't just increase the picture, it's actually spawning a new file to the front side. Now, come in on the back side, take the old picture out, put the new one in, but all the intelligence is kept. All the settings that you've been messing with on your control panel don't go away.

When your front side's done, you click on tab three, goes to the back side, you have much the same functionality. These are templates that the customer asked us to create. It can be more free format, but these were custom requirements. They're orienting templates to some of those core markets that I talked about earlier, real estate, etc. You have much the same functionality on the back side as you do on the front side, full word processor capability on the actual text, but there's one cool feature.

You'll notice in a moment, we're actually going to highlight a bunch of text and delete the text, and nothing will move. And the reason is because that's where you designated you wanted that text to be. A lot of the existing solutions that are trying to do something like this are based on business rules, so they actually build in hard-coded logic, an example of which is when you highlight text, the middle section there, and delete it, it says there's a bunch of white space, we need to center that so it looks good. But what if you don't want it centered? Too bad. Well, we didn't want too bad as an answer.

We wanted, if you don't want it centered, put it where you want it, and we'll figure out a way to dynamically take those postcard-specific values unique to your postcard and integrate that into your real-time preview result that you get. So you'll notice that the text there didn't change. If you want to move it, just like you did on the front side, you can.

On this specific template, it's set, but a lot of the templates are much more free form. So we look at the final postcard in the back, and it looks to be okay. We're doing some final modifications on the back side, trying to put a logo on there, and the logo pops up on the bottom.

And when you're done, you hit continue, and this, tab four, is real-time preview. 90% of the time, this is going to work. You can look at this and say, it's precisely what I want, I'm going to go to the fifth tab and order this, and it goes to the camera, and you shoot it, and you're done. The bandwidth and the cycles that the client spends is minimal. The savings that they've devised as a result of this, the sky's the limit, and that's why this is the 5% solution.

So that's what we did. We think it's kind of cool. The client thinks it's very cool. How did we do it? It's a long process, but the easiest way to explain it is to kind of take it from the end and work our way back to the beginning. What you end up with is what you just saw, a postcard that has a lot of functionality. And no, it's not HTML. It's actually a series of dynamically nested Flash movies.

And Flash actually uses a very dynamic component which allows you to go and change one element. So you want to change the font, you change the font. Everything else stays the same, and the font command is contained in a Flash movie, so everything else stays the same. So the footprint is very small for that command. It takes just what it needs, throws it up there, so it's very... It's very quick, and the rest of the data and the settings, the integrity is intact. So you're allowed to dynamically change whatever you need to very, very rapidly and very free form.

So that was really significant for us. So you have your finished postcard, and again, it's a series of dynamically nested Flash movies. Well, Flash uses a file format called SWF, S-W-F, much like Word uses the doc format. And so we had to figure out how to get the SWF file format onto the browser so you could see these movies and do the magic. Well, what we used was... What we used was the WebObjects direct action, which is a call within WebObjects.

There's a lot of different ways we could have done this. WebObjects direct action is cool for two reasons. One is you can actually bookmark those files and come back to it later, and the second one, which is more important for us, it allows a stateless session. So you don't need to spawn a physical session because that wouldn't give us the dynamic nature and responsiveness that we needed.

We needed a stateless environment to be able to push these actions very rapidly, and so that's why we used the direct action. So that was really the mechanism that we used to get this to work. the Swift and spawn it to the browser.

And I think Robb's going to finish up for us here.

So we have the WebObjects lab located in room K. It's actually in the other building. And the roadmap is just some other sessions. The subsequent session is developing desktop applications with WebObjects. I highly recommend it. Moving to WebObjects 5 in room A1 and directed Java in room A1 immediately following it.