Follow Up On Outlook HTML+CSS Post
Posted by Tyler | Filed under On Software, Work
Note: I work for Microsoft, in the Office division, but I don’t work in or with the Outlook team. I don’t have any specific knowledge about their decisions or plans, and this post is based only my own experience here at Microsoft.
My post on Outlook’s HTML+CSS rendering generated a bit of buzz, due in no small part, I’m sure, to Zeldman linking to it from his own post. I’m finally getting some time to respond.
First of all, thanks to everyone for the responses; I am glad that this alternative viewpoint at least sparked some discussion. Despite what you may think, there are plenty of people on the “front lines” at Microsoft that really care a lot about this stuff, and we try very very hard to make sure The Right Thing ™ happens whenever possible.
I have responded to the comments directly in the post, but I wanted to also mention that I filed two separate bugs in our internal bug database. The first covers the fact that we’re apparently not obeying your browser preference when you open an email in a browser, though this may have something to do with the actual file type that the email message gets stored as temporarily. Non-IE browsers might not register to open that file type.
The second covers the actual piss-poor rendering Outlook does of the acid test email. Thanks to Dave Greiner from the Email Standards project for providing links and addressing the questions I had in the original post. Once I had a copy of the acid test email I was able to get the bugs officially filed.
I will not be posting any further details on the status of these or other bugs, either now or after we ship, so please don’t ask. I am sorry, but it isn’t standard practice at Microsoft to reveal publicly the status of bugs, and I don’t plan on starting a trend in this particular area. It’s also frankly not my place to comment on bugs on which I am not an expert, especially those that are in areas completely separate from the ones I work on. You’ll have to take my word for it as an honest, standards-loving software developer that I filed them.
Please continue to send feedback in any way you can to Microsoft, and specifically the Outlook team. Here’s hoping for some quality HTML+CSS email rendering in the future.
Tags: css, html, outlook, standards
Outlook, Email, and CSS
Posted by Tyler | Filed under On Software, Rants, Work
Update July 13, 2009: Thanks to some comments, I’ve got new links and minor updates in the post now.
Note: I work for Microsoft, in the Office division, but I don’t work in or with the Outlook team. I don’t have any specific knowledge about their decisions or plans, and this post is based only my own experience here at Microsoft.
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.
Update: Turns out you can see this in the Email Standards project’s review of Outlook 2007. As I suspected, no real differences.
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.
Update: You can now mail yourself a copy of the email directly from the acid test page.
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.
Tags: css, html, outlook, standards
PowerShell for Fun and Profit
Posted by Tyler | Filed under Work
Stefan Goßner has a great post on his blog covering some common problems that people have with Content Deployment in SharePoint. Problem 13 has to do with the default timeout window for Content Deployment jobs. Stefan provides some sample code that you can use to adjust the timeout value, since it’s not exposed through the UI, but I find writing and running sample code on a server a bit of a pain. Instead of writing code, you can actually use PowerShell to do this directly from the PS prompt.
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.
Tags: content deployment, powershell, sharepoint
Office 2010: The Movie
Posted by Tyler | Filed under Links, Work
A bit cheesy, but glad to see some news about the next version of Office finally coming out. I wish there were some screenshots or videos in the little movie clip, but it’s early – I’m sure we’ll be releasing that sort of stuff in the future. It’ll be a busy next few months for those of us on the product group, but it’s exciting to finally start telling people about all the cool stuff we’ve built.
Tags: office, sharepoint
SharePoint Permissions “Cheat Sheet”
Posted by Tyler | Filed under Work
Back when we were building SharePoint 2007, a member of our Program Management team left Microsoft, and I inherited the permissions-related features for the then Content Management Server team, which was responsible for all of the web publishing features in SharePoint. Essentially, this meant that I has to figure out what the correct set of permission levels were for our features, and what lists/libraries should have unique (non-inherited) permissions.
Now, if you’ve used SharePoint for any length of time, you’ve no doubt been frustrated with permissions management. It’s definitely a sore point. Unfortunately, I don’t have any magic bullets or golden hammers. When I started trying to figure everything out so that I could make educated decisions for our designs, I realized that I needed to write stuff down. People always asked questions like, “What rights do Designers have by default?” Sure, you can find out by going to the site itself and checking, but the UI isn’t the easiest to navigate, and oftentimes what you really want to do is compare multiple permissions levels. “What rights do Designers have that Contributors don’t?”, for example. To help keep it all straight in my mind (and so I could point people to the info rather than answer 100 emails a day with the same question!), the SharePoint Permissions “Cheat Sheet” was born.
It’s nothing fancy, and it’s certainly not anything that no one else could have created. But still, it has proven useful over the past few years. I still keep a copy of it pinned to my office wall. It’s pretty self-explanatory. The first sheet has a table of the default publishing permission levels and what fine-grain permissions each of them has. The second sheet is just the descriptions of each of the fine-grain permissions so I didn’t have to go hunting through the UI to find them whenever I was wondering what the differences were. Finally, the third sheet is a list of “securable objects” (which what I decided to call a list/library that had broken away permissions inheritance and was independently secured) and what default groups had what rights to those locations by default. This was particularly important since in general, you want to avoid breaking permissions inheritance if you can, and we wanted to be very deliberate about where we did, and also track them to ensure they made sense over time.
So how exactly do you use this? Well, it can be a handy reference as-is, but chances are that you have your own permissions level or have modified the existing ones to suit your needs, so you can modify this sheet to reflect your own custom permissions and keep track of everything. It really is helpful to have a centralized reference of all of the various permissions levels. If you go through and put in your own levels, you might realize that there’s a lot of needless duplication in the custom permission level you might have created. When it comes to SharePoint permissions, less is better, so this can be a helpful auditing tool as well as a reference.
A couple of disclaimers… This was created based on the RTM version. As far as I know, nothing has been changed in SP1 or SP2 that would impact it, but I haven’t been checking to keep it up to date. If you do notice errors you can let me know and I’ll try to correct it. Also, this obviously won’t take into account any customizations that you may do that would alter the default permission levels.
If you use this for any of the purposes listed or for additional things, leave a comment! I’d love to hear how it’s working for you and if it’s been helpful. Download it below:
SharePoint Permissions “Cheat Sheet” (XLSX)
Tags: sharepoint
Accessibility Insanity
Posted by Tyler | Filed under Links, Rants, Work
Part of my responsibilities for SharePoint these days involves markup cleanliness and accessibility, so over the last couple of years I have educated myself on the ins and outs of these issues, and have managed to learn a lot about browser behavior, the history of markup, etc. I am far from an expert, but I know a heck of a lot more than I did when I started.
One school of thought I come across quite frequently is that web content whose markup is not well-formed or is missing required attributes or something just fail to render completely, in order to ensure that all content on the web is gorgeous, standards-compliant markup. This ridiculously draconian viewpoint loses sight of the fact that the ultimate goal of delivering content over the web is just that – delivering content. It seems bad form for a browser to just “give up” when markup is badly formed, because the end-goal of the person building the page – and the person consuming it – is to deliver content. Much of this debate has been chronicled by the IE team; they have a tough job – bring the standards compliance of IE into this century without breaking their customers/users pages. Hence compatibility mode, legacy rendering, etc. etc.
In the past, I’ve always heard this argument from the standards-compliance standpoint. For example, if a page claims to be XHTML but isn’t fully compliant, it should fail to render in a browser. No “best-effort” rendering, just fail. This of course ignores the fact that even the W3C can’t create a parser that can completely validate a page against the spec, but that’s a rant for another time… Assuming the browser can detect that a page is non-compliant, it should just stop.
Anyway, this is a long and winding intro to a post Mark Pilgrim wrote talking about this viewpoint as it applies to accessibility. I had never heard these arguments before, but apparently they’re out there. A choice quote from Mark’s rebuttal (emphasis mine):
I think it would be wise for people who truly care about accessibility to take a closer look at the so-called “experts” who are participating on their behalf, and to understand exactly what these people are proposing. It’s true that some of their proposals have not been adopted, but it’s not because some cartoonishly monocled villain enjoys being mean to them. It’s because the proposals are insane.
Agreed.
Tags: accessibility, sharepoint
Site Move and Redesign
Posted by Tyler | Filed under Personal, Projects, Work
The server that is currently hosting the SharePoint version of tylerbutler.com is being decommissioned. Unfortunately, I wasn’t given much notice about this so I have not been able to secure an alternative SharePoint-ready location at Microsoft to host the site. In the meantime I’ve used this opportunity to move the site over to WordPress, and I’ve refreshed the look and feel. Hopefully this will be temporary, since I intend to rebuild the site on the new version of SharePoint once it’s publicly available. But in the meantime, WordPress is serving my needs.
The main www address should be redirecting to blog.tylerbutler.com as soon as the DNS changes propogate. The main RSS feed should be switched over, but I have not yet moved the others. Regardless, though, you shouldn’t notice any differences since I’m using FeedBurner.
Tags: tylerbutler.com
SharePoint Updates
Posted by Tyler | Filed under Work
We’ve changed the way we’re managing and releasing updates here in the SharePoint team. This is all very good news. It makes things more manageable internally for us, which translates into quicker, more effective turnaround on issues, but it also means that updates and patches will be much more predictable, so you can plan around those dates more effectively. There is still recourse for you if you have an absolutely critical issue that needs to be resolved ASAP.
More details on this SharePoint blog post and KB article 953878.
Tags: sharepoint
But Why? #0: But why, “But Why?”
Posted by Tyler | Filed under Work
I love hearing stories. When I was growing up I used to love when people would visit and my Dad would tell some of his stories. Even though I had heard most of them a thousand times, it was awesome to sit back and watch other people experience them for the first time. I also read a lot of stories growing up, and I developed a special love for short stories in particular (I especially like O. Henry).
While I was in college, I discovered a site that I have since lost many hours of my life to – folklore.org. It’s a site put together by Andy Hertzfeld (not to be confused with Don Hertzfeldt of Rejected fame), and contains "anecdotes about the development of Apple’s original Macintosh computer, and the people who created it." It is incredible – it combines my love of stories with a topic I find interesting – the early days of personal computing. Best of all, the stories there are written by the people who experienced it, and often contain a healthy dose of humor and humanity. But behind that, there’s some cool technical details about the challenges the engineers faced, and why some of the decisions got made the way they did. I find that part of it utterly spellbinding.
I’ve been on the lookout for other sites like this for other tech companies, like Atari or even Microsoft. The closest I’ve found for Atari is DadHacker.com, written by a guy who worked for Atari back in the day. His blog is interesting in a variety of ways, but I particularly like his Atari posts. In fact, his post titled Donkey Kong and Me was what got him into my RSS reader permanently. It’s good – you should read it.
I actually work with a developer who was also on the team that developed Clippy, and I’ve heard some interesting stories for him about what that was like. Maybe I’ll try to convince him to write up some of his experiences… :-) I am sure there are some more great stories out there… If you know of some sites, please do point me to them.
Because I find this stuff so interesting, I thought it would be good to start chronicling some of the stuff I know about because I’ve been working on SharePoint. Thus, I plan to write a series titled "But Why?" about various SharePoint features that I either worked on or have been exposed to, and why they behave the way they do. These posts will be one part SharePoint history, one part storytelling, and if I do it right, will pull back the curtain a bit so you can see just why things wound up the way they did.
But first, some disclaimers: These posts are my own thoughts and opinions, and do not reflect those of Microsoft or of anyone else who works/worked on SharePoint. Also, my memory may be fuzzy and blatantly incorrect about some things, so everything should be viewed through that lens. Finally, you shouldn’t expect these posts to be as interesting as anything you read on folklore.org. :-)
Tags: But Why? Series, sharepoint
Gettin’ Famous
Posted by Tyler | Filed under Work
George found this article over at SearchVB.com that mentions my MIX ‘07 Session. While I am not quoted directly, my name is mentioned, and the content of the session is referenced a bit:
At Microsoft’s MIX07 conference, Tyler Butler, a program manager for Microsoft Office SharePoint Server, pointed out three Web applications built on SharePoint — Hawaiian Airlines, mobile phone game firm Glu Mobile and music and event firm Hed Kandi Radio.
Butler also indicated that, since the SharePoint 2007 platform is built on ASP.NET 2.0, developers can use ASP.NET AJAX and Silverlight to provide a rich user interface.
I’ll try not to let the fame go to my head. :-)
This is the online journal of 
Hello, visitor from the Internet. You may have arrived here expecting to see a site built on top of SharePoint, and are no doubt confused by the fact that tylerbutler.com is running on WordPress. 
You can subscribe to this site in a variety of different ways. The best and simplest way is via RSS. There are three main RSS feeds: