Google To Begin Rewarding Mobile-Friendly Websites

Google recently announced that beginning April 21, 2015, they would start slightly rewarding websites that are mobile-friendly at the expense of sites that are not. There are several things that Google looks at to determine whether or not a site is easy for a user on a mobile device to view and navigate. Some of the things that Google looks for include the following:

  1. Fonts that are big enough to be legible
  2. Users don’t have to scroll left and right to see content
  3. Links are big enough and have enough space around them to be clickable with a touch of a finger.
  4. Avoids technologies that are not present on mobile devices, like Flash.

If you make sure that you follow the above guidelines, your site will be prepared for the upcoming change in Google’s search results. To find out more, check out Google’s blog post.

Related Posts

Jun 11, 2014
2 minutes

Defensive Development Failure

In the past, I have argued that devensive development is a useful tool to ensure unexpected exceptions are not introduced into a piece of software as well as ensuring that the error conditions are handled in an appropriate manner. Unfortunately, if defensive development is implemented poorly, it achieves none of its goals and can cause errors and exceptions to occur. One example that I found while reviewing some code recently is below:

Jun 2, 2014
2 minutes

Defensive Development - Fail Fast or Go Home

Defensive Development is a programming practice that is frequently misunderstood, but is nevertheless a critical practice to follow when working in many environments. I have seen articles written that argue that defensive development simply causes nonsensical null checks to be written, and as a result of seeing people writing bad code defensively, argues that no one should practice defensive development. There are other articles that, like many things in software development, argue that you should always use defensive development for everything.

Mar 12, 2015
3 minutes

The Number 1 Cause of the Not Invented Here Syndrome

One of the quickest ways to get a new internal tool bootstrapped is to utilize an existing design, making slight adjustments to ensure the design matches the requirements of the current project. Instead of using another internal tool as the basis for the new design, I used a design that was purchased specifically for this project.

This particular design was unique in that there were multiple working examples using AJAX, pure HTML, and AngularJS. While it was nice having supposed working examples, when you start to look at the readme file for how to get this functionality working on your own hosting setup, thats when the niceties disappear. Specifically when lookng at the readme file for AngularJS, it effectively says: “Because this is a well-known JavaScript framework, we are not including any documentation for how it works or how to get started with our design”. Granted, the inner workings of AngularJS need not be covered in the readme, but a simple walkthrough of what to expect this design to do would make things much more user/developer friendly.