I need to read Brave New World immediately.

Chris Greening, the developer of iPhone Sudoku Grab, explains how it works. I find this section the most interesting:

One of the things that makes recognizing Sudoku puzzles an easier task than most image processing/recognition problem is that it is a highly constrained problem – a standard Sudoku puzzle is going to be a square grid and it will only contain the printed numbers 1-9. These two points are very important. The first point – it’s a square grid tells us what shape a puzzle is and what we should be looking for in an image. The second point – it will only contain the printed numbers 1-9 tells us that we aren’t going to need a sophisticated OCR system. When we look at the problem there’s nothing that jumps out and says “nobody has solved this before – it’s probably really hard”. We can also add some additional assumptions -

1. In a photograph of a sudoku puzzle, the puzzle is going to be the main/most important object on the page A user is going to be photographing the puzzle – they aren’t going to take a picture of a whole newspaper page, they won’t be taking a photograph of a coffee shop and expecting us to find a sudoku puzzle that someone is playing four tables away. Also, the user is going to try and capture the whole puzzle, they won’t miss a corner or chop off the top.

2. The puzzle will be orientated reasonably correctly. No-one (hopefully) is going to be taking a picture of an upside down puzzle, and typically they will be trying to align it nicely in the camera viewfinder so it is reasonably straight without too much distortion.

A great example of how some simple assumptions made about your problem make it far easier to solve. Of course, the key is making sure the assumptions are valid, or being prepared to handle edge cases where these assumptions prove false.

Great insight from Jeff Atwood:

One of the (many) unfortunate side effects of choosing a career in software development is that, over time, you learn to hate software. I mean really hate it. With a passion. Take the angriest user you’ve ever met, multiply that by a thousand, and you still haven’t come close to how we programmers feel about software. Nobody hates software more than software developers.

This is so true it hurts. An additional side effect of being a Program Manager is that you become extremely critical of everything. Parking meters. Elevator buttons. Anything that isn’t as usable as it should be. Not that I could do any better at designing these things, necessarily, but they still anger me, and much more than they used to now that design is a part of my daily work life.

Another great quote from the article:

Hardware companies don’t generally do software well. Digital camera companies excel at building digital camera hardware. Software, if it exists at all, is an afterthought, a side effect, a checkbox on some marketing weasel’s clipboard.

This is true not only for consumer electronics like digital cameras, but also for other hardware that you might not think of as running “software.” Think of your microwave. The ice dispenser on your fridge. Your washing machine. Your car’s on-board computer. All of these are running software in some fashion most likely, and they all kind of suck.

Just made a minor fix to the site… I noticed that dates weren’t showing up for some posts. Took me about 5 minutes to figure out that the Wordpress the_date() function had changed:

When there are multiple posts on a page published under the SAME DAY, the_date() only displays the date for the first post (that is, the first instance of the_date()).

Quick and easy change…

Before:

<?php the_date() ?>, <?php the_time() ?>

After:

<?php the_time("F j, Y, g:i a") ?>

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 (tm) 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.