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.

MacFUSE Follow-Up

I recently wondered aloud about the benefits of MacFUSE-supplied ssh access in a web development environment. A reader asked for a follow-up in the comments to that post, so I thought I'd just do a quickie today.

After writing the article, I tried out MacFUSE and the sshfs extension to that bundle. This combo facilitates the mounting of ssh-enabled computers directly on the Mac OS Desktop via a bundled GUI app, foregoing the need for an FTP client application. It was our hope that this would provide a more intuitive and user-friendly experience for our web developers. Unfortunately, in my experience there were bugs: the ssh filesystems often hung or had trouble mounting, often requiring a logout or restart to get things back to normal. (Mind you, this was over a month ago, in Mac OS X 10.4.something-or-other and God-knows-what version of MacFUSE and sshfs.) Also, from a user-simplification standpoint I felt that adding yet another application to the mix (the sshfs GUI app for mounting shares) didn't really do all that much to simplify things. In fact, in some ways, it complicated matters as it is not standard practice anywhere as yet.

That said, I really like the idea of mounting any sort of network share in the Finder. It's what's done in every aspect of our filesharing lives except web development, for some reason (that reason mainly being that Apple, inexplicably, still has not implemented this capability into the Finder.) As I mentioned in the original article, there are styles of development that take place outside the lab that are inherently different from what can happen inside a lab. The use of MAMP, for instance, is not friendly to a shared, multi-user environment, but is perfectly suited to a lone user on a single computer. So, again, I wonder aloud, do we provide a different way of working inside the lab than outside? A completely different workflow?

Ultimately, my answer will mostly be yes, I think. We provide it. We provide it right alongside the sorts of workflows that are common in the industry today. We provide both. We show students. We show teachers. And hopefully, someday, down the line, this will become the standard way of developing for the web. Until then we leave the old ways in place; they are not mutually exclusive.

My concern with MacFUSE and sshfs right now is stability. Because the product requires kernel extensions, and because I saw bugs in my limited testing, I am reluctant to put this on our machines. I can, however, use NFS from within our lab to provide a testing ground for the same sort of behavior that MacFUSE provides (i.e. ssh servers on the Desktop). And this will actually fit in nicely with the way we mount other shares in the lab as well (more nicely than the sshfs GUI, in particular). I will most likely implement this over the summer, however, as there's not enough time in the semester for it to really have much impact. Also, things will probably change a bit with the arrival of Leopard to the lab, and I don't see much point in making folks learn it twice.

Again, external development can be handled differently. So I may recommend, for advanced users, the use of MacFUSE outside the lab if they really end up digging the Desktop web development experience.

That's my take at this point on MacFUSE and web development. Hope it's useful to someone.

Web Programming and MacFUSE

I'm not a web programmer by any means. But a component of the department I work in deals with the web from an artistic standpoint, and a subset of that group does, in fact, do programming. We have web programming classes.

Recently, one of the teachers of one of those classes made the charge that our approach to web programming is old and outmoded. Whether this is true or not is not really the issue. I've been looking for new ways to think about the systems end of that workflow because, well, that's my job, and because it's an inherently interesting challenge to me. How can we make our web development environment more user-friendly?

One general suggestion has been to make the experience more "OS-like." And one step in this direction is to have the web server mount on the Desktop, allowing the developer to work on her site as if it were local. That is, rather than firing up one of the popular SFTP clients and transferring files back and forth from the local machine to the server, the developer could mount her site — or actually, the share her site lives on — directly on the local filesystem. I have two options here: MacFUSE and NFS. I'm testing both currently. So far I've had a couple minor hiccups with MacFUSE's sshfs.app, but it looks to be a fairly smart and user-friendly implementation that web developers here might benefit from. And the NFS approach would work well also, though only from inside the network.

I'm curious what other Lab Admins are doing with regards to web development in their environments. How have you facilitated ease-of-use for a process that's inherently complicated? Or have you? Also, I'm curious if anyone is using MacFUSE — specifically the sshfs component — and what experiences you might have had with it, either positive or negative.

If any of you fine readers have any thoughts on this I would really love to hear them. I've been querying students, staff and faculty for ideas, but haven't come up with much. Maybe things here are perfect, but somehow I doubt it. And, as always, I really just want to make things better.

Please sound off in the comments if you're so inclined.

Word of the Day

The term "sea change" has been extremely popular of late. I'm not sure why. I have a sneaking suspicion that the universe of online Mac journalism is highly incestuous. (I feel dirty.) But stranger still, the word "rejigger" has popped up, in one form or another, in no fewer than three articles or blogs, today alone, each related to Leopard.

And that is why rejigger is today's Word of the Day.

Okay kids. Give it a rest now.

Hallelujah Items

Two hallelujah items today: First, Google Mail now supports IMAP. This is great news for us POP haters, particularity to the extent that we love ourselves some serious GMail. As of this writing, GMail's IMAP capabilities aren't available to everyone, but should be in the next few days. According to Google:

Don't fret if you don't see "IMAP Access" yet under the Settings menu. We're rolling it out to everyone over the next few days.

Second, the hideous Leopard Dock will now, apparently, be optional. And what's awesome is that the attractive replacement actually looks to be an improvement over the current, Tiger Dock, at least from my aesthetic perspective.

Neat-O!

The Tiger Dock of Yore: All Good and Well, and Square

(click image for larger view)

The Godawful Leopard Dock: My Eyes!

(click image for larger view)

The Attractive and Useful Leopard Dock Option: Rounded and Tinted

(click image for larger view)

By default, the no-glass option is apparently only available when the Dock is placed on the side. It can be had at the bottom, however, using the following command:

defaults write com.apple.dock no-glass -boolean YES; killall Dock

At least that's what being reported as of today, two days before Leopard's actual release. We'll see how it actually goes. Either way, I'm happy.