Category Archives: Web Apps

Posts about web apps I’ve created or am working on.

Creating a d3.js Game of Thrones Visualization

For any Game of Thrones fans out there, I’ve created a neat little interactive visualization. It ranks characters by how many episodes they’ve been in, makes note of who’s alive and who’s dead, and allows you to go backwards in the show’s history to see how things have developed over time.

It also reveals some interesting stats:

  • After 40 episodes, the show has around ~140 notable characters.
  • The show seems to kill an average of 13 notable characters per season, or 1.325 per episode.
  • 37.1% of the notable characters have been killed off so far.

You can see a spoiler-free version of the visualization below (character avatars and death information has been removed):


The chart is written on top of d3.js, which is a web-based visualization library. I learned how to use it earlier this year and have been on the lookout for projects I could use it for. After seeing the bubble chart from Matthew Daniels’s Largest Vocabulary in Hip Hop visualization and noticing it was based on an example by Amelia Bellamy-Royds, I decided to see if I could create my own bubble chart.

D3 Context Menus

I didn’t see any d3.js context menu plugins while doing this project, so I wrote my own. I could have used a jQuery plugin, but I wanted to keep as much of the code within the D3 way as possible (it just made working within their event structure easier).

Other Game of Thrones Visualizations

So there’s are plenty of other Game of Thrones visualizations out there. If you’re looking for more, I’ve compiled a short list below of some of the best ones I’ve found.

  • Events in the Game of Thrones – A visualization of the events from the first 5 Game of Thrones books.
  • Game of Thrones Map – Interactive map of the Game of Thrones universe.
  • Beautiful Death – A piece of artwork drawn for each episode in the show. I’m not sure if this technically counts as a visualization, but they’re pretty cool.

TheDraw’s Lost ANSI Art Fonts


Sample ANSI art by Roy/SAC

Most people know what ASCII Art is – its art created by arranging text into pictures. ANSI art is also text art, but it’s a little more special. It allows you to create text art that includes additional text characters, color, and limited animation. It gained popularity in the tech underground of the mid-80’s, and a community of artists emerged and flourished. It’s hay day was short lived though. In the 90’s unicode became the standard for encoding text, and since ANSI Art was based on IBM’s extended ASCII* character set, its presence became more and more uncommon.

These days the most editors can’t open ANSI Art files. If you try to view them they just wind up looking like gibberish. This doesn’t mean the art form is dead though – fans of the genre have gone out of their way to create special editors and viewers so that the art can still be appreciated, but the community is much smaller than it once was.

The Lost Fonts

About a year ago, someone named Aaron Haun sent me a zip containing over a hundred user created ANSI art font files from an old DOS app called TheDraw. He thought I might be able to provide a place to preserve them since I’d done so for the AOL Macro fonts. The only problem was neither of us knew how to decode the files within the zip.


Aaron’s ASCII Tattoo

Armed with copies of TheDraw and ACiDDraw, I decided to do some ASCII archaeology. I ended up going through the same rigmarole I did when I was trying to get Mark Zuckerberg’s Vader Fader to work, and was able to load up the old DOS apps on a Windows 98 virtual machine. This unfortunately didn’t help much, but it was cool to see the old apps in action.

After some more research, I learned most of IBM’s Extended ASCII characters had unicode counter parts. Since unicode is easy to display, I wrote a script to process the font files and return unicode compatible versions. This script also stripped out the color information. Though I felt the colors were neat, I couldn’t figure out how TheDraw was encoding them**.

What was left were some pretty neat ASCII fonts from the late 80’s / early 90’s. Created for use in emails and on old BBS systems, today it appears these fonts have mostly disappeared from the internet. After talking with Aaron, the only two sites that appear to host ANSI art font files are and, and in both cases you’ll need a special ANSI art viewer. Aaron told me he originally grabbed the font zip from ASCII Artist Roy/SAC’s web page (, but that site appears to have been shutdown a year ago. Roy/SAC does still have a deviantart page though, and you can see what his site used to look like at the internet archive (NSFW-ish).

With the fonts in hand, I decided the best thing I could do was convert them into FIGlet fonts so people could once again start using them. I created simple web-based FIGlet Editor to assist in the process, and ported over the fonts I felt looked best going from ANSI to FIGlet. Sadly this means I only ported over a hand full (10 total), since a lot of ANSI’s charm is in its color. Plus, even with the decoded files and my editor, it took a decent amount of time to make the fonts.

You can see what the ported over fonts look like in the screen shot below or you can browse the “ANSI FIGlet Fonts” section of TAAG and use them yourself. Later this week I’ll also add them to the figlet.js repo if you want to download the individual figlet files.

You can see what the originals look like on Roy/SAC’s old font page (internet archive link). At some point it might be interesting make something that would show the ANSI fonts as they once were, but for now I thought it’d be cool to at least provide a way to use some of them in a stripped down form.

More ANSI Art


* This is somewhat confusing because there’s an extended version of ASCII known as ANSI that was done by Microsoft. This leads me to believe that the name ANSI art was a mistake that wasn’t noticed until it was too late (plus “IBM Extended ASCII Art” doesn’t have much of a ring to it). Making this even more convoluted, Microsoft’s ANSI character extension was never standardized by ANSI, so it makes no sense to call it ANSI in the first place.
** TheDraw didn’t encode colors with ANSI escape codes.

2014.01.22 Edit: I updated the font screen shot to include all of the fonts instead of just 4.
2014.05.18 Update: Roy/SAC has recently relaunched his site and created a neat tool for working with fonts from TheDraw.

Random Updates for October

Over the last month I’ve done a lot of little updates. Now that the government is shutdown and I’m just hanging out at home, I figured I no longer had an excuse not to write them up.

If you let them build it, they will build it

I added the ability for users to submit presets to the Keyboard Layout Analyzer and the feature ended up being reasonably popular, with users creating and submitting lots of neat configurations. However, I was lazy in implementing the feature, and made it only partially automatic. Once a layout is submitted, I’m emailed the code I need to add to the config.htm file. This works out fine, since I only get about one or two submissions a week.

Since that feature worked out great, I decided to add a similar feature to the Text Color Fader, except instead of layouts, it was color presets… and oh did my laziness come back to bite me. It was originally setup to email me the code I needed to add after each submission, but after a week of getting 20-30 emails a day (and discovering that most submissions were just people testing out the submission feature), I realized I’d made a grave mistake. I went back and re-wrote it to include a proper admin panel and submission database. Now I just get a few emails a day and can easily approve/disapprove submissions. This approach definitely doesn’t scale, and with the number of presets growing daily, neither does the combobox I’m using on the front-end. However, I feel like I’ve bought myself time, and at the least there’s a neat color preset database that’s being compiled (users have submitted some very nice presets).

Ergodox Layout

When I originally overhauled the Keyboard Layout Analyzer, I put in support for different keyboard configurations – however, I never really showed this feature off. After getting a request to support the Ergodox layout, I knew I had an opportunity. I created a “key map” for it and uploaded it into the app. Within days users had submitted a number of nice alternative layouts for it, which was really cool to see.

The Years We Spend on YouTube

I read an interesting fact the other day. It stated that if you added up all of the views of Psy’s Gangnam Style, it would equate to over 13,000 years of human viewing time. I thought it was a pretty trippy concept, and since I’d sort of been looking for a reason to play with YouTube’s API, I thought it might be kind of cool to make a quick app around the idea.

You can see it in action here – Years Spent Watching YouTube.

Let me know if you have any suggestions for example videos.

Keyboard Layout Analyzer 3.0 Beta Release

I’m not completely done, there are still a hand full of new features I want to add, but I have a feeling that if I put off the update any longer, it’s never going to get posted up. So today I’m releasing the newest version of my Keyboard Layout Analyzer (KLA), which I’m dubbing version 3.0, since it’s the 3rd overhaul of the layout.


New features:

  • Analysis results can be shared.
  • Charts are interactive / contain hover effects.
  • There are more “Display” options in the various results sections.
  • You can turn on/off certain keyboard data in the individual results sections.
  • The heatmap uses a more realistic heatmap visualization, has a table of key stats, and I’ve re-added in the mouse over effect (the biggest complaint in my previous version was that I took this out).
  • Miscellaneous section has charts for each piece of data.
  • Layouts you create can be submitted.

The biggest change though is the UI. The main reason I created this version was because I thought it would be a fun project to get better familiar with AngularJS. MV* JavaScript libraries like Angular have taken off recently because they make maintaining, updating and reusing front-end code easier. I felt the code I wrote for version 2.0 of KLA got a little spaghetti-ish at points, so this really appealed to me.

To keep things short, I’ll go ahead and just cut to the chase: Angular lived up to its hype. It was great at giving structure to the app. The new KLA code base feels a lot more sane and the HTML is easy to follow. If you do front-end development, I’d highly recommend you try Angular out. If you need a starting point, has some great tutorial videos and Dan Wahlin has a really nice AngularJS Fundamentals video. And as a side note, even though Angular’s official documentation is good, I wouldn’t start there. I found it to be somewhat cryptic when I first started out. It’s a good reference point after you’ve gotten your feet wet though.

The only negative I came across with Angular was that it had a steep learning curve. I ended up having to back track a few times and re-do sections of the app because I didn’t do them the “Angular way”. Angular forces you re-think how to do certain actions and it uses some strange terminology, but once you get past all of that, it’s a pretty powerful tool.

Removing JK.js

My early days in JavaScript reminded me of an old puzzle game called The 7th Guest. In The 7th Guest, if you had trouble solving one of the puzzles, you could ask for a hint from the library. After getting 3 hints, the puzzle would be solved for you, but you’d miss the video that was shown after completing the puzzle, therefore missing a part of the game’s story. If you missed too many videos, you’d have no idea what was going on.

When I first started learning JavaScript, I kind of felt this way about third party libraries. I didn’t mind using ones that provided UI components, but I felt I’d be missing out on something if I used jQuery. So I wrote my own jQuery-like utility library called JK.js, which I used in my personal projects. However, I no longer feel like I’d be missing out on anything by implementing low level utility functions. What I really care about is writing an app, not a library. So as I’ve been refactoring my projects, I’ve been removing JK.js and replacing it with jQuery.


Bootstrap makes it easy to create nice looking web pages. I decided to use an awesome Bootstrap theme someone created called Flatly, though I tweaked the colors a little bit. I also used an image from as the background to make it feel a little livelier. However, while Flat is cool looking, I worry the result may be a little too flat, so at some point I may backtrack.


The charts in my previous KLA versions used a modified version of PlotKit. PlotKit was a good library, but it hasn’t been maintained in years. On top of that, my modifications to it used my own JS library JK.js, which I wanted to weed out, so I knew I needed a new chart library if I was to redesign this app. I decided upon jqPlot since it was jQuery-based and had a lot of great functionality. So far I’m pretty happy with it.


I came across a neat visualization library for heatmaps, so I decided to use that over the simple key-color heat maps I was creating before. Interestingly, the author of this library also has his own keyboard heatmap app. When I saw this I felt a little weird about using the library – but since the heatmap library was its own separate component, I figured it wouldn’t be too weird if I used it too.

Future Updates

I still a have more features I want to add, ones that will be more stat based, so hopefully there’ll be another update in the next 2 weeks or so. I also may update my Typing Speed Test to use this same type of layout (it’s in dire need of an update). If you have any feature requests let me know. Special thanks go out to Wayne D. for submitting a bunch of awesome ideas and feed back!

The Chrome Web Store Effect

It’s been about 5 months since I tried out Chrome’s Web Store for my Snake and Text to ASCII Art apps, and I figured I’d give an update on how putting them in Chrome’s Web Store has effected their usage.

My Snake game has sat around for about 4 years on this site, consistently getting an average of around 30-50 users a day. I originally wrote the game as a nostalgic tribute to my high school days, and it’s only undergone a hand full of updates since its initial inception. Since this site was getting around 6.5k visits a day, 50 visitors means the app was accounting for around 0.077% of the site’s total traffic. After placing the app in Chrome’s Web Store, the daily usage began to steady rise, and the app has recently been getting between 900-1,000 visitors a day on the weekdays:

Snake Stats

Holy crap, the Chrome Web Store is awesome! Even with the bagillion other Snake games listed in the store, traffic has gone through the roof, with daily usage up 2,000%! But what about the TAAG app, has it also seen such a meteoric rise in traffic? Interestingly, even though both the Snake app and TAAG app have a similar number of installs, TAAG hasn’t seen a noticeable rise in traffic:

TAAG Stats

Hrm, this is kind of interesting. My guess is that this discrepancy is caused by the following factors:

  • TAAG is a utility app and isn’t really something that’s used often.
  • There is a high volume of people trying out games in the Web Store (installing them, and then uninstalling them if they don’t like it).

It’s hard to be certain of what’s actually going on, but I found these results to be pretty interesting, so I figured I’d share. I had wondered if the Chrome Web Store would be a positive for web app developers, and so far, from my limited experience, it seems like could potentially be a big plus for web app developers, especially game developers.

Notes on Offline Web Storage for TAAG

After you’ve visited it at least once, the Text to ASCII Art Generator (TAAG) will now work even when you don’t have an internet connection. I had a user request this, so I figured I’d add it in for them and anyone else out there who may want to use the app offline.

Offline web applications are one of the new capabilities being introduced with HTML5. An offline web application has its files downloaded and permanently installed in a web browser’s application cache. This allows users to go to an app’s URL and have it work even when they aren’t online. It’s a smart idea, but it has some interesting pros and cons. In this entry I’ll detail what I did to set TAAG up to work offline, detail some issues I ran into, and provide some notes for anyone looking create an offline app.

The first step in creating an offline web application is to create a manifest file which tells the browser which files it should store in its application cache, which files should try getting from the network, and if offline, which files it should use in place of certain standard files. Any HTML files that reference this manifest will be implicitly added to the CACHE section of the manifest and after a user’s first visit, all cached data will come from the application cache, even if a user F5’s the page. The application cache is only ever updated when the manifest file is updated, and even then, it will take 2 visits for a user to see any updates. This is because when a user visits the app’s URL, the application will be read from the cache, it will then see the manifest has been updated, and it will then update the application cache for the user’s next visit. These idiosyncrasies are a bit to take in, but once you know what’s going on its not that bad. Here’s what a sample manifest file would look like:

# This is a comment.
# The cache is only ever refreshed when changed.
# Last updated: 2012.08.18

# The CACHE section indicates what we want cached.
# The HTML file linking to this manifest to auto-added to this list.

# The NETWORK section indicates which non-cached files should be 
# obtained from the network. This will almost always be "*".

# The fallback section allows us to setup "fallback" pages to use 
# when offline.
page2.htm page2-is-offline.htm

An HTML file linking to this manifest might look like this:

<html manifest="my.appcache">
<head><title>Test</title><meta charset="utf-8"></head>
<div>Some text</div>
<img src="one.jpg"/>
<img src="two.jpg"/>
<script src="jquery.js?12345"></script>

And one last gotcha – to keep the manifest file from being cached by the browser, and to ensure the manifest is served with the correct mime type (an incorrect mime type will keep the manifest from being recognized), we need to update the web server’s configuration. For Apache, we’d add the following rules to our .htaccess file:

AddType text/cache-manifest .appcache

<Files *.appcache>
    ExpiresActive On
    ExpiresDefault "access"

That should do it! With this technique your users will now be able to use your apps even when they don’t have an internet connection. I find this cool because it makes web apps more useful and puts them a step closer to supplanting Desktop apps. However, there are unfortunately a number of issues that have held offline web apps back, and they’re worth mentioning.

Issues with application caching

A lot of people aren’t happy with how application caching currently works. The W3C has set up a working group that’s discussing possible improvements, though hopefully the main components of the current spec will continue to work. However, I also feel like they need to make some changes too. Below I’ll list my biggest concerns.

  • How would users know that certain URLs still work when they’re offline?

    I don’t understand how this isn’t the most important issue for offline applications. Without someone manually telling you that you can use a particular application while offline, I don’t see how someone would think they could browse to and expect it to work when they didn’t have an internet connection. In their current form, I only see offline applications as useful to techies or people in the know.

    It’d be nice if offline applications could provide an icon, name, and description, and then browsers could show users which offline applications they had installed. It could be argued that this is a browser feature, but bookmarks are a browser feature too, and all browsers allow webpages to provide a favicon for bookmarking purposes. Whatever the case, there should be a way to let users know certain web pages/apps work offline.

    I’ve only seen this discussed once, and the people involved didn’t come to any conclusions, so I’m not too hopeful on this one. However, I think it’s probably the most important point, since no users = no usage.

    2012.09.01 Edit: Someone alerted me that there is a Widgets spec that’s currently in the works that supposed to solve this issue. I haven’t taken a good look through it yet, but it’s good to know there are attempts to solve this problem currently in the works.

  • Fresh updates aren’t served immediately / F5 doesn’t break the cache / the page that links to the manifest has to be cached.

    This seems to be the most popular feature request, though after reading spec author Hixie’s take on the issue, I sort of agree that many of the use-cases for using the application cache in this way are very similar to straight up HTTP caching. Though it would be nice if an app used the HTTP cache while online and this cache synced with the application cache, which would then be used when a user was offline.

    Around two months ago, a new feature was added to spec in an attempt to address this. It takes the form of a new setting that gets added to the manifest:


    It’s explained here, though there’s some debate on if its the right solution, and I was unable to get it to work in Chrome or the nightly FireFox build, so I’m not sure how it works or if it actually solves the problem.

Other Notes

  • Chrome was easier to work with than FireFox

    Chrome will print to the console as its loading the application into the cache, so you know instantly if there’s a problem or not. FireFox didn’t do this and that made it a bit more annoying to work with.

  • Listing installed applications

    • For Chrome, browse to the URL “chrome://appcache-internals/”
    • For FireFox, in the menu, go to: “Tools>Options>Advanced>Network” and see the section on “Offline Web Content and User Data”.

  • In the manifest, URLs need to be URL encoded and query strings needed to be included

    Kind of obvious, but worth mentioning.

  • The popular iframe trick doesn’t work in FireFox

    There is a popular trick that aims to allow an HTML page to use the application cache while not being cached itself. It attempts this by having the page include an iframe with an HTML tag that links to the manifest. From my own tests, this trick works in Chrome but not in FireFox.

    2012.09.10 Update: After updating to FireFox 15, it seems to work now.

  • JavaScript API

    I didn’t go into it here, but there’s also a JavaScript API for the application cache. See the “Additional Resources” section below for more information.

  • What would happen if every website wanted to work offline?

    The space on a user’s computer is finite. I’m not sure how offline storage will work if offline apps end up becoming very popular in the future. Maybe the solution is to focus on installable apps which have the option of working offline – and users can pick and choose what they want installed?

Additional Resources

Showdown Reboot

Comparing only Facebook-related data wasn’t that much fun, so I decided to soup-up the Social Media Showdown!* app to take into account sharing information from Google+, Pinterest, Twitter, StumbleUpon, Delicious, Digg, and LinkedIn. It’s now a lot more entertaining to see which side gets which trophies:

Thankfully all of the services mentioned have public APIs which make getting the share data a piece of cake. This handy Share Counts page details how to do it for all of the major APIs.

The only service I didn’t use the API for was Google+, and that’s because I sadly didn’t find that API page until I was about half done the reboot. Until recently, there was no way to read the number of +1’s a site had gotten, so clever people had found ways to parse that information out of the source code. I took this approach, but will go back and do it the more correct way later on.

Other than pitting sites against each other, this kind of data can be useful for creating your own share buttons or tracking the popularity of a website. It could also probably be used to answer some interesting questions – Are G+ users really more technical, or do they like cat pictures just as much as Facebook users? Are the different services used to share different kinds of information, or are they strict competitors? Does popularity on a particular service correlate with anything? Though for now I don’t see myself doing much else with these APIs.

The only other major change to the app was that I removed my custom built JavaScript library and replaced it with jQuery. For personal projects, I’ve tried to only use JS libraries for GUI components, since I was worried I’d be missing something if I relied too much on a library. However, I now feel pretty comfortable with the guts of JavaScript and the DOM, so writing my own utility functions seems a bit silly.

Over time I think jQuery has won out as my favorite all purpose library. Initially YUI blew me away, and I still think its an awesome library, but I’ve come to dislike the verboseness of its syntax. Anyway, I hope you find the updates to the app entertaining. Let me know if you have any suggestions/feature requests/etc!

* Formally known as “Website Showdown!”. I figured “Social Media Showdown!” made more sense.

TAAG Reboot

The HTML Frameset tag is officially obsolete in HTML5. Since their inception, frames have drawn the ire of many web designers, though I’ve always had a soft spot for them. When I first learned how to use the frameset tag back in ’98, I thought it was the coolest thing ever. I was able to do all sorts of trickery with it, like creating an online midi player and storing data between page loads. When I heard people go on about how they sucked, I ultimately knew they were right, but I felt like they were throwing the baby out with the bathwater.

Times have changed though, and as HTML has evolved, the gap framesets filled has been replaced by better technologies. Knowing their fate was sealed, I decided to overhaul the one app I had here that was still using them – the Text to ASCII Art Generator (TAAG)*. The new version was written from scratch, but with the aim to keep the same look-and-feel. This time around I also wanted to implement the full FIGfont spec, which surprisingly has a lot to it.

The main part of the spec that I didn’t implement last time was the vertical layout rules. These rules allow font authors to “smush” letters together vertically. Below you can see an example done in the “Standard” font.

  _____ _   _ _   _ 
 |  ___| | | | \ | |
 | |_  | | | |  \| |
 |  _| | |_| | |\  |
 |_/ _|_\___/|_|_\_|
  | |_| | | | '_ \  
  |  _| |_| | | | | 
  |_|  \__,_|_| |_| 

This can be fun to play around with, but it’s not always what you want. Therefore, I decided to also allow users to control which horizontal and vertical layouts they wanted a font to use. Exploring what layout looks best is actually kind of fun.

The other main part of the spec I left out last time was the loading of non-standard letters. Most fonts don’t implement characters outside the normal ASCII range, but the FIGlet spec allows authors to define whatever unicode character they want, and some fonts implement quite a few extra characters. For fun, I went ahead and added unicode character #3232 to a few of the fonts, so that people could make a FIGlet look of disapproval:

   _____)      _____)
  /_ ___/     /_ ___/
  / _ \       / _ \  
 | (_) |     | (_) | 
  \___/ _____ \___/  

I’m probably too easily amused. Anyway, there are quite a few other updates, but if you’re interested you can read about them here.

I’ve also decided to open source the JavaScript FIGlet driver I wrote for this app. There were no other open source full-spec implementations of FIGlet that I could find, so I figured it could be useful. If you’re interested, it can be found here or here.

If you have any suggestions for the app please let me know. Also, I haven’t forgotten about the Keyboard Layout Analyzer, so don’t think this reboot means I wont be adding any more to that.

Oh, and as a final side note, it was interesting to learn that frames can be a drag on the loading of page. The additional HTTP requests should make this obvious, but that combined with whatever else the browser has to do to accommodate them, makes for a non-optimal load time. And interestingly enough, even though the new app has a heavier page weight (190k vs 114k), it loads much, much quicker – though I should say that frames are definitely not the only factor to influencing this.

* It’s former name was “Text Ascii Art Generator”. I noticed some people calling it “Text to ASCII Art Generator” and thought that was a better name.

Keyboard Layout Analzer 2.0

On Sunday I uploaded the new version of the Keyboard Layout Analyzer. It has a plethora of new features and charts, and a new layout design. My goal was to create something that was more useful and easier on the eye.

Several key features are currently missing from the app (saving/loading of layouts, heatmap stats, etc), and I hope to have those finished within the next week or two. I’ll do a second post, when version 2.1 is released, to chronicle those features. I decided to launch the new app before I had finished everything because I was worried my to-do list would get too large, and I’d simply just never finish before moving onto another project (I have quite a few unfinished projects). Work is also about to get a little hectic in two weeks, so I figured it was best to launch while I had some extra time on my hands. Below is a list of what’s new in the app.

  • Resigned layout.
  • Code rewritten from scratch (mostly because I just wanted to start fresh).
  • New configuration keyboard that allows you to set finger placement, finger start positions, and modifier characters for each key. Also supports drag and drop for ease of use.
  • Drop down for loading sample texts (hopefully more to come soon).
  • Bar charts comparing fingers are now available for distance and finger usage. For row usage, a row usage bar chart is presented.
  • Distance traveled is now broken down by finger.
  • Distance, finger usage, and row usage are displayed by a selectable unit type (percent, key strokes, etc).
  • Stats on consecutive finger and hand usage have been added in.
  • An adjustable number of layouts can be compared.
  • New algorithm for determining the best layout.

Many of the new features are user driven. I received around 8 emails, and they were all extremely helpful in guiding the direction the app took – so thank you to everyone who gave feedback (even if I didn’t implement every idea – yet at least). Hopefully in another week or two I’ll do another update chronicling the remaining features.

Lastly, I had a request to keep the original version intact and available, and have decided to make it available here. If you use IE8 or below, you’ll automatically be redirected there anyway.