Update Location Metadata - Show Closest Locations

New website features:

1) Users can now edit some location metadata fields:

- Operator
- Location Type
- Phone Number
- Website

To edit them, lookup a location then click “click to update location metadata”.

Both Operator and Location Type are from dropdowns. So if you want to assign an operator that isn’t currently listed, then you should use the contact form and request to have that op added.

The Website field currently only accepts values that start with http:// – But we’ll soon have it also accepting https://

The Phone Number field only accepts this format: 000-000-0000. And we haven’t added error messages yet! So, if you type in (000) 000-0000 you’ll be silently rejected.

2) Regional maps now include a “Show Closest Locations” button! When clicked, it will display all locations within a 5 mile radius.

This button is in the header.

The results even show how far each spot is from you!

We’ll be adding in more geolocation-based features to the website soon.

Feedback About Regional Map Model

When we first launched this site back in 2008, it was the Portland Pinball Map. Then people in other cities wanted to use our interface+app, so we created separate maps for them. We figured that distinct maps would encourage locals to “own” their map and keep it up to date. And distinct maps would help contain the data, so that admins would have a better chance of verifying the validity of data. And users would have a higher chance of updating the data, given that the regions were centered around populated areas with active pinball scenes. Plus, we didn’t want to attempt to map every machine in the entire country. That had been done before, and it resulted in many locations in far off areas that are never updated.

We refer to each map as a “region.” But what is a region? Where does it end? The Portland, Oregon map extends across the river to Vancouver, and all the way to the coast. This map includes all the pinball machines in Portland, but also all (or most) of them in 30 other cities. The edge of the Portland map is fuzzy. We don’t know where it ends – it’s a judgment call.

Now there are 65 regions on the site, which means 65 judgment calls. Which means site users are sometimes confused. For example: We used to have a Milwaukee region. But it grew to cover the entire state. Users from Madison would contact us asking for coverage in their city. They didn’t realize (understandably) that Madison was tucked within the Milwaukee map. So we changed the name of the region to Wisconsin to more accurately reflect the contents.

Regions are sometimes defined as cities, sometimes states, and sometimes… regions. But most of them turn into the same thing: amorphous blobs with no definable edge. And it’s the people who turn them into this. So we’re trying to figure out if each map’s value as a curated, regional map has been surpassed by peoples’ desire to cover everything.

So please take this survey! And leave a comment if you have a comment. We want the data to be valuable and accessible. There are upsides and downsides to both the regional model and the open map model.

Survey is closed as of November 17, 2015! We’ll make a post about the results soon!

Pinball Map Pebble App

POP QUIZ. Do you know what’s easier than pulling out your phone to find nearby pinball machines? Bzzzt! Time’s up. The answer is glancing at your wrist. Glancing at your wrist is easier.

Pebble makes a cool smart watch with a long battery and a simple interface. So we made a Pinball Map Pebble App.

Here’s what it shows you:

  • The closest locations with pinball machines
  • Recent updates to the map
  • Upcoming pinball events in your area

Nice and simple! Here are some screenshots:

Now you can have the Pinball Map app in the palm of your… wrist.

UPDATE: @FamilyFunArcade just made this amazing graphic of the Pinball Map Pebble app in action, and we have to share it:

Yes, there are downsides to this app: Dick Tracy might miss out on catching some baddies because he’s too busy playing pinball. Are we okay with that?? We are!

New Format for Machine Condition Comments

As we mentioned in the last post, we’ve updated the format of machine comments. We said, “Instead of each machine allowing just one comment that users can edit and edit with no punctuation until it turns into nonsense, each comment will now stand on its own.”

What do we mean by unpunctuated nonsense? We mean this:

and this

Why are those so hard to read? Well, that’s partially our fault. When a user edits a comment, the previous comment sits there in the textbox. So they add their new comment on top of the old one (before it, or after it, or in the middle of it – whatever’s easiest!).

This is bad because the comments you leave about machines are really valuable! People use them to figure out where to play. Do you want to ride your bicycle five miles to play a crappy Earthshaker? No, nobody does. And now you don’t have to. The comments are not only useful to other humans, they’re also useful to operators (har har). Operators can check them out to see what’s broken. And they do!

So now it looks like this (screenshot from the website):

Pretend those don’t all have the same date on them, but are a succession of comments left over time (oldest on bottom). With this format, you can see the condition history of a machine in a simple, readable format. The current comment is on the top, and the others are below.

You can’t edit your comments anymore. When you activate the textbox to add a new comment, the previous comment clears out. But you can remove old ones (power to the people)! And we’ll only display the most recent ones.

At the moment this feature is only on the website. The apps will catch up. Oh, and about the next iOS app update: it will come out really soon. It re-adds machine comments into the location info view (as mentioned in the last post), and adds back the date of the last comment (we accidentally removed that), and more. We’ll post more details about it when it comes out.

The Verdict Is In

Hey you guys,
Thanks for filling out the survey in the last post! Here are the results:

As you can see, 28 people answered the survey (decent sample size!). Of those 28 people, 17 (61%) said they would like to see the comments while browsing location info, and 11 (39%) said nope.

The people have spoken! We’re adding them back to that view. Stay tuned for an iOS app update soon.

We’re also revamping the comment system. Instead of each machine allowing just one comment that users can edit and edit with no punctuation until it turns into nonsense, each comment will now stand on its own.

We’ll post more details later.

We want your feedback!

As readers of this blog (and users of our site/apps) know, we are regularly making changes to things. Sometimes we remove a feature (remember the “share on social media that you made an update!” prompt? No? Well that’s why we removed it!), and sometimes we add a feature.

We always want to know what you people think about these changes. Feedback is awesome. So, this post is a general reminder to give us feedback. But we also have a specific thing we want feedback about, which we’ll get to in a second.

Another really helpful thing that you can do for us is to leave app feedback. Please rate the iOS app and the Android app!

Now we have a specific question

In the latest version of the iOS app, we cleaned up the location info view: we removed the machine condition comments from it (so underneath each machine name, it no longer displays any comments that users have left). So, when you bring up a location, it just shows you the list of machines. If you click a machine name, then you see any condition comments that have been left.

Which do you prefer? Is it useful to you to see the machine comments on the location overview, or does it get in the way of the meat of the page (the machines themselves)? We created a survey to help find out. Please check out the before/after screenshots, then let us know what you think!

This? (No)

Or this? (Yes)

<<<Survey is now closed!! Thanks for giving us your feedback!>>>

We're using the IFPA API to post events

Remember when the International Flipper Pinball Association released an API? We do, fondly. And we dunno if you noticed, but we’ve been using it on our site. (also, the IFPA website was made by one of our admins!!)

Here’s what we’re doing. We’re snagging data from the IFPA calendar to list nearby pinball events on our regional events pages. Here’s what it looks like for sunny San Diego.

Prior to this, our admins manually added in events. But, it can be difficult to keep up with them all! So this automates the process. The admins can still edit these and add other events. But if they don’t bother with adding any, the IFPA and their sweet sweet data picks up the slack!

Interested in seeing how others have been using the IFPA API?

http://wppr.slapsave.com has World Pinball Player Ranking cards! They show some stats, and have your WPPR user id number, so that you can easily share your info with tourney organizers and such.

http://wpprnerdery.com has player history charts. It shows the history of your ranking in a nifty chart.

Both of those use Greg Dunlap’s IFPA API wrapper. That’s a good place to start if you’re interested in using the API.

Know of any other uses?

Searching for all machine editions

This is a follow-up to this blog post about pinball machine name standardization and why from our standpoint it’s annoying to have 4 different editions of a machine.

When we left off, we were talking about how pinball map users have to do multiple machine searches in order to find all the (for ex.) The Avengers machines in their area. One search for The Avengers Pro, and another for The Avengers Superbro LE, etc. Most users, we surmise, would want to see ALL of the editions in the search results.

We got some helpful feedback in the comment section from admins and site users. And we think we’ve come up with a great solution that will improve the user experience of the site!

Starting from the back: we have a database of machine names. For each entry, there are four fields: machine name, the year of manufacture, the manufacturer name, and a link to its ipdb.org entry.

Now we’ve added a fifth field: Group. In the back-end, we can create a group – for example, a group called “AC/DC.” Then we can assign each edition of AC/DC (LUCI, LE, Pro, and Premium) to that group.

Now to the front: from a site users perspective, nothing much will be different. They can still add AC/DC Pro or AC/DC Premium to a location – e.g. the machine names are still there, and they don’t see the group name anywhere. But if they do a search for AC/DC Pro, the search results will include any location that contains a machine from the AC/DC group.

So, a single search will bring up ALL of the editions of that machine. This really relieves a burden from the user, allowing them to see more relevant data with less work. (If a user really is looking for just AC/DC LUCI and doesn’t care about the other editions, well she can use her eyes to see that some of the results are for different editions.)

Anyway, this is a small update, but we think it’s a cool one! It does a good job of addressing this issue. And another cool part about it is that it automatically works on the apps! No need for an app update.

Using the Pinball Map API to list machines on your website

Here’s a simple example of using the Pinball Map API to do something cool. In this post I’ll give a detailed how-to (with PHP and jQuery examples) so that you can implement this feature on your site.

Background: http://pinballmap.com aims to actively promote pinball. If you own a business that carries publicly-playable pinball machines, then our site is free advertising for you.

Say you want to share on your own website that you have pinball machines. And you want to list the machines you currently have, AND you want that list to stay current without you having to update your website.

Well, that’s easy. You can pull that information from http://pinballmap.com using the Pinball Map API.

Here’s an example of it in action.

There’s a cool pinball spot in Los Angeles called Pins and Needles. They have a rotating list of around 20 machines. PNN’s website is made with WordPress.

Scott created an API endpoint specifically for listing a location’s machines (note: this is Ryan typing, and I’m not an expert on any of this stuff). Here’s what the raw json file looks like for PNN: http://pinballmap.com/api/v1/locations/4845/machine_details.json

Note the “4845” in the url. That is the location ID. To see the machine data for your site, you’ll have to replace 4845 in the url with your location’s ID. So now you should be asking, what is the location ID for my location?

That’s easy to find:

First go to the regional map that your location is in. For PNN that’s the Los Angeles Pinball Map

Then search for your location. When it comes up, click the link that says “Link to this map result”

That link has your location ID. In this case it’s http://www.pinballmap.com/la/?by_location_id=4845

4845! So, just plug that number (or rather, your number) into the json link above and you’ll see your machine data.

Parsing the json data, and putting in on your website

It might hurt your brain to stare at that json data. The important thing to know is that there’s an object called ‘machines’ and within it is an array of hashes. These are the keys in each hash: “name” “year” “manufacturer” “ipdb_link”. And each key has a value.

To spit out the data, you iterate through the hashes, pulling out the values you want along the way. In the PNN machines page, I used all of four of those values. There’s the name, and if you click the name it goes to the ipdb_link, and then in parentheses there’s the manufacturer and year.

Here’s a PHP method for spitting this out

In WordPress, you can create a page template and then place this code in it. Place this code near “the_content” (your mileage may vary).

So here’s the php code, with my comments explaining what everything does. At the bottom of this post is a link to the complete code, so you can copy it.

First grab the json file and decode it.

$url = "http://pinballmap.com/api/v1/locations/4845/machine_details.json";
$json = file_get_contents($url);
$data = json_decode($json, TRUE);

Then add a FOR loop that counts through the hashes.

for($i=0; $i<count($data['machines']); $i++) {

Then I created variables, so that the final part is easier to read

$link = $data['machines'][$i]["ipdb_link"];
$name = $data['machines'][$i]["name"];
$manufacturer = $data['machines'][$i]["manufacturer"];
$year = $data['machines'][$i]["year"];

And here’s the output

echo "<h4><a href=" . $link . ">" . $name 
. "</a> (" . $manufacturer . ($manufacturer? ", " : "") 
. $year . ")</h4>";

If you want to only spit out the names of the machines, then “echo $name;” would do it.

(If you’re wondering about the conditional statement ($manufacturer? etc) – that’s there because some machine hashes do not contain values for the manufacturer field. So that conditional is saying "if there’s no manufacturer value, then don’t print that comma.)

jQuery Method

(In WordPress, you usually have to use “jQuery” rather than “$”.)

First add this div to the template, placing it near “the_content” (your mileage may vary).

<div class="machine_list"></div>

The results will print in that div. The code below should be within a script tag.

jQuery(document).ready(function() {

get the json file

jQuery.getJSON("http://pinballmap.com/api/v1/locations/4845/machine_details.json", function(data) {

create a loop

jQuery.each(data.machines, function(i, obj) {


var machineName = data.machines[i].name;
var link = data.machines[i].ipdb_link;
var year = data.machines[i].year;
var manufacturer = data.machines[i].manufacturer;
var list = jQuery(".machine_list");

spit out the result!

jQuery("<h4 />", { html: "<a href=" + link + ">" + machineName
 + "</a> (" + manufacturer + (manufacturer? ", ": "") 
+ year + ")"}).appendTo(list);

Here’s the raw code for both methods

The result on the Pins and Needles website

Even if you don’t have a WordPress site, these methods will work. You just need a website that supports either PHP or jQuery.

So, now we never have to update that page on the Pins and Needles website! As long as the map is up to date, the website is up to date.

In conclusion, this is a simple way to post your machine list on your website. Tell me if you have any questions, and tell us if you use it on your website!

pinballmap.com API V1

Hello Pinballers,

We’re pleased to present to you, the pinball public, version 1.0 of the pinballmap.com API. This is the API that we’re using to power our Android and iPhone apps (look for huge new releases of both of those applications in the near future, btw). It’s our hope that by putting the public closer to the data behind the map, that we can all work together to build new and exciting views into the pinball landscape of these United States.

API documentation is available here:

If there are any features or endpoints that you feel are missing from this API, please submit patches for them here:

…or request that someone make them for you via our Portland admin contact form, here:

This API is stable with its current offerings, but expect additions to V1 to roll out in the next couple months. Please let us know if you any of the current documentation or functionality is unclear.

Let the data mining begin! All we ask is that you let us know if you end up doing something cool with the data, because we like seeing cool stuff with this data too!

Some ideas of things maybe you’d like to do with this data…

  • A windows phone app
  • A website showing what machines are the most popular, by region
  • A “high high score board”, showing the top scores nationwide
  • Data validation tools to help ensure that locations on the map are still in business

…I dunno, SOMETHING. We’ve only got so many hands and brains over here, let’s work together.

Yours in pinball,
The cats and staff of PBM

PBM Android App 2.0

We’re happy to announce the release of version 2.0 of our Android App.

Previous, our app was targeting Android 2.2 or higher. Unfortunately, we have been using some location finding technology that was completely removed in Android 4.3. This broke features like “closest locations” for 4.3+ users. So, we took this opportunity to start targeting 4.3 and updating a lot of features that were deprecated. You probably won’t notice a huge difference in the way things look, but here is what you maybe might notice:

  • improved location finding services (“closest locations” should be snappier and more accurate)
  • new mapping system (we’re using the fancy Google Maps Android V2 api now)
  • speedier/response interface in general

Unfortunately, only users of Android 4.3 and above will get the opportunity to upgrade. That’s just a limitation of the technology available in older OSes. Sorry about this. I’m pretty sure that the older version of the app is stable for older versions of the OS.

A final note here.. I didn’t notice there were any issues with the app until they were reported by an alert and responsible user. I had been using Android 4.0, and was just kind of blissed out and blind to the whole terror that was hammering 4.3+ users. So, please, never hesitate to report any bugs that you find with the Android App (or the website or the iOS app). We’re not cool with stuff being broken, and we’ll jump on fixes as soon as possible.

Thanks for checking out the app, and good luck with all of your pinball games.

How we keep the map ad free.

Hello. We thought it might be interesting to talk a little bit about what goes into the general development and maintenance of the pinball map. Specifically, the things that we do to keep everything free (and ad free) for you, our treasured users.

The Perl Years

Initially, the PBM was just the “Portland Pinball Map”, because that’s where Ryan and I played pinball. It’s just the town we knew, OK? There was a local Google Map, but it was difficult to work with. So, Ryan and I decided to replace it with something more user friendly. This was in 2008. The Portland Pinball Map was written entirely in Perl/HTML/CSS/JavaScript. My background at the time was pretty heavily Perl-based. So, that was just the language that made the most sense to me.

Getting a website like the PBM up and running basically boils down to these things:

  • Web Framework: Like I mentioned before, the initial map was written mostly in Perl. A lot of people don’t like Perl, and find it horrifying that someone would use it for anything except scripting. And hey, I get that, but I’ve seen people do great stuff with Perl too, so lay off. In addition to Perl modules for our Models and Controllers, we also had Mason embedded in our HTML.

  • Database: Initially, the PBM ran on top of MySQL. This was before Postgres really captured my heart, and I really didn’t care what database we used as long as it was relational.

  • Hosting: Here is where an actual cost comes in. In order to host the map at this point, we used Dreamhost. Dreamhost offers a plan for $120 a year that gives you unlimited bandwidth, disk space, and one free domain. It wasn’t a bad deal at all. You get a virtual server that isn’t very beefy, but we also weren’t really dealing with a heavy traffic load at the time. And it’s just $10 out of my pocket every month, which is not a big deal at all.

  • Domain Registration: Dreamhost gave us one free domain, so the costs here were rolled into the $120 per year fee.

  • Data Administration: This was handled 100% by Ryan. Since we were only dealing with Portland at this point, Ryan was able to use his extensive knowledge of the city to make sure that the data on the site was accurate and clean.

We were able to keep our out of pocket costs down to $120 a year by going entirely with Dreamhost. We were able to eliminate any costs of the software itself by staying 100% with free / open source tools. And, we were able to eliminate any “human costs” by just donating our time to it in the form of software development and data administration.

BUT, the most important component was, of course, the users. The site would be completely empty if you guys weren’t out there playing pinball and then telling your fellow ballers where the machines are.

Mobile Times

In early 2010, we got approach by another developer with the idea of expanding the map to mobile devices. This was an area that no other pinball maps were exploring, so we thought it was worth a shot. Isaac Ruiz (of brackelope fame) put together the app for us.

This is maybe a story for a different blog post, but this is where a lot of my current technical beefs with the website began. A lack of inexperience on my part in API design, coupled with the technology stack we were using made for some hasty decisions that continue to haunt us to this day.

When the iOS app first launched, Isaac chose to sell it for $1. The economics of mobile apps are sort of goofy. People pay $500 for a phone, but freak out when an app is a dollar. But hey, I get it. Isaac made the decision to sell it based on the fact that Apple charges developers $100 a year just for the honor of being an Apple developer. A year or so ago, Isaac made the app a free download (he is stacking bills with brackelope now, so…). At the same time, he donated $200 of the app proceeds to the pinball map so that we could register pinballmap.com (more on this later), paid a designer (Drew Marshall) for work that he did for the app, and also sponsored some local pinball tournaments with the money. So, even your one dollars were ultimately going back into the pinball community in some form.

To follow-up on the success of the iOS app, I took this opportunity to develop an Android app for the map. This was sort of a cool project for me because it gave me the chance to “get my feet wet” with mobile development for the first time. It’s much easier approaching a project like this when you have an audience, a clear set of requirements, and the desire to learn a new thing. On a personal level, this is where the synergy of the pinballmap and my development interests come together. I enjoy exploring new programming languages/frameworks, and it’s a lot easier to get motivated to do this exploration when I know that the results of my efforts aren’t going to get shelved in a repository when they come to fruition. So, thank you for your patience with issues that come up on the map, a lot of stuff here is a learning exercise for me.

Anyway, roundabout when we had both apps launched, we noticed that the traffic to the site more than doubled. That was exciting, but scary. Even though hosting and bandwidth was not an issue, performance was beginning to be.

Added costs:

  • Another developer added to our team, doing unpaid work.

  • A whole new breed of user, now doing the important community service of taking their cellphones out in the middle of a bar and selecting a machine from a drop down menu.

The Expansion Teams

In 2010, we heard the call from our brethren in the north. They wanted a pinball map too. We were a little nervous about expanding, mostly because we didn’t want the data to go untended. But, we put our trust in the enthusiasm of the administrators and users in other areas, and we think it’s paid off! We started by adding LA/Seattle/BC, and saw our traffic go up by a factor of more than 5.

After the initial swath of regions rolled in, we continued to slowly expand the map. Once we added “bay area”, we knew that we were about to be in trouble. Traffic was way way up, and performance was starting to take a noticeable hit.

A pretty classic way to address problems like this in computer science is to “throw RAM at it”. And, that (maybe) would have worked, and been awesome. But, that also would have cost money, and we knew this wasn’t an option unless we started putting ads on the site.

Added costs:

  • Many many more admins; all volunteering their time to make sure that data in their areas was well-formed, and maintained.

  • Supporting thousands more users; all volunteering their time to make sure that their communities knew where to put their quarters.

Ruby Times

With the increase in site traffic, we looked to a modern web framework to split up the load more intelligently (and give us access to tools that Perl didn’t have). This happened to coincide nicely with a new project that I was working on at my 9-5 job; a rails app. I thought it would be mutually beneficial to work and the PBM audience if I was learning rails in two places at once. I’m not sure if that ended up being the case, but here we are. Porting the app from Perl to Ruby took a long time, but was actually sort of fun. This smart guy I know at work once told me “the best way to learn a new language is to port something to it that you are already familiar with”, thanks Ian. I took it to heart, and tried to do the best I could.

This iteration of the PBM was open-sourced on github, to try and encourage community participation in the project. So, if you are a rails developer or would like to become a rails developer, maybe check out http://www.github.com/scottwainstock/pbm and see what you think.

Although the spirit of the PBM remained the same after the port to Ruby, the technology underneath it had completely changed. In order to keep costs the same, we continued to host the site with Dreamhost. Unfortunately, at the time, Dreamhost really wasn’t setup to host rails apps. So this meant that we add a couple goofy hacks to keep things running (e.g. a few nasty symlinks, lack of passenger, and a slightly convoluted Capfile). It was around this time that we also noticed that Dreamhost had a lot of issues with uptime. We were seeing the site go down a couple times a week, sometimes for as long as 2 hours at a time. We knew that pinballers needed constant connectivity with their data, and we knew that we needed to make a major change if we were going to be able to offer this.

Added costs:

  • Isaac donated $200 to secure the pinballmap.com domain. There is an on-going $30 a year fee for this.

The Heroku Years (present times)

We saw great gains with Ruby. Performance was way up, code was easier to maintain, and deployments were a snap. Starting over and writing (almost) everything from scratch let us get rid of a lot of rough edges that were starting to be an issue. Things were almost totally awesome. We were falling way short in one area though, Dreamhost. Dreamhost continued to have outages issues. At one point the site went down seven times in one week, and was unavailable for up to an hour at a time for each outage. We were started to get complaints, and we knew there had to be a better way. Enter Heroku

Heroku is essential cloud hosting (and more) as a service. It’s tailor-made for the rails app that the pinball map had evolved to. It also presented us with a number of hurdles that we had to overcome in order to keep the monthly fees of running the site to a minimum. Specifically…

  • A 10,000 row limit on the size of our database. In order to use Heroku’s free-tier of postgres, we have to make sure that the database remains under 10,000 rows. In order to do this, we eliminate a lot of history from the system. So, when you remove a machine, we actually are removing the data from the database altogether. Ideally, we’d retain history like this. (don’t stress though, we have daily backups of the entire system, so the data is available, if not immediately available) Even with a fairly aggressive “trimming of the fat”, the system currently hovers around 9000 rows.

  • Goofy logging. Heroku doesn’t really allow us to write files to their server (outside of when we deploy the code). Because of this, we use a nerfed version of Papertrail for our logging. What this means is that we only get to see the first 10 megs of each day’s logs. Despite a number of optimizations in the nature of the data we actually tore, this 10 megs only gets us through to about 4pm each day.

  • A limp version of New Relic. New Relic is an application performance monitor. It’s a really cool service that shows you information about the health of the system over time. Unfortunately, the free version doesn’t show us much at all. So, we’ve had to switch over to Google Analytics to get an idea of what sort of load the system is under, and GA doesn’t really do much in the way of actual performance metrics.

  • Outsourced email. We use Sendgrid, which is a pretty great email service, don’t get me wrong. The problem with their free service is that we’re limited to 200 emails per day. After that, silence. We only process maybe 50 legitimate emails a day (in the form of new location suggestions, machine additions/deletions, etc), so the 200 limit typically isn’t an issue. We’ve had three or four outbreaks of spam throughout the years though, and have had to write some code to check for robots.

  • S3 for image hosting. Like I mentioned before, we aren’t allowed to upload files to heroku beyond the code that runs the actual site. So, when we moved things there we needed to open up an S3 account to host the images of the locations that you see on the map. This only costs us a dollar or so a year, but it’s sort of a pain to not just dump everything locally.

  • We have a lot of processing restrictions with the free instance of Heroku. The site runs on 512 megs of RAM, has a Max 200msec per second CPU time, a limit of 100 megs for size of the app, and a limit of 2tb per month in traffic. I don’t think we get anywhere close to 2tb a month in traffic, but we’re constantly bumping up against the RAM and processing restrictions (in addition to the database limit). What this has meant for us the need to constantly “run lean”; looking for code optimizations and caching solutions where ever we can. On the one hand, it’s been frustrating, on the other hand it’s sometimes fun to see how much we can squeeze out of how little we have.

I don’t want you to take this the wrong way or anything, we love Heroku. It’s hard to complain about a service that is completely free, and rock solid. The site offers a ton of useful stuff that “just work”, and we’ve never had to pay them a penny for any of it. I just thought it’d be interesting to call out the sort of goofy workarounds that we need to do in order to keep things ad free. Even just $50 a month would make a huge difference in the speed and responsiveness of the site. But, as things stand right now, the site runs for about ~$2 a month, which all goes to the domain registration fees. Heroku enabled us ditch the $120 a year Dreamhost fees. Not bad!

It’s worth calling out one more time that the number one thing that keeps things running around here is the input of the users. We are here to provide a site that is responsive, intuitive to use, and robust in features. But without you providing the data, none of this code does anything useful at all. So, thank you for that.

I think that’s it for now. If any of the technical bits in there caught anyone’s eye, let me know, and I’d be happy to expand on them. I tried to keep this post constrained to cost-centric issues, but I love typing about this stuff in general. Thanks for reading and thanks for the continued support of your pinball maps.

36 Ways to Share Pinball Love with IFTTT

In a previous blog post, titled Reviews of Various Twitter Feed Services, we concluded that IFTTT.com is the bomb. It has an extremely simple, visual interface (with nice and giant text and images), and most importantly, it works great!

Here’s a visual of the very simple recipe we use:

IF update to RSS, THEN post update to Twitter

We have one mega Twitter account that uses all 36 IFTTT recipes, sharing updates from all regions across the site. As noted in the profile, that account isn’t for the faint of heart. It gets updated often (over 2,000 posts since late June) – which is a great reflection of how much activity the site sees! If you want updates, but you don’t want ALL the updates (if you live in Charleston, chances are you don’t care much that Brixie’s Saloon in Chicago just added the new Star Trek pin), there may be regional twitter/fb/etc accounts to follow.

But if there isn’t one in your area, then… well, you can start one!! When we first started pinballmap.com, and only had a couple regions, we were like, “let’s set up a twitter account for each region.” And so we created @bcpinball, @seattlepinball, @la_pinball, and @portlandpinball… but then we stopped. Robo-updates are not the only things followers want to see. Followers are attracted to personalities, not just hard data. And it’s difficult to stay engaged when you have 5+ twitter accounts (granted, those accounts all have a decent amount of followers – people do like data! and also, we do post non-robo tweets to them semi-regularly)! This goes right back to why we have locally-based regional administrators for each region on the site: locals own their map; they know the area, and they know how to engage with others in the area and promote it. Having a local at the helm helps give users the impression that they are not alone.

So we thought we’d share all 36 (now 37 – actually, now like 50 and counting) pinballmap.com recipes, one for each region that is currently on the site. If you live in one of these areas and are into pinball and want to help it gain popularity, then feel free to use (or modify) your region’s recipe. You can change the THAT part of the recipe: the update can be posted to Facebook, or sent straight to your email, or a number of other things (list of available channels).

EDIT: Rather than continue updating this entire list, just go here to view all our shared recipes.

Just yesterday, I shared the Eugene recipe with @pinballeugene, and five minutes later that account was posting map updates. It’s easy!

Feel feel to post any questions/comments. Also, tell us if we’re missing any social media accounts that are sharing pbm updates. We probably are.

Mobile site update

screenshotThere are two ways to access pinballmap.com: through a website browser, and through a mobile app (on either the Android or iOS platforms). And browsers, for the most part, are accessed either by a desktop/laptop computer or a smartphone/tablet. Most of our users who visit the site via a browser are using a desktop/laptop, but some are on their phones! Why would anyone access the website via a browser on their phone when they can just tap into the data via an app? Well, they might have a Windows Phone. We don’t have an app for WP just yet. Or they might just like to access all of the features on the website that may not have been added to the apps yet.

The latest major style update to the website introduced some less-than-mobile-friendly designs. Notably, elements with fixed positions that, when the browser window is teensy (as they often are when viewing from a mobile device), start overlapping one another. This makes things hard to read and click. And that’s not cool.

So we designed a really simple mobile version of the site. Using Rails, we detect if you’re on a mobile device, and if you are, a mobile-specific stylesheet loads that re-skins the site. Functionality is all the same (well, a few things have been removed or simplified), but everything fits a little better on a narrow screen. Elements (buttons and text) have also been made larger, so that your giant fingers and crappy eyes can easily click and read.

The screenshot to the right shows what the mobile site looks like at 320px wide. Your device might be wider than that. The design isn’t perfect, and we’ll do some style tweaking here and there so that it looks totally beautiful. But for now, it’s pretty good (definitely better than when we didn’t have a mobile-specific site!). If you have feedback, please share it!

This image is humongous, and there isn’t anything else to type… But it would be cool if the text on this post was just as long as the image, so more words can be found. Hmm… Stern just released a video preview of their upcoming Star Trek machine. Check it out. The playfield is pretty reminiscent of Star Trek: TNG, don’t you think? That’s probably a good thing.

Machine name standards

Names. What are they. I mean… really? Some say that nobody knows. But others say that practically everyone does.

One of the fields in our database is for machine names. It doesn’t contain every single pinball machine ever made – rather, it contains all the machines that are on, or have been on, any region of the site.

When Stern comes out with a new machine, it can be surprisingly difficult to figure out what the real name of it is. Avengers, or The Avengers? Their press releases will use both!

We consider the Internet Pinball Database to be the standardbearer for machine names. For the most part, we follow their conventions (because they know what they’re talking about). Is it Who Dunnit? or Whodunnit?? Neither! According to ipdb, it’s WHO Dunnit.

When our site users add machines to a location, they can choose from a dropdown list of all the names in our database, or use the text field to type it in (which will, helpfully, be auto-filled with likely results).

This gets more complicated when using the mobile apps. Mobile users tend to prefer typing a name in, and there isn’t an auto-fill feature on the apps. So, inevitably some will type in Demo Man instead of Demolition Man, or Adams Family instead of The Addams Family – this results in a new machine name being added to the database. The obvious downside of having a new machine name in the database is if a user wants to search “by machine” (aka find all the locations that contain this machine), they’ll have to do two separate searches – one for The Addams Family and one for Adams Family – just to see the results for what in reality is one machine. (We get notified whenever new machine names are added. So we are usually really quick to remove Adams Family and replace it at that location with The Addams Family.)

So, it’s in our interests to encourage users to pick a machine name from the existing list (as we mentioned in a previous post, one of our aims is to guide users to making wise decisions). And if the machine truly isn’t already in our database, then they can add it (and we will clean it up when necessary).

And then came Stern…

From our perspective, it’s unfortunate that Stern likes to put out 8 different editions of one machine. Each one gets their own database entry: X-Men (Pro); X-Men (LE); X-Men (Wolverine LW); X-Men (Magneto LE); etc.

We always wonder: how much do site users care about these editions? If they want to locate the nearest X-Men machine, are they they going to be like, “nevermind,” if the closest one is a Pro version and not an LE version? Plus, there is the hassle of having to do multiple searches in order to find ALL the X-Mens. Would it be more useful to just have one machine entry for X-Men that covers all of the editions? The problem there is that some users will still create entries for special editions. And if we let that be, then the data will be inaccurate (because some LEs will not be tagged as LE, etc).

The first person to enter Metallica into the database entered it simply as “Metallica.” The next person entered it in as “Metallica (Pro)”. IPDB tends to be slow to add brand new machines to their site. So at this point we weren’t entirely sure if these names were accurate. For Stern’s Avengers machine, they didn’t have any that were simply called “Avengers.” All of them had some sort of subtitle, and the “plain” version was called the Pro.

Turns out this wasn’t the case with Metallica. According to the Stern website, there isn’t a “Pro” version of Metallica. And the plain version—I think—is just called “Metallica.” This lack of a sensible naming policy on Stern’s part tends to confuse users!

So now we had one spot with Metallica and one spot with Metallica (Pro). So we combined the two names into just “Metallica.”

Then someone created a name called “Metallica (Premium).” This is a legit name. And now users, when adding a machine to a spot, have the choice of adding either “Metallica” or “Metallica (Premium).” And chances are some will choose Metallica even when that machine is a Premium version. Not everyone’s going to notice the difference when they’re out playing pinball. So, things get splintered. And I guess that brings us back to the question posed above about whether separating out these names really matters to most users.

Perhaps we could link up certain entries, so that if someone searches for “Metallica (Primo)ALL of the various Metallicas will show up in the results.