Architosh Staff (info@architosh.com)

4 August 2001

Nem Interview Summer 2001 (not real title)

Architosh Nemetschek Interview 2001

Material Rough Draft

Sean Flaherty, CTO of Nemetschek North America

Anthony Frausto-Robledo, Editor of Architosh.com

Interview Beginning

AFR My question for you right now is, when do think the Mac OS X version of Vectorworks will be ready?

SF We're looking at the next several months. The September-October timeframe is in the heart of our target area. I am hesitant right now to put a firm date on anything because the technology is something we've been bad at predicting up until this point.

AFR Sure.

SF We plan to go into a public beta of the OS X version in about a month. Right now we have released the OS X beta into internal testing and we are taking that first set of in-house eyes and then we are going to do a public beta since we have a lot of users clamouring to see the OS X version and we certainly want to get a wider set of eyes on the software.

And we think the typical OS X user right now a classic early adopter, because there certainly is a big learning curve with OS X and you are dealing, almost across the board right now, with early release and beta software. So we think in about a month we'll go to public beta and probably a couple months after that is what I think would be a reasonable release time frame.

If anything, things are moving much much faster now. We actually have Apple and Metrowerks helping us directly, instead of indirectly through the normal tech support channels. We have a direct line with them and they have really acelerated our development. We went from three weeeks ago to actually having nothing working under OS X to having most of the application working and actually having it in our test department.

AFR What was the technical difficulty confronting you with this early development in OS X?

SF Well, we had a couple of things. We've actually been Carbonized for more than two months now. Being Carbonized at the very basic level means that you have taken a completely working application and switched it to the Carbon API's and are linking and running under Carbon.

What we expected was that the time between being fully Carbonized and working was going to be a lot smaller (laughter...)

AFR Right.

SF Well, I think there has been two big areas that has been the cause of our schedule problems.

AFR What are they?

SF First there were quite a few API's that have changed significantly within the operating system. Some examples of that are: we do network licensing using standard AppleTalk networking calls, and those aren't supported at all in OS X and everything had to be re-written to use OpenTransport. The whole scrapbook manager is brand new for Carbon and the previous classic version doesn't work so we had to completely replace our scrapbook handling as well.

So going in and working on those have taken up a decent chunk of our item.The second thing is the debugging environment has been slow coming out of Metrowerks. And that is where they have really stepped up and helped us out. We finally approached them and said, "we don't have any source level debugging", and this has become such a basic tool of our product development it is really like trying drive down the road with blind folds on and someone giving you directions. You can still do it but it is far far less efficient. We had to revert to some really old style development techniques in the absense of a source level debugger.

AFR I see...

SF And that was when one of our biggest breakthroughs came. We finally got in touch with someone at Apple who got us contacted at Metrowerks and they offered to take the whole project from us and take a look at why were having so much trouble. And this has been a real breakthrough for us.

AFR So you are using, for development purposes on the Mac, the Metrowerks CodeWarrier Development tools?

SF That is correct.

AFR Now everything that you are doing with the OS X version is related to Carbon. Is that correct? You are not doing anything with Cocoa at this point?

SF We are not.

AFR Now let me help readers get a sense of how much work is involved. How many lines of code are involved in VectorWorks?

SF We were just talking about that before you called. We don't really do a count. We've got in our project about 8000 files, and those are pretty big meaty files; they are not single one object-per-file types of things. We are guessing on the order of 10,000,000 lines. But it is a tough measurement.

AFR Well that's alot. I know, for example, the Ashlar folks were telling me that there application was near—this was for Vellum, not Solids, their new Graphite program—around 1,000,000 lines. And then you have programs like Maya which have 26,000,000 lines of code. So 10,000,000 lines is a lot of work.

SF The scope of the application ... and I think obviously we knew this going into the project, it's really large. And Paul was talking to me earlier about this, the number of dialogs built-into the core of the application was 175. So if you do anything, like with Aqua going in to make buttons wider and move things around a bit...if you had to do that for every single dialog, it takes a lot of time.

Another thing which is different, like with Cinema 4D—which is also in the Nemetschek product group—they have a very innovative product develpment technique, and one of their big advantages is they are less specifically reliant on the Mac OS directly than we are and we have a very broad use of the Macintosh which means we are more effected by core changes to the OS.

So what you are seeing are applications that have shifted quickly and others that have not and that comes down to your internal development style.

AFR Let's talk about some of the challenges in detail. I would like to know how you have delt with some of the Aqua interface guidelines across your dialog boxes and menu bars and stuff like that. Has that been a challenging thing?

SF Challenging isn't really the word. Apple has done a really good job over the last couple of UI revisions in OS X, which handle these specific conditions.

There are some emerging Apple standards which we are keeping an eye on. For example something that was be passed around the team this morning is Apple is recommending less use of group boxes, saying that they add visual clutter and I haven't seen the final form of this in the Apple Human Interface Guidelines but certainly it is going to be interesting when and if they make this departure which in the Windows interface is very group box heavy. And we may be forced to adjust that in the future.

AFR What do you mean by the group box look?

SF Group box is when you have a say a bunch of radio buttons and a box around it with a label on it.

AFR Sure. OK. I see what you are talking about.

AFR Now I know of some Apple applications, like Final Cut Pro, where they have almost custom looks to them. Do you have that ability to make custom looks too if Aqua doesn't quite size up to useabilty in VectorWorks for OS X?

SF No. We would be happy with one working look. Like I said, everyone does things differently. Some applications don't rely on the standard Apple controls and that is how they can create custom looks. And that is what you are seeing with things like Cinema4D and Final Cut, where people are actually drawing the things themselves.

I'm not sure that is necessarily the direction we want to take. I don't know how you feel...but I look at a lot of things and as a class the media viewers and music players are some of the most nonstandard interfaces out there. They look really neat...but CAD is a much deeper application.

We all have lots and lots of functions, and buttons and menu commands. And I think we are exactly the type of application that doesn't want ot break with the interface rules because we want things to scale where users can take the knowledge of the operating system and apply it to getting into the CAD application.

AFR That's why I asked, because to my eyes—and I think to a lot of people—Aqua seems to be heavy and on the big side and it appears to be challenging for some developers to get things all fitting nicely.

SF Right. Well OS X at Nemetschek N. A. has been a controversial update because there are a lot of die-hard Mac users here which I think say the same thing as what you are saying, which is the look is not necessarily a full win.

AFR Right, that's right.

SF But, I'm certainly willing to give Apple a shot and work with it a bit longer. I certainly think that visually it is really quite stunning. And I think Apple is working to tune out some of the things that don't work. And Paul is pointing out to me that Apple put in a small Aqua look, which is one of the last things they have done.

AFR What are your plans after you have Carbonized with VectorWorks? Do you have plans to begin a Cocoa version?

SF No.

AFR So you never—I mean, well never is a big word...

SF Ya, never is a big word!

AFR At this time you have no plans on a Cocoa version?

SF No. I don't know how much you follow the developer new, but I have been dissappointed at the amount of marketing that Apple put on Cocoa versus Carbon.

They have really left lingering in some people's minds that Cocoa is somehow superior, or more native than what you can get with Carbon. But just recently, especially since WWDC, they have been more active in promoting the fact that Carbon is a full fledge way to create native OS X applications. And more importantly right now it is the only way to avoid a dual development problem...of having to do an OS X target and an OS 9 target.

And that's what we're trying to avoid. Whenver you do things twice you have twice the chance of introducing realiabiltiy problems.

AFR Ya, what you are saying is enlighting and makes a lot of sense.

SF Apple is really working to overcome this perception but at the same time something they are trying to do—and this is a subtle but very important change—is they are tying to get back into the developer tools business, in the same way that Microsoft controls the tools market for Windows development. When the operating system manufacture doesn't provide the tools you can get into a problem where you can have a lag between the capabilities of the operating system and the capabilities of the tools.

And Microsoft is very very good about that. When windows 2000 was coming out and now with XP coming, developers were using reliable tools long before the release of the operating system. And I think Apple is trying to be more like that.

AFR When the OS X version is ready to ship will it have any additional features or inherent abilities over the classic version at that time?

SF They are both going to be the same version. It will be one executable that runs in either Carbon OS X or classic OS 9. This is not a feature upgrade. It's going to have a lot of maintanence fixes only.

AFR What about PDF printing and PDF production out of OS X? Will that be implemented as a service in the OS X version?

SF I don't think it needs to be OS X only. Or necessarily Macintosh only. We use the QuickDraw interface. And we aren't really familiar with the internal OS X PDF features. We have it as an internal development task to look at the features with that.

AFR OK. So basically when OS X comes out somewhere in the October time frame what users can expect is essentially version 9.5 runninig on OS X. Is that correct?

SF Yes. It will look just like version 9. It will have all the same features of Version 9 with the Aqua look and running native under OS X instead of the emulation environment.

AFR What about printing. Is there going to be good printer/plotter support under OS X? Are you guys working in tandem with the plotter people like HP and Epson?

SF We put out a dual QuickDraw-Postscript file. So what happens in OS 9 right now, say when you go to an Epson inkjet, is that it interprets some combination of those two pieces and puts that into the Epson printer language. Drivers for printers in OS X are really kind of immature right now, in general.

There are a lot of manufactures working on drivers right now. Printing to small printers is not what customers are really worried about but rather having large format support.

You had an interview with Robert Coulling of Microspot a few weeks ago and all eyes are on Microspot, I think, and that is one of our bigger concerns right now: how do we have large format support?

Working with Epson an HP? I am less concerned about that right now. They are progressing right along with their driver support. I mean, I don't know. What was your feelings from talking to Robert?

AFR Well, my feelings from talking to Robert [Microspot UK managing director] were that they might not be delivering new OS X driver products until January. That was just a sense that I got from his unwillingness to spill the beans, sort of speak, on unannounced new products.

I think they have some new products in the works and they want to keep that stuff pretty close to their chest at this point. But Robert seemed very excited about their prospects with OS X.

SF They got really burned on a few dead-end Apple technologies.

AFR That's right and, a lot of things along the way...

SF They really should get a medal from Apple for being war-veterans in the Mac community because Microspot in particular, I think, has really done a tremendous effort to try to support the latest and greatest from Apple.

AFR Right.

SF I think the only thing they didn't bite into which died was OpenDoc...

AFR Right.

SF ...and they are probably counting their blessings. But I have to admit that we approached this very cautiously because we were one of the applications to ship for the PowerPC [back in 1994-5] and that was very difficult. That was not a smooth transition and in many ways was a simpler transition than what needs to be done in the Carbonization process.

In fact we were one of the very first people to use the PowerPC compilers. And it's a tough place to be in. And this time we wanted to wait a little longer for the things to be more mature.

I think we did some good timing there because I am not sure if we were more actively working on the Carbonization process say, last summer, if we would be any further along than where we are today.

AFR I see. Would it have been faster just to re-write the whole application from the ground up in say Cocoa?

SF No. No. Not at all.

AFR Too much effort. I see.

SF VectorWorks 9 is essentially a re-write. We took the entire application and split it in half to create the interface shell—we talked about this in the last interview—a ground up completely new application that looks just like VectorWorks 8, but written in PowerPlant.

And one of the big reasons we did this is to handle exactly these times of operating system changes. So if Microsoft one day says they are going to pitch MFC [Microsoft Foundation Classes] and replace it with a brand new development environment, we would be ready for that.

Regarding Cocoa. I don't know what you hear talking to developers but there is a lot of us here that really wonder about the wisdom behind picking Objective C as your standard language. You have a language that exist on no other platform. You standardize that as your development language of choice and you have problem.

I think Apple is doing the right thing by continuing to push Carbon. They are much much more likely to get people to port to another C++ environment or to a Java environment because you can hire programmers that know this well.

AFR That makes a sense.

SF Cocoa is appropriate for some needs but for a big cross-platform application like VectorWorks I don't think you can rely on having a good steady stream of people without having a massive training initive.

AFR I was under the impression that with Cocoa you have the option of Objective C or Java as your language?

SF Yes. You can do Java. So why aren't we re-writing in Java? You are really getting down to the specifics on development tools. The big reason for us not to consider it is that the only target for Cocoa is the Mach O kernel, and that only runs on OS X.

So as long as we want to bridge this gap here. I think having a CFM target is a better way to go. Which is the target which runs on OS 9 and OS X.

AFR I see.

SF Are you running OS X?

AFR I have but most of my applications that I use for Web development and publishing, like Dreamweaver, are not ready. So I can't really be on it all the time. I would, especially after September because I think the update will run much faster, even faster than OS 9—so I'm very anxious personally and I know a lot of Architosh readers are as well.

I think what a lot of readers are seing is that the 3D apps, like Lightwave and Cinema4D and others are ready now. They seem to be ahead of the curve. I even think that the Strata 3D folks may deliver an OS X version in the near future as well.

SF Did you see the Lightworks announcement today that they have delivered an OS X version of the Lightworks library?

AFR Oh, Lightworks, Yes. I did not read that. I was referreing to the LightWave.

SF That's a key component we have been waiting for as well because RenderWorks rendering engine is all Lightworks-based. If you read their announcement you will see some of the other developers who rely on this as well. I think this was a really postive announcement for the OS X community. You know FormZ is also based on this. We wouldn't be able to wrap our RenderWorks without this library being available.

AFR Right.

SF But back to the Cocoa Carbon thing. That's why I stressed this Carbon thing. Because you are really asking a developers' tools question. Not a platform question. It's in the question about the tools, what they are capable of and how well you can develop with them, rather than in the capabilties of the operating system.

Next version of Vectorworks

AFR When are you planning the next major release of VectorWorks?

SF Version 9.5?

AFR Yes.

AFR When is your next big feature planned? What does your window look like there?

SF Uh,, (laughter). That's a tough question there. I think it may be too early.

AFR Ya, I may be getting ahead of you.

SF We have been running around as a company and trying to figure that out. We have traditionally done 18 month releases and VectorWorks 9 was a 27 month release. And that is too long. It is really hard to say. We are going back and re-evaluating what is the best way to get the latest technology in coustomers hands.

I think the CAD market is an interesting one because basically companies standarize on it as a platform like they do with an operating system. And changing the platform too often can be very very disruptive. But at the same time there is a large push to continnue to support new technology. So for us we have things pulling the schedule both ways.

So I think we wil have a better idea late in the fall what are real window is.

AFR Can I ask you a few questions about your Web strategy?

SF Sure.

AFR You know you have Autocad out there -- very aggressive on the Web side, they just bought Buzzsaw.com, and so forth. Where is Nemetschek going with the Internet?

SF Well, it is good that you say Nemetschek there because this is going to be a group strategy from us. Coming from Nemtesche AG. They have a web portal comprababple to Buzzsaw called Mybau.com, which is primarily used in the European market, which for us is 30-40% of our business. In fact, we split the world by about 30% for Europe, Japan and the United States and Canada and the other ten percent is split between companies like South America and and we have a growing user base in Australia.

So for us this will help to have strategy there. I think the whole CAD community got really side tracked onto the project management sites...

AFR True

SF that made all the news. And it's interesting because did you attend AEC?

AFR No. but I followed some of the announcements.

SF Becuase the shear absence of booths was remarkable. Because last year it seemed like every third booth was some sort of online collabration site. And they were all gone this year. And it was really the die-hart Buzzsaw's and Bricsnet that are the ones that are really viable.

The direction we are looking for as a corporation is really first about how to get information up on the Web, and visible and viewable. We got -- and this will appear on our Web site in the next month or so -- we have viewer version of VectorWorks.

AFR So you can view files on the Web?

SF Right. YOu can open up, look at files, zoom around and print them.

AFR Well that's good news.

SF Yes, so this is good. So that is certainly going to be a big advantage because certainly any service beaure can download the viewer app and they will have a full plot ready version of VectorWorks.

You know anytime you go to DWG or any translation process there is always loss. So we want to be able to have people post and pass aroudn VectorWork files directly. Andd to have a viewer means that to go to some third-party which isn't necessary a VectorWorks user means they can access the file. In fact, what a lot of our customers often need is when they are sending some VectorWorks files as DWG's to some Autocad user, that user can use the viewer to open the VectorWorks file directly and compare it to the DWG export and verify that they got everything they needed.

So that is certainly going to take us forward there. I think the direction we are headed -- and we are probably aobut five years away -- is some Web-based component spec where you Pella and Anderson can not just put up DWG representations of their windows but to actually have a component that you can click on a Web page and drop it into your CAD application.

There is a whole host of specs running around right now. And if you search on architecture and XML you will find more information. I think that is where peple are headed.

I think long term the people who can actually get manufacturers to put things up on the Web will actually have a real competitive advantage. And that'[s what we are workign with NAG on right now, espeically with the mybau projects and a lot of hte manufactures there, is to use their Web based component specficcation. And taht is somethign that they are just kind of getting going.

As far as further Web technologies I'm not sure I see a lot that are specific to CAD.

AFR What about 3D and things like Macromedia's newly announced Shockwave 3D format, things like that?

SF The streaming 3Ds?

AFR Yes, the newest streaming 3D technologies.Like the ShockWave 3D format that people like Maya, Lightwave, Amapi and others are all geting very excited about?

SF I don't know. To be honest, I don't know if I have a strong opinion about that.

AFR OK.

SF It'something, you know, where VRML was all the rage about six or seven years ago. It's not really done a lot. The formats liek Shockwave are nice when you need toshare small 3D drawings with somebody. But I am just not convinced that if you are working on a large 3D version of a house that you want to see it in a small, quicky streamed 3D format.

I think when you are collaborating with someone on something yyou are going to want ot have a full CAD syystem there to work wtih it. I think the red-lining features you have with DWF are much more appealing to our customers.

With VectorWorks 9 we reved our 3D engine. And we continue to rev our rendering technologies. Those are where we want to attack the 3D market. To take VectorWorks up to be the industry leading architectural modeling and rendering package.

AFR Sean, I think we need to wrap up now but I want to thank you for talking to Architosh about VectorWorks on OS X, and all the detailed discussion on development. This conversation sheds a lot of light on what it is really like to move an application -- especilly one as large as yours -- over to Apple's next-generational operating sytem.

SF You are welcome. Thank's for the opportunity.