When you open an unfamiliar Mac application, you occasionally get the feeling that something’s not quite right. Often, the reason is that the application has been ported from the Windows platform in a fairly literal-minded way.

Other times, you open an unfamiliar Mac application and...it just works. Such applications are usually designed for the Mac by developers who know the Mac well. Occasionally, though, such an application was translated (not ported) to the Mac, and you can tell. Compare it to other Mac apps and it looks the same, but compare it to its Windows counterpart and you can see that the two are worlds (or, more accurately, platforms) apart.

Mindjet’s MindManager 6 Mac is an excellent translation of a mature, successful Windows product. As soon as you begin using it, you know that it is undeniably a Mac OS X application. That’s why MindManager 6 Mac is an Apple success story, and it’s worth looking at how Mindjet translated their extremely successful Windows application to the Macintosh platform.

The Demand for a Mac Version

According to Scott Thompson, a member of the MindManager 6 Mac development team, the call for a Mac version of MindManager first came from Mindjet customers who were also Mac users.

“In fact,” Scott says, “many of our beta reviewers commented that they were glad to have the Macintosh version because they could either finally get rid of a Windows laptop, or they could finally stop struggling with running MindManager under Virtual PC.”

Couple that with the fact that MindManager customers—including people in the business, education, and creative professions—are the same kinds of people who buy Macintosh computers, and you can see why Mindjet decided to create a version of MindManager for the Macintosh platform.

Once Mindjet had decided to create a Macintosh product, Thompson explains, what happened next was “kind of unusual. Usually you get told, ‘We want you to port our program, and here’s what it should look like.’ But they brought us in and asked, ’What do we need to do to make a Mac product? What’s it going to take to do this right?’”

Mindjet and Mind Mapping

A mind map is a kind of drawing that begins with a central topic that the user wants to investigate or brainstorm; from there, additional topics radiate outward from the central topic, with free-form lines added to connect a “parent” topic to all the “child” topics that are related to it. Many people, including visual thinkers, prefer mind maps over more hierarchical text-heavy outlines, and mind-mapping software has become increasingly popular in both business and educational settings.

MindManager 6 Mac, Mindjet’s first product for the Macintosh, enables users to create fully-editable mind maps using familiar Macintosh windows, palettes, icons, and behaviors. Once they have created a MindManager document, they can edit and rearrange various items on the screen to make the clearest possible presentation of their ideas. MindManager documents can be read by both the Mac and Windows versions of MindManager, as well as by a free MindManager Viewer. Because MindManager 6 Mac is integrated into the Mac OS X environment, users can search for any text in any MindManager document using Mac OS X’s Spotlight.

The Pitfalls of Porting

So the challenge for the MindManager Mac 6 team was to create the look and feel of a Mac application, use the key Mac OS X technologies, but keep the application consistent with the existing Windows version functionality. The MindManager Mac 6 team began by making a list of the things they would not do.

“The goal is to avoid the ’least-common denominator’ approach to the user interface,” Scott says, “which is what happens when you use the cross-platform development approach. When you do that, the resulting application does run, but it doesn’t behave right for each platform. For some applications, that’s fine, but for consumer-level products, I wouldn’t go there. Mac users just won’t use applications that have a Windows user interface. They can spot them from a mile away, and they just won’t buy them.”

Thompson points out another way that a misplaced commitment to one source-code base can cause you to weaken your application’s appeal on the Mac platform. “If your code retains the structure of a Windows application, you may not be able to integrate it with some specific Mac-specific feature,” Scott believes. “For example, you don’t want to deny your Mac customers access to features derived from Core Image just because you’re stuck in a Windows-based world that doesn’t work the way Core Image does.”

In addition, delivering the user-interface appearance and behavior that Mac users expect saves you development time in two ways. First, you save time by using the UI components and behaviors that are built into the Macintosh platform and the Cocoa development framework—that’s code that you don’t have to write, debug, and maintain. Second, the more your application leverages what Mac users already know, the less you have to support it through documentation and tech support calls and overall, the more comfortable your users will be with your product.

Application Architecture Decisions

Scott says that the single most important task the MindManager 6 Mac team faced occurred at the beginning of the project. A robust Windows version of MindManager already existed, and the C++ source code was available. This naturally led to a flurry of architectural questions that had to be answered:

• How much of this code can be used?
• Given that the goal is a true Mac application, how much of this code should be used?
• Windows does feature X in a certain way—does this translate faithfully to the Mac, and if not, what alternate mechanism will work?
• Which features absolutely must be included, and which can be left until a later version?
• Since both versions must handle the same file format, how will the Mac version handle Windows-originated data corresponding to features not included in this first implementation?

These questions (and many more) were answered by the team’s completion of this first task, which was to specify the new application’s architecture, how each detail was to be implemented, and how the various subsystems interacted with each other.

Guidelines for Windows-Mac Application Translations

A number of the design decisions that the MindManager 6 Mac team made are applicable to most Windows-to-Mac application translation efforts. As such, they are expressed as guidelines that you may want to keep in mind.

Use Cocoa. “We decided to go with Cocoa,” Thompson explains, “because it had so much ready-made functionality in it. By and large, we realized that we could wire the user interface together rather than write the user interface. That is very powerful, and I feel that deciding to go with Cocoa was actually a big part of our success.”

Use as much Cocoa as you need. “Another interesting decision that we made is that we decided not to use all of Cocoa,” Scott says. “The team had decided to use the C++ code that implements the Windows version’s data model. This code also implements the functions for manipulating such data—in particular, its undo and redo functions. Scott credited the modularity and flexibility of the Cocoa framework with making it possible for the team to avoid having to reimplement undo/redo on the Mac side.

Translate Windows UI conventions into their Mac equivalents. Of course, the look and feel of the Windows and Mac OS X platforms are very different. For example, Windows apps show as many options as possible in tool palettes, while Mac OS X apps have a clean, sparse look that visually emphasizes the user’s data. Windows apps often use tabs and panels to contain everything in one window, while Mac OS X apps use multiple windows and palettes to spatially separate units of information.

If you don’t translate these (and many other) user-interface elements and behaviors to acceptable Mac equivalents, you will be severely compromising the attractiveness of the finished application to potential Mac customers. As Thompson puts it, “Mac users can spot an application that has a Windows user interface from a mile away—and they just won’t buy them.”

Use existing code for your data model, but rewrite your user interface for the Mac. Objective-C++, a language supported by the Objective-C compiler of Apple’s Xcode suite of development tools, makes it easy for you to call existing C++ code from Objective-C code and vice versa. Interface Builder, also part of Xcode, makes it easy to create your new Mac user interface using a visual editor that supports a toolkit of standard UI elements.

Use the Core Foundation framework. This Mac OS X framework uses a procedural C API to implement a number of useful low-level functions and data types. It is particularly useful for building translated-to-Mac applications that must join procedural C/C++ source code to object-oriented Objective-C code. According to Scott, many Core Foundation data types can be converted to Objective-C objects (and back again) through a simple typecast mechanism; this ability is extremely useful when you are creating an application that must bridge both kinds of source code.

The Benefits of Good Design

Thompson relates several anecdotes that show how good design decisions often result in unexpected benefits in the future. Even if you don’t encounter similar situations in your own development work, it’s useful to remember that good design decisions provide both immediate and long-term benefits.

The Windows version of MindManager was implemented using the MVC (model-view-controller) design pattern. Its usage resulted in a clean separation between the code that implements the data model and the code that implements the user interface. This design decision gave the MindManager 6 Mac team an unexpected benefit in that it enabled the team to use major code subsystems of the Windows version as part of the new Macintosh version. This reuse of code significantly decreased the time needed to bring MindManager 6 Mac to market.

Another unexpected benefit came from the earlier design decision that the Windows version would store most of its document data in an XML format. Now that Mac OS X runs on both PowerPC and Intel processors, the byte ordering of data (which is different for each processor) is now an issue for any application that writes binary data to disk. Because byte ordering is not an issue for text-based XML files, the MindManager 6 Mac team needed to make only a few minor changes to the Windows C++ file I/O code to use it for the new Mac version of MindManager.

Finally, some design decisions that Apple made in implementing the device-independent Quartz 2D graphics system certainly benefited the MindManager 6 Mac team (and, probably, other developers doing Windows-to-Mac app translations). Quartz 2D has significant structural similarities to GDI+, which is the 2-D graphics system used by most Windows apps. Because of this, Thompson says, the MindManager 6 Mac team was able to adapt most of the Windows version’s GDI+ drawing code for use in the Mac version.

Two aspects of Quartz 2D deserve mention because of the ways in which they made development easier. First, Quartz 2D is, unlike GDI+, a resolution-independent drawing system. This means that Scott and his coworkers were able to adapt one version of the Windows drawing code and use it for displaying images to the screen, printing them out, and converting them to PDF documents. Second, Cocoa enables a program to access Quartz 2D through either an object-oriented Objective-C interface or a traditional C interface. The MindManager 6 Mac team used the C interface because doing so made it easier for the drawing code to interact with the C++ drawing routines that are shared with the Windows version of MindManager.

Recommendations for Translating Windows Applications

As someone who has done an excellent job of translating a full-featured Windows application to Mac OS X, Scott is well qualified to talk knowledgeably about the subject. Here are his recommendations to developers contemplating similar projects:

• Make sure you have some Mac expertise on your team. “If you don’t have anybody with Mac experience in your company,” Thompson advises, “hire someone who does.”
• Allow time to learn the Mac platform. “A Mac application is structured differently from a Windows app. Realize that you’re going to need some time to get familiar with the Macintosh platform and how Mac OS X applications are structured.”
• Don’t port your application—translate it. Mac users just don’t buy products that look like they’ve been ported from Windows.
• Take great care in designing the software architecture of your product. “You want be sure that your code factors the user interface away from the data model. I would recommend using the data-model code as the platform-independent part of your application and reworking the user interface for each platform you develop for.”
• In relation to the previous point, make sure that your design decisions don’t prevent you from using appropriate Mac OS X-only technologies. “You want to be sure,” Scott says, “that you’re not shooting yourself in the foot by missing opportunities to use important Mac-specific features.”
• Base your new Macintosh application on the Cocoa framework. “Cocoa gives you so much standard functionality—code that you don’t have to write or debug yourself. That’s why we decided to go with Cocoa, and we think it was a big part of our success.”
• Use Xcode as your development environment. Thompson found many things to like about Xcode, including its context-sensitive Cocoa help system, its support for automating the build process, and its flexibility and extensibility.
• Follow the Macintosh human-interface guidelines closely. As Scott puts it, “Anytime you stray from the user-interface guidelines, you’re making work for yourself and the user.”
• Embrace Objective-C. “Yes, it does look different and there’s bit of a learning curve, but it’s worth it. Apple had good reasons for choosing it over C++, and so much of what you can get ‘for free’ from Apple technologies is based on Objective-C.”

For more information about MindManager and Mindjet, see the Mindjet website.