Climbing out of the morass; chipping away at obstacles

My current chores-and-knitting audio book is Blind Descent by Nevada Barr, which is set in Lechuguilla. The story’s murder could be a metaphor for my experience working with the current Visual Studio technology. The non-billable time may well kill my business and livelihood, but I’m not ready to give up. So, today, I am thinking of the expedition as the better, somewhat less bleak, metaphor. Simply trying to wrap my head around add-ons, toolkits,  products, domains, and appropriate uses to assess the viability of any tool has been very much like journey to the center of the earth.

  • Squeezing through spaces so narrow I can’t look ahead to where I’m going? Check.
  • Navigating huge spaces filled with refrigerator sized obstacles? Check.
  • Rappelling down narrow shafts with knife sharp protuberances? Check.
  • Climbing past fragile features? Check.
  • Doing all this in utter darkness except for the questionable beam of my own intellect? Check.
  • All sense of direction lost? Oh, my, yes.

Fortunately a long-time friend of mine is in town for the annual Microsoft Most Valuable Professionals Summit. Reluctantly, I asked Kathleen Dollard to review my project plans for two customers who’ve been waiting patiently for three projects. Lately, I’ve missed my own time as an MVP, not only for the SWAG and camaraderie, but for the ability to plug into the internal state of MS development teams.  She can’t divulge NDA information, of course, but she has an extensive breadth of experience. Research is part of her job, so she tries, as much as is possible today, to keep a broad overall view of the programming landscape. Like me, she’s practical, believes technology serves customers (not the other way-round), and is willing to look outside Microsoft for solutions and examples of good practice. I was reluctant to ask for her help because she makes her living mentoring and consulting. Luckily, she was willing to work for breakfast, dinner, beer, a room, free wi-fi, and all the cat hair she wants.

She helped me tremendously, as have a few other references that are starting to come together as the most recent revs age. In short, she reassured me that, no, I am not yet senile. .Net programming is hard. Really hard. In addition, the programming landscape is in such a state of flux and tools so nascent that choosing an approach today that will be current in 2015 (one requirement) is a tough call. We went through various options, ranted about the general state of programming, drank wine, beer and ate soft tacos from Taqueria Guaymas, ranted some more, and wrote some code. Kathleen is, as we say, good people.

I’m reawakening this slumbering blog for two reasons: 1) I still believe writing helps me think better, and I’m finally at the point that I can fashion sentences that are, at least, coherent; and 2) to fulfill my promise to Kathleen to share my experience. Part of the joy of being a Visual FoxPro developer was the tightly knit, experienced community. Collectively, we knew just about everything there was to know about the product, how to use it well, what to avoid, who to listen to, who to ignore. I still believe the best advisers are programmers who write live, production software. As smart as the folks are at Microsoft, and they are,  field experience will always be more valuable for defining best practices. I say that because I believe any best practice has to take into account the entire scope of a project with heavy emphasis on deploying deliverables and measuring how well applications work for the customer.

There is a wealth, or maybe welter would be a better word, of advisory flotsam on the Internet seas, and I don’t want to contribute to the noise. I want to document what I’ve found to be helpful, obsolete, or gratuitous. If anyone believes this blog is too much noise and too little signal, let me know in comments, please.

Meanwhile, as I sort out my thoughts, concerns, trials, and decisions, please feel free to note your own thoughts. I told Kathleen at one point that I don’t see myself as particularly special. If I’m struggling with something, have a question, or want a feature I know there’s someone else who feels the same. It doesn’t mean that my point-of-view is viable or relevant, but it does mean it might need addressing. Because I’m also not a complete idiot. That’s a mantra I’ve been repeating to myself lately. I am not an idiot; this stuff is hard. I’ll cover the following broad areas: vocabulary, technologies, helpful links, wishes, and ruminations on the state of independent programming.

I like feedback. Don’t be shy.

HTML email and Outlook 2007 summation

My journey into Office 2007 land is finally at an end. For which my client is happy, I expect. To recap, I have a modest ASP.NET (1.1) application that displays one simple webform, on which there are about two dozen TextBoxes and a dozen CheckBoxes. Users fill in some information, check or uncheck some email addresses and the send the form off to the requested email addresses.

The form is simple. There were a few formatting and required entry validators. Before I send the email, I remove a few control that aren’t needed, but other than that, it is a straightforward project. It was maddening that such an autocratic descision as to change the HTML rendering could complicate things so much (and cost my client money and inconvenience).

Here is a summary of what I had to change, how I changed it, and what I found out.

First, I found out that the only way to be sure of how Outlook would display the HTML was to install Outlook 2007. Word 2007 does not display the HTML the same way Outlook 2007 does. That alone should be enough to put the lie to the marketing fluff about user experience. And the validation tool doesn’t help at all either, since whether or not an element or attribute is supported has little to do with what the visual affect will be.

I also found out that unsupported elements are not ignored as MS states–at least not the way I define “ignore.” Input elements (ASP.NET TextBoxes, CheckBoxes, and so on are rendered as Input elements) are only ignored in so far as anything useful is concerned (say, the style attribute, or InnerHTML), but they will still render in Outlook as spaces delimited with square brackets.

In the end, I’m just glad it is a simple application, or I’d have had a nightmare. OTOH, if it was complicated I would have handled the emailed form differently. Anyway, here’s what worked for me:

  • Replace div and span elements with tables.
  • New 04/11/08: Replaced ASP.NET validators with server-side validation that registers a JavaScript alert if entries are missing.
  • Put all styles in-line.
  • Added Html label elements that pair up with TextBoxes and CheckBoxes (which render as text- and checkbox type input elements). Set display:none.
  • Before sending email, store text input element values in Html labels InnerText, and remove the input element. Store a “[X]” for checked checkboxes. (Very 1980’s.)
  • Removed Img element.

Note that in this I’ve lost the ability to have printer css styles applied, which isn’t fatal.

That’s it in a nutshell. In short, yes, I can shout an affirmation that Office 2007 sets email back five years. At least.

Why is the Microsoft HTML Engine an embedded module at all?

It occurred to me sometime in the night that someone should really spread the word about the power of modular programming at Microsoft. Maybe even talk about web services. Okay, I know the folks are Microsoft are actually really great people and are definitely smart. (I still think they need a few more hunchbacks, though.) But really, why are there two HTML rendering engines at all? And, why are they embedded in applications? Why isn’t there one rendering engine?

It seems like basic (no pun intended) software design. But, then, I’m definitely a hunchback.

Getting around Word 2007 HTML Rendering Engine in Outlook 2007

Just a quick note that the work-around for Word’s mis-rendering (rending?) of HTML is a satisfactory, if short-term, help for my client. The work-around is to open the the email, then select “Other actions…View in browser.”

It also looks like biggest problem isn’t with the TextBoxes so much as with the div and span elements I used instead of a (HTML) table. Which chaps my butt a bit since the page would have been so much easier to create and maintain using tables, but I had succumbed to peer pressure that “tables are bad.” Anyway, will rework with tables and then reasses how bad the input elements appear.

Microsoft chooses Word 2007 HTML Rendering Engine for Outlook 2007

As Gary Larsen’s classic cartoon illustrated, it’s another case of “too many scientists and not enough hunchbacks” at Microsoft. I admit I’m late to the bitch fest regarding HTML rendering in Outlook ‘2007, but it was only recently that I got my first complaint about munged HTML email after a user upgraded to Office 2007. That I’ve had only one is no comfort since that person sign my checks.

The problem for those of you who have been living under a grindstone, as have I, is that Microsoft changed Outlook 2007 to use Word’s HTML rendering engine instead of IE. If you support software that creates and emails HTML content, then you’ve either hit this problem, or will do so.

I’ve found some web posts from marketeers proclaiming the second coming with the change. By far, the majority of hits are blog posts (developers!) complaining bitterly about this change. I guess Mr. Ballmer no longer loves us. *sniff* But I digress.

The saddest part of searching is that the posts are almost all more than a year old, including one that states the usual Microsoft deflection “we want to hear about your issues and will listen.”

The only result I can see is a Microsoft CSS/HTML validation tool. I’ve installed it (in Visual Studio 2005) so I can validate my HTML against Word’s HTML engine. Yikes. It tells me “media”, “form”, “input”, “onload”, and so on aren’t supported commands. Oh, joy.

I’m not posting just to vent, but because I’m finding there are few practical suggestions for how to redevelop HTML so it doesn’t look putrid in OL’07 at the very least. Ideally, it will look identical between browser and email client preview.

By the way, the Outlook ’07 ribbon* apparently has a button “Other actions,” from which users can chose to view the email in the browser. (Um, doesn’t this seem, oh, I dunno, sorta ironic?)

In this case, I have a Visual Studio 1.1 Aspx application that collects some info on an HTML form, lets users select who to email copies to, and then emails the page (without some of the controls like buttons) as an HTML attachment. I remove some elements now. I will have to do more to transform unsupported elements like TextBoxes (which aspx renders as input elements, and seem to be the biggest problem) into supported elements.

As I redevelop the page, I’ll post with suggests of what works and what doesn’t. And if any of you know an Office ‘Softie, thump ’em upside the head for me, would you?

Relevant links:

The Party Line

Campaign Monitor’s Guide to CSS Support in Email Clients

Samples of HTML Rendering in Outlook 2007

Some Dolt Who Thinks Only Spammers Are Affected

* Ribbon? Give me a break. Since when does “ribbon” mean “menu that takes up a lot more screen real estate, thus hiding more of what you actually care about?”