http://www.zephoria.org/thoughts/archives/2009/05/27/when_teachers_a.html.

The web community has been up in arms the last day or so about a campaign via Twitter pushing for Outlook 2010 to stop using the Word rendering engine for HTML email. I engaged in a short friendly discussion with my buddy Vlad on Twitter about the issue, and that got me thinking about the issue a bit more deeply. And the more I thought about it, and read everything that was being written, the more I realized that people aren’t actually communicating effectively, and that pisses me off…

The fixoutlook.org website says this: “Microsoft has confirmed they plan on using the Word rendering engine to display HTML emails in Outlook 2010.” (emphasis added) Based on that, and the rest of the text on the site, it seems like the big beef they have is that Word’s rendering engine for HTML is not up to snuff. Fair point – it isn’t. But they contradict themselves in their updated response to Microsoft’s response when they say, “We’re asking that the HTML produced by the Word engine be standards compliant. This in turn will ensure that the engine will correctly render standards-based emails.” (emphasis added)

Wait a second. Do they want an editor that produces HTML, or a rendering engine that works properly? Doing the work to make sure the editor is producing clean markup might produce a rendering engine that renders nicely, perhaps it even should produce one, but that doesn’t mean it will. Those two pieces of work are not the same thing.

Lots of people have been pointing to a post from Zeldman about this. Zeldman’s a brilliant guy, but he completely misses the point when he perpetuates a rumor about why Outlook chose Word’s engine: “Rumor has it that Microsoft chose the Word rendering engine because its Outlook division “couldn’t afford” to pay its browser division for IE8. And by “couldn’t afford” I don’t mean Microsoft has no money; I mean someone at this fabulously wealthy corporation must have neglected to budget for an internal cost.”

Ummmm… no. In my experience, the phrase “couldn’t afford” at Microsoft R&D has nothing to do with monetary cost. It has to do with engineering cost. Features don’t exist just because you want them to exist. (An aside: Raymond Chen has a great quote about this that I can’t find. If you have a link, please let me know.) So I imagine that the rationale in the Outlook team went something more like this:

Well, we want Outlook to produce really rich emails, and we want it to have a really familiar look and feel, so people already using our products will feel at home. Hmmm, building an editor is extremely hard to get right, plus we, being part of the Office suite, have several editing tools already. Emails tend to be a lot like documents, so Word seems to be a reasonable choice. This way we can leverage all the editor features Word already has, plus things they’re building this release, and focus on the Outlook-specific work we have to do. We don’t want to invest our engineering time in building an editor when we already have one.

From this standpoint, it’s easy to see why using Word for rendering as well is the next logical step. You could argue that they should use IE (or Gecko, or Webkit, as Zeldman does, but again, just because those engines are free doesn’t mean using them is without cost) to render email, and Word to author it. That’s a reasonable idea. In fact, the Outlook team seems to agree with you, because if you get an HTML email that looks wrong, you see a link to open it in a browser. In fact, even the example image at fixoutlook.org has the “info bar” at the top that does this.

You can take issue with the implementation, certainly, because it sucks mightily. The fact that I have to open the email in a browser separately blows. I shouldn’t have to do that. But don’t kid yourself into thinking that integrating an IE window into the message window is so stupidly simple that Microsoft is maliciously avoiding doing it to somehow screw users. It might be straightforward – I honestly don’t know. But do you? If you think you do, please go read Steve Yegge’s post “Have you ever legalized marijuana?” and come back.

What really bugs me about this whole thing is that people immediately jumped on the fact that Outlook uses Word for rendering, instead of sticking to the real problem that Outlook’s rendering of HTML sucks in some cases. The rendering engine they’re using is immaterial, really, because if the team goes and fixes the rendering inadequacies, then the issue goes away. They can choose how to fix the issues, should they choose to fix them at all, but at this point, even if all the rendering issues are fixed, many people will still be pissed because Word is used to render the email. The argument has shifted from being about the support proper email display to being about Word used for rendering, so there doesn’t seem to be a path to redemption for Microsoft in the court of public opinion that doesn’t involve ripping out Word completely.

I completely agree, personally, that web standards serve as a reasonable basis for email format standards even though there is no formal effort to standardize email. But please argue about the right things. Spend your energy trying to see those standards acknowledged rather than perpetuating this silly argument about ripping out Word from Outlook. Hopefully this effort will have the desired effect, and these rendering issues will get resolved prior to Outlook 2010 RTM. But I can almost completely guarantee that if you want Word completely ripped from Outlook, you’re not going to get what you want.

By the way, does anyone have a screenshot of what the email used in the example image looks like in Outlook 2007, which also used Word for rendering? That struck me as a strange omission. I’m wondering if the issues displayed in that screenshot are just bugs in the 2010 beta. I doubt it, but would still like to see it.

Also – is there any way to get a sample HTML email from the Email Standards Project’s email acid test? Seems ridiculous there’s no “email me this sample email” form on the acid test page. I can and will file a bug against Outlook if I can get a copy mailed to me.

This didn’t really fit into the overall flow of the post above, but I still think it’s reasonable info to consider, so I’m including it here anyway. I’m about to throw out a bunch of numbers and statistics that are not backed up by any data. They are based only on my own logic and occasionally rational mind. I think they’re true and reasonable statements, but I welcome data that contradicts them.

I think it’s safe to say that a majority, say, 80%, of Outlook users use it with Exchange. Also, a majority of Exchange users use Outlook, and Exchange is primarily used in business settings. Since a large majority of email sent in a business setting is sent to other people in your business, then they’re probably also using Exchange, and also probably using Outlook. Based on this not-so-scientific reasoning, I argue that the number of emails received in Outlook that didn’t originate in Outlook is relatively small. That means, practically speaking, that as long as Outlook can render email that started in Outlook, you’re hitting the majority of your users’ needs.

Now, the idealist in you (and me, for the record) is screaming bloody murder, because you want to see the “right thing” happen for all cases, not just the majority case. But unfortunately, software is more about practicality than idealism, and at some point some smart, but possibly naive people in Outlook made a tradeoff. I’d say with 99% certainty that at some point a developer or two in Outlook estimated the cost of different approaches and implementations, and this one wound up cheaper. They made a cut. They made a tradeoff. And we disagree with the tradeoff.

http://jiggmin.com/play_game.php?title=Effing+Hail

http://topherchris.com/post/106795199/recommendation-letter

• I get double-exposure to their content. If I am interested enough in someone to follow them on Twitter, and they also have a blog, then 90% of the time I also subscribe to their RSS feed. That means I see their posts in Twitter then also in my feed. That bugs me.
• Tweets are limited to 140 characters, and typically blog posts are longer. That means I see 100 characters plus a link, possibly less in the tweet itself. That’s useless.

At the same time, I find myself tweeting a lot of links, because Twitter is just a more vibrant community than my blog. I get a lot more comments and replies from people there than on my blog. Twitter is a decent place to broadcast stuff, but I don’t like the fact that I can’t easily find the stuff I’ve posted later. Have you tried using Twitter search to find a link you yourself posted in the past? It’s ridiculously bad. I figure if I can just keep it on my own site at least I have more control over the search experience. Another reason I want to do this is to have a centralized place to write stuff, then choose how it’s syndicated. This will let me do that.

In order to address the two issues I have with common auto-tweet solutions, I’ll only be tweeting some of my posts. I am doing this by feeding only posts tagged “tweet” to Twitter via TwitterFeed. In addition, I grabbed a WordPress plug-in that does character counts of posts in the WordPress web UI. This will help me keep my posts that are auto-tweeted short and completely digestible as a complete tweet.

Hopefully this will all come together and work. Let me know what you think.

The key to doing this is loading the SharePoint DLLs into your PowerShell environment. You can do this using the System.Reflection.Assembly class. Take a look at this sample script:

param( $newTimeout = 600 )

[System.Reflection.Assembly]::Load("Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")

$cdconfig = [Microsoft.SharePoint.Publishing.Administration.ContentDeploymentConfiguration]::GetInstance()

$cdconfig.RemoteTimeout = $newTimeout
$cdconfig.Update()

"Updated RemoteTimeout to $newTimeout seconds."

In line 3, I load up the Microsoft.SharePoint.Publishing DLL, then I grab the ContentDeploymentConfiguration (line 5) using the GetInstance() static method. I update the RemoteTimeout property, then call Update(), and we’re done. No code to write and compile.

This example uses the param keyword, which means you can save it as ChangeRemoteTimeout.ps1, then run it like this:

PS C:\> ChangeRemoteTimeout –newTimeout 1200

This is completely optional, of course, but if you find yourself doing this a lot, it might be worth saving it as a reusable script.

You might also want to make changes to some of the options that are exposed through the UI already. Here’s an example:

PS C:\> [System.Reflection.Assembly]::Load("Microsoft.SharePoint.Publishing, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c")
PS C:\> $cdconfig = [Microsoft.SharePoint.Publishing.Administration.ContentDeploymentConfiguration]::GetInstance()
PS C:\> $cdconfig.AcceptIncomingJobs = $true
PS C:\> $cdconfig.RequiresSecureConnection = $false
PS C:\> $cdconfig.Update()

In this case, I’m configuring the farm to accept incoming deployment jobs and not require secure connections. You can also make additional changes to other properties, such as FileMaxSize and RemotePollingInterval using this method. Stefan covers these properties in his Pimp My Content Deployment Job post.

One other note… Using .NET DLLs in PowerShell is generally supported across the board. It’s not limited to the SharePoint DLLs. There’s some pretty exciting stuff you can do here once you start playing around.

Who Watches the Watchman? (via Daring Fireball)

I started calling these Wikipedia Walks. The concept is simple - start at an article you find interesting, then just continue on to any articles linked from the original. Finish when you get bored. To make it more interesting, you should record both the starting article and the ending article, so you can see just how far off the beaten path you’ve gotten.

To start, I’d suggest the article on Game Theory.