I apologize to the Ecto-supporters out there, but quite frankly, that piece of software you love, can be quite intrusive at times.

Since I heard Ecto was the best offline blog-manager out there, of course I had to see what’s up and give it a try. I’ve been using MarsEdit for the longest time and was quite happy with it save for one problem: You could only keep an offline cache of the last 30 posts you’ve made.

I thought “Hey, since Ecto can do Markdown too, then there’s nothing to lose.” – or so I thought.

Before everything else, I acknowledge that MarsEdit probably has a differnet “type-of-user-market” from Ecto altogether… so some points here may be contested by either side saying “but this is how we do this, and this is how we do that.” If you’re that type of user, then this article is probably not for you.

MarsEdit: How I blog

Ok first you’d have to understand how I go about my blogging business. As you know MarsEdit and Ecto, basically offer the same thing: a faster way to blog. By not being at the mercy of servers processing requests here and there, these tools allow you to draft your posts offline, then simply contact the server and apply the necessary additions/changes when you’re done.

For me, using an offline weblog manager is a no-brainer… but which one to use… aye there’s the rub!

I’ve been a rabid MarkDown supporter ever since I first heard of it, I has managed to keep my back-end code neat and clean: I can export all my blog entries to mere textfiles and they would still be readable (with minimal or no HTML code clutter)

If you check my blog’s pagesource, you’d see it’s still in xhtml. That’s because MarkDown is only applied when publishing. What does this imply? The actual source (which is stored in the database) is still in the simplified MarkDown format. Why am I mentioning this? Because this is where Ecto seems to drop the ball on their MarkDown support.

Just as I prefer my code in web-development in Notepad/BBEdit, I want my blog code untouched So basically, my only requirement is MarkDown support – and that support is of course just for the “preview” pane alone.

MarsEdit does this perfectly: I still edit my code as-is, but the preview pane shows it with the MarkDown formatting applied

Enter Ecto

Ecto has been around a long time, hence the software has matured as far as “features” are concerned. It’s really a beautiful piece of software. I’d switch to it in a heartbeat if it would just resolve the issues I’m about to discuss in this post.

One of the main feature’s Ecto has to offer is of course code-automation, meaning shortcuts that can generate your tedious xhtml tags quickly. Hence their Rich Text formatting is a big hit to the users who want that WYSIWYG feel. It requires less brainpower to use, hence Ecto users can just focus on the content of their posts.

Now, Ecto supports MarkDown, and if enabled, you basically have no problems with it. But that is a resounding if. This is also where Ecto‘s intrusiveness come’s in.

The Story

I set Ecto up, everything went fine. I also am very pleased to see that I can import any n number of posts. Great! I set it to import all my posts. No problem! Then I check out how it “edits” published posts. Now this is where the madness begins (cue The Shining background noise/music)

First of, to use MarkDown, you have to set it to xhtml/html mode (default is rich text) Fair enough. But you can only set this “editing mode” after it has opened the post/draft. The editing mode is grayed out when you’re in the main window… and there’s no option to force or disable editing modes to circumvent the problem.

What does this entail? Assuming you’ve written something with MarkDown code before – if Ecto happens to open it in rich text (I say “happens to” because as I said before, you don’t get to pick editing modes from the main window), it will parse the source as such, and when you then switch to html mode, your once simple syntax is now riddled with html code! In short, you lose your MarkDown syntax totally – no way to bring it back.

This is a horrible situation to be put in, especially if you like editing previously published posts. It mentions something about “setting the default formatting options,” which again is only accessible on the draft/edit window (and only applies to such). I did that, and for some reason it sometimes remembers the settings, and sometimes it just goes back to rich text mode.

If you hand-code via html syntax, it would be fine since toggling between rich text and html retains the inherent “source” which is html-formatted. If you’re a MarkDown user however, you have to be extremely careful with the formatting buttons you press – you may just lose everything in a heartbeat.

So what? It’s not like users care about the “source”

That is true as far as the readers are concerned, they still see the html output anways. But as I mentioned before, the reason I use MarkDown is so I have a clean readable format in case I decide to simply print directly from the DB. Plus the less clutter you have, the easier it is to edit. The problem with Ecto is that if you edit something made with MarkDown (and assuming it successfully opens it html mode (which retains the MarkDown syntax) – if you switch to rich text then re-publish, the code stored on the database itself will now be html formatted, hence if you try to edit that again… you can never get your MarkDown syntax back… ever!

Categories

Another issue is the way Ecto handles multiple categories: In my blog I have category icons – the icon accompanying a post is usually the primary category of that post. Ergo I can have a post included in 10 categories, but the icon still will show the category of my choosing

What makes this significant? Weblog systems usually list categories in alphabetical order. If you select multiple categories, regardless which category you set as primary, it still will display it in alphabetical order.

The problem in Ecto is it assumes the latter argument for all users, when clearly it’s not the case. So if you have 2 posts, spanning 3 categories called general, technology, and nonsense. Suppose you wanted the first’s primary as technology, and the other’s primary as nonsense. When you publish that with Ecto, it will display both as General. Why? Because it entered the categories alphabetically – and the server probably assumed the first one entered was the primary category.

MarsEdit on the other hand, boldens the first category you check and sets it as the primary (I surmise that when submitting to the server, it sends that category first, then the rest alphabetically. So in my blog, even if the categories under the title are still alphabetically arranged – you can still see that the icon correctly represents the primary category I chose.

Developers should never assume how end-users use services. It’s one thing to anticipate stuff to make an interface more intuitive – provide the functions that can make a task easier. It’s another thing to assume the required processes in which these tasks are done.

Back to MarsEdit

So now, I’m back to MarsEdit, I have to live with the problem of it downloading 30 posts maximum. Now I know MarsEdit developers should also not assume that people will never need more than n number of recent posts cached offline – but I’m sure you agree with me that that fault is far more forgivable than Ecto‘s formatting antics.

Still I still give props to Ecto for their feature-set. But they have to understand the reason why MarsEdit is thriving despite its lack of features, is because it implements the “basic stuff” better than Ecto does.