Responsive-Web-Design

Using The Ampersand With Compass

While much of working with Compass to generate the CSS for your site is straightforward, there are a few ways to use Compass the provide great power, but are not as easy to understand at first glance. This article discusses one such way, hopefully making it easier to understand.

The operator that we will be looking at first is the & operator. The & as part of a selector in Compass allows you to take the entire selector string at a higher nesting level than the & currently resides upon, and replace the & with that selector string. Typically, when this precedes a selector with a space between the & and the selector, it would operate normally as if the & were not present. However, if you remove the space, it allows you to select elements with multiple classes assigned to them as part of a single selector token.

Compass Makes Writing CSS Fun Again

One of the things that has always annoyed me about web development is that writing CSS generally becomes a task that has a major lack of the features that you would expect in a programming language, even one as simple as JavaScript. These features that would be wonderful to have when working with CSS are the ability to use variables to define a set of basic colors that are in use across the site in one place, and then use the variable name throughout the stylesheet.

Optimize Wide To Narrow

If you consider the path that a user takes through your website from landing page to successful conversion, you can think of the number of users that make it to each point along the way to a successful conversion as similarly shaped to that of a funnel. In a typical setup, you may have a very small percentage of your users make it to a successful conversion, but there are several areas along the way that either improve the chances the user will convert or decrease those chances.

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.

When Is Enough CSS Enough?

One of the major pushes in web development today is to try to do as much of the styling of a website as is possible from within the CSS of the site. The idea behind this is that when you do so, you remove styling responsibilities from your JavaScript and HTML content, resulting in a much better separation of concerns. The other aspect of this is that CSS styling is typically handled in a more native fashion in the browser as compared to what you can accomplish via Javascript.

The Easiest Way to Create A Solution That Works

The easiest way to create a solution that works…is to do it right the first time. Yes, this is a bit of a cop-out, but it turns out to be an important factor to keep in mind when you are tempted to come up with a quick and dirty solution for a problem that does not follow established best practices and is likely to have code quality issues later.

I have run across many sections of code that I or other developers have written in the past that we thought were “good enough” at the time it was written, yet, I was revisiting the code because we discovered a bug in it. Many times, this code had an issue that would have been trivial to fix at the time it was written, if it were only found. It seems that as a developer, we tend to find the least sufficient solution that will solve the immediate problem we are experiencing instead of finding an optimal solution that will be easily maintained months and years after it was written.

Estimating Software Development Projects is Hard

As a software developer, working with non-technical management and end users to define a deadline for when a project will be ready to use or how long it will take from start to end of a project is an extremely complex task. Unfortunately, the non-technical audience thinks that it should be simple to give some sort of estimation on the fly without detailed analysis of the project and what it involves, as it seems simple for them to estimate tasks that are like ones they have done before.

AddThis Can Cause Your Site To Not Load

Over the last few days, I have run across quite a few websites that seem to never finish loading. After waiting for 20 seconds or more, I give up, realizing that whatever content was on the site wasn’t worth it anymore for me to stare at a blank white browser until it loaded however much longer. Unfortunately for those websites, they are losing traffic that they will never get back.

== and === in JavaScript and HTML Input Elements

If you read any current information about best practices in JavaScript, you will typically find the following advice somewhere in the list of things to do.

Always use === and !== while avoiding == and !=

While I will never argue against this advice, there are a few things that a developer shoule realize when using === and !== instead of == and !=.

1. === and !== first do a check of the data type of the two objects you are comparing. JavaScript never forces you to explicitly define the datatype for an object you are creating as it will automatically assign one based on the contents of the object and how it was created.
2. The output of all of the Math functions produce integers or floats as the datatypes for the resultant numbers. For example, Math.floor(10.39438) will produce 10.
3. When retrieving the value of any select or input or textarea is always return as a string. This means that even though the value of the string may be a perfectly good number, it will never match a number data type. For example "10" is not equal to 10 when using the ===.

You should always use === and !== instead of == and !=, but you should make sure you understand the datatypes you are dealing with so that your comparison works as expected without any surprises at runtime.

Always URL Encode your Cookies

One of the things that you tend to forget about when dealing with websites that typically only cater to English-speaking visitors is how to properly deal with Unicode throughout the site. It turns out that some browsers handle Unicode support in different sections of the browser differently.

For instance, it turns out that when you want to store Unicode data as the value in a cookie, your success may vary across browsers. When I tested this with the Euro symbol, €, it worked without a hitch in Chrome, Safari, and Internet Explorer. However, in Firefox, it was stored as an empty string. In order to correct the issue, you can use encodeURI() on the Unicode character to get the ASCII version of the Unicode character, and then store that in the cookie. Fortunately, this seems to work without issue across all of the major browsers.

5 Ways To Do Responsive Web Design Poorly

Responsive Web Design is a website design methodology that seeks to adapt the way a website is displayed depending on the capabilities of the device that is displaying the site. Frequently Responsive Web Design is used solely to adapt to the screen resolution of various devices, but it has other applications that are yet to have full browser support, such as delivering smaller graphics automatically for low-bandwidth connections, etc. As with everything, some people do it well, while others, well, they do it poorly. Below, I show my Top 5 Ways to do Responsive Web Design Poorly.

Responsive Images with Picturefill 2.0

Responsive Web Design seems to be the way that the majority of websites will be developed in the near future. For a while, everyone was creating a separate website that catered to mobile devices in addition to the main website that desktop browsers were able to access. Web Developers and UX Designers quickly discovered that this was a less than ideal approach as it required maintaining two separate websites, and the mobile website tended to remove data that was visible on the desktop version of the site.

Mobile Web Development Is the New Internet Explorer 6

Developing a website that works well across devices and browsers is an excersize in playing Whack-A-Mole. Once you get one browser working on a desktop browser, you go to the next browser and find that not everything works the same way. In 2014, it seems that there aren’t that many differences in functionality between desktop browsers, but that all changes once you start making a responsive website that must handle mobile devices as well as it does desktop browsers.

Launching a Redesign of a Website

Over the last few months, I have been working on a major redesign of an existing Magento website. One of the major goals of the redesign was to take a legacy desktop-only website and upgrade it to take full advantage of Responsive Web Design so that customers could equally utilize mobile and desktop devices to browse and purchase products.

For a site that had seen only minor updates over the last 5 years, this redesign represented a major change visually and navigationally from the previous site. Based on the history of the site, the development team was optimistic that the redesign would be well-received, but were suprised by a few things that came up in the feedback we saw.