A la Scriptogram and Calepin, a Dropbox-powered blogging engine. Currently in closed beta. Differentiating details are sparse for now, but they do seem to tout automatic syncing.
This is an online editor with a focus on revisions and editing, in some pretty heavy-duty ways: it includes the ability to easily save drafts and compare multiple versions of documents, plus the ability to send drafts to other users for editing.
This is a particularly polished version of the Throwww/Feathers immediacy model. I like the interface. Posts are anonymous or pegged to your twitter handle. The ability to optionally create a custom URL for a post is a very nice feature.
In the most basic, obvious terms, it's a novel middle ground between tweeting and blogging: through formatting and post organization it tries to encourage a series of concise mini-posts—usually about the length of a single thought—which, unlike in Twitter, are all organized into individual streams, each on an individual topic.
This is an interesting and elegant enough choice that I think all the different purposes it can be put to remain very much to be seen. In my case it seems perfectly suited to the practice of thinking aloud (this stream itself being a notable exception), that is, sending a series of individual thoughts or steps of a thought process across the transom without necessarily having my entire argument reasoned out ahead of time; indeed the format seems to lend itself just as easily to realizing halfway through a stream that one's initial premise is redundant, or malformed, or not as interesting as one originally thought. Which is part of the fun.
On the other hand the format creates new niggles and demands in the realm of contextualization and personalization. Because each user does not have just one blog, and because any user's output is going to exist in a form that's not really familiar or immediately intelligible to a reader from offsite, the design can lead to the expectation, I think, that users are all writing for each other; that is, that it's a social network, and that we are in the process of accreting a culture and vocabulary that we all share, and talking primarily for each other. Which isn't right, I don't think; my intended audience is the internet at large, and that seems to be the case for most users here.
It's hard to tell how to assist that intention. Greater personalization and theming is one obvious way; like in Marquee above, and to a lesser extent in Twitter itself, custom backgrounds and fonts are an effective way to create a 'brand' and emphasize the individual user. On the other hand, any web designer will surely lament the day that they sign away their pleasing, homogeneous aesthetic to the disarrayed whims of the mob.
Simple familiarity might be the greatest aid here; I am trying to think back to the first couple of times that I clicked in to someone's Tumblr or Twitter page, and whether—font customization be damned—I simply needed to see more and more unconnected people using the service in order to know what to expect when I clicked a link, and to not have to waste any thought on contextualizing the feed; that is, to when I was able to simply read a Twitter feed as an individual's Twitter feed, rather than another instance of this service, Twitter.
Looking back at this list, it's clear that one of the areas in which developers have really progressed from the first generations of blogging software is in posting methods—the whole conceits of many of these services lie in the clever and frictionless way that a user can make a new post. I'm particularly attracted to Dropbox-based services, as I retain a slight pre-web suspicion of text input boxes located in the browser, and because they also completely solve the problem of data lock-in as a bonus.
So this is an obvious area of potential growth for ThoughtStreams. Right now one can only post in a text input box located in the browser. Email-to-post is an obvious direction, though it immediately becomes complicated by the novel format. Normally one emails one's blog, and the subject becomes the title, and the body becomes the text. For any given ThoughtStream user, the blog analog is an individual stream. Leave aside that individual posts don't have titles; that would imply that there would be a new email address for every stream created in the system, and the word 'profusion' quickly comes to mind.
The alternative is that blogs (and thus destination addresses) map instead to users, subjects map to streams, and bodies map to text. But the same problem as above sticks in here: users tend to have a lot of streams. They're encouraged to have a lot of streams. As such, it's a pretty lofty technical requirement that in order to post by email the user must a) remember and b) spell correctly the precise name of the stream they'd like to post in.
Posting by Dropbox is a little more appealing to me, though that's probably because a vision of its operation involves more handwaving—that is, more hard technical work on the part of somebody else. But one could imagine a system in which the entire structure of a user's ThoughtStream (what's the name for all the streams that belong to a given user? Stream bed? I hope so) stream bed is reflected in their Dropbox folder hierarchy: there is an Apps folder in my Dropbox, and a ThoughtStreams folder in my Apps folder, and therein is one folder for each stream. If I want to create a new stream, I can create a new folder or subfolder. If I want to create a new entry in a stream, I can create a new plaintext file in the folder of my choosing. This is appealing; it would doubtless also require significant refactoring.
Like Posthaven, it's $5/mo off the bat. Like Calepin/Scriptogram, it pulls Markdown files from your Dropbox.
This is an interesting case. Started by Garry Tan as a consequence of the somewhat characteristic decline of Posterous, it seems like they are aiming to only slightly update the Posterous model on a technical level—post-by-email, simple frictionless blogging—instead solving the problem of longevity and and service survival. That is, addressing the fact that this type of service, which is almost always free or freemium, has a tendency to go away, either because the service has been bought out, or because the service has not managed to be bought out.
Posthaven is charging $5/mo from the very outset, with the pledge that they will effectively never shut down, and that anything published with them will remain accessible forever.
This one is really on the extreme end of the immediacy–richness spectrum; no users, no text controls; just a title and a body and a simple link.
Very slick, very webfonty, blogging/publishing; pages are organized under a single user but each page can be very thoroughly and individually styled, so they can really stand on their own as documents. The level of polish on the interface is very high. All editing is done in-browser.
A buffed-out version of Calepin. Supports theming, has a simple post editor web interface and a bookmarklet. Generally seems to be on stronger footing. And perhaps most pertinently, it has its own API so third-party apps (like Mou) are able to upload to Dropbox and remotely trigger the Publish routine in one go.
The first, to my knowledge, fire and forget Dropbox-based hosted solution. It's a very elegant concept: hook the app up to your Dropbox account, where it watches a folder for new Markdown files. Put one in and it renders it as a new post in your static blog using Pelican.
The only problem is that you have to regenerate the blog every time you want to post. My understanding is that this is due to a limitation in Dropbox's API; it doesn't let 3rd parties automatically monitor for file events.
Calepin supports custom domains. But its longevity is still in some doubt; its creator gave notice that he was abandoning the service, but doesn't exactly seem to have done so. It's still being updated.
A Markdown editor for writers, with things like reading time and word count, that includes file management and multi-format export, as well as the ability to publish as a standalone webpage within Quabel itself. Very inviting for most kinds of standalone work, though I'm annoyed that the Speaking Time and Reading Time readouts are always present in editor and published views. I have no need for such things!