Qumana 3.0 Beta out; state of the blogtoolosphere

Qumana LogoQumana has released the 3.0 beta of their blog editor, touting the following features:

  • a “blog manager” that locally stores your drafts and published posts
  • support for trackbacks and pinging
  • improved editor with valid XHTML, plus ability to view and edit code
  • a way to refresh the editor (‘New Post’) – to clear away published material and start a new post instantly
  • improved image dialogue, including preview and auto upload trigger from Drag & Drop

Looking through their Tour, there’s some remarkable similarities in their workflows to how we’ve solved similar issues in Flock (adding a blog, tagging). This suggests to me that there is some consolidation and consensus emerging in client-side blogging apps. MarsEdit 1.1 similarly added tags late last year and some other niceties.

Some things are still pretty unique to each editor… like Qumana’s Adgenta program or the DropPad feature that enables drag and drop blogging from the desktop (Ecto has something like this as well). Ecto also features email integration with the Mac Address Book to notify your friends of updated posts.

But so besides pimping Qumana’s release (hey, more choice is a good thing!), I also wanted to point out that we’re starting to see at the least the beginnings of some standard features in blogging apps, including a kludge for consistently adding tags to posts. As I use the excellent Ultimate Tag Warrior to tag my posts (when composing via the web interface), I’m hoping that tags will soon become something represented in the standard blogging APIs (I know Matt‘s already done some work on this that we’ll be taking advantage of soon). Once that happens, tools like Flock, Performancing, Ecto, MarsEdit, Qumana and so on will be able to offer native tag support and not just append that extra data to the body of the posts.

The death of the beta

Guardian Technology Icon

The term "beta" will also collapse into irrelevance in downloadable software, predicts Chris Messina, who calls himself director of experience at Flock, a startup developing an open source browser. Users of Microsoft products know that when software products move out of beta, users are flooded with security and quality patches in short order, meaning that version 1.0 isn’t so much a magic milestone as just another point in a continual cycle of development.

"I see gradients of validity where for my mom I might wait until Flock gets to 0.8 before I install it for her," Messina says. "For friends who I like I’ll give them the development version that won’t crash the system, and then for people I don’t like they can have the nightly builds. So I think we’ll have three tracks."

Guardian Unlimited Technology | Are you a dummy for beta software?

So there you have it, if I don’t like you, go download an nightly hourly build. 😉

No, just kidding.

But the point stands — software development is indeed becoming more organic, without really even realizing it (or maybe it has been all along, but we’ve fought its natural state for business reasons — after all, selling upgrades is a lucrative bidniz). Sure, you’ve still got holdouts and beta logos plastered all over the place, but the reality is this: software is a process. It’s never really done. The longer we go on pretending that the vaunted one-dot-oh somehow indicates a sense of finality, security or stability, the harder time we’re going to have convincing folks not in the geek world that there will always be bugs, that there are no right answers, that, just like natural systems, we’ve got to design for imperfection, frailty, accidents and hell, the irrationality of human actors.

So listen, I’d read somewhere recently (I forget where — I wasn’t using Flock so I can’t full-text search my history) that this whole BETA program fad is just a way for companies to shirk responsibility for the apps they deploy. It’s like, you call something "beta" and poof, no more responsibility. Well, clearly no one really does read EULAs anymore or you’d know that, beta or not, no one takes responsibility for anything anymore. It’s all the in the EULA, usually in some big bold type like this: WE DON’T CARE IF YOU BLOW UP YOUR COMPUTER WITH OUR SOFTWARE, IT’S NOT OUR FAULT AND THE LAW IS ON OUR SIDE, GET OVER IT (copied from the IE7 beta 2 EULA).

(No, just kidding).

Anyway, I think the point that Schofield makes in his article is a good one, and I enjoyed the chance to talk to him about it. But really folks, and this was raised in that conversation, what the heck are we going to do with desktop apps and the ever-present push towards one-dot-ohs? I don’t see them going away any time soon and yet they simply don’t reflect anything useful, especially since webapps have the luxury of never really worrying about that problem and can be in a constant state of flux and no one really cares… As it is, Thunderbird has been downloading updates every other day, asking me to restart it so that it can update itself… I have no idea what version I’m running — only the knowledge that somebody, somewhere is working on the thing and that its stability comes in fits and spurts. And that’s ok, because I’ve come to Jesse baby, hallelujah!, praise the Ford, Zen-master dojo, taekwon-do and on and on. Yeah, now that software development is becoming more zen-like, how do we help the rest of the world cope with the realities of such uncertainty?

Incurring the wrath: tags vs labels

Tags vs LabelsSo now that the Google Toolbar has added support for “labels” (and not tags) it seems like there should be some consensus built about the heck we should call these little jellybeans in Flock.

Vera has repeatedly told me that “tagging” is a hard word to use in documentation because it has multiple purposes… whereas “labeling” is a bit more clear and more singular in its utility. Let’s face it, when you label something, it’s pretty clear what the before and after states are. When you tag it, not so much.

The other thing we have to consider is this: since Google is obviously throwing its hefty weight behind labels and not tags (consider Gmail, Picasa, your search history, the toolbar and elsewhere), we might do well to realize that the de facto “word” for this behavior will not be “tag”, but will instead over time become “label”.

Sure sure, we need consider what Redmond will standardize on, but from what I’ve seen of IE7, etc., they’re playing a game of catch up and will do whatever the consumer market standardizes on first. (Imagine that… what happened to that whole bit about needing a monopoly to innovate? Guess that didn’t work out after all, eh guys?)

Anyway, Flickr has tags, delicious has tags, ‘rati has tags and most other Web Two projects seem to support tags… so when Google goes the other way and pushes labels, seems we ought to pay attention.

Mind you I’m not advocating one or the other or suggesting that we all change course now (especially within Flock), but instead proposing that we think seriously about this now before the rift between the two starts to hit teh long tail and we have massive confusion between one term and another.

Microformats + Thunderbird

Microformats + ThunderbirdThe things that bother me about Thunderbird on OSX are certainly many, but I can come up with one above all others that totally kills me: the lack of integration with the Apple address book. Nothing more than this illustrates the source of Tantek’s fervor for wanting data portability and his resultant hope in microformats.

Think about it. If Thunderbird stored hCards, and Address Book.app read hCards (or used them as its storage format), there’d be no problem.

One format to rule them all: XHTML! Best of all, you could use Spotlight, Applescript, and whatever other Mac-centric technologies on this data as well. No weird one-off formats that nothing else supports, no conversion, no special readers or parsers… and you could upload your address book and view it on the web… anywhere.

Drupal bugfix meetup! Tomorrow, Jan 24!

My buddy Neil is hosting a Drupal bugfix meetup tomorrow at everyone’s favorite cafe in the Mission. If you code good, you should go. If you hack open source, you should go. If you deal with CMS’ or know what one is, you should go. If you play ultimate, yeah, you should go too.

technorati tags: , , ,

Going where no mashup has gone before

dodgiemonk logo

Idea.

So Michael Arrington posted about BillMonk, a hella cool service that lets you keep track of outstanding debts between you and your friends… part of something they refer to as “Social Money“.

Now the first thing me and Tara thought of (before really taking a look) was — hey cool, but wouldn’t it be better if you could be at restaurant or something and SMS your debt to the service… which, duh, it does (okay, we’ll read more closely before jumping to feature ideas next time)!

But the second idea we came up with really has some legs… and will probably make the Attention Trust folks go all squishy in the knees: perhaps the next frontier in mashable services will be the nexus between your cell phone/SMS/remote devices and the range of services previously-reffered-to-as-Web-Two-Dot-Oh that you access through http-type connections (yeah, like the one that your browser made to this blog).

What huh?

Ok, in English 1.0: Behind the scenes, all these services which currently provide some utility separately really start to become incrementally indispensible when you can mash them together to form aggregate services of your own design. But now add in a Firefox-extensions-like model as personal in-betweener web service… kind of like Suprglu meets 43* meets .Mac meets Ning (conceptually). Ok ok, that still doesn’t make it much clearer.

I mean, here’s how it works now: I check in with some friends on Dodgeball somewhere… who cares where, but for example’s sake, let’s say Tantek‘s Lair (aka Crepes on Cole). At some point in the evening, we determine who’s paying for what… split the bill, etc., and if there’s any discrepancy (oops, Chris is out of cash again!) we ping BillMonk with the amount that I owe to so-and-so. Simple, but Dodgeball and BillMonk don’t know jack about each other. So while I’ve just created a checkin and an IOU, I can’t go back in my history of Dodgeball checkins and see where I incurred said IOU. Similarly, I can’t go to BillMonk and see where the IOU originated from. Sure, I can add a description to the IOU, but should I really have to when Dodgeball already knows where I am? See what I’m getting at here?

So let’s see how that fabled Web-Two-Oh open-API-goodness that we’ve all become accustomed with could make both services more valuable… Hell, let’s throw a little Plazes cell-phone action in there too for fun… And let’s see what kind of cake we can bake with the following: 

  • a service to notify friends where you are (Dodgeball)
  • a way to record IOUs (BillMonk)
  • a location-service for identifying and recording where you’ve been (Plazes)

Now, let’s say we merge in some kind of attention stream aggreagator and — presto! — we’ve got a view of where you’ve been, who you’ve told about your whereabouts, and where, with whom and when you incurred (or became the benefactor of a friend’s) debt.

And that’s of course, only the beginning. Toss in some mapping APIs (which Plazes and Dodgeball already support) and you can see watch your debt-accrue as you travel the globe! In fact, you could map your friends’ whereabouts to the same map and play your own mini debt arms race. Fun while watching all your friends go bankrupt! 

Yeh, anyway.

While this is all good and smaht, etc., you’re likely to start throbbing with, “ooo, yay, convergence!”

Okay, eff convergence.

I don’t want one service to collect all this data. I’m not a privacy maven, but even if it were possible to do the one-stop-shop thing, don’t do it, don’t try it, don’t even think about it coz I won’t use it. Nope, I don’t wanna be boxed in and so-help-me-Ford, I won’t let you. You and your proprietary megaservice can kiss my RSS.

BUT, I do however, want an external agnostic service aggregator (which I control and plug stuff into of my own choosing) to help me make sense of all this data… one API/feed at a time. Avoiding convergence allows me choice of services, allows each provider to innovate in their particular domain, and also gives me the freedom to experiment with different combinations of services as they are released and/or improved. Maybe I want to switch from TextPayMe to BillMonk without losing my history of transactions. This proposed third-party service aggregator would allow me to do this smoothly and seemlessly coz the data would be out there and tracked, yet neither BillMonk or TextPayMe would need to know about my prior service history. That’s data for my eyes and my eyes alone.

Sucks to be a service provider with open APIs you say? Puts them at the mercy of the whims of fickle “consumers”?

No, I don’t think so. Indeed, if you don’t open up, the open source community (or your competitors) will build something that does the same thing as your service and then they’ll open it up and give it away for free. So hey, I’d pay a couple cents per hundred transactions if you’re innovating and providing a really nice user experience… that also spits out data that I can plug in elsewhere, invisible to you (what do you care anyway?). Put your customers in the driver’s seat and I can pretty much guarentee you’ll not only get long term investment from them in what you’re doing, but heck, you might even get new Plazes, Dodgeball and BillMonk buddies with lots of friends who haven’t yet found out about you… and are eager to use whatever it is their friends are using.

Mashing up social networks: oh yeah, now there’s the next killer app. Gimme a way to cross-polinate, cross-aggregate, mix up, re-use, recombine or reinterpret and reshare and you’ve done something interesting.
Something I’ll use, and yes, probably tell my friends about. This is where mashups are going. And I can hardly wait…!

technorati tags: , , , , ,