Advertorials & Opacity
I’ll say one thing for daringfireball’s mini-posts with links — at least they don’t pretend to be product reviews. Even so, mixing editorial with advertising is pretty damn annoying, and it’s perhaps the single thing about daringfireball I really don’t like.
Now it’s possible that this is actually not an advertorial, but a heartfelt recommendation — however, I’m giving John Gruber the benefit of the doubt. If he’d actually tried using Opacity and written this, my estimation of him would drop far further.
Based on its focus and feature-set, Opacity seems like a must-have product for developers. It appears to be a layer-based Core-Image savvy vector-drawing program for UI designers that snaps vectors to pixels to make sharp but resolution-independent graphics. I wasted about two hours trying to produce some simple icons in Opacity — icons I had already designed in Photoline (which is definitely not intended for this purpose), which means I had done the hard part elsewhere — and it looked fairly promising until I tried exporting the icons (something Opacity is apparently specifically designed to optimize).
Now, I have to say that the warning signs were there from the start. Opacity’s icon is childishly horrible, and the sample icon they focus on in most of their web marketing on (a faux Safari-style compass) is a sad joke and a typographic nightmare. Both things that make me believe Gruber was simply schilling this piece of crap for a few bucks.
So the basic idea of Opacity is that you want to use vector graphics because they’re resolution independent, and you want pixel-aligment to prevent horrors like single pixel lines being rendered as smears when their coordinates are fractions (e.g. when drawing in HTML5 canvases if you create a rectangle along integer coordinates and stroke it with a single pixel line you get a 2-pixel wide 50% transparent line. Ouch.) The problem is that Opacity does all this with astonishing incompetence.
I was trying to create 24×24 pixel button icons. Opacity offers a “UI mode” for this which is (supposedly) optimized for creating 32×32, 24×24, and 16×16 icons from a single vector source, and lets you work in your favored resolution. Perfect! I switched to 24×24 view, and started drawing.
Now, Opacity doesn’t snap your vertices to pixels or pixel edges. Nope, it simply snaps the coordinates it derives from those vertices to pixels or pixel edges (this may be a preference item, but I’m talking default behavior). So the odd thing is that you’ll draw an object and get something else. You then slide the vertices around until the rendered bitmap looks like what you want, and then when you’re happy, you can preview the results in all the desired (?) output sizes (i.e. 32×32, 24×24, and 16×16). So editing splines and polygons is kind of hit and miss, but you can get the job done.
What about output? My first icon was a simple “magnifying glass with a + sign inside it” to indicate “zoom in”. I had produced a pretty nice version in Photoline (think Photoshop but cheaper and faster and with a clumsier UI for most things, but better vector tools than Photoshop and better bitmap tools than Illustrator) but it suffered from “smeared lines and edges” syndrome. (Note that Photoline is cheaper than Opacity.) I replicated this design in Opacity and it looked perfect — I mean perfect — in Opacity. I then clicked preview and discovered that:
- The + sign in the 32×32 preview icon was messed up. BADLY messed up. Oh well, I don’t actually want a 32×32 icon so who cares?
- The + sign in the 24×24 preview icon was messed up in the same way. WTF?
WYSIWTF
I’ve just coined a new term for what Opacity does.
So here’s the deal. I don’t know exactly what Opacity is doing wrong, but my guess is that when you’re in 24×24 edit mode it generates your edit (“fatbits”) view by snapping vertex coordinates to pixels at 24×24 resolution. So far so good. But when it tries to render the icon at 32×32 it snaps the vertices to a 32×32 grid (producing random results), and when it tries to render a 24×24 icon it snaps the already-snapped-to-the-foreign-resolution vertices to the 24×24 grid, producing random pointless variations from the results you first thought of. How this piece of crap hopes to justify its existence as freeware let alone an $80 pricetag ($40 for the crippled “express” version) escapes me. Bear in mind this is in the ballpark of Photoshop Elements, Intaglio, Pixelmator, Acorn, and Photoline.
(Disclaimer: you can’t actually export anything from Opacity (without having crap splatted on it) until you register — in fact you can’t even preview anything properly, let alone export to code, so it’s possible all this stuff works perfectly when you pay for $80, but since my free trial went so swimmingly, I’ll be hanging on to my dollars.)
Incidentally, aside from Photoline and Photoshop, the only “bitmap editor with vectors” program I’ve got handy is Acorn 1.5.x (I haven’t played with Acorn 2.x yet because my Macbook Pro is still running Leopard — but Acorn 2.x hasn’t added any vector functionality according to the release notes). Acorn’s vectors comprise lines, circles, and rectangles (seriously, that’s it) but with the intriguing property that all vertices snap to pixels. It’s a brilliantly polished half-assed feature. Indeed, if Acorn’s vector layer didn’t suffer from all kinds of bizarre UI bugs and supported arbitrary bezier curves it would crush Opacity like a bug.
Given my icons were very simple, I tried doing them in Acorn and produced perfect results (albeit only at 24×24 resolution) once I figured out that (a) forcing Acorn to create a new vector layer requires creating a bitmap layer you don’t want and trying to draw a vector on it, (b) duplicating vector layers in Acorn is prone to randomly losing or reordering layer components, and (c) selecting vector objects in Acorn requires marquee selecting way more objects than you actually want and then shift-deselecting the ones you didn’t want in the first place by guessing where the hit rects of the objects are. The fact that producing these icons in Acorn was vastly more pleasant and quicker and produced better results than undertaking the same operation in Opacity speaks volumes.
Gruber — hang your head in shame.
Reviewing the Reviewer
I’ve written magazine software reviews for real money way back when people like me still read magazines. Even when the typical computer user’s principle source of information was magazines (such as Australian MacUser — the now defunct publication I wrote for) and reviewers got packages months in advance and had weeks to write their reviews, most reviews were hopelessly superficial. (Mine were not, but I also tended to hand them in rather late.) So it should come as no surprise that in these days of incredibly rapid releases and zero lead times, most reviews are utter crap. Pretty much the only reviewers worth reading are either (a) reviewing a product long after release, or (b) dedicated beta testers. Anyone else simply doesn’t have the “real world product experience” to say anything much useful.
It’s astonishing to me that despite the dozens of fairly prominent bloggers who discuss graphics software for the Mac, none seem to ever mention Photoline. OK, it’s not Mac-only (but then neither is Photoshop or Photoshop Elements), and it doesn’t have a gratuitously chic UI (like Pixelmator) but it’s actually useful. No-one who uses graphics programs for anything but the most trivial of edits (redeye reduction, fixing exposure, cropping) would give Acorn — say — anything other than short shrift as a general purpose image editor. Pixelmator is at least vaguely useful for basic image editing. I’ve seen some decent work done with Pixelmator. The only real use I have for either product is as a wrapper for Core Image filters (and since I figured out how to graphically set focus points for filters in Acorn, that means I have no use for Pixelmator whatsoever).
The gold standard for reviews (at least in my experience) is the New Yorker‘s non-fiction book reviews. A typical example will start by discussing the recent publication of a particular book, or several books on a given topic, and then broadly sketch out that topic’s landscape, including the strengths and weaknesses of the existing “definitive” works covering the same material. The review will then go on to give you a rough outline of what the new book or books cover, what they add to the existing literature, and what their weaknesses — if any — may be. The result is that I — for one — often end up reading reviews of books I have no interest in, find any given review both educational and interesting, and end up either wanting to read the book(s) discussed or happy enough not to, but with some kind of vague understanding of what I’m missing out on. Fabulous.
Obviously, simply having read the book or books in question and being well-versed in the pre-existing literature covering the same subject matter is but a feeble and insufficient prerequisite for writing such a review.
A good software reviewer should do something similar. They should discuss the problem domain the program or programs handle, the dominant products (if any) in that category, and describe what the reviewed products add (if anything) and any obvious weaknesses. It follows that they must have a broad understanding of the problem domain, solid familiarity with at least some existing competing products, and have seriously used the product being reviewed. It’s pretty clear when you’re reading such a review, and it’s pretty clear when you aren’t.
Thank goodness for Ars Technica.