S-Town, Maps, and the Passage of Time

SPOILER ALERT: If you’re considering or are just starting to listen to S-Town, don’t read further unless you’ve listened to at least as far as the very end of the second episode.

I mean it.

OK, here we go.

Like John B. McLemore, the man at the center of the S-Town podcast, I’m obsessed with time. Well, maybe not as obsessed with it as he is. But I’m always thinking about it.

Another obsession I have, that we have not, at least by mid-episode 3, heard is (or, rather, was — there’s the first spoiler) shared by John B., is with maps.

(I’m calling him “John B.” rather than just “John” because that’s what the people who were close to him call him. I’m not sure if he liked that or not, but I’ll assume he was OK with it.)

I had already read enough in a review, not to mention on the S-Town website itself, to know that someone else in the story actually dies, and that this most likely would be revealed at the end of episode 2. And, with the heavy foreshadowing early in that episode, it was not much of a surprise to me when it happened — who, or how. (Yes, even the method, which is revealed early in episode 3. That’s foreshadowed too.)

This is a true story of a real person’s life, so I am not trying to make light of it. I felt a genuine loss, and I’ve only known about this person for a few hours.

But let’s go back in time a bit.

I listened to episode 1, and the first 15 minutes of episode 2, when I was out running. I ended up listening to the rest of episode 2 in bed last night, finishing it well after midnight. But before I listened to that final half hour, I spent at least as long looking at satellite views of Woodstock, Alabama in the Apple Maps app on my iPhone… hunting for John B.’s hedge maze. I knew I was close when I spotted the South 40 trailer park that had been mentioned in episode 1.

I might have saved myself some time by searching on the latitude and longitude coordinates rattled off in episode 1 — curiously specific, I thought, even though producer Brian Reed had edited out the last bit, to respect John B.’s privacy. That struck me as odd right away… and also seemed to be a bit of foreshadowing, that maybe John B.’s privacy didn’t really matter so much now.

As I was saying, I might have saved myself some time, but I didn’t feel like going back and hunting for the exact spot in episode 1 where the coordinates were named. More fun to just explore the satellite images until I spotted a circular hedge maze in the woods.

But that wasn’t the first thing I spotted. First I spotted John B.’s school buses… the ones Brian Reed said he was using to age lumber. There were three now, not two. I panned a bit to the west and saw the house, then north and there it was… the hedge maze.

John B.’s house, school buses and hedge maze, from Apple Maps satellite view.

Excited by my discovery, I took to social media. Then I decided to see if anyone else on Twitter had possibly found the maze as well. Of course they had.

Except… wow. That looks a lot different. At first I was second guessing that maybe @RASEC29 had found the wrong maze… or that I had.

John B.’s property as seen in Google Maps.

I mean… where were the school buses? And the house… it looks… so overgrown.

That’s when I knew.

The satellite images in map apps aren’t dated (although I think that may be changing), so I have no idea exactly when these different images were taken. I don’t know if John B. was still alive in the Apple one, or if it’s just that the buses hadn’t yet been cleared away, the maze abandoned, the yard overgrown. And in the light of day, with a better view on my computer, the land doesn’t seem quite as devastated in the later photo as it did when I saw it at around midnight, on my iPhone screen. It’s a different time of year, and a different time of day. Things are brown instead of green, shadows fall in a different direction.

But clearly, time has passed, things have changed, John B.’s world has decayed, much as he obsessed over.

I have so many more things I would like to say, but… time. Also, I’m not even halfway through the series yet, so there is much I still don’t know that is yet to be revealed. Or not.

So I’ll leave it at this. As the quote on John B.’s astrolabe reads, life is “tedious, and brief.” I’m sorry John B. never made it out of his Shit Town, if that’s what he really wanted to do, but I’m glad he shared his story. And I hope he’s wrong about, you know, everything being doomed.

Update: Several other people have now replied to @RASEC29, including @tifotter, who has posted dated images from Google Earth:

How to win when you lose: unbalanced representation in the U.S. government

I haven’t talked politics here much lately. Frankly it’s all been too demoralizing. I mean, how do you talk about someone who is so patently unqualified, not to mention arguably legally disqualified, not only “winning” an election (courtesy of archaic undemocratic rules), but receiving nearly full-throated support from the cynical opportunists of a political party who only a few months ago were decrying his very presence on the scene?

Well, enough on that. Others are fighting that fight better than I ever could, so I’m going to move into the realm where I flourish: geeky data analysis.

Specifically, I want to look at three ways in which the U.S. government — Congress and the presidency — are inherently imbalanced, plus one additional way that they’re being made more so through the shameful tactics of one party whose power depends on exploiting those imbalances to their fullest extent. (Take a guess which one I’m talking about.)

The three ways are: 1) House district apportionment (specifically, “Gerrymandering”), 2) the two-per-state structure of the U.S. Senate, and 3) the Electoral College. Full disclosure: I am not a history scholar. I’m relying mostly on things I actually — gasp — remember learning in public schools in the 1980s.

I’m going to just jump to my thesis here, since the perspective it provides is going to come up in a few places in the rest of the post: In the present day, the values of most Democratic voters favor living in more densely populated areas, whereas the values of most Republican voters favor living in more sparsely populated areas. And since these three aspects of the American electoral process were specifically designed to benefit less-populous states (to get them to go along with the Revolution in the first place), the Republicans today are in a position of power far beyond their actual support amongst the electorate as a whole.

Whew. OK, let’s begin.

Gerrymandering in House seat apportionment

Ah, Elbridge Gerry. Over 200 years later, his name is still applied to the sadly still too common practice of redrawing congressional districts in absurd shapes to deliver the maximum number of House seats to a favored political party. Both parties have been guilty of doing this, but as the Republicans have been in a position of outsized influence at the state level (see my main thesis), the majority of questionable district apportionments in modern times have been to the benefit of the Republican Party.

Beyond the unscrupulous tactics of Gerrymandering, there is still an inherent imbalance in the House, which becomes even greater when we talk about the Senate: because the total number of seats in the House is fixed at 435 (due to the Reapportionment Act of 1929), and because each state has to have at least one representative, low-population states have much higher per-resident representation than larger ones.

But don’t take my word for it. Let’s look at the numbers. Here’s a table (source: Wikipedia) that breaks down state populations and representation both in the House and Electoral College.

Rank State Population House
Seats		 Elect.
Votes		 Pop. per
House
Seat		 Pop. per
Elect.
Vote		 Pop. per
Senate
Seat
1 California 38,802,500 53 55 717,763 691,662 19,401,250
2 Texas 26,956,958 36 38 723,867 685,769 13,478,479
3 Florida 19,893,297 27 29 715,465 666,123 9,946,649
4 New York 19,746,227 27 29 724,824 674,837 9,873,114
5 Illinois 12,880,580 18 20 715,292 643,763 6,440,290
6 Pennsylvania 12,787,209 18 20 709,085 638,177 6,393,605
7 Ohio 11,594,163 16 18 721,514 641,346 5,797,082
8 Georgia 10,097,343 14 16 708,568 619,997 5,048,672
9 North Carolina 9,943,964 13 15 750,159 650,138 4,971,982
10 Michigan 9,909,877 14 16 705,954 617,710 4,954,939
11 New Jersey 8,938,175 12 14 738,716 633,185 4,469,088
12 Virginia 8,326,289 11 13 744,170 629,682 4,163,145
13 Washington 7,061,530 10 12 689,701 574,751 3,530,765
14 Massachusetts 6,745,408 9 11 738,460 604,195 3,372,704
15 Arizona 6,731,484 9 11 728,139 595,750 3,365,742
16 Indiana 6,596,855 9 11 726,370 594,303 3,298,428
17 Tennessee 6,549,352 9 11 717,360 586,931 3,274,676
18 Missouri 6,063,589 8 10 752,749 602,199 3,031,795
19 Maryland 5,976,407 8 10 735,570 588,456 2,988,204
20 Wisconsin 5,757,564 8 10 715,800 572,640 2,878,782
21 Minnesota 5,457,173 8 10 672,392 537,914 2,728,587
22 Colorado 5,355,856 7 9 741,083 576,398 2,677,928
23 Alabama 4,849,377 7 9 688,860 535,780 2,424,689
24 South Carolina 4,832,482 7 9 674,818 524,858 2,416,241
25 Louisiana 4,649,676 6 8 766,982 575,237 2,324,838
26 Kentucky 4,413,457 6 8 730,069 547,552 2,206,729
27 Oregon 3,970,239 5 7 779,871 557,050 1,985,120
28 Oklahoma 3,878,051 5 7 762,964 544,974 1,939,026
29 Connecticut 3,596,677 5 7 718,059 512,907 1,798,339
30 Iowa 3,107,126 4 6 768,547 513,364 1,553,563
31 Arkansas 2,994,079 4 6 737,283 491,522 1,497,040
32 Mississippi 2,984,926 4 6 746,232 497,488 1,492,463
33 Utah 2,942,902 4 6 713,822 475,881 1,471,451
34 Kansas 2,904,021 4 6 721,476 480,984 1,452,011
35 Nevada 2,839,099 4 6 689,733 459,822 1,419,550
36 New Mexico 2,085,572 3 5 695,179 417,108 1,042,786
37 Nebraska 1,881,503 3 5 618,508 371,105 940,752
38 West Virginia 1,850,326 3 5 618,471 371,083 925,163
39 Idaho 1,634,464 2 4 797,864 398,932 817,232
40 Hawaii 1,419,561 2 4 696,157 348,078 709,781
41 Maine 1,330,089 2 4 664,596 332,298 665,045
42 New Hampshire 1,326,813 2 4 660,359 330,180 663,407
43 Rhode Island 1,055,173 2 4 525,146 262,273 527,587
44 Montana 1,023,579 1 3 1,005,141 335,047 511,790
45 Delaware 935,614 1 3 917,092 305,697 467,807
46 South Dakota 853,175 1 3 833,354 277,785 426,588
47 North Dakota 739,482 1 3 699,628 233,209 369,741
48 Alaska 737,732 1 3 736,732 243,816 368,866
49 Vermont 626,011 1 3 626,562 208,670 313,006
50 Wyoming 584,153 1 3 576,412 192,137 292,077

If you study the numbers carefully, you see it’s a bit of a mixed bag at the House level. Wyoming, the least populous state, carries more weight per seat than California, the most populous, but in between there are variations. Conservative Montana, the most populous state with only one seat, is under-represented compared to liberal Rhode Island, the least populous state with two seats. But one thing that this table doesn’t show is the representation by party for each of those 435 house seats. If we factor that in, and look at the aggregate, we see that the Republican majority in the House doesn’t come close to representing a majority of the American public at large:

Top 5 Albums of 2016

As I noted earlier when I posted the contenders for this list, 2016 is a year I’d just as soon forget. And I suspect it’s possible this year and the next three (or seven, or the rest of my natural life) may also fall into that category. In other words, I’m not extremely excited about dwelling on any details of 2016, even my favorite music from the year.

But it’s my tradition to produce these lists. And so, I present my ranked top 5 albums for 2016, this time without commentary, which I may or may not add at a future date when I am less demoralized by the world we’re living in.

5. King Crimson • Radical Action to Unseat the Hold of Monkey Mind
4. David Bowie • Blackstar
3. Radiohead • A Moon Shaped Pool
2. Solange • A Seat at the Table
1. Tycho • Epoch

I think I like Super Mario Run

Here’s my early review of Super Mario Run, less than a day after it was released.

I think I like it.

I have been waiting forever for Nintendo to finally accept the reality of modern mobile devices and make games for the iPhone. (No, Miitomo doesn’t count. And Pokémon Go doesn’t really, either, especially since Nintendo didn’t actually make it.)

There have been a ton of Mario-inspired platform games for iOS over the years, and while many have been of very high quality and creativity, none has stuck for me.

What makes the top-tier Nintendo franchises (and here I am thinking Mario, Zelda, Metroid, and maybe Pokémon) so great? These are the criteria:

  1. Engaging concept
  2. Attention to detail
  3. Playability
  4. Platform-optimized experience

Every would-be Mario surrogate on iOS has failed at least one of these criteria. And I expected that, if Nintendo ever did make an iOS game, especially a Mario game, when it finally did arrive it would be an unmistakably “Nintendo” experience because it would nail them all… and most likely differ from what I thought I wanted about the experience, because what I thought I wanted wouldn’t really work, and what I actually wanted was something I couldn’t quite imagine.

People have been saying it for years, but yes: this is how Nintendo and Apple are alike, and why I expected to be surprised, if not amazed, by what Nintendo came up with, even if it didn’t seem at first glance like it would be successful.

The biggest surprises for me about Super Mario Run when it was announced were a) how slow Mario seems to run, and b) that it’s essentially an endless runner with one control: tap-to-jump. It’s like the old joke before the iPhone came out that, if Apple ever released a phone, it would only have one button. Guess what: it did, and it changed everything.

Let’s explore the criteria, one by one:

Engaging concept. It’s classic Mario. The basic formula that has existed since Super Mario Bros. in 1985. More specifically, this game, visually and structurally, fits very much into the mold of the New Super Mario Bros. series that debuted about a decade ago on the Nintendo DS. Check.

Attention to detail. This feels like a Nintendo game, in all of ways, both good and bad. The good is where it counts — the actual game experience. The bad is the surrounding stuff, showing that Nintendo is still out-of-step in the online world. First, the bad: this game requires an always-on Internet connection, which seems a bit ludicrous. Apparently the primary reason is to prevent piracy, which I really don’t get. The only way to pirate iOS games is to jailbreak the device, and it seems like there would be easy enough ways for the game to detect that without an Internet connection.

Besides the Internet connection issue, there’s also the fact that the initial setup process requires selecting your country from a huge list (again, this is something the game should be able to detect automatically, especially since it has to be online to function) and a distracting Nintendo Account step. Then after a brief gameplay tutorial, you’re thrust into a black screen with a progress bar as the full game content is downloaded. I’m not sure if my experience was just due to peak interest at the launch, but it took forever to download… in fact, I tried over four sessions as I was out-and-about, jumping between LTE and WiFi in various locations, until I finally got the last 5% to download when I was at home several hours later.

So, that’s the bad, and it really kind of sucks. But the good is, once the game is actually loaded up on your device, it has all of the polish you expect in a top-tier Nintendo title. The design is flawless, the UI interactions are smooth as can be, and everything about it shows the same level of care that Nintendo puts into the best Mario games for their own systems. And because the iPhone screen resolution is so much better than on a DS/3DS, this looks much more like a Wii U game than a mobile game.

Playability. This is where I was really surprised. At first I was disappointed. Mario runs continuously, which makes sense for the one-hand — really, one-finger — control scheme, but he seems slow. This is not the “hold down the B button” running we’re used to in a Mario game. It’s about halfway between his usual walking and running speeds. But you quickly realize the speed was carefully calibrated for optimal playability. When you don’t have the ability to make Mario stop, you need just a fraction of a second longer to figure out how best to react to what’s going on in his environment. Before long you realize this speed feels perfect in conjunction with timing jumps, interacting with special blocks and avoiding enemies.

Speaking of enemies, when Mario is running and approaches an enemy, he automatically vaults over it. It’s a cute effect, but initially it made me wonder… is there any way to die in this game? Especially since it seems like even when Mario would die, such as falling down a hole, he instead goes into a bubble (as in New Super Mario Bros. U) and gradually floats backwards on the course? Well, yes. I didn’t immediately realize that you have to earn those bubbles, and they eventually run out. Plus, Mario only vaults over enemies if he’s running. If you’re mid-jump and he touches an enemy (other than landing square on its head), he dies just like in any other Mario game.

After a couple of easy screens, the complexity of the courses quickly catches up with you, and before you know it you feel like you’re just playing a regular Super Mario title, not a streamlined “endless runner” version.

Platform-optimized experience. Speaking of that streamlined “one-finger” control: one of the most irritating problems with any iOS game, aside from the difficulty of using a simulated, on-screen D-pad for movement, is the fact that your fingers obscure part of the screen. Nintendo, of course, solved this perfectly. When you’re navigating the game interface, the full screen is used as in any other game. But during a run, the bottom 1/4 or so of the screen has no action… only a generic background design matching the style of the current course. That way, you can keep your thumb poised at the bottom of the screen ready to tap (or tap-and-hold for a longer jump) without covering up any of the action.

I would never have expected a one-control, endless-runner style Mario game to work as a real Mario game, but it does, and is probably the only way to make this work on an iOS device. But Nintendo not only defied most fans’ logic with this control scheme, they perfectly tailored the elements of the game to work with it. They removed standard elements of Super Mario games (like Fire Flowers) that simply wouldn’t work with this control scheme, and they added things that — while they maybe would work with a traditional control scheme — are only logical with an endless runner, like special blocks that make you change direction when you jump on them, and others that pause the action to give you an extra moment to decide how to proceed.

A couple of other realities of mobile devices that Nintendo acknowledged with this game’s design are the brevity of play sessions and the interest in online competitive play. The levels here are shorter than typical Mario levels, although they don’t feel especially short, but they work well if you only have a minute or two to play. And the Toad Rally mode is a great way to do online competitive play. You’re not actually competing in real time, but the game makes it feel like you are, by matching you up with actual previous runs by other players.

There’s also a reward system for daily play, unlocking both useful features like additional playable characters as well as more frivolous prizes like decorations for your Mushroom Kingdom, similar to some of the features in Miitomo. And of course, you can tie in your Nintendo Account so your Mii shows up throughout the game. (I assume some of what you do here feeds back into the Miitomo experience as well, but to be honest I deleted Miitomo off my iPhone months ago.)

Overall… yes, I do think I like it. This is not the perfect classic Super Mario experience I always thought I wanted on my iPhone, but… let’s be honest. There are enough other, really well-done iOS platform games out there that I have tried for a day or two and then abandoned that I realize a perfect classic Super Mario experience is impossible on a touchscreen device with no physical controls. What Nintendo has delivered is a new kind of Super Mario experience that feels 100% “Mario” but actually works on an iPhone.

Now, what I really want them to do is an iOS Zelda game. There are Zelda DS games that rely almost entirely on the touchscreen and stylus for all movement and action. It seems like a no-brainer that this experience would translate well to a mobile phone. But then, what do I know?

Just remember… If you see a stylus, they blew it.

A passable but imperfect solution for full-bleed background images on Android and iOS

I’m working on a site right now that has a fixed, full-bleed (i.e. background-size: cover) background image on the <body>. The content flows over it, mostly obscuring it completely, but the background is occasionally revealed in the spaces between content blocks. Some blocks have a semi-transparent background so you can see the fixed background as if through frosted glass.

Here’s the CSS:

body {
  background: rgb(255,255,255) url('../images/ui/body_bg.jpg') center center no-repeat fixed;
  background-size: cover;
}

It’s a cool effect, but it really, really does not want to play nicely on mobile. Various odd things happen on both Android and iOS, and they are completely different.

Quick side note: Yes, the background image is a JPEG. Normally I only use PNG or SVG images in UI elements, but I had good reason to use JPEG here: even though it’s only two colors (with some in-between colors due to antialiasing), the pattern in the background is incredibly complex, and a JPEG version of the file is about 1/5 the size of the PNG. And since it’s an illustration, I tried making an SVG version first, but the pattern is so large that the SVG was about 2 MB! So JPEG it is… which may be a factor in the issue I’m having on Android, but I haven’t tested a PNG version of the image to verify that.

iOS Problems

I’m an iPhone user, so I mainly test responsive sites on iOS. I do own an Android phone (a Motorola Moto E, which I highly recommend as a cheap-but-decent Android phone for testing), but I generally only break it out during the final round of browser testing prior to launching a site.

The issues with background images on iOS are well-known to most web developers. iOS has a number of rather arbitrary seeming limitations imposed upon the Mobile Safari browsing experience, generally for one of three reasons: 1) performance, 2) touch interface usability, 3) the whims of the ghost of Steve Jobs. In the case of background images, background-attachment is not supported. I’m not really sure how this would impact either (1) or (2) — although I think with the early underpowered iPhone generations, it did impact performance — so I think we’re dealing mostly with (3) here. At any rate, because you can’t have an attached background on iOS, I added this in my media queries:

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;
  }

}

Another quick side note: Why is my phone break point at 782 pixels, you ask? Because that’s where WordPress has its break point for the admin interface. I’m not exactly sure why the WP team chose that number, but why fight it?

Besides the background attachment, there’s also the issue that background-size: cover on a phone is going to make the background image huuuuuuuuuge because it’s scaling it to fit the height of the page content, not the screen size. I initially solved that with background-size: 100%;, since we’re now allowing the background to repeat. As you’ll see, however, that led to problems on Android, so I ended up scrapping it.

Android Problems

Yes, Android has problems. Don’t even get me started! But I wasn’t prepared for this.

I opened the page in Android, and, although the background image was displaying as I expected in terms of size and attachment, it looked… awful. The original source image I am working with is a generous 2400 x 1857 pixels, enough to look reasonably sharp on most displays, even at high resolution. And it looks great on my Mac, great on my iPhone. But on the Android phone it was splotchy and low-res looking… like it had been reduced to 200 pixels and then upscaled (which is maybe what Android is doing, somehow… and here is where I’m wondering if the image being a JPEG is a factor, but that’s just a stab in the dark).

I tried a number of possible solutions, the most obvious being to set exact pixel dimensions for the image. I tried 1200 x 929, basically a “x2” size for high-res devices. Still looked like crap. I even tried setting it to 2400 x 1857, the actual dimensions of the image, and it looked like crap… and I don’t mean pixel-doubled, which is what it actually should be; I mean the same splotchy weirdness I had been seeing at other sizes.

And then I discovered David Chua’s solution:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;
}

Yet another quick side note: Here I am not placing this inside a media query. We don’t want to only fix this issue on phone screens. Granted, the iOS solution above needs to work on iPads, too… something I haven’t really solved here. I’m workin’ on it!

This change for Android worked perfectly! By this point I had, temporarily at least, removed the iOS workarounds I mentioned above, so on Android the background image was not only perfectly scaled to the browser window, looking sharp and clean, but it was even fixed-position, just like on desktop!

But… the image was back to being huuuuuuuuuge on iOS. Apparently this html trick for Android does absolutely nothing on iOS, so you’re left trying to find another solution that won’t simultaneously break Android.

An uneasy compromise

It’s not perfect, but I found that if I put both of these tricks together, everything works… the only thing we lose is the fixed-position treatment that Android allows but iOS does not. But the background looks great on both platforms and most importantly, behaves consistently on both.

Here’s the complete code I’m rolling with, for now:

html {
  /* For background image scaling on Android */
  height:100%; min-height:100%;
}

@media screen and (max-width: 782px) {

  body {
    /* For background handling on iOS */
    background-attachment: scroll; background-repeat: repeat;
  }

}

As noted above, this doesn’t really address iPads. A simple solution would be to change the media query to @media screen and (max-width: 1024px), but a) that doesn’t account for the larger iPad Pro and b) it also means a desktop display will lose the proper background effect if the window is smaller than that size. I don’t really have a solution; an adaptive treatment using either server-side or JavaScript-based browser detection would be a consideration, but I don’t really like resorting to that sort of thing for something as basic as this.

It doesn’t help that I recently gave my iPad to my daughter so I don’t currently have a tablet of any kind for testing. That’s about to change as I have a newly ordered Kindle Fire arriving today, but of course that’s not going to give me the answer for an iPad. I can try Responsive Design Mode in desktop Safari, but that’s not always a perfect representation of the quirks of an actual mobile device.

Still… this combined solution for phones is an improvement over the default behavior in both cases.