Address formats are hard, let's go shopping!, revisited (aka To me, 'good enough' just isn't good enough)

by Michael S. Kaplan, published on 2011/03/28 07:01 -04:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/03/28/10146277.aspx

So, in some recent blogs like When your Clipboard isn't their Clipboard. Or my Clipboard... and Microsoft is better as one big company, I have gone to some great lengths to contrast the roles, some of the strengths, and even some of the weaknesses of different parts of Microsoft, focusing on Windows and DEVDIV especially.

Office had a bit part in the drama here, but I mainly was talking about the stuff it did, that it created.

I never got into motivations that drove them -- it was all about what they did, not why.

Today I'm going to get into that a bit.

I'm going to start with Pi. You know, π.

For most general purposes, you can use 22/7, or 3.14159. You don't need to do 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679 or longer (like writing code to get it to 1,000,000 places for pages like this one

It is hard to escape the fact that for most uses even 22/7 will do.

And generally speaking that's where Office places itself. In being good enough for people to get the job done. Thus you won't see nearly as much excitement over a need to do every possible theoretical thing within a feature as you will over the need to fit the scenario.

Now Windows is more of a platform, and as much as we like to focus on specific scenarios in the spec, we know that you can't design device driver stacks or window messaging semantics or protocol implementations or file systems on just a few scenarios. They have to work a hell of a lt more broadly than that.

This is how things happen like the feature I described in Oh (Saka to me, Saka to me, Saka to me, Saka to me) Whoa Babe (Just a little bit) A little respect (just a little bit). That feature is woefully incomplete from the standpoint of Windows. Terribly so. Though it is "good enough" for on epart of Office to use.

Thus when I originally wrote about Address formats are hard, let's go shopping!, and explained why even though a part of Office felt like they could jump into the whole address format space, even if the job wasn't complete. While at the same time, Windows wasn't willing to try to pick up a feature like that, since there wasn't really the resources or time or staffing to take on, and to do the job right.

But onc again the Office feature is good enough -- for Office, and the scenarios they thought would be nice to light up.

Now I don't want to say that Windows is perfect and Office is a crap just because they focus so often on being good enough.

I mean, the reason the Windows calendar story is so awful is that no one wants to make incremental improvements -- they want "the right fix". And since we lack resources for that, no fix ever happens. The Windows insistence on handling the full end-to-end job for a feature or an area causes more than one feature to be absent when the product ships. And there is no virtue in that.

Now with all that said, the massive migration of people from Office to Windows that started a few years ago has had some impact here, particularly in the upper levels of the UI. They talk more about scenarios and such and solve problems perhaps less completely but also perhaps more fully for a narrower number of cases. But the deeper you go the less such a philosophy can penetrate....

Anyway, I thought of this when I saw the folllowing issue in my email inbox on Friday:

The Unicode Consortium has posted a new issue for public
review and comment. Details are on the following web page:

     http://www.unicode.org/review/pri180/

Review period for the new item closes on April 11, 2011.

Please see the page for links to discussion and relevant documents. Briefly,
the new issue is:

Issue #180 Proposed addition of address form metadata to Unicode CLDR

The Unicode Consortium is considering the addition to CLDR of address form
metadata. This metadata is intended for presenting a form for users to fill
in with address data. The format and data is being donated by Google. The
consortium is soliciting feedback on these changes. Feedback should be
submitted as comments to http://unicode.org/cldr/trac/ticket/3572.

The detailed proposal and background information can be found at this link:
http://www.unicode.org/review/pri180/

If you have comments for official consideration, please follow the
instructions and the link in the text of the PRI.

My comment?

Well, I wish them well.

A mondo address database will keep Unicode and the CLDR folks busy for years and is a very natural extension to the whole CLDR project.

But I've seen the data they are talking about.

It's fuzzy, and its incomplete. It's poorly scoped, and the real usages are not well captured by the data and thus for many cases what it provides will never be better than just letting people address their letters their own way.

And maybe that's "good enough" for some people.

To me, it's like weather prediction algorithm that can accurately forecast the weather three days in advance, and whose only flaw is that it takes three days to run. And thus in the end has results comparable to looking out the window.

Perhaps its my [non-Office] bias showing, the bias that caused me to be one of the group to turn down the similar offer/request years before, but a mound of data of uncertain value and high expectations is not always a good thing. Even if it's a huge horking mound of data.

YMMV, but to me "good enough" really isn't good enough, to me....

John Cowan on 28 Mar 2011 8:51 AM:

Michael S. Kaplan on 28 Mar 2011 11:34 AM:

referenced by

go to newer or older post, or back to index or month or day