MDIs on the Mac

Way back when the first graphical user interfaces were created, Apple and Microsoft went similar ways. Both used the desktop metaphor with files and folders, both had overlapping windows which showed documents and folder contents. However, they also took different paths for a few fundamental UI concepts. Apple had the “always on top” menu bar, while Microsoft put the menu bar inside windows. Apple went with an application-centric model, where each application could only be launched once but have many windows, while Microsoft went with a document-centric approach, where applications would sometimes launch multiple times.

The Multiple Document Interface

Apple very strongly went with the idea that each document corresponds to exactly one window, while Microsoft introduced a concept called the “Multiple Document Interface” (MDI), which allowed applications to have hierarchical windows: document windows reside under a parent application window.

MDIs have some advantages; they naturally help reduce clutter by grouping windows. They make it easy to hide all windows for a given application. If you tend to use applications in full-screen mode, having a MDI makes sure you really only see the active application and no other application.

Either way, Mac applications never had MDIs.

The times, they are a-changing

Mac applications used to have many windows. Recently, this has started to change, mainly due to Apple’s influence. Mac applications such as iPhoto, iTunes, iMovie, Aperture or iDVD tend to only have one window.

However, these applications do not have MDIs. Neither of these applications are multi-document applications. They are either media managers (iPhoto, iTunes, Aperture), or they are typically used to open only one document at a time (iMovie, iDVD).

MDIs on the Mac

Unfortunately, some companies have taken Apple’s new one-window-approach to UI design as a hint that they should introduce MDIs (or an MDI-like approach to UI design) on the Mac. Nolobe’s Iris, otherwise a very capable program, is such an application: Note the list of open images in the bottom row of the single window.

Adobe’s CS4 applications will also use MDI on the Mac (albeit only optionally - one can only hope that it will not be the default choice): Note the tabs above the image.

MDIs on the Mac are generally a very bad idea.

So why are MDIs on the Mac a bad idea?

Glad you asked. There are many reasons why MDIs are a bad idea; some of them generic, some of them due to how the Mac normally works.

Why MDIs are bad in general

Please note that these lists are not exhaustive; also, not all of these points apply to all MDI applications. To name one example, Adobe has gone to great lengths to make sure their MDI would work around almost all of the issues in this list.

• Most modern computers support multiple screens, and a lot of people make use of this feature. MDIs don’t support multiple screens; since all of your documents are inside one window, you can’t put one document on one screen, and another document on another screen. Note that in the CS4 UI, it’s possible to pull document windows out of the main window, so this criticism does not apply.
• MDIs often make it hard to compare several documents belonging to the same application, or to view them side-by-side. CS4 supports tiled views to allow for this.
• MDIs make it hard to drag from one document to another inside the same application. In Photoshop, dragging layers between applications is something I do daily. MDIs make this hard (or even impossible, depending on the implementation), and force the user to copy-and-paste instead. Adobe’s CS4 UI supports spring-loaded tabs, which isn’t quite as good as direct drag-and-drop, but should be a workable solution.
• Some implementations of MDI make it hard to remove palettes from the main window. This is bad because in a multi-screen environment, a typical setup is to move all palettes to one screen, while keeping documents on the other screen. Again, the CS4 UI allows for this, so no complaints here
• MDI takes away space on larger screens. After your screen reaches a certain size, it doesn’t make much sense to maximize windows anymore. Having an MDI means you always waste space with a ton of application chrome around your documents - space which could be used by other applications running at the same time. Again, CS4 has a solution for this; hitting tab removes the application chrome (although I wasn’t able to get it back easily - hitting tab again did nothing at all). Unfortunately, the application chrome is not hidden if the application is put in the background while in MDI mode.

Why MDIs are especially bad on Macs

As if these reasons were not enough, there are a few additional reasons unique to Macs:

• MDIs break Spaces. You can’t have one document in one space and another document in another space if all documents must reside inside the same window.
• MDIs (including tabbed browsers) break Exposé. This is what happens when you activate Exposé in Fireworks when the MDI is active:

Obviously, it’s entirely useless. This is what happens with the MDI turned off:

Much better.

By the way, Adobe, “zoom to fit” is currently broken and maximizes windows instead of zooming to fit their content - yet another Windows behaviour that has no place on the Mac. Also, the little “this document contains unsaved changes” dot in the close button does not work, which is probably another result of the MDI; UI elements don’t need to look the same in all apps, but if they look similar, they need to behave the same so as not to confuse users.

What Adobe did right, and what they did wrong

Adobe actually implemented workarounds for most issues I list. However, they are often non-obvious. Furthermore, if other applications with MDIs try to fix these same issues, they will most likely find different solutions, creating an inconsistent user experience.

Since there is no history of MDI applications on the Mac, and since Apple doesn’t have anything similar to these applications, there are no established UI guidelines. Hence, MDI-based applications confuse users since they behave inconsistently with each other.

Replacing an obvious, consistent solution to a problem with a non-obvious, inconsistent solution is generally a bad idea, unless the new solution is shown to be considerably better than the old solution (as an example for this, check out the Ribbon UI in new versions of Word for Windows - it’s non-obvious and inconsistent with other Windows apps, but it’s so much better than earlier versions of Word that the change is worth the issues it causes).

In this case, consistency with the host OS and its applications seems a lot more important than consistency with different versions of the same application.¹ In my opinion, the Mac version of Photoshop should look and (especially) behave like a Mac application, rather than like the Windows version of Photoshop.²

I should point out that I don’t have access to Adobe’s UI test results. One would hope that they did usability tests and found that the new UI is much more usable for Mac users than the old one before deciding to go with the MDI UI on all platforms. If so, changing to the new UI is the right thing to do.

Apple is to blame, too

Apple itself has at least one document-centric MDI application, too: Safari. The fact that Apple has an application which uses tabs to switch between several documents inside one window is probably partially to blame for the recent third-party enthusiasm for MDI apps on the Mac.

Originally, tabs were not meant to switch between documents. They were meant to organize “things” (such as settings) into groups of similar “things”, or - at most - to switch between different views of the same document. Not so switch between different documents.

It is kind of unfair to blame Apple for introducing tabs in Safari - after all, users demanded the feature, and Safari’s tabs are turned off by default (something other developers should copy if they insist on bringing MDIs to the Mac). It’s just very unfortunate Apple’s choice helped usher in a new era of MDIs on the Mac.

Conclusion

MDIs are bad news on the Mac because they break a lot of behaviours Mac users are used to. They should be avoided.

Addendum: John Nack replies to my blog post (scroll down to the comment linking to this post). He points out that most of my criticism of MDIs doesn’t apply to the CS4 UI since it’s possible to have (tabbed or single) windows outside the main window (Admittedly, I noticed this while trying the Fireworks prerelease, but actually thought it was due to a bug because I wasn’t exactly sure how I ended up in this state).

He furthermore thinks that it’s Apple’s fault for not giving developers a way of supporting Exposé for tabbed windows, with which I agree; still, Apple doesn’t force anyone to create interfaces which don’t support Exposé :-)

I’ve updated this post to reflect the fact that CS4 provides solutions for most issues MDIs normally cause.

Addendum 2: I mistakenly claimed that Final Cut Pro was a one-window application. This is false: I have not used FCP in a while and misremembered how its UI works. While FCP looks like a one-window application, the different areas of the UI are actually individual non-standard windows. Thanks to Ben De Rydt for pointing this out to me.

Addendum 3: Mike Lee, the world’s toughest programmer, disagrees with much of what I write, essentially saying that the concept of an MDI is not in itself flawed, but that it’s a question of context (how is the application in question used?) and implementation. He makes some good points, and furthermore calls me “chef,” so I recommend that you read his post. Also, who wants beef with the world’s toughest programmer? Not me!

I do have to take exception with two things he says, though.

He claims that it is false to differentiate between media managers and document-based applications. He does not, however, explain why this is false, except for pointing out that both Photoshop and iPhoto work with “media.” However, iPhoto is not a media manager due to the fact that “the documents in question are media.” iPhoto is a media manager because its main use is in managing your data. Faulting a media manager for having multiple documents in one window would be akin to faulting the Finder for allowing more than one file in a folder: In the application’s model, you are typically working with representations of your documents, not with the documents themselves.

Then, just after writing that “nobody likes Adobe,” Mike claims that I did not use Photoshop as an example “because people like Photoshop.” This is not why I used Fireworks. I went with Fireworks instead of Photoshop because I do not have access to a Photoshop beta, only to a Fireworks beta. The two share the same user interface, so any criticism I have made applies to both applications equally.

June 7th, 2008 / Tags: MDI, UI, usability, HIG, Apple, Iris, Nolobe, Adobe, Photoshop, Fireworks / Trackback

Apple's Photoshop Killer

Three days ago, Adobe announced that Photoshop CS4’s 64-bit version will only be available on Windows. There won’t be a 64-Bit version of Photoshop for the Mac until CS5.

How Mac OS X came to be

First of all, I want to make it perfectly clear that this is not Adobe’s fault. Apple has brought this upon itself, and to understand how this has happened, we need to go back a few years to the time befor Mac OS X. In the early 90s, Apple was in a bad position. Its operating system was technically outdated. Several projects inside Apple, and several joint-ventures with other companies aimed at creating a successor to Apple’s operating system had failed. Apple was essentially forced to either buy an existing solution, or license an operating system from Microsoft or Sun. Apple didn’t want to become dependent on a third-party operating system, so they had to buy an OS. At the time, there were two options: Be’s BeOS and NeXT’s OPENSTEP. Apple bought NeXT in 1997, bringing Steve Jobs back to the company as well as giving it a new operating system.

Soon thereafter, Apple announced its plan: Developers were basically forced to rewrite their applications in Objective-C for NeXT’s object-oriented, comparably modern APIs and frameworks, or “Cocoa,” as Apple called that part of what would become Mac OS X. Third-party devs were understandably not pleased at all. In particular, Apple relied on two third-party applications: Microsoft Word and Adobe Photoshop. Without these two applications, Mac OS X would be stillborn. Given Apple’s financial position at the time, chances were they could not survive such a disaster.

The Plan

Microsoft and Adobe must have made it pretty clear to Apple that they were not going to rewrite their applications for Cocoa, because soon after its first announcement, Apple changed its tune. In addition to Cocoa, there would be a second API called Carbon. Carbon is essentially a port of the old, procedural pre-OS X Mac APIs. Using Carbon, developers could easily port their old Mac applications to Mac OS X without having to rewrite large parts of their code.

When the first end-user version of Mac OS X came out in 2001, it didn’t take too long for native versions of most important applications to come out, and all was well for Apple.

64 Bits

Today, we are looking at a similar transition as the one from Mac OS 9 to Mac OS X, albeit on a different level. For the last decade, most computers used 32 bits to address blocks of data in memory. Since each address has a fixed length of 32 bits, the number of individual addresses is limited. As memory has gotten bigger and bigger, computers are starting to run out of addresses for the individual blocks. To allow computers to address larger memory spaces, they are switching to using 64 bits for each address.

To cope with these larger addresses, operating systems as well as applications have to be updated. As late as 2006, Apple’s story was that they would upgrade both Carbon and Cocoa to 64-bit versions, allowing all Mac applications exist as 64-bit versions. Adobe thus worked on a 64-bit version of Photoshop. Last June, Apple pulled the rug out from under them by killing the 64-bit version of Carbon.

This leaves Adobe with a year of wasted effort and no easy way to create a 64-bit version of Photoshop.

I want to make it perfectly clear that I do not think that Apple’s intent was malicious in any way. Recently, there has been quite some evidence that Apple’s engineering is understaffed. In order to finish the iPhone in time, Apple pulled engineers from Leopard and had them work on the iPhone, which lead the Leopard’s delay. It is obvious that Apple either simply found out that they did not have the resources required to finish 64-bit Carbon in time, or thought their developers’ time would be better spent working on something else.

So now Adobe is forced to throw away some of their work and rewrite large parts of Photoshop in Cocoa, which isn’t a small task by any means.

How can Apple afford to do this?

So how can Apple do this? Back when they moved from Mac OS 9 to Mac OS X, Microsoft and Adobe were able to force Apple’s hand. Why don’t they have that power anymore?

Apple learned a lot from that time. It’s a lot less dependent on outside developers today.

Microsoft

When looking at Microsoft, first of all it’s important to keep in mind that a 64-bit version of Office isn’t really needed. Office doesn’t have to cope with documents sized in the multi-gigabytes. Office works perfectly well in 32-bit Carbon, and will continue to do so for decades, if Apple keeps 32-bit Carbon updated.

Second, there’s iWork. While iWork isn’t a perfect replacement for Office, it works really well for many people. Today, it’s possible to use a Mac that is free of Microsoft applications in almost any environment.

Adobe

Adobe is a tougher nut to crack. While Apple has been competing with Adobe on many fronts such as video editing or photo management, they don’t have a Photoshop killer.

What Apple has been doing for the last few years, however, is create APIs that make it easier to create Photoshop-like applications. Using Apple’s Core Graphics frameworks, developers can create rudimentary graphics applications within days, and even small teams can create applications that, even today, can replace Photoshop in many cases. Pixelmator, to name one, was created by one single developer and one single user interface designer. Even in its first version, it does many things that Photoshop does. It even does a few things Photoshop doesn’t do. More importantly, it is improving quickly. While Pixelmator currently still lacks many features Photoshop users take for granted, there are new Pixelmator versions with more features almost monthly.

Here’s another thing Apple has done: Its popular photo management software Aperture now supports plugins. There is nothing stopping a third-party developer from adding an image editor with many of Photoshop’s features right within Aperture.

As Apple continues to improve its graphics frameworks, it won’t need to create its own Photoshop competitor, because it will have an army of third-party Photoshop competitors.

This, I think, is why Apple was able to simply kill 64-bit Carbon: For the last decade, it has worked hard on becoming less reliant on Microsoft and Adobe. Delaying the 64-bit version of Photoshop by a year or two won’t hurt Apple at all.

April 5th, 2008 / Tags: appler, aperture, photoshop, lightroom, mac os x, mac os 9, carbon, cocoa, adobe, microsoft, word, iwork, iris, acorn / Trackback

Pixelmator, Acorn, Iris and DrawIt doing real-world tasks

This is a greatly enhanced version of my original comparison of Pixelmator, Acorn and Iris. Here’s a list of changes:

• Due to popular demand, I’ve added DrawIt to the list of reviewed applications (I originally did not include it since I felt it was more of a vector image application)
• Acorn 1.1 is now officially out, so I’ve changed the review to take its changes into account (new features pertinent to this review include a new drop shadow filter, drag and drop support for moving layers between images, web export and speed improvements)
• Joshua Lund alerted me to the fact that you can push Caps Lock to get Pixelmator to draw the brush cursor in the correct size. I typically turn Caps Lock off on my Macs, so I never noticed this

In recent months, a lot of new image editors have appeared on the Mac platform. New APIs from Apple such as Core Image have allowed small, indie developers to create quite sophisticated image editing tools.

I’ve seen a few reviews of these applications, but the reviews mostly concentrate on user interface concerns. I’d like to do something different here; Instead of simply looking at their UI, I’d like to look at how these applications handle tasks I typically do. In this review, I’ll look at three different tasks:

1. Stitching a few shots to create a panorama image
2. Adding a fancy title to a picture
3. Creating a simple pixel image

I will not look at fixing levels, exposure and the like, since iPhoto does a pretty good job at that, and I think most people will use these editors in conjunction with iPhoto or even Aperture or Lightroom, using them to do tasks that involve layers and selections and pixel-level operations, features which iPhoto, Aperture and Lightroom don’t provide.

Some Disclaimers

• I am using these apps on a MacBook Pro 2GHz Core Duo with 2 Gigabytes of RAM.
• I would have liked to also review Photoshop Elements 6, but I haven’t got a copy of it yet.
• I bought licenses to all reviewed applications except DrawIt with my own money, and have no financial (or other) ties to any of the companies which make them. I used the DrawIt demo for this comparison. Of all the reviewed applications, I have the least amount of experience with DrawIt.
• Since I am used to Photoshop, and since Pixelmator works most similarly to Photoshop, I am most likely slightly biased towards Pixelmator.
• I am testing Pixelmator 1.1.2, Acorn 1.1, Iris 1.0b3 and DrawIt 3.3.3, which are the most recent versions of these apps at the time I’m writing this. Iris is still in beta and not a finished application.
• It may be slightly unfair to include an unfinished application in this comparison, but since it actually managed to do one of the tasks Acorn could not do, I decided to include it anyway. Still, keep in mind that Iris is still in beta. With that out of the way, let’s get to the first task.
• Including DrawIt, primarily a vector drawing application, in such a pixel-oriented comparison may be a bit unfair, but it was a popular request after the first version of this comparison went online.

Manually Stitching Images

For this test, I’m going to manually stitch two images I took when creating this panorama image:

I took these without a tripod, so the images don’t align quite properly.

Each image is 3072 × 2048 pixels in size.

Pixelmator

I start with the left image, making the canvas larger to add room for the second image. I add the second image as a layer using drag and drop, make it slightly transparent, and align the two images. I then add a mask to the second image’s layer and start removing parts which don’t fit. This all works very well and Pixelmator still works quite quickly, although not as quickly as in Photoshop.

By activating Caps Lock, the cursor can be changed into a circle with the actual brush size. This is a bit unfortunate, because Caps Lock changes the behaviour of other tools (such as the selection tool), and also because I typically turn the Caps Lock key off entirely.

Pixelmator has a masking mode which allows for creating selections by drawing into the image. Using this, it’s easy to apply Filters to a selection, blurring it. Filters can also be applied to layer masks.

All in all, Pixelmator offers all the features needed, but could use a bit more speed and stability.¹

Acorn

Again, I’m starting with the left image, resizing and adding the second image as a layer. Resizing tools are a bit less sophisticated than in Pixelmator; Unlike Pixelmator and Photoshop, Acorn does not discern between resizing the image, and resizing the canvas.

Acorn 1.1 introduced dragging of layers, so I simply drag the second image’s single layer into the first, resized image. For large images, zooming with the slider becomes cumbersome; I prefer the zoom tool (Acorn provides a zoom tool, but it’s hidden in its palette). Even though Acorn 1.1 seems faster than 1.0, it still feels sluggish when working with larger images.

Acorn does not support layer masks, which means I have to actually delete parts of the layer to stitch the images. Unfortunately, even when anti-aliased, the eraser tool leaves a sharp edge, which makes it impossible to seamlessly blur the two images together.

Stitching images in Acorn seems impossible.

Iris

First weirdness: You can’t open Iris in an “empty” state. You’re forced to either select an image to open, or create a new image. If you hit “close” on the welcome screen, not only does the screen close, but so does Iris itself. Another nit: Images open fully zoomed instead of zoomed to fit the window.

I attempt the same thing: I open the images, resize the left image (the cursor does not change to show the selected tool, which is extremely disconcerting), paste the second image. The Cmd-A shortcut only works after actually clicking into the image. Dragging layers does not work if there is no selection, which seems to make it impossible to drag parts of the layer that are outside of the image back into the image, since you can’t select them. Strangely, layers are ordered from bottom to top, with the topmost layer in the Layers palette being the bottommost layer of the image.

I found no way to change the transparency of layers. There’s a context menu on layers which has commands that seem to set layer filters, but the commands don’t do anything.

What Iris does have is a rather neat little editor for brushes and the eraser. Using this, I can create a large soft brush and erase the parts of the image I don’t need (see brush stroke on top right of the stitched image).

while Iris is missing most of the features I would have liked to use for this task, it does offer enough features to get the task done.

DrawIt

I again start by opening the first image in DrawIt. Unfortunately, even resizing the canvas to accommodate the second image creates issues. For some reasons, using “Edit” -> “Change Document Size” not only changes the size of the canvas, but also the size of its image layer (as soon as I select it), which stretches my first image. Undo only works inconsistently and, in some cases, does not redraw the image properly until I zoom in and out again. This is actually all very strange. Here’s the image after I’ve opened it:

This is what it looks like after “Edit” -> “Change Document Size”:

So far so good. However, when I then click on the “image” layer, this happens:

And hitting Cmd-Z leaves me with this:

Until I zoom in and zoom out again, at which point I’m back where I started:

This approach obviously does not work due to some bug (presumably - maybe everything works correctly and I just don’t understand what I’m supposed to do). So I create an empty new image with the proper size and paste the two layers. This actually ends up working. There is no obvious way of making layers partially transparent, so aligning the two layers is quite hard. DrawIt has a masking feature, but figuring out how it works is - as with most things in DrawIt - hard. The documentation suggests that there’s a Screencast that explains masks, but… which one is it? After a bit of playing around, I figure out how masks work. I also find out that it’s possible to change the brush size and softness by clicking on the gear to the left of the Image label above the layers area (although sometimes, clicking on the gear simply removes the image breadcrumbs without displaying the tool settings). In general, the UI feels alien. I actually can’t figure out how to delete a layer, and now I can’t select my second layer anymore; as soon as I select it, DrawIt freezes for a few seconds and then deselects it again.

I decide to start again. Create new empty image of the proper size. This time, I drag the two images into DrawIt right from the Finder. On my first attempt, I can’t select the two layers after that. So I start fresh again. This time, it works. As in Iris, Layers are ordered backwards (Layers which are further down in the list appear above layers which are above them in the list). I add a mask and start editing it. Unfortunately, I somehow end up with an image that has a bright white line in the middle that I can’t remove. I’m starting to question my sanity. And now the app “unexpectedly quits” on me.

Starting fresh yet again. This time, I get a bit further. And then, I find out that brushes stop working after their softness is set to a value outside of 0 and 0.44. Which means I can’t merge the two images.

Admittedly, I am now sitting in a corner, weeping like a little child. The application’s strange modal interface makes sure you often don’t know quite what mode you’re in, and thus what clicking on the image is actually going to do. Modes switch unexpectedly (for example, entering a softness for the brush and hitting return switches your tool to the default move tool, which means that trying to paint then actually moves parts of your image), and the app is sluggish and buggy.

Trying again a day later, I manage to stitch the two images quite quickly, partly due to DrawIt behaving a bit better, and partly due to me knowing how masks work in DrawIt, and how I can work around the issues I encountered. Still, the brush can’t be made soft enough for a nice stitch, although the final result looks a lot better than Acorn’s:

Fancy Title

For this task, I’d like to add a fancy title to an image. The title should have a background image and a drop shadow.

Pixelmator

I open the image I want to put the title on. Using the type tool, I type the title. I add the image I want to use as a background for the type as a new layer. I Option-click on the border between the type layer and the new layer to make the new layer the background of the type layer. I then duplicate the type layer, rasterize the duplicate, blur it and move it a few pixels down:

Layer filters would have been useful for the drop shadow, but Pixelmator doesn’t provide them. Other than that, adding a title in Pixelmator is easy.

Acorn

Again, opening the images, adding the type, adding the background image. Acorn does not allow using layers as backgrounds for other layers. Instead, I rasterize the layer and use the magic wand to select the letters. I then invert the selection and cut out the parts of the background in the selection. Using Acorn’s Drop Shadow filter, I add a drop shadow to the text background layer (adding Drop Shadow to a type layer would require rasterizing the layer first, but since I had to do that anyway, it doesn’t matter).

Iris

I can’t do this task in Iris as the type tool is too broken.

DrawIt

I open the image in DrawIt. I add the text background image as a layer. I add a mask to the text background image and type in the text. Unfortunately, adding an effect to this layer only adds the effect inside the mask, so I add a text layer for the shadow, enter the text again, and add a blur filter. The “add” button displays the menu for selecting which effect to add in a weird place, but it works anyway. I first add Gaussian Blur to the effects list.

All of this actually works really well.

Pixel Image

In this task, I want to create a smiley image for something like a chat application. The image is 16x16 pixels large and has black, white and transparent pixels.

Pixelmator

I create a new image. Turning off anti-aliasing, I create a circle and fill it with black. I then create a smaller circle and fill it with white. Using the pencil tool with a size of 1 pixel, I draw the face. Switching between black and white is a bit of a chore, since I can’t just alt-click to get the eyedropper, and switching background and foreground color requires the use of the context menu. Still, Pixelmator works reasonably well for this type of work.

Acorn

At first, zooming seems limited to 1000%, which is a bit small for a 16x16 pixel image. Fortunately, it is not actually limited; instead of using the slider, click on the image to the right of the slider to zoom larger than 1000%.

Again, I create a circle. For some reason, the selection looks really weird:

Unfortunately, flood-filling the selection doesn’t look any better, and the circle is anti-aliased despite anti-aliasing being turned off:

Acorn’s selection tool seems to select something else than it tells you it will. Here’s the selection while the tool is in use:

But this is what actually seems to be selected:

I try to work around this by selecting smaller circles, but nothing works out to the circle I want.

It would be possible to use the bottom-left “good” side of the circle for all four corners of the image, but at this point, it’s quite obvious that Acorn does not seem suitable for this type of task.

I also tested the most recent beta version of Acorn, and the selection tool behaves the same in that version.

On the plus side, though, Acorn does have a nice feature which the other two lack: A web export panel.

Iris

Strangely, Iris has similar issues. This selection:

Creates this circle:

Which looks like this when filled in:

Again, I stop as the application seems unsuitable for this type of task.

DrawIt

There seems to be no way of turning off anti-aliasing in DrawIt, so this task can’t be done.

User Interface

When I said I wouldn’t say anything about the user interface of these apps, I lied. But I promise to keep it short.

Pixelmator’s UI is very close to Photoshop’s. If you’re familiar with Photoshop, you’ll instantly be familiar with Pixelmator, which is good. Unfortunately, this means Pixelmator also inherited Photoshop’s mess of palettes, which means this application works best if you have either a really large screen, or more than one screen.

People are raving about Acorn’s UI, but I find I often have to click twice to select a tool, which starts to get slightly annoying if you constantly switch between tools. Going with text-only labels for tools also makes it hard for me to figure out which one to click - each time I switch tools, i have to scan the list, reading entries until I find the one I want. And finally, since the tool window is so wide, it often overlaps with the image; there’s no easy way to only show the stuff I need, the tool window always has the same size. I think Acorn’s UI, while interesting, is ultimately flawed.

Iris shows the list of open images as a horizontal list at the bottom of the screen, which is neat. Unfortunately, I can’t drag images from the Finder into the list to open them. Still, I really like this. I don’t like the tool palette. The icons are a bit ugly, and clicking on some of them opens a small menu, without their buttons giving any indication that they aren’t normal buttons. Also, you don’t see which tool is selected from looking at the tool palette.

DrawIt has a really strange interfact with many modes. While it offers pixel editing features, it actually feels more like a vector application. If you often have to mix and match pixels and vectors in a single image (and used to like Deneba’s Canvas), this application might be for you.

Unfortunately, all of the editors are missing basic keyboard features, like holding down Option to get the eyedropper, drag modifiers like holding down shift to move only horizontally or vertically, holding down shift to open circle or square selections, holding down option to duplicate things, holding down shift to retain the ratio when resizing things, holding down shift to draw straight lines or create vertical or horizontal gradients, holding down shift while clicking twice to draw a connecting straight line between the two.

And finally, despite of what you might have read, none of these apps are particularly fast. While they start up pretty quickly, actually working with them with large images can become painfully slow. Photoshop remains the only application which can work with really large pictures and many layers.

Conclusion

Unfortunately, unless your needs are very basic, at this point I can only recommend Pixelmator, though even Pixelmator is not suitable for advanced image editing involving large images and many layers. And while Pixelmator is the most full-featured application of the three, it’s still missing useful and somewhat basic features such as layer effects, rulers, guidelines or web export with jpg preview.

Iris is still in beta, and it shows: a lot of features don’t work or are buggy. It’s not usable for actually getting anything done.

Acorn is missing too many fundamental features. It’s okay for very basic image manipulations and it has some neat filter features, but for the tasks I tried to do in this review, Acorn’s features are too basic. Furthermore, many features seem to still be a bit buggy.

Both Acorn and Iris lack precision when working with selections on the level of single pixels, and turning off anti-aliasing on selections does not seem to actually turn off anti-aliasing.

Pixelmator is the most full-featured editor of the three. It offers most of the features people actually use. If you don’t intend to work with large images with many layers, this editor might actually be adequate for you. Of the three editors, Pixelmator has the least amount of deficiencies for the type of work I do, and it actually replaced Photoshop for all non-demanding tasks.

DrawIt offers the most vector-related features. This actually is a vector image application more than a pixel-based one. While DrawIt has a strange, unfamiliar interface, is sluggish at times, and seems to suffer from quite a few bugs, it actually offers many interesting features. If you work with pixels and vectors in the same image, this app is definitely worth a look.

Even with their obvious flaws, all editors are extremely promising and interesting, and I hope and expect that they all will become viable options for prosumers within the next year.

Further Reading

Jon Whipple has written a similar comparison of Pixelmator, Acorn and DrawIt.

February 19th, 2008 / Tags: acorn, iris, pixelmator, drawit, editor comparison, photoshop, stitching / Trackback