As I was talking about on my personal site, I was looking forward to checking out TheAthletic.com to see how it how it stacks up to other Chicago sports sites. But, it’s me, so while reading and skimming, I started getting into the guts of the website to see if there were things they could do to increase their subscription conversion rate, usability, time on site, user retention, and search visibility. I was inspired after listening to the founders at 2016 NLDS Game 3
To preface, I really love the website, the content, the passion of the founders, and the direction this seems to be headed.
This is just to point out that your first site, whether for an online startup or a small or medium-sized business starting out – even if it is an online business, doesn’t have to be perfect.
As Cubs manager Joe Maddon would say, “Be present, not perfect.”
There are a couple things I’d like to see them clean up. The tweaks should increase conversion rates and improve indexability in search engines, which would give them even more of a fighting chance to keep the lights on and prosper. It’s just a teaching moment. These are just thoughts from a fan.
Here’s what I’d do:
From a UX perspective, I’d like them to fix the mobile header issues on the iPad
Many sites design for mobile and website and then assume the tablet will fall in line with one or the other. But tablets are their own beasts. Sometimes, the header bunches up, especially when there’s a lot up in it, as in the case here.
Now they’re probably not as concerned about this because their app is designed to handle mobile traffic, but I’m a non-subscriber without login credentials so downloading the app probably wouldn’t have helped. I was simply laying in bed after the game and wanted to take a look at the website. I pulled it up on my iPad and ran into this:
If I didn’t know about the site beforehand, I would still consider it a bit amateurish. Now this is coming from the guy who has his own mobile header issues on his personal site that he has to spend next weekend tweaking – probably while watching game 1 of the NLCS – but, that said, fixing the mobile / responsive issues in tablet model would definitely help the conversion rate. Not only could I not navigate the site, I wouldn’t have been able to subscribe nor would I have known there was a subscription available.
The mobile header menu fix in iPad
The way the code works for that mobile menu, they actual wrap an image of the menu within the anchor tag, but when you go to view it on my iPad, this hamburger menu image doesn’t load:
There’s not even a place in the code for it. I had to go pull it from the mobile phone browser designs in order to view the image and see how this was supposed to work.
To fix this issue, all they’d have to do is insert that image and subsequent coding in the id="menu-toggle"> anchor tag (A tag) found at: body > #wrapper > #topnav > .container > #nav-left > #mobile-suite-nav-button > #menu-toggle:
And it cleans this issue.
The content-stuck-under-the-header-on-the-Chicago-main-page fix
They way they built the site, presumably on Bootstrap 3 (haven’t looked to confirm), they used a added a “spacer” div class to act as padding to keep from getting stuck under the header and unreadable. Right now, it’s only set to a height of 24px. They could set it to 100px (80 for the header and the extra 20 to make it easier to read), and the content will slide out from under.
The teams’ main page categories also have header tweaks
Each page also has a logo-ed background header that doesn’t load in iPad mode. They’d have to manually insert those images like they have them for mobile and desktop or add them to the CSS as background images. Up to them. There’s only so many times I’m going to add the hamburger menu image back into the site just to navigate it and look around and be specific.
Then, they’d have to do mobile responsive stylesheet structures for the media queries
There are typically two ways to set up a style sheet so your present and future designers can keep track of the work:
- Media Queries: styling all elements by a width
- Element Queries: styling one element according to widths
The advantage of media queries is that you can go ahead and style up the sheet based on the chosen widths, and then divide styles into multiple, cleaner, more manageable sheets.
They breakdowns usually go according to size. Some say start mobile and work up. I say start desktop and work down because you need to know all the content you’ll need, and then starting Tetris-ing things into small containers. Once again, as Dr. Gregory House would say:
“When in doubt, plan broad.”
- The universal (desktop) styles: this is where you set your standard rules for desktops. The ones underneath are meant to modify those rules for different devices. You don’t even have to set the widths here. They’ll be the defaults. Old school.
- Tablet – 768px-1027px (I’ll even set on from 728px-1027px just to get the table mobile responsive running early)
- and then from there, it depends on how much shit you have in your menu. To break down for mobile devices, many set it to as low as 280, though setting no minimum works, too.
As of now, they have one universal sheet that the use media queries to style an element when they have to. The problem they’re starting to have is that whoever is CSSing it is setting min widths in the range to 768 for some rules and then setting 768 as the max width in other rules. This means that any time down the line, if any coder injects multiple rules within these margins, they could run into conflicts because a min rule for one will be the max for another. The tiebreaker in these rules will be the last one that loads, which in this case is the last one on their stylesheet, will typically take precedence – barring the coder puts ! important in the first and not the second and really putting in unnecessary loading time on the page.
Then there are a couple SEO things they’ll want to work on
Outside of the mobile header, the rest of this doesn’t impact the quality of the content. It just impacts the content’s online visibility.
Link architecture
Their indexed URLs in Google are coming out as:
https: //theathletic.com/?p=5587
Then they’re 301ing upon clicks to a structure such as:
https: //theathletic.com/5587/2016/03/23/what-to-watch-for-as-bulls-start-home-and-home-series-with-knicks/
This means:
- None of the keywords in the URL are helping with SEO.
- The content is nested 5 subdirectories deep. This tells search engines that the continent isn’t primary or important, like the all the other articles in the
/5587/2016/03/23/subdirectory. Your stuff should be.com/here/or-here-at-worst/. The rest are essentially superfluous, especially on new sites whose architecture wouldn’t be grandfathered into Google / Bing’s history like a TechCrunch.com
The optimal approach would be https://theathletic.com/what-to-watch-bulls-home-and-home-series-knicks/.
Even that would be too many words in the URL. You’d try to get it down to 5 words / 35 characters after the .com/, also remove those stop words “to,” and “and” (though, the phrase “home and home” would make an exception for that particular use of “and”) would help, but I haven’t read enough of their stuff to know how many times they’ve written an article on this specific topic. So, even a https://theathletic.com/bulls-home-and-home-knicks-2016-2017/ which is still a touch long, would still be optimal.
Then, they wouldn’t have to worry about redirects on any new articles going forward.
The CDN
They run a CDN, which is a good thing. It allows the site to load from more than one location, speeding up the page load. To do it optimally, you want your images to load from a location that, according to the search engines, is coming from your domain. Here are a few of the reasons why you would want this:
- The site gets credit for ownership of the images :
- The ownership leads to content authority :
- It increases visibility in image indexing :
- Allows for increased schema markup :
In their case, they’d want it at https://i.theatlantic.com/image-name or https://images.theatlantic.com/image-name or the like.
But, like with most sites on AWS, to have that feature is expensive. I’m speaking of one who still has an enterprise level CMS on AWS. It ain’t cheap. The problem is, now their images sit accordingly (unless they are a part of the theme):
https://s3-us-west-2.amazonaws.com/wp-media-theathletic-production/app/uploads/2016/06/06015726/sharma.png
In addition, their SSL cost would increase because they’d have to go with a WildCard SSL, which covers all the subdomains within a domain.
Minify content
The other thing, like the issue with my site at the moment, is that there’s too much whitespace in the content’s source behind the scenes. The same with the stylesheets. When one minify’s content, all the spaces in the code get removed, thereby shrinking the amount of content on the page. In some cases, that can be up to 25% of the pages. That means Search Engines and web browsers can load the page 25% faster. That improves rankings and indexability in search engines because Google loves speed.
I’d go deeper, but I haven’t read too many articles to see if they’ve done more stuff
Like schema markup and internal linking (think of how all the pages on WikiPedia essentially link back to each other – but not that obsessive). Didn’t much look at the metadata either – which can act like a rudder to navigate where you want the page to rank.
Chicago (or Toronto) sports fan? Go check out the site. It’s quite functional and has great content.
Like I said, I love TheAthletic.com website. Y’all will enjoy it. And, if I didn’t mention anything, y’all wouldn’t have noticed much of anything. Most first websites are like that. Some of my first websites are still up and I cringe every time I look at them. They’re bloated and bulky, but they got the job done.
So long as your website is present and functional, it won’t have to be perfect, today.
Tomorrow is always another day.