Response to Eric's Blogware Feedback

Having just moved from MovableType to Blogware, Eric Longman has some great feedback for the Blogware team over on his new blog that I thought deserved a moderately detailed response. Typically these types of questions and answers get dealt with in our private reseller blog or newsgroups, but since he asked them publicly, I figured a public response would be fair game and also give non-resellers a better idea of what the behind the scenes interactions look like...

Re: Bookmarklets...

I'm not sure why you are seeing spotty performance. The bookmarklets are served from the same system as the main CMS, so you should see the same performance from Blogware's bookmarklets as you do from Blogware proper. The only difference being the javascript setup which may take varying amounts of time to render depending on your setup. For instance, I see a noticable different in setup time between my work box (FireFox/XP) and my home box (IE6/XP).

The "System is down for maintenance" error is the catchall error that we generate when the system encounters a critical error and can't recover. Everytime you see this, we are capturing the error and environment and our dev gets a report via email that they can then act on. I will definitely check into what is going on here as it sounds like you have stumbled on a reproducible error that we haven't fixed yet. It is always worthwhile reporting bugs like this via our bug tracking system at bugs.blogware.com - set yourself up an account and start getting us reports! ;) Lastly, we will be changing the wording of this message prior to the release of v1 to make sure that it is a little bit more self-explanatory.

As far as templating the bookmarklet posting defaults goes, that's a great idea. I will make sure that it goes on our development list and that it gets addressed in a future version.

You bring up the notion of "default blog" a couple of times (in slightly different ways) in your post. This is something we eschewed in favor of the notion of having an "active blog" - i.e. the one that you are currently managing. This is somewhat different from how MT approaches things and definitely takes some getting used to. We do need to improve how this is dealt with inside our bookmarklets however - Tom and I have been discussing this for literally months but haven't ever settled on the best way to approach it. The current behavior is to force the bookmarklet to post to whatever your active blog is and not allow you to change it.

Lastly, regarding your UI suggestions - these are completely spot on. The bookmarklets are probably the least developed aspect of the UI - we will definitely be making improvements to them in the no-so-distant future.

Re: Admin interface...

Categories on the fly eh? Hmmm. Off the top of my head that sounds like a disastrously complex feature to drop into the editor. As you point out, we've got 50 million or so features that we need to present to the user - adding more makes the UI even more complex than it already is. Wouldn't it make more sense to add topics instead? Note that unlike other weblog management tools, Blogware categories are really just navigation aids and don't really have any bearing on the permanent link or URL of the entry. This allows you to easily change where an entry lives in from a navigation standpoint without breaking its permalink. Further, it also makes it trivial to have an article live in a dozen or so different categories. My practice has always been to create a new category after I've written a bunch of articles that you should live there and then change or add to the category associated with these articles. Adding topics would just increase the utility of this scheme without making the UI unecessarily complex (ie - we would have to add topics to the UI regardless - adding topics and enhanced category management would be overkill if you requirements are met by simply adding the former.)

Our WYSIWYG editor is a blessing and a curse and mostly, a work in progress. In its current state, it is far preferable to dealing with the non-WYiWYG editor that we previously had. Forcing a user to deal with a not-all-that-great-WYSIWIG editor (that we are continuously improving) is far preferable to making them learn HTML. We're committed to making the editor as slick as we can, so filing as many bug reports as you possibly can would definitely go a long way towards helping us.

Adding keyboard shortcuts to the editor is a great idea - a long way out, but a great idea nonetheless. I'm much more interested in making sure the editor works great at this point than I am in adding new features (keyboard shortcuts, spell-checker, etc.).

Lastly, where in the UI should we add the XML-RPC info? It is located in the help manual (which I'm betting that as an "old" user, you didn't read because your reseller didn't send you a link to it ;) so I'd need to find a place where adding it to the UI makes perfect sense.

Thanks again for the great feedback - this is all definitely helpful.