For anyone looking to learn about Movable Type, I’ve started writing a series of articles about MT for Devlounge. My most recent was published a couple of days ago and covers how to use the Action Streams plugin, which I’ve talked a bit about before.

And while I’m mentioning that, I thought I’d also talk about the various ways I’m publishing these days. Like a lot of people, I don’t post to my blog as often as I used to. Over time, this has turned into a place for longer articles, and short “link posts” just aren’t what I want to do here. But I see things all the time that I want to share, so here’s how I’m divvying them up:

• Really short, of-the-moment type stuff goes on Twitter.
• Links that I’m saving for my own reference get saved at del.icio.us.
• Links that I don’t necessarily need to save, but that I want to others to read — and thoughts that are longer than 140 characters — are shared via Google Reader.
• And, as I said, longer blog posts go here, and MT tutorials go on Devlounge.

Of those, Google Reader’s shared items is the one I’ve really gotten into lately. Since they added notes and sharing anything, it makes a decent tumblelog. I’m hoping they continue to move it in that direction.

So that’s where I am with blogging. What about you — how do you publish these days, and how has it changed since you first started blogging?

My first reaction to GroupTweet was: What’s the point? It seemed like an indirect way to send and recieve tweets with people I already communicate with on Twitter.

My second reaction to GroupTweet was: Ok, this could be useful for communicating with a subgroup of your friends. As people use Twitter, they tend to accumulate followers that are spread out geographically. If you’re wanting to make plans to go out on Saturday night, those tweets don’t necessarily need to go to people that live hundreds or thousands of miles away from you.

My third reaction to GroupTweet is to unfollow those I’ve followed, and not join any others. The problem with GroupTweet is it undermines one of the biggest strengths of Twitter: the ability to control the experience. When you follow someone else’s group, you allow that person to decide, at least partly, what you receive. The group owner chooses who to allow in the group, and when they let someone in, you start receiving their tweets to the group, whether you want them or not.

Just to be clear, I haven’t had an actual problem with GroupTweet yet, like getting spammed or anything. It was just seeing a tweet from someone I hadn’t followed that made me realized the idea has a fundamental flaw.

So I could see starting my own group, but I can’t see joining someone else’s without a clear set of rules on who will or won’t be allowed to join — much like the example GroupTweet gives on their home page. I don’t know that there’s a real solution to the problem without making the GroupTweet service significantly more complex. It may be that this is an idea with limited application until Twitter offers more fine-grained control of what you receive.

Microsoft announced today that IE8 will, in fact, act like IE8, a complete switch from their previous plan. Why the change of heart? Perhaps to get various governments off its back. From the IEBlog:

While we do not believe any current legal requirements would dictate which rendering mode a browser must use, this step clearly removes this question as a potential legal and regulatory issue.

So in the end it was government regulations, not community backlash, that got this idea nixed. Whatever the reason, I think Microsoft is making the right decision — one that will continue IE’s evolution into a standards-compliant browser.

I just made the official announcement over at Smart Goat, but I also wanted to get into some of the whys and wherefores of the whole thing.

Continue reading “Start All Over Again”…

Gruber’s been writing about the rumors of Flash coming to iPhone. I think he’s right that it’s unlikely, but I think there’s an angle he misses here:

Lastly, perhaps you might be thinking that although Flash-for-the-iPhone may not be in Apple’s interest, it is in Adobe’s — and so perhaps Adobe will port it themselves once the imminent iPhone SDK ships. Think again. The iPhone SDK is not going to be the sort of environment like Mac OS X where developers are free to create system-level plugins. No one is going to get to diddle with MobileSafari without Apple’s approval.

Gruber’s probably right, but Adobe may be able to make an end-run around this problem by porting Adobe Air to the iPhone. They’ve made it clear since the early releases that as soon as they can create mobile versions of Air (sometime after 1.0), they will. With Mobile Air they could release their own Webkit-based, Flash-enabled browser.

Of course, don’t expect this any time soon. Adobe Air 1.0 hasn’t been released yet, and a Mobile Air would likely have even worse memory issues than a MobileSafari Flash plugin. Still, I’m sure Adobe’s working on it.