Who Won Sochi? Wrangling Olympic Medal Count Data

I have always been a big fan of the Olympics (albeit I like the Summer Games better given my interest in Track & Field, Fencing and Soccer). However, something that has always bothered me is concept of the Medal Count. For years I have seen countries listed as “winning” because their medal count was higher—even though several countries “below” it often had many more Gold medals. Shouldn’t a Gold medal count for more than a Silver (and much more than a Bronze)? What would you rather have as an athlete: three Gold medals or four Bronzes?

Evidently, I am not the only one debating this point. Googling “value of olympic medals for rank count” yielded a range of debates on the first page alone (Bleacher Report, USA TodayThe New Republic, the Washington Post and even Bicycling.com). Wikipedia even has an entry on this debate.

This year, however, I noticed that throughout the games that Google’s medal count stats page (Google “olympic medal count”) was not ranking countries by absolute medal count. For quite a while Norway and Germany were on top—even when they did not have the highest total number of medals—because they had more Gold medals than anyone else. Clearly Google was using a different weighting than “all medals are alike.” Not a surprise given their background in data.

Winter_Games_CoverartI started to wonder what type of weighting they were using. In 1984 (when the Olympics were in Los Angeles) a bunch of gaming companies came out with various Olympic games. Konami’s standup arcade game Track & Field was widely popular (and highly abusive to trackballs). The game I used to play the most (thanks to hacking it) was Epyx’s Summer (and Winter) Games. This game had the “real” challenge of figuring out a “who won the Olympics” as it was a head-to-head multi-player game (someone had to win). It used the 5:3:1 Medal Weighting Model to determine this: each Gold medal was worth 5 points, each Silver 3 points, each Bronze 1. I wondered if Google was using this model, so I decided to wrangle the data and find out.

Data processing

I used Google’s Sochi Olympic Medal Count as my source of data as this had counts and Google ranks of winners (I go this via their Russian site so I could get final results, there were 26 countries who won any Olympic Medal).

Of course, by the end of the Olympics it was a bit less interesting as Russia had both the most medals and the highest rank. However, I still wanted to figure out their weighting as a curious exercise. I built a model that calculated ranks for various Medal Weighting Model (MWM) approaches and calculated the absolute value of all Rank Error deltas from Google’s ranking. I both computed both the sum of these errors (Total Rank Error or TRE) and highlighted any non-zero error, enabling me to quickly see any errors in various MWM weightings.

Trying out a few random models

The first model I tried was the “Bob Costas Model” where every medal is the same (1:1:1). This was a clearly different than Google’s as it a TRE of 72. I then tried the Epyx 5:3:1 model… no dice: this one had a TRE of 35 (better than Bob, but not great). I tried a few other mathematical series:

  • Fibonacci: 0,1,1 (TRE=50); 1,1,2 (TRE=42); and 1,2,3 (TRE=43)
  • Fibonacci Prime (TRE=54)
  • Abundant Numbers (TRE=54)
  • Prime Numbers: (TRE=42)
  • Lucas Numbers (TRE=28)
  • Geometric Sequence (TRE=23)
  • Weird Numbers (TRE=2)
  • Happy Numbers (TRE=39)

I then tried logical sequences such as the lowest ratios where a Silver is worth more than a Bronze, and Gold is worth more than both (TRE=31). Still not luck

Getting more systematic

I decided to get more systematic and begin to visualize the TRE based on different MWM weights. I decided to keep Whole Number weights as I was operating under the general principal that each Medal has N points and that points (true in most sports—but not in things like Diving, Figure Skating and Gymnastics—nevertheless, I wanted to keep things simple).

I first looked at Gold Weight influence, WGOLD:1:1 where I varied WGOLD from 1 upwards. This clearly showed a rapid decay in TRE that flattened out at 2 with Gold was worth 13x that of a single Silver or Bronze medal:

Gold-Silver

Rapid decay in TRE as Gold medals gain higher weighting

This reinforced that Gold was King, but that Silver was better than Bronze by some value (not surprising). I then kept WGOLD at 13 and started to reduce WBRONZE. I found an interesting result: as soon as I made Bronze worth any value smaller than Silver (even ε = 0.001), I got Zero TRE (a complete match to Google’s Rank). However, I could not image a scoring system of 13:1:<1 (or 13:1:0.99). It was just too geeky. As such I tried a different approaches, all with Whole Number ratios of Gold:Silver:Bronze. The lowest ratios I found with Zero TREs were the following:

  • Gold=21, Silver=2, Bronze=1
  • Gold=29, Silver=3, Bronze=1
  • Gold=40, Silver=4, Bronze=1
  • Gold=45, Silver=5, Bronze=1

TRE never went to zero when Bronze was given Zero weight. Of these models, 40:4:1 had the most symmetry (10:1 to 4:1), so used that is my approximated Google Olympic Rank MDW (it did have zero TRE for all medal winners).

So who won?

I figured I would look at the Top Five Ranked Countries over various models:

Demonstration of how easy it is to add a Grading Curve to the rankings. The higher the TRE the more underweighted winning Gold medals (i.e., truly winning events) is. The country in bold is the one that benefits most from the Grading Curve

Demonstration of how easy it is to add a Grading Curve to the rankings. The higher the TRE the more underweighted winning Gold medals (i.e., truly winning events) is. The country in bold is the one that benefits most from the Grading Curve

Obviously, Russia is the all around winner as they won the most medals and the most Golds and the most Silvers. (Making this exercise a bit less interesting than it was about a week ago). However, it will be fun to apply this in 2016.

And at least Mr Putin is happy.

Note: While this post is not explicitly about tech, it is about applied data science to an item widely looked at by consumers this month.

Unboxing Google Glass

After a second try, I finally got into the Google Glass Explorer program. I tried last year but waited too long to apply (about 36 hours after the application process opened). This time, I moved faster.

As not a lot of people have the opportunity to get to use Glass (I am lucky, my employer is paying for me to explore its use for M2M and IoT), I thought I would share my initial experiences getting—and unboxing—Glass to help those considering entering the program later.

The First Step: Registering for the Explorer Program

Registering for and buying Glass is a bit different, so I thought I would start here. It turns out you will need to link Glass to a Gmail account. As such, I strongly recommend using a Gmail account when you apply to the program. I think Google should add these instructions in the registration process, perhaps if it detects your email is not one that they manage at Gmail or Google Apps.

Application Approval

GlassProgramSmallMy application got approved about 10 days later, via email. The email contained a sixteen-digit alpha purchase code that was very obviously place. It also contains a 16-digit numeric unique ID in much smaller font in the email footer. Keep track of this, as you will need to enter it if you call the Glass Help Center.

I made the mistake of using a corporate email account (one not based on Google Apps). This created a bit of a problem for me, one that required a call to the Glass Help Center to resolve. I can say that the Glass Help Center staff are quite friendly and responsive. Working with them is more akin to a call with a Professional Services team than a call to a typical call center or corporate IT help desk.

Purchasing Glass

It turns out that you can only buy Glass with Google Wallet. As such, your experience will be much easier if you 1) apply with a Gmail account and 2) have a Google Wallet for this account set up in advance. If so, you need only click on the Get Glass URL and proceed. You will be prompted to confirm which Gmail account you want to use, then re-authenticate to Wallet to make your purchase. The entire process should take less than five clicks and one password to complete.

I did it a bit backwards. As the Glass Help Center let me know I would need to have Wallet setup, I was able to log into my Gmail, register for Wallet and add a Payment Method before re-starting my purchase. Once I go my purchase reference code reset, I was able to go through this process pretty quickly (it would have been less fun to stop, setup Wallet, then re-start).

I chose to purchase basic Glass (I picked the Shale color). I did have the option of a few Hipster-like frames that could support prescription lenses. However, I do not wear glasses so I went for the minimalist—and least expensive—options. I did get the free–detachable–Active Shades (essentially Terminator-style sunglass shade). Get these. They are incredibly useful if you are looking at the viewer screen in bright sunlight (a rarity in Boston).

activeshades

Shipping and Delivery

The time from purchase to delivery was amazingly fast: I purchased around 11am, got an email notice that Google was handing off my purchase to UPS around five hours later, and received the package in Boston the next morning by 10am. This next-day shipping was included in the $1,500 price.

What arrives will be a four-pound box about 2x the width and 1.5x the length of a shoebox. Coincidentally, my Glass came on the same day as my new Nexus 7. However as the Nexus was uncharged, I used my iPhone to take all of the following photos:

IMG_1886

Unboxing Glass

I waited until the end of the workday to open the box (I admit the engineer in me wanted to start right away).

Upon opening the UPS box and packing I was presented with a white box with a San Serif Glass logo and XE on the side. The packaging was very similar to what you would see with a high-end product (akin to Lytro and first iPad, but a bit nicer). The back of the box is black (so is the inner cover):

box

The Archive Shades are in their own box (and could be shipped separated based on my initial email receipt). They come in their own “Glass” branded felt sleeve:

IMG_1888

Opening the Glass box reveals a translucent paper screen cover (mysterious?!):

IMG_1864

This cover easily comes off, revealing the Glass with the only written instructions for use that comes in the packaging:

IMG_1878

Lifting this off reveals an interesting felt pouch with an armored base—yes, an armored felt pouch. As the ticket explains, this is intended to protect your Glass when you pack it away (the armored shell makes the pouch 1.75” deep:

IMG_1883

Underneath this pouch is a black card with your ear bud:

IMG_1870

And underneath this is your USB 3.0 cable with detachable electric plug. The cord appears to be 36” long:

IMG_1869

Also included are some replacement nose pads and a funny FAQ. One example:

                        Q: Can I use Glass while operating a jackhammer?
                        A: Use caution.

IMG_1884

Charging Glass

When I plugged Glass into charge, it automatically booted up without me pressing the ON button. This can also take up to 30 seconds at times. However, it charges rather quickly (about the same speed that a smartphone charges, much faster than a tablet does).

Setting Up Glass

IMG_1875You will need either an Android or iOS phone or tablet to setup Glass as you will need to install the MyGlass App (iTunes version, Google Play version). I chose to use my iPhone as I did not want to walk around with an Android Tablet in my hand and Google Glass on my face. However, I may pair the phone to my Tablet as well as I experiment with Glass a bit more.

I definitely recommend you turn BlueTooth and your Personal HotSpot on BEFORE launching the MyGlass App and starting the pairing process. As I learned first-hand, it will save you the mess of aborting the process, turning these on (I keep them off to save power), and re-starting the process. I would recommend Google improve the App to detect these settings and notify you to exit and turn them before continuing to device pairing (unfortunately, iOS now forbids apps from turning these settings on for you—a now-needed security precaution in today’s world).

Unfortunately I could not take photos through Glass while I was setting it up (not unexpected). You can see videos of the setup process here, on the Glass YouTube Channel. I admit that setting up Glass created the opportunity for me to imitate Fred Armisen’s infamous Glass skit on SNL. I was very glad I could do this in the privacy of my house, doing it in the office would have created more than a few laughs.

Using Glass

I will now spend the next week playing around with Glass to fully understand the UX before I start thinking about how I would designing how an Glass app would work. However, I can say from my first hour of using Glass that it IS a very different experience, one that takes some getting accustomed to. I want to try to remember this experience so I can design applications that will be immediately useable from Day 1. (I did try to see if I could get actions of Glass to trigger IFTTT–alas, there are no Glass triggers yet).

This does not surprise me. I consider Glass on of Clayton Christensen’s classic disruptive innovations. While it is behind in some areas (the camera is not as good as a standard smartphone, usability is still a work in progress), it provides other capabilities nothing else does.

Final Note: Commercial Applicability of Glass

I know many people think Glass is not a commercially viable product. Some cite price point, others appearance, others limited availability. However, I believe that coupling of SDK from the people who brought us the Operating System with fastest adoption in history with a wide range of capabilities (POV-based camera and microphone, hands-free operation and telephony, voice recognition and Internet access) opens the door to some very interesting augment reality-based applications.

I have always thought the most beneficial Glass apps would be those that mapped to real-life activities—but streamlining them by eliminating the need to use your hands to record information and augmenting them by capturing information from your direct POV and combining this with other information. This could be provide enough benefit to justify Glass’ not-insignificant cost in wide range of business situations, from capturing the vision of a contract artisan or craftsperson (my first idea) to a whole new set of ideas I am now exploring.

Glass is a trademark of Google Inc.

Galaxy Gear: Minimum Viable Product or Niche Accessory?

Yesterday, Samsung announced the launch of their new Galaxy Gear “smartwatch.” By now, you can read a multitude of reviews about this device. In general, they praise features like the Gear’s 1.9-megapixel camera (something neither the Pebble or the SONY SmartWatch has) and the 70 native apps that will be available at launch. However, many critique the Gear’s limited compatibility (at launch it will only pair with Galaxy devices running Version 4.3 of Android Jelly Bean). This conflict of better-than-market features with limited market applicability begs an important question: does the Galaxy Gear rise to the threshold of a Minimum Viable Product (“MVP”) or is it only a niche accessory?

Galaxy Gear - 6 colors, but few connectivity options (Samsung)

Galaxy Gear – 6 colors, but few connectivity options (Samsung)

Why Launch Now?

In his post “What Now? Product Release” Peter Levine (of Andreessen Horowitz) defines an MVP as a product that satisfies the 3-5 most compelling customer needs with highest attention to quality.

MVPs are not just for startups; they are essential to the successful launch of any disruptive innovation. The digital music players market illustrates this powerfully. For nearly a decade, many leading (large-cap) tech companies launched digital music players. However, none of these met the threshold of minimum viable product (easy to download music or copy over CDs, easy to play, work with the majority of PCs) until Apple launched combination of the iPod with iTunes (for Mac and Windows). From here, the rest is well-known history. Clearly, a successful MVP can open up a highly valuable product category for a company with the size and smartphone market share of Samsung’s.

By launching the Gear ahead of it major competitors (i.e., “Apple”), Samsung has attempted to seize several first-mover advantages, namely early market leadership and mainstream definition of a new product category. It has also seeded expansion of a series of interconnected portable computing devices and established platform from which it can obtain data on everything from usage patterns to marginal cost.

But is the Galaxy Gear Viable?

However, the Gear’s first-mover advantages are only useful if it is a viable product. The Gear does appear to have the required level of Quality (as any user of Galaxy S3 or Note can tell you). But does it satisfy the most essential consumer needs?

  1. Can it serve as a watch? Yes—both analog or digital
  2. Can it serve it run apps like a smartphone? Yes—apps built on the most widely used OS
  3. Can it keep me connected like my smartphone? Only if you have a compatible Galaxy device (the Galaxy Note 3 pre-sales only begin today; US retail price is approximate $700) AND this device is within 1.5 meters
  4. Can it be bought and used by most people? No. Only a small number of people can buy and use the Gear (unless they want to buy another more expensive device alongside it)
Not yet

Not yet

While the Gear technically meets the essential consumer needs, it does so with extreme limitations. The Gear is not the ultra-convenient smartwatch that finally lets me take my smartphone out of my pocket in evening (or lets me stop worrying if I am missing key alerts while I am working out). Instead, in its current form, it is an ultra-niche accessory.

What’s Next?

While the Gear is not MVP, it is only Samsung’s first mainstream foray into connected wearable computing. I—like many others—would love a standalone water-resistant watch that is part connected smartphone, part fitness band, part MP3 player, and looks nice. It would much more convenient to use outside of business hours—especially while our shopping or working out at the gym. Hopefully, we will see this true smartwatch MVP in the Gear II. If not, we will likely see it from somebody else over the next 12 months.

Building a Native Mobile App Experience—Without the App

Note: This post was adapted from the more developer-oriented “Piggybacking on backbone.js for performant mobile web”, originally published on Sawdust Software.

Native mobile apps are great. They provide a rich user interface (UI). They can easily access other core applications (e.g., camera, calendar, message center) on your smartphone to create stickier, more immersive experiences. They routinely provide a much faster user experience (UX) in terms of menu traversal and screen-to-screen navigation.

However these benefits come at a cost. They require lots of work: learning, developing, and testing on an entirely different tech stack (most likely iOS or Android). They bind you to navigate a proprietary app store release and submission process (one far slower than the ability to release software on your own web farms). Worse, these are not one-time costs. They can double the cost of adding new features (as you have to develop these for web and native mobile). The also introduce a new mobile OS compliance cost: keeping your app up-to-date with new mobile OS releases—while supporting users on older mobile OS versions—can routinely add 30% to your costs of mobile development and testing.

In some situations, the benefits of using a native mobile app far outweigh the costs; in others they do not. Luckily, there are many technologies and approaches available when you want to create a mobile web experience and do not require (or want to) development of a native mobile app:

Create mobile web-optimized templates

The responsive web design (RWD) movement has gained much traction in the design and development community. While it is appealing to create universal web templates that can detect and respond to the size of the browser screen, this is not always ideal for mobile web. More often than not, universal web templates can have quite large file sizes. Downloading these over a 3G connection can be quite slow. Worse, they can burn battery life on your customer’s phones, leading them to not use your site on mobile.

When considering functionality for mobile pay attention to size of the pages you need users to download. If the desktop (or ever increasingly Tablet-plus-WiFi) versions of your HTML templates are large, create mobile-only templates that are smaller and optimized for download and display on smartphones. If you are on a standard web framework, you have a range of plug-ins you can add to easily detect then customers are accessing your site with a mobile device and serve these templates (e.g., Django Mobile, User Agent (for Rails), Spring Mobile Device Module). You can even use these to serve up a different experience for mobile tablet (vs. mobile smartphone) users.

Use HTML5 and jQuery Mobile to emulate native mobile UIs

Thanks to the rise of mobile and responsive web design, there are now many libraries available to develop lightweight (i.e., small file size) touch-responsive web interfaces using HTML5. Some great examples include: JQuery mobile (if you are a jQuery purist), jQT (if you have a Sass shop), and Zepto (if your really want super fast performance).

When you combine these with mobile browser detection (see above), you can serve up HTML interfaces that use widgets that are virtually indistinguishable from their native mobile counterparts to 80% of your customers:

Mible

Entirely HTML5, Sass and jQuery mobile web–with emulated iOS widgets (www.custommade.com)

It is worth pointing out that using these libraries not only lets you emulate a mobile app experience, using them also keeps your teams on a single technology stack. Developers building web UIs can easily switch over and develop mobile web equivalents (or vice versa). This makes life much more interesting for developers (they can do more, more easily) and management (people can do more and switch to whatever is most important more easily).

Use backbone.js to load navigation control into the browser

One of the reasons that native mobile apps are able to navigate (between menus and moving from screen to screen) so quickly is that they embed a model-view-controller (MVC) architecture directly into the app installed on the mobile device. In an MVC architecture, the Controller directs what Views (screens, menu elements) to display when a user touches (or clicks) on something. On native mobile apps, the Controller is located on the device itself (an is accessible virtually instantly). This is very different than “traditional” browser based web-applications, where the View Controller is hundreds (or thousands) of miles away on a web server—something made even worse when a smartphone is trying to ping a server over a 3G (or worse) mobile connection.

However, over the past 2-3 years, several JavaScript (JS) frameworks have been developed that solve this problem. All of these frameworks were created to simplify development of Single-page browser Applications (SPAs): rich web applications that approximate the interactivity of traditional “thick client” applications. They do this by loading MVC (or MVC-like) frameworks into the browser. This not allows browser-based apps to display updates without action by the end user; it also provides the secondary (and critical) benefit for mobile web apps of moving the View Controller from a remote server into mobile device in the hands of your customer:

arch

Adding a SPA-oriented JS framework like Angular, Backbone or Knockout embeds a MVC architecture in the hands of your customer, just like a native mobile app does.

As result web apps on a smartphone, tablet or desktop can be just as fast as native mobile OS apps. Several JS frameworks are available to achieve this. Google first developed Angular.js in 2009. Steve Sanderson of Microsoft developed Knockout.js a year later. Jeremy Ashkenas also developed Backbone.js—a favorite of many eCommerce and consumer web companies—in 2010.

Caveat

This technology stack does not allow for completely offline operation, something that is possible to achieve with a native mobile application. If you need to support offline operation (for extended periods of time) without losing any data, you will still need to build a native mobile app with an embedded SQLite database. However, that is not the use case more the vast majority of mobile apps.

Credits & Disclaimer

This author of this post used to lead technology at CustomMade Ventures where we have used HTML5, Sass, jQuery Mobile, Backbone.js and Django Mobile to create a mobile web experience for ideation and collaboration for our two-sided marketplace. Translation of this architecture into reality is the work of two great members of our Engineering team: Brendan Smith and Mike Manning.