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.

iPhone to iCal Sync Problems

I recently had a problem with iCal syncing to my iPhone: Calendars would sync fine from the Mac to the iPhone, but any event entered on the phone would not sync to the Mac. Moreover, calendars deleted from iCal on the Mac — calendars that no longer existed — would still be available for syncing in iTunes. Clearly there was a problem with cached data of some sort, somewhere. But where?

After a lot of trial and error, and hunting around — I tried resetting iTunes preferences, iCal preferences, and anything else that might present an easy fix — I finally figured out where all this data gets mashed up. There are two folders in your home account that are responsible for syncing the databases between your iPhone and your Mac. The first one, as far as I can tell, just contains a backup of your iPhone data. It is:
~/Library/Application Support/MobileSync

The second is where all the syncing action happens:
~/Library/Application Support/SyncServices

To fix my problem, I renamed these two folders. They'll get recreated the next time you sync your iPhone and you can keep these in case anything goes wrong. Then start up iTunes and reset all the items under the Info tab for your iPhone. (Fortunately, items under the other tabs seem to have been left alone, at least in my case. YMMV.) I still couldn't see my calendars in iTunes at this point, but I went ahead and just hit the Sync button. And it worked.

Everything now appears properly in iTunes. New calendars show up; deleted ones disappear. And syncing calendars between my iPhone and my Mac works perfectly now.

UPDATE:
Reader Ferdinand points out that Apple strongly discourages the removal of the SyncServices folder. Instead they recommend resetting your SyncServices with the instructions in this article for Mac OS X 10.5 or this one for 10.4. I'm quite happy I didn't have any problems, but if you need to mess with your sync services, I strongly recommend following Apple's advice over my own.

Leopard Beefs

So I really like Leopard. It's nifty, but not without it's problems. I thought I'd take a minute to post some of the issues I've had with the new OS.

So far I've only had a few complaints. Actually, my initial experiences were quite positive. I did an Archive and Install, preserving user and network settings, on my work machine, a Quad-Core Intel Xeon tower. I left all my old preferences in place and used my old home account data. All this went off almost completely without a hitch. The only snag, oddly, was my Final Cut Pro Studio suite, which needed to be re-serialized. Beyond that, smooth sailing.

Upgrade Woes
That upgrade went so well I decided to do the same to my aging PowerMac 2.7 GHz G5, and for the first time since I bought it that machine felt slow. Dog slow. Problematically slow. This was cause for concern. But what finally convinced me that there were major problems was what Leopard did to my iPhone. Oh, the horror!

Addresses
On the first iPhone sync with Leopard, all my addresses got completely borked. Each address was there, yet the name field was blank and there was a lot of information that didn't make the transfer. Fortunately I had a backup, and I was able to get back up and running. Oddly, the second sync worked perfectly, and only the latest contact info on my phone was lost.

Photos
Importing photos from the iPhone to iPhoto was also problematic on the upgraded Mac. The import took an extremely long time, and the imported photos suffered from strange color shifts and banding. They were unusable.

At this point I decided to do a fresh install. This worked much better, and my computer has been running much faster and handling iPhone syncs much more reliably. As part of the fresh install process, I also started with a fresh home account, which may have helped as well. But this was not the only source of problems, as I verified their existence on a clean account as well. Still, better safe than sorry, I figure.

In any case, for whatever reason, older hardware seems to like a fresh install. Things have been working reliably now for a few weeks. I'm happy.

AFP and MPD
My other beef with Leopard has to do with AFP mounts in the Finder. The way the Mac OS has always dealt with such mounts in the past is that when you mount a shared drive, you authenticate as a user with access to the resource and the drive mounts as though the authenticated user had mounted it, even if that user is different that the one who's logged in. So, for example, I could be logged in as SystemsBoy, but authenticate to a server as JimminyCricket. The server will show me the available shares for JimminyCricket, not SystemsBoy, even if they have different access privileges to that server. If I unmount the share, I can then reconnect to the server, this time authenticating as SystemsBoy, and then I see the shares available to SystemsBoy. This is actually more useful than it sounds. I have numerous identities that I use on my network. This allows me, for instance, to be logged into a machine as a non-admin user, but still connect to a server as an admin user and have admin access to those resources.

In my initial experiences with Leopard, however, the behavior had changed in a way that was potentially sucky. In Leopard, when I'd connect to a share I'd authenticate as a user, just as in the past. And the share treated me like the authenticated user, just as in the past. But once authentication had taken place, Leopard remembered the user credentials even after ejecting the mount. At this point, when attempting to re-log in as a different user, the Finder would refuse to forget the previous login identity and authentication would be bypassed. The server would simply remount as the originally logged in user.

This behavior could be a convenience for users who only use a single identity on client and server. But for those of us with MPD (that's Multiple Personality Disorder, smart guy) it's a real problem. We'd now find ourselves unable change our login identity on a server without a reboot, or until some period of time has expired. Crap!

Now, I have to say, this was happening to me without fail a few weeks ago, and it was really annoying. But now, for some odd reason, the behavior seems to have reverted back to it's old self, asking for authentication each time I request a server. It's really quite strange. I know this was a problem, because I noted it in my log of Leopard issues, but I'll be damned if I can reproduce it today. I suppose it's something to watch out for, but I'm glad to see that it seems to have cured itself. In any case, clearly there are bugs in Leopard, however inconsistent and occasional they might be.

~/Library
Leopard is a bit of a hard ass when it comes to your Library folder. The Library folder is where all the user's settings are stored, and Leopard takes steps to insure that it's always there. In fact, it disallows you from renaming or moving the folder. Try to rename it and it simply won't highlight; try to move it and you can only copy. This is both a blessing and a curse, I suppose. I mean, from an admin standpoint, I never really have to worry again about users removing their ~/Library folders. But then again, I never really did anyway. Conversely, it requires a trip to the Terminal to move a user's Library folder and test any problems therein, which is a fairly common troubleshooting step. I guess we break even here, but I think I preferred the old way of doing things. It just made my life easier.

Uh... So far that's it. Compared to my Tiger Beefs from a couple years back, that's nothin'. Hell, compared to any new software release that's frickin' amazing.

I'll say it again: Leopard is a pretty damn sweet release.

UPDATE:
I continue to have AFP problems on my Intel machine. They're different from those detailed above, but no less annoying. Earlier, I attempted to connect to a server and the process hung. I had to force quit the Finder to get out of it. And just a few minutes ago I connected to a server and copied a group of files over to my local system using a "command-c" copy, only to be denied for permissions reasons. Dragging and dropping the same batch of folders worked properly. And now, after ejecting and reconnecting to the same share, both styles of copying the same, exact folder work just fine. So clearly there are some AFP bugs that need to be worked out in Leopard. Nothing life-threatening, but surely annoying.

Leopard Quota Alerts

Our home account server — the one all our network users' home accounts live on — mounts via NFS. I've already mentioned one of the improvements with regards to this behavior in Leopard, namely, autofs. But I just discovered another.

See, that NFS mount I'm always talking about, well, it's a Linux RAID — Fedora Core 6, I believe. And we've put quotas on every user's account to keep it from filling up. This has worked great, for the most part. The problem has always been how the Tiger Finder handled a user exceeding his quota. Basically, what would happen is that any Finder copy that exceeded a user's quota would fail, mid-copy, with an extremely vague and essentially — unless you happened to know you were looking for a quota problem — useless error message. Can't recall it exactly, but it's something along the lines of: "The Finder encountered an error and could not complete the request."

Ew.

The good news is that the Leopard Finder behaves exactly like we'd want and expect:

Leopard Quota Alert: That's More Like It!
(click image for larger view)

This alert actually came somewhat prematurely, as I hadn't actually exceeded my quota, and the alert seems to be triggered by hitting the soft quota rather than the hard. What's up with that?

Still, I have to say, I'm endlessly impressed with these little tiny details. They make all the difference in the world from an admin standpoint. I no longer have to worry about quota weirdness! It's great to see Apple do so much for admins with this release. I'm seriously pleased as punch.