ScreenFlow and Opacity Redux

I recently wrote some criticism of a couple very promising new applications: ScreenFlow and Opacity. Both these apps came out at roughly the same time, and each was of particular interest to me. Each also had some pretty glaring bugs.

One of the great things about being a member of the Mac Community is that it actually is a community. Loosely, It's a group of people with similar interests and ideas about the computing experience. And Mac software developers — perhaps more than anyone — feel keenly this bond. At least the good ones do.

So, in true Mac Community fashion, shortly after my initial reviews (like, the next day) I got comments from the developers of ScreenFlow and Opacity. And those comments basically said, "Hey, I addressed the bugs you mentioned, and have released an update to my software. Check it out!"

I have checked it out. And it is good.

Unfortunately, I don't have time to do a complete review of these products. And I'm sure that someone more qualified will beat me to it in any case. But I did want to mention a few things about each.

ScreenFlow
ScreenFlow is a revolutionary approach to screen capturing and screen-based presentation. It is a complete environment for creating computer-screen-based presentations, in fact, letting you capture both your computer screen, its audio, and the video and audio from an external camera all at the same time. ScreenFlow then drops you into a very elegant editing mode that allows you to do all sorts of tricks specifically designed for screencasts (the Callout Actions are particularly nice).

I had a few problems with the 1.0 version, but I'm happy to report that the latest update, v. 1.0.1, fixes them all. I've been playing around with it a lot, and I can't say I've really had any problems at all, at least on my home machine. My work machine sports a 30" monitor, however, and ScreenFlow has problems with its native resolutions. The good news is, it says so:

ScreenFlow Alert: Better Late than Never
(click image for larger view)

The bad news is that this alert comes up after you've captured your too-big screen. Still, it's absolutely crucial information, and this alert is better than the nothing we had in version 1.0. I'll take it.

Otherwise, ScreenFlow has been a complete joy to use, and I do anticipate buying it for our lab at some point, probably in the summer. I've even showed it to my boss, who was duly impressed.

If you're looking for such a beast, ScreenFlow makes all the others I've tried pale in comparison.

Opacity
Opacity is a graphics app dedicated to creating, editing and outputting screen graphics — for the web, applications or desktop icons. As an occasional icon creator I can tell you, something like this has been a long time coming. In the past I've used a combination of Illustrator, Photoshop and the IconBuilder plug-in for Photoshop to create icons. Opacity costs only slightly more than IconBuilder, and it doesn't require Photoshop. In fact, it doesn't require anything. It, like ScreenFlow, is a dedicated environment for doing one thing. Unified, task-based apps like this are all the rage right now, and I for one think it's great.

Opacity Interface: Simple and Specific
(click image for larger view)

Opacity is more personally interesting to me than it is something we'd need for the lab. It's also something I need more time to explore. ScreenFlow is almost instantly intelligible. But Opacity will require a bit more investigation on my part before I decide whether or not I need it. Since many of my icons are hand drawn with a Wacom, I'll need to investigate the level to which this will be possible in Opacity.

But there are two things I want to point out about Opacity. One, I like the idea of it very much, and I think it's actually fairly novel on the Mac. I'm sure professional icon designers are loving that this exists and that it might actually turn out to be good. Two, it seems to be a very well-though out application. I think icon design is actually a much more complex task than screencast recording. But Opacity strikes a really good balance between the complexity of the task and a clean, elegant UI. It might not be right for me in the end, but if you design computer graphics of any kind, you should certainly take Opacity for a spin.

Oh, and one other thing about Opacity I'd like to mention: Its latest version (1.0.1) resolves every issue I mentioned in my initial article.

So, my thanks to the creators of these fine applications. Not only have they made what look like a couple of really neat apps, but they've handled initial criticism with the aplomb worthy of a Mac Developer.

Great work, guys!

UPDATE:
Testing of Opacity continues, and not without issue. The program is a good deal more solid than it was in version 1.0, but, for the record, attempting to import very large Illustrator documents causes the "Out of memory" alert to rear its ugly head once again. This alert will cause the application to quit. And, unfortunately, the default behavior of Opacity is to open the previous document on launch. If that document happens to be a large Illustrator file that causes the alert and subsequent quit of the program, you will be unable to successfully launch Opacity without moving the offending file. Bummer.

Also of note, Opacity is not currently pressure-sensitive when used with a Wacom tablet, which may be a bit of a problem for some — myself included — though perhaps not a deal-breaker. I'm certainly not averse to creating line-art in pressure-sensitive programs (like Illustrator) and importing them into an app like Opacity if it beats my previous workflow. But obviously this won't work if the Illustrator file essentially kills Opacity.

In any case, like I said, this is all for the record. I still feel Opacity has great potential. That's why I'm testing it so rigorously.

What's So Funny 'Bout Peace, Love and WYSIWYG HTML Editing?

I'm not sure why, but the concept of the WYSIWYG HTML editor has really taken a beating. The most recent comment I've heard comes from Shawn Blanc's review of MarsEdit, an offline blog editing product. Shawn says that:

"In all my experience with WYSIWYG editors I have found them a clumsy enemy of fine web typography."

This, apparently, is the major rationale for what seems to be the prevailing notion in the web development community that WYSIWYG HTML editors are an inherently bad idea. The logic seems to go something like: every time I edit my web page in a WYSIWYG editor, the experience is a bad one, therefore the concept of WYSIWYG HTML editors is flawed from the get-go; real designers only ever edit raw HTML. (Though I might point out that I have yet to see or read of a single example of a WYSIWYG editor creating terrible HTML code in a very long time, at least when it comes to fairly simple HTML pages, which most blog pages are. But I'm getting ahead of myself.)

Comments like the following also make it sound like if I'm not editing raw text, I'm just a big pansy-ass wuss:

"I suspect most of you are at least a bit HTML savvy and prefer the use of monospace type and a HTML editor anyway. But for those who are getting weak in the knees at the thought of having to type your own HTML relax."

Now, I'm not a web developer by any stretch of the imagination, but my experience with WYSIWYG editors — even web-based ones — has been largely positive. And, though I'm fairly comfortable looking at HTML code (and actually enjoy looking at other types of code), I never, ever want to edit it if I can at all avoid it. It's a completely unnecessary distraction from what I'm here to do: write. I'd much rather work on something that more closely resembles the finished product and not have it cluttered up with code. It's not that I'm scared of the code, it's that I'm annoyed by it.

For my personal web pages I have always used Dreamweaver. And while the user experience offered by that app is not always the most intuitive or Mac-like, it's always far preferable to me than using a text editor. For my blog pages — which are all formatted exactly the same way as per the Blogger style sheets I've set up — I use the Blogger-supplied online WYSIWYG editor. As much as I like the idea of working on my blog offline, I do not use MarsEdit or any other such client. And the reason is because of their lack of WYSIWYG.

Blogger's HTML Editor: All I Really Need

(click image for larger view)

John Gruber also supports the use of MarsEdit and its ilk:

"My best argument for using MarsEdit (or any desktop weblog editor) instead of a web-based interface is that it’s like using a desktop email client instead of webmail."

That's a great argument, except that it's a bit flawed: A desktop email client adds features and ease-of-use to the email experience. MarsEdit, on the other hand, removes a major feature that, for me anyway, greatly hinders ease-of use. It's far less aggravating to me to use a web-based WYSIWYG editor than it is to use a desktop-based code editor. To follow Gruber's analogy, using MarsEdit is like using a desktop mail client that only shows you the code in which your email is written. MarsEdit hinders ease-of-use by making me look at code when I really don't need to. All I need are some very simple markup commands and basic text editing. I really can't see any reason not to use WYSIWYG, particularly when it comes to editing blogs.

But this is not to completely disparage MarsEdit. That's not my intention at all. It sounds like a great product, really, and MarsEdit's author, Daniel Jalkut even acknowledges the need for WYSIWYG in his product and is planning it for a future release. Awesome. I may even buy and use MarsEdit when that day comes.

My point is that the WYSIWYG HTML editor is a great idea that someone needs to get on and do right. I believe its time has come. Over the past few years I've watched a series of HTML editors hit the market. The latest are either completely template-based — like Apple's iWeb, which lacks any ability to examine the code when it's necessary to do so, which is a big problem — or completely code-based — like, well, all the others. In between is a gaping chasm. The giant WYSIWYG hole. CSS editors, too, seem to be plagued by this lack of WYSIWYG. So I always find myself using Dreamweaver in the end, for lack of a better replacement. I suspect I'm not alone.

Again, I can't help wondering if there's a faulty rationale at work here. Do software authors think that, because their WYSIWYG editor experiences have been bad ones, the basic idea is also bad? Or entirely too difficult to build? Or unprofitable? Because I think that, in the same way that beautiful, affordable image editors are springing up to challenge Adobe's dominance with Photoshop, WYSIWYG HTML editors could have great appeal. I've been marginally on the lookout for one for years, and I write web pages only occasionally. And the best I've found, frankly, is Dreamweaver, which is good but not great, and very expensive.

Or is it possible that it's just machismo? (God, I hope not. Is there anything worse than macho geeks?) It is possible that developers think that WYSIWYG just isn't cool? That real web developers would scoff at such a product? Seriously, why is it that Coda, an absolutely beautiful app that does, like, everything under the sun, lacks the basic WYSIWYG found in all web-based editors? (Yes, I would totally buy Coda if it had WYSIWYG. Without a doubt.)

Guys, all I can say is, you're missing a big opportunity here.

What Everyone's Bitching About

There's been no shortage of commentary on Leopard's 3D Dock, mostly because it's just ugly as Hell. But that's fixable.

There's been almost as much bitching about two other new visual changes in Leopard. The first is the menubar, which is now translucent. I'm ambivalent about this one. On the one hand, I understand that, from a usability standpoint, it's a bad idea. It's now slightly harder to read a primary interface element under certain conditions, those conditions being, in particular, the use of busy Desktop pictures and/or patterns. The default Desktop picture for Leopard, in fact, is an image of outer space whose star field can directly compete for visual attention with text in the menubar. My argument to this, however, is that busy, distracting, high-contrast Desktop pictures are a far greater hindrance to usability than slightly-harder-to-read menubar text, and if you're really bothered by the menubar changes, you should probably switch to a nice, solid or muted Desktop background and remove all distractions from your life once and for all. That's what I do and, so, while the I understand that translucent menubar is not the best idea for usability's sake, it really just doesn't bother me in the least. Actually, I kind of like the muted, lower-contrast lack of in-your-face-ness of the new menubar.

The other big gripe has been about pulldown menu transparency. No. Seriously. David Pogue of the New York frickin' Times for Pete's sake:

The most serious misstep in Leopard is its new see-through menus. When the menu commands — Save As, Page Preview, whatever — are superimposed on the text of whatever document is behind them, they’re much harder to read. Often, Apple’s snazzy graphics are justifiable because they make the Mac more fun to use. In this case, though, nothing is gained, and much is lost.

This one I don't get. Pulldown menus have been transparent in Mac OS X for a long time. (Oh, wait. I mean forever!) The difference between how Tiger deals with them and how Leopard does is extremely subtle.

Tiger Pulldown Transparency: Pinstripes! Ew!
(click image for larger view)

And Leopard does away with the pinstripes, which to my mind is a huge usability gain. At worst we break even here.

Leopard Pulldown Transparency: A "Serious Misstep." Really?
(click image for larger view)

I wonder sometimes if people are forgetting that pulldowns in Tiger were transparent. You'd think, by the level of general annoyance with this change, that they had. Honestly, people. It's really not that bad. I'm totally on board with the Dock thing (though a lot of people don't mind that even). But when it comes to the new transparencies, they just don't bother me much at all. I hardly even notice.

UPDATE:
Oddly, Firefox's group bookmark pulldowns exhibit the old-style, non-blurred menu transparency, minus the pinstripes of course. I can't find another application that does this. Weird.

Firefox's Group Bookmark Pulldown: Old Skool
(click image for larger view)