Back in May I wrote a post talking about trying to make my sites mobile friendly. I shared some links in that post where you can check to see if your sites are ready for mobile or if they need some work. I also had a few gripes in that post; that’s because no matter what I was reading, I just couldn’t figure things out.

At least my blogs were all fine, thanks to WP Touch. I use the free version because I don’t need all the bells and whistles that come with it, but it’s a fabulous program that helps WordPress blogs become mobile friendly. If you’re not using this and aren’t mobile friendly, it’s a plugin you need to check out.

For the rest of us… well, it’s basically taken me over 5 months to finally figure out what was going wrong with all that I’d been trying to do to get my sites mobile compliant, and when I finally figured it out, it turns out that the information wasn’t on any of the websites I’d been reading. So, I’m going to address some of what I discovered on my quest; some is on other sites, some isn’t, and some wasn’t explained fully. These won’t be in any particular order, but I’ll number them in case there’s some you already know and some you don’t.

1. Table coding structure

Do you see that code above in the image? All coders know that, except for a couple of enhancements, that’s the basic table coding structure for websites. This particular snippet is the code I use when I put images on my blog posts, whether they’re mine or whether I’m using the Compfight plugin, which finds free images that are allowed to be used via Flickr and Creative Commons.

Anyway, most websites use this structure to put their websites together, whether or not they also use CSS (cascading stylesheets). At least they use it as an initial basis because it’s stable and helps lock many elements into place.

The problem as it concerns mobile comes when you’re designating specific sizes that might be higher than what mobile will allow in general. I’m one of those anal types who usually set my initial tables at 90%, which means that my content would spread out over 90% of the space on someone’s monitor. I’ve always thought that helped things look pretty cool… but it turns out that it ends up fighting anything you try to do with mobile. It’s the reason this code I had found, meta name=viewport content=”width=device-width initial-scale=1″, wouldn’t work on any of my sites; ugh. What I decided to do was take out the width connected with my main tables. That helped a great deal… but there’s more (as always lol).

On some of my sites I was using the Google box ads. To make them format within my content I used the same table code.

On my medical billing site, the size of the menu on the left side and the size of the table in the content made the mobile version too big. I couldn’t shrink the size of the menu, so I had to remove the box code. That brought the pages on that site that I altered into compliance, and instead of fighting to keep the side box I switched to a different code… which I’ll come back to later.

On my main business site, I totally removed all secondary tables and went back to original coding instead, using the main table only and breaking the two columns up by using the

tag. I also altered the size of the two columns by making the width of the first td tag to 15% and the second one to 50%. I needed to go with the 65% because on that site I have two images up against each other, and they wouldn’t show properly if I reduced the size of the columns more.

2. Logo images

If you go to the page that talks about speed, it’ll recommend that you reduce the size of your images so they’ll load faster. What they don’t tell you is that you might need to reduce the width of your images as well for true mobile compliance.

On my medical billing site, the logo was 793 pixels; on my business site the combined size of the two images was around 850 pixels. That’s way bigger than the allowed size for the initial mobile size, thus you’ll never be mobile compliant that way. Although I loved the way the larger images looked, I knew I had to make a change.

For the medical billing site, I reduced the width of the image to 400 pixels. On my main browser it’s definitely smaller, but still looks pretty cool. On my business site, I went a totally different direction and changed the height to 100 pixels for both images. It reduced the size of them both enough so that they would be compliant. The only problem I have is that if you look at it on the phone lengthwise the first image sits on top of the other one but I can deal with that because one, I doubt many people will be looking it up on their phone (maybe the blog), but two, if they’re like me they’ll probably turn their phone sideways, where they line up properly.

3. Google code

If you read that previous post, you will have seen my little rant that one of the issues turns out to be Google’s own stupid code. The code size that always worked the best was the 728×90 ad, which one normally put at the top of a page. Well, that 728 is way too big for mobile phones, so it looked like Google wasn’t giving us a choice of what to do.

Turns out they had made a relatively recent change that I didn’t know about, that I learned of from Lisa Irby’s YouTube channel, where she was talking about responsive ads and how one of her friends had doubled his income since switching. I don’t know about all that, but what I discovered is that if you use the responsive ad, it alters its size based on where people are viewing it. So, if it’s on their home browser they’ll get a big ad, even bigger than the 728, and if it’s on the phone and people aren’t blocking those ads they’ll show up perfectly for them and as big as they’re allowed.

I tried this out on my medical billing site and it works wonders! However, remember earlier when I was talking about using the tables for the ads within my content? For some reason the responsive ads won’t work if confined, and the table made the overall size for the phones being viewed lengthwise that it took them out of compliance. What I’ve done instead is killed that side box and put a second responsive ad at the end of the content. Since I was only running two ads on each page, and hopefully people are reading all the way to the end of those articles… all should be good long term, and I’m still mobile compliant.

4. Viewport code

Remember that viewport code I shared above? I had a couple of pages where I was having trouble with it in that form. The Google insights page kept saying to use the code as given; forget that mess. Most of today’s smartphones will handle a width size of up to 525 pixels, so what I did was alter the code and make the width 500. I had seen this figure altered on a couple of pages I visited while trying to figure things out. However, what none of them did that I did was to leave the second part of that script in there, the initial-scale part. For some reason it helped bring everything together; I can’t explain it but it worked. 🙂

By making all these changes, my pages were suddenly mobile compliant; yay! That doesn’t mean they’re perfect by any means. If I put the code into the insights page, it keeps finding recommendations to make to try to get to 100%. However, the main thing we all want to achieve is compliance, since that’s the thing Google is penalizing some of us for, and these changes overcame that.

To think, it only took me 5 months! lol Hopefully, if you’ve run into any problems this will help you solve some of them. I still have a ways to go to get to all the pages on those two sites, and I have one more site where the coding was so intensive that I’m going to have to do something drastic with it… but at least I now know what needs to be done… and you do also. 😉