When you open an unfamiliar Mac application, you occasionally get the feeling that somethings 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.
Mindjets 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. Thats why MindManager 6 Mac is an Apple success story, and its 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 heres what it should look like. But they brought us in and asked, What do we need to do to make a Mac product? Whats 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, Mindjets 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 Xs 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 doesnt behave right for each platform. For some applications, thats fine, but for consumer-level products, I wouldnt go there. Mac users just wont use applications that have a Windows user interface. They can spot them from a mile away, and they just wont buy them.
Thompson points out another way that a misplaced commitment to one source-code base can cause you to weaken your applications 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 dont want to deny your Mac customers access to features derived from Core Image just because youre stuck in a Windows-based world that doesnt 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—thats code that you dont 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:
These questions (and many more) were answered by the teams completion of this first task, which was to specify the new applications 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 versions 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 users 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 dont 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 wont 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 Apples 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 dont encounter similar situations in your own development work, its 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 versions 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:
For more information about MindManager and Mindjet, see the Mindjet website.