Code by Kevin

About
Code by Kevin, Programming, code, business, and other pursuits

Your Host
Kevin Walzer, software developer.



Home

Subscribe to RSS Feed
Get a syndicated feed of my weblog.

Archives
2020
2019
2018
2017
2016
2015
2014
2013
2012
2011
2010
2009
2008
2007
2006

Categories
Business
Software
General

Privacy Policy

Site design: Skeleton

 

Sat, 18 May 2013

Mac integration: what matters most?

Earlier this month I talked about recent changes in UI fashion on OS X, away from bright colors and icons toward a more muted look. This general trend is going to help guide me as I do a significant round of updates on my apps.

I wanted to talk about a related topic as I decide how to update my apps, in terms of how they integrate with OS X. I've always believed that a high level of OS integration is very important in my apps even though I develop using a cross-platform toolkit. The question is, what type of OS-level integration is the most important--visual integration, integration under the hood, or some combination of the two? Until very recently, even though I do strive to integrate with the OS on several different fronts, my answer to this question would have focused on visual integration. Most of my work in recent years has focused on visual integration: native toolbars, printing dialogs, manipulation of the Dock icon, a status icon in the menubar, and more. And my apps have done well on this front.

Yet I am beginning to wonder if the time I've spent on visual integration has been well-spent. In terms of functionality, my apps have advanced at a much slower pace than their visual fidelity to Mac UI conventions. And the increasing pace of change and complexity in Mac UI conventions--especially to support Retina displays--mean that I will have to spend yet more time on UI integration, at the expense of other features.

I'll be honest: I'm getting a bit tired of this treadmill. So I'm starting to look in another direction for an example of how to proceed, NeoOffice, a Mac-optimized version of the open-source OpenOffice office suite, developed for the past decade by Patrick Luby and Ed Peterlin.

A bit of background: OpenOffice is essentially a cross-platform, open-source clone of Microsoft Office. It was originally developed as a commercial product, was bought and open-sourced by Sun Microsystems, and then became a fully independent, open-source project after Sun was acquired by Oracle, the database company. A large community of volunteers and some professional developers maintain OpenOffice and several variants, including LibreOffice (which forked from OpenOffice after it was acquired by Oracle and before Oracle divested the project) and NeoOffice.

NeoOffice came into being because, back in 2003, OpenOffice only ran as a Unix-style X11 application on the Mac: powerful and functional, but not integrated in any way whatsoever. Patrick Luby and Ed Peterlin have gradually enhanced the OpenOffice code base with Mac optimizations, to the point where their version is far superior on the Mac to standard OpenOffice (which now runs natively, but has no special Mac optimizations beyond running as a standard app and not in the X11 environment). They have chosen a different, incompatible open-source license for NeoOffice (GPL) so their code changes cannot be merged back into the standard OpenOffice code suite.

A list of differences between NeoOffice and OpenOffice is instructive. The most recent version of NeoOffice supports the new Mac fullscreen mode introduced in 10.7; supports the Mac document "Versions" feature introduced in 10.7; is much faster than OpenOffice because it uses the latest Mac text-rendering framework, Core Text; supports OS X Services; and more. OpenOffice supports none of these features.

This high degree of OS-level integration may not be immediately apparent if one looks at a screenshot of NeoOffice, such as below, because NeoOffice does not invest heavily in visual integration with Mac UI conventions:

The icons fit reasonably well with the Mac, but toolbars are definitely not native, and the general UI design--i.e. putting tons of buttons in a toolbar--does not follow Mac-optimized guidelines either. While the under-the-hood integration is superior, the visual integration of NeoOffice from a design standpoint is little different from the other variants of OpenOffice. In response to user questions about the UI, the NeoOffice developers have said that, because of limited resources, rewriting the UI of NeoOffice is not in their plans; they prefer to focus on under-the-hood integration, application performance, and so on.

What I find very interesting about NeoOffice is that its under-the-hood integration with the OS is not just better than OpenOffice; it is also arguably better than Microsoft Office's. Microsoft Office 2011 does not support the "Versions" feature either, and I suspect it still uses the same older text-rendering engine that OpenOffice does. Microsoft Office 2011 is, from a general performance standpoint, much slower, less snappy, more sluggish, than NeoOffice, as well.

In terms of visual integration, however, Microsoft Office far surpasses NeoOffice, using a native toolbar, native search field, and, in general, an overall design that well adheres to Mac UI guidelines. Microsoft has taken its "Ribbon" UI concept and, rather than doing a straight port of it from Windows, has implemented in a way that makes sense on the Mac:

Microsoft is to be commended for its work in visual integration. It also goes without saying that Microsoft Office is very powerful. However, as one who uses both Microsoft Office and NeoOffice frequently, I have to suggest that Microsoft's superior visual integration does not offset its sluggishness. I find that NeoOffice is generally easier to use, despite its lack of visual integration. (In fairness, one significant under-the-hood area where Microsoft Office does greatly surpass NeoOffice is in its support for AppleScript, but I don't make much use of this feature.)

So what lessons am I drawing from this discussion? An important one is that I have come to conclude that perfect visual integration is overrated. The likely overhead of continuing to provide a high level of visual integration in my own apps, i.e. to comply with Retina display requirements, does not seem worth it if the apps are sluggish and slow--a complaint I've increasingly heard in the past year or so, which also coincides with an unexpected decline in sales. I want to have reasonable visual integration, but it has to be done in a manner that is easily maintained and allows me to focus on other kinds of optimization and integration as well.

The NeoOffice developers recognize their limits, and are focusing on the types of optimizations and integrations that will give them the most bang for their buck. And I say "buck" literally; the developers earn their living from NeoOffice work, charging an annual $10 download fee to get the app from their website and a year's worth of updates. They have enough users that this is feasible from a business standpoint, and they manage this in spite of the competition from the free OpenOffice variants, such as LibreOffice and the original OpenOffice.

So I will work to maintain a reasonable level of visual integration--I fully intend to support Retina displays--but this will be done in a way that allows me to use my limited time for other, arguably more important, optimizations and integrations. I want my apps to be fast and pleasant to use, and I want them to integrate with the OS in ways other than just visually. They have a ways to go on that front, but I'm taking my first steps in that direction.

One Tcl/Tk app I like for its clean, basic UI is WaveSurfer, an open source tool for sound visualization and manipulation. Its UI is very simple, providing a visual representation of a sound's waveform, with a single set of toolbar buttons that get out of the user's way:

The lack of a standard Mac "unified toolbar" here is not problematic for me, and I imagine the overhead of adding one to the app's UI design would not be worth it for the developer. This app gets its job done in a clean, simple way, and, as with NeoOffice, I'm taking instruction from it for the future development of my own apps.

[/software] permanent link