The Assumption of the Average

Every so often, it occurs to me that I've duped myself in the qualitative evaluation of something.

Today, in pursuit of simple and arbitrary pleasures, I decided to stroll over to the local Panera to grab a late lunch and some free Wi-Fi action on their open-air patio. (Yes, these are the things in life that make me happy.) I consider myself to be fairly well-versed in Panera's offerings, as my co-worker and I usually patronize the one on Route 9 in Natick every Monday. I don't really need to look at the menu (except to determine whether a favorite seasonal offering has returned), I just usually blurt out one of three or four of their sandwiches that I like and get it with a bag of chips and a salad (occasionally tacking on a smoothie or an iced chai latte). The cashier hands me a pager, and five minutes later, I've got my food.

Unfortunately, that's not exactly an accurate description of the Panera experience that I had today. After ordering my food (turkey sandwich, chips, salad, and an iced chai latte) and receiving my pager, I sat down at a table and waited for the pager to buzz. After five minutes, I wandered over to the specialty drink counter (no latte yet), and then continued over to the food prep area to monitor the progress of my order.

This is where things started to get strange. There were two people (likely college or high school kids on hiatus) assigned to sandwich- and salad-making duty, but what they were actually doing was far less clear. (From what I could tell, it involved slowly walking in circles while occasionally commenting about someone named Roy.) Five other people (including an extremely pregnant woman, who I'll call Claire due to her striking resemblance to Emilie de Ravin) who had ordered before me were also standing and waiting, their faces awash with a mix of concern and irritation. At some point, one of them looked over and noticed everyone waiting, and doing his best to conceal an expression that can only be described as the Universal "Oh Shit" Face (which I hereby trademark, along with the acronym UOSF) and tore off a chain of three or four order tickets from a printer device.

Clearly, I wasn't getting my sandwich anytime soon, so I wandered back to the beverage counter. Still no iced chai lattes in sight, and a thorough scientific analysis of the situation led me to hypothesize that this was because no one was working at the station. Claire wandered over at some point, looking physically distressed, and perhaps this triggered someone to actually pay attention, because it wasn't ten seconds later that the young lad who'd taken my order -- visibly sporting a UOSF -- was asking us whether we were waiting for anything. Claire, who looked like she was in immense physical pain and holding back tears (I didn't know whether it was my place to ask her if she was okay, but I nearly did) indicated that she was waiting for a frozen lemonade, and I reminded him of my iced chai latte. The young man nodded, murmured some excuse about thinking that "someone else already helped you guys," and got to work.

Meanwhile, back at the food prep counter, there were several plates assembled with various sandwiches and salads, but since none of them looked like my order (at least not within a 95% confidence interval), and since my pager hadn't yet buzzed, I figured that none of them were mine. However, seeing as how the sandwich-makers had returned to their walking-in-circles-while-discussing-Roy routine, I stepped up to take a closer look. Sure enough, one of the order tickets matched mine, even though there was a baguette instead of chips, and even though they'd never rung my pager. After badgering one of the so-called employees to exchange the baguette for chips, I returned to the beverage counter.

"Here you go, buddy," said the drink-maker. It was a strawberry smoothie. "Sorry I forgot about your smoothie."

At this point, correcting him -- again -- seemed to be the ultimate exercise in futility, so I took the damn smoothie and left to eat.

As I ate, the simple thought Wow, this Panera sucks crossed my mind, as I'm sure happens to many of us at the conclusion of a similar experience. But then it occurred to me to ask: was that necessarily true? Is it really this particular Panera that sucks, or do all Paneras generally suck except for the one that I happen to patronize on a weekly basis? What if the abysmal customer-service experience that I had just been through was, in fact, closer to the norm than it was an exception to the rule?

When we evaluate an instance of a particular object or experience for the first time (whether it be dining at a Panera restaurant, playing whiffleball, or riding in a hot air balloon), I think we have a tendency to presume that the instance we're evaluating is perfectly average and falls in the middle of the bell curve of all possible instances of the same object/experience. From a statistical perspective, this seems like a reasonable presumption: 68% of your impressions will be of an "average" instance, and 95% of the time you'll be evaluating a "roughly average" instance. It also makes sense from the standpoint of natural selection: if, the first time your little brother Grrglmmick tried to jump onto a sleeping T-Rex he got eaten, it's reasonable to assume (for the purposes of preserving your gene pool) that Grrglmmick's experience is what "usually" happens when you try to jump onto a sleeping T-Rex.

And yet, thanks to the beauty of statistics, there will still be many cases in your life where your initial impression of something is actually one of those outliers that resides within 2.5% of either end of the bell-curve. (Recall the saga of Red Sox pitcher Clay Buchholz who, in his second major-league start, threw a no-hitter, and then proceeded to be one of the worst pitchers in all of baseball for the next half-year until he was sent back to the minors.) It is cases such as these that cause you to recognize and question your natural inclination to give greater weight to your initial impressions of something, and doing this can feel a little unsettling, perhaps even humbling, as though you're realizing that you've pulled off a doozy of a con-job on yourself.

But if you ask me, it's an acceptable consequence of living in a universe that, in spite of being doomed to an eventual heat-death at the hands of entropic degradation, takes a thankfully (and thanklessly) unpredictable path toward its final destination.

The Vampire Blood in My Wine Glass Speaks!

"There are too many bears that have fallen into bottomless pits with trapezoidal openings."

"The wheel upon which are all spinning -- it measures 392.7 meters across, even though Napolean's scientists incorrectly defined the meter as being 1/10,000,000th of the distance between the north pole and the equator, whereas nowadays it is simply defined as the length of the path travelled by light in vacuum during a time interval of 1/299,792,458 of a second. Morons."

"I was at peace with my current position in the space-time continuum, but then Locke let Ben move the island and now we're all randomly warping back and forth through time, occasionally suffering from a fatal nosebleed. Ah crap."

"When a child hunts for easter eggs, he or she does not expect the act of finding one to cause his or her basket to explode. Yet this happens all the time. Why?"

"1, 1, 2, 3, 5... Eureka! Awk! Pah-cuck!" (all birds speak chicken)

"You should get contacts because you can't see anything. I recommend a +1.25 for your right eye, and a link of hot italian sausage for your stomach."

"If cows could fly around and devour Billy Corgan, the world would become devoid of music that no one has listened to in over a decade."

"Sports teams playing each other is funny when the combination of the names of the participating teams and the result implies a balance of power that makes no sense in the natural world. For example: Eagles 27, Bears 3. In real life, it would be: Bears 4,398,186, Eagles 4."

"I am the Man in the Iron Mask, and I can shoot fireballs."

Internet Explorer Mobile and File Upload: Utterly Flimsy

Okay, a brief respite from the usual random babbling. This post has a mission. And if you're not a web developer, your eyes are about to glaze over.

Ready?

So, I just spent the entirety of my day yesterday trying to get one conceptually-simple thing to work. As part of an ongoing mobile web application development project, all I needed to do was to enable a smartphone or PDA user to upload a file from their device to a server. In today's alleged "Web 2.0" word, this type of file-upload capability is virtually ubiquitous across most interactive and community-based websites.

To enable file-upload in a standard desktop browser, all a web developer has to do is include something like the following code within a web form:

<form action="Upload.aspx" method="post" enctype="multipart/form-data">
   <input type="file" name="MyFile">
   <input type="submit" value="Upload!">
</form>

Additionally, if you're using ASP.NET as your development platform (as I am), you can just use this little snippet:

<asp:FileUpload runat="server" ID="MyFile">
<asp:Button runat="server" ID="btnUpload" OnClick="btnUpload_Click">

Continuing with the ASP.NET example for a moment, to actually process the upload, you write a handler for the btnUpload button's Click event, like so:

protected void btnUpload_Click(object sender, EventArgs e)
{
   if (MyFile.HasFile)
   {
       // Do something with the file here, such as:
      MyFile.SaveAs(Path.Combine(@"C:\Uploads", MyFile.FileName);
   }
}

Simple, no? (I bet even some of you non-coders were able to follow along...)

Indeed, in most cases, it really is that simple. For just about any modern web browser, whether it's Internet Explorer, FireFox, Chrome, or Opera, and whether it's running on your PC, PDA, or smartphone, this example will work without any hassle. Of course, having read the title of this post, you know that there's one browser that's a glaring exception to this rule, and that's Internet Explorer Mobile. (Strangely enough, another one is the version of Safari that runs on the iPhone.)

"Now, what just a minute!" you might say. "Mobile browsers are still fairly primitive creatures, and only recently have a scant handful started to support file upload. I mean, yes, if I were in charge of a team that was building a mobile browser, I'd make file upload a high-priority task, since of course most mobile application developers are going to want to be able to take advantage of their users' rapidly advancing photo and video-capturing capabilities..."

Well, yes, this is technically true. Many mobile web browsers are just achieving a basic level of usability, and there are many mobile browser vendors who openly state that their products do not yet support file upload. Microsoft, for its part, has stated that Internet Explorer Mobile running on Windows Mobile 6 Professional Edition (but not Classic) does support file upload. And while that is also technically accurate, their implementation of this feature is so utterly broken (and in such an asinine way) that you'd be hard-pressed to convince yourself that they're telling anything resembling the truth.

So, what's wrong with file upload in IE Mobile? To the casual debugger stepping through the ASP.NET code such as the earlier example, you may (or may not) notice one or more of the following symptoms:

• The Click event of the Upload button never fires.


• The Request.Files collection is empty.


• The HasFile property of the FileUpload control is false.


• In spite of the above, the Request.ContentLength property is larger than the size of the uploaded file.


• The contents of Request.InputStream include the uploaded file's data, along with some (but not all) of the ASP.NET form values.


• All ViewState information on the page is lost. (This seems to happen with any ASP.NET multipart/form-data postback, in my experience, regardless of browser.)


• Many (but not all) members of the Request.Params collection are missing.

After spending many hours capturing, studying, and stepping through the raw HTTP requests and responses of a simple file-upload web application and a variety of desktop and mobile web browsers, I discovered that the following conditions will cause IE Mobile's multipart HTTP request to become corrupted:

• The user uploads a file whose name exceeds 15 characters in length. (This length includes the file's ".ext" extension, but does not include any directory path that the user supplies.) For example, if the user attempts to upload a file called File1234.doc (12 characters), the upload request will succeed, but if the user tries to upload a file called File12345678.doc (16 characters), the upload request will become corrupted.


• The <input type="file"> or asp:FileUpload tag appears on an ASP.NET page that uses a Master Page. This one baffles me. I can't even begin to think of why using an ASP.NET Master page would cause IE Mobile to corrupt the upload request. Does it have to do with the way ASP.NET names and renders a container's child controls with all of those funky dollar signs and such? I've read that it's because the Master Page form's enctype doesn't get set to multipart/form-data, but in my testing I did not find that to be true. At any rate, if anyone who knows the answer to this little puzzle, please provide your explanation in a comment to this post, and you'll rewarded with a gold star (possibly one gleaned from a Google Images search).

Of these two bugs, it's the first one that really gets me. 15 characters?! What is this, 1988 and MS-DOS 4.01?! My guess is that this is some kind of non-terminated string oversight, most likely because some nitwit declared and allocated a char* buffer that was 16 bytes long, but then forgot to check the size of the actual string he wanted to load into that buffer, causing some kind of memory corruption that cascades into the text of the HTTP request.

Given these obstacles, what's a mobile web developer to do to get around them? Well, keep in mind that Opera Mobile -- which is now the default browser on the Windows Mobile 6.1 phones that Verizon, Sprint and AT&T are offering -- handles file upload requests flawlessly. (In fact, when I compared the multipart HTTP requests of Opera Mobile and the desktop version of Internet Explorer side-by-side, I noticed virtually no difference.) So, really, all you have to worry about is dealing with IE Mobile.

Thankfully, IE Mobile has pretty good JavaScript support, and you can use this to your advantage when you design your file upload web form. One possibility is to have your web page inject a special JavaScript validation function if it detects that the browser is IE Mobile, and wire your Upload button to run this script when clicked. All the script has to do is check the length of the file upload control's text (making sure to strip the path from the filename), and if it exceeds 15 characters, warn the user about IE Mobile's limitation and prevent the form's submission.

Here's an example:

ASP.NET Web Form:

<script type="text/javascript">
function ValidateFile(ctlidFileUpload) {
   var fileUpload = document.getElementById(ctlidFileUpload);
   if (fileUpload) {
      var sFilename = fileUpload.value;
      var nLastSlash = sFilename.lastIndexOf('\\');
      if (nLastSlash >= 0) {
         sFilename = sFilename.substring(nLastSlash + 1, sFilename.length);
         if (sFilename.length > 15) {
            alert("Internet Explorer Mobile requires that the document's filename (including extension) be 15 characters or less. Please rename this file and try again.");
            return false;
         }
      }
   }
   return true;
}
</script>


Code-behind:

protected void Page_Load(object sender, EventArgs e)
{
   // Inject validation script if necessary
   if (Request.Browser.IsBrowser("IEMobile"))
   {
      btnUpload.OnClientClick = "return ValidateFile('" + fileUpload.ClientID + "')";
   }
}

As for the issues with Master Pages, well, think of your file-upload page as having the same role and function as an "Open File" dialog box would in a desktop application. Essentially, you're just prompting the user to select a file for some greater, more interesting purpose. Does the dialog box need to have the same look-and-feel as the overall application? Not really, and if you think about it, neither does your file-upload page. You can maintain a relatively smooth, continuous user experience by just including a few visual cues (colors, logos, etc.) from your Master Page on your file-upload page. Give it a try and walk through the application flow -- you'll be surprised.

ERR-OR. Sentence Fragment.

On the eve of Super Bowl CCXCVII, let us take a moment to examine a particularly fascinating aspect of sports broadcasting, one that many people typically digest unaware, like the thousands-plus calories present in a typical McDonald's value meal.

Recall the last sporting event that you either watched on TV or listened to on the radio. Can you still hear the voices of the announcers and color analysts who were calling the play-by-play and providing commentary on the competitors' current winning streak, assist-to-turnover ratio, or ballpark-adjusted O.P.S.? Excellent.

Now, pretend for a moment that you were deaf, and were watching the same sporting event with closed-captioning on. What does the close-captioning feed look like? Perhaps something like this?

Allen to Garnett on the block. Better hurry. Kicks it out to Pierce and-- batted away by Iverson! Recovered by Perkins, but a 24-second shot-clock violation.

Or this?

Two out, bases loaded for Ortiz. Ortiz hitting .352 with runners in scoring position. This Yankee crowd getting a little uneasy. Sabathia into the stretch. The pitch. Line shot down the first-base line! One run in. Ellsbury right behind. Nady having trouble getting it out of the corner. Pedroia rounding third, the throw to the plate. Not in time! And the Red Sox take a 5-4 lead on a bases-clearing triple by David Ortiz.

Now, riddle me this: if you were to transcribe the play-by-play commentary for an entire sporting event and hand it into your high school English teacher, how many boxes of red pens would he or she have to buy (assuming Costco bulk quantities) to elevate the grammar to an acceptable level?

Indeed, most sports announcers speak in sentence fragments, and I think that this is something we easily accept because those fragments are mostly descriptive in nature and complement what we can otherwise plainly see (or hear) about the event and situation in question. There does appear to be some variation from sport to sport, however.

Referencing the above examples, I've found that most baseball commentators frequently omit the word "is" (and "there is") from their sentences, even in between plays when there is no action to describe and including the "is" would produce a complete, grammatically-sound sentence. (e.g., "Ortiz hitting .352 with runners in scoring position.") Basketball announcers, by contrast, seem to have a tendency to end their sentences in nouns that directly reference a rule of the game that has just been applied (e.g., "Recovered by Perkins, but a 24-second shot-clock violation" or "Roy drives through the lane, and a foul!") And although I haven't watched enough football to pick up on any patterns (maybe I can use Joe Buck's cross-sport announcing as a constant), tomorrow's Super Bowl may provide an ample opportunity if and when the Steelers find themselves up by 47 points.

In closing: if you're planning on taking the TOEFL, please be careful not watch any sports, because they will cause you to fail.

Next time: transcribing movie trailers, and the hilarity that ensues.

Exercising the Right to be Arbitrary, Episode #391

Today, whilst purchasing a decanter at Ye Olde Crate & Barrel, I encountered a very large point-of-sale console that happily offered to process my credit card transaction. Its dimensions were approximately 16 inches wide by 12 inches tall, and it prompted me to sign for my purchase within a box that was approximately 10 inches wide by 6 inches tall. This seemed excessive, so I decided to draw a giant smiley face above my signature.

The cashier seemed amused. She asked me whether I did this all the time. I said no, this was the first time I'd done it.

Then I pillaged the Sweet Factory.

How to Make a Speculative Documentary About the Apocalypse

Well, this week is Armageddon Week on the History Channel, and as the owner of a month-old plasma TV, that means it's time to watch a bunch of fiery, high-definition explosions bathe my living room in a hearty warm glow. The week's lineup includes an in-depth analysis (and CGI re-creation!) of the events depicted in the book of Revelation, and exposé on The Bible Code, and no fewer than thirty-seven treatments of Nostradamus' verses. As a child who kept the crushingly vacuous boredom of church at bay by reading the Book of Revelation over and over, I am So. There.

Now, you'd think that producing a show about Armageddon could carry a hefty price tag, what with all of the CGI artists you'd have to hire to animate a lamb with seven eyes and seven horns, gravely wounded and bleeding profusely "as It had been slain" (Revelation 5:6), not to mention the crazy Bacchaen woman riding the Beast with seven heads and ten horns. (I mean, there's a lot of careful decision-making involved when it comes to allocating the horns across the heads. Does each head get a horn? Which heads get more than one horn? For the heads with multiple horns, are the horns symmetrically arranged?) Alas, it is not so. In fact, just about any ol' Joe with a digital camcorder and an iBook can easily throw together their own end-of-days TV special by following these simple guiding principles:

1. Hire the most sinister-sounding narrator you can find. Test their worth by having them read Goodnight Moon and determining whether the child's head rotates a full 360 degrees in your mind.


2. Include several shots of a modern U.S. city being hit with one or more fiery projectiles streaking out of the sky. Limit the voiceover content to vague descriptions of "absolute destruction" and "complete chaos" -- do not attempt to describe which city it is, what the projectiles are, or what is generally going on.


3. Whenever you are filming something benign (e.g. some children playing Four Square), shake the camera violently to indicate that a massive earthquake is sweeping the entire planet as the Final Battle rages in the heavens.


4. Occasionally punctuate the narration with a random Bible verse (not necessarily one from the Book of Revelation or having anything to do with Armageddon), preferably voiced by a retired Shakespearean actor.
   
   "For where two or three are gathered in my name,
   there am I among them."
   -- Matthew 18:20
   Ensure that the verse appears on-screen as it is read. Use wet, hand-written ink on a yellowed scroll if you can.


5. Make at least one mention of Nostradamus, and show him to be an ominous-looking, age-worn man with a beard, a funny hat, and a crystal ball. Helpful hint: add pupil-less, glowing eyes for effect.
   
   


6. Ensure that the soundtrack features a full-bodied choir chanting something ominous in Latin, Sanskrit, or some other ancient language. If you are unable to translate a phrase such as "four the horseman blacken the sky and sunder the earth," Google the language of your choice in conjunction with the word "phrases" and use whatever result you get by clicking the I'm Feeling Lucky button.


7. Consult various subject-matter experts for their thoughts on the Book of Revelation, the current situation in the Middle East, nuclear arms races, and global warming, but do not mention or display their names, titles, or qualifications at any time.


8. If at any point you feel that you are running out of material, keep cutting back to the shot of the anonymous U.S. city getting blown up by unspecified fiery projectiles. Show this scene in slow-motion or with negative coloration to lend it a sense of variety.