Responsive Web Design – 7 Helpful Tips

Responsive Web Design (RWD) is the most common, industry-standard term for designing websites so they work well on mobile devices (cell phones) and desktop computers and anything in between. The website will scale to the size of the browser window on which the site is being viewed. Utilizing CSS3 media queries (@media) is the most common method of making a site responsive (scalable).

Here are some general principles and technical considerations you should make when creating a site with or converted a site to responsive design:

  1. Flexibility
    A common design concept is called “mobile first” meaning you should design your site first for mobile devices then alter the design for desktop browser sizes. The assumption with mobile first being that due to the increasing number of people who will be viewing the site on a phone and possibly only on a phone, it’s best to take that into account first. In principle this makes sense, however, a better practice is to design with fluidity or flexibility in mind regardless of whether you’re designing mobile first or desktop first. You should always plan for how it will look on various screen sizes and include this planning in your wireframes/mockups.
  2. Break-points
    The common three size ranges (or break-points) used in RWD CSS media queries are:

    • Mobile size range:
      @media (max-width: 480px) { …CSS goes here… }
    • Tablet size range:
      @media (min-width: 481px) and (max-width: 1199px) { …CSS goes here… }
    • Desktop size range:
      @media (min-width: 1200px) { …CSS goes here… }
    • Regardless of the standard break-points, you should always put in break-points to suit your content. If your content is flexible throughout, you may not need any. If your content looks awkward when the screen is around 700px, then an additional break-point may need to be added there. Set your break-points and style to what works for your content, not necessarily what might be the most common size ranges.
  3. Container Max-Width should Equal Desktop Break-point Media Query
    The container max-width on your site should be equal to the desktop size range (break-point) min-width value in that media query. In other words, if your container has a maximum width of 960px, then the break-point is @media (min-width: 960px). When the container has a maximum width in pixels, it makes no sense to make the desktop break-point smaller or larger than it. If it’s smaller than the container, then the container won’t fit and your site will have a horizontal scrollbar. If it’s larger than the container, then the container will have already locked out at the smaller size. It could be relevant if there was some other change — like font-size — occurring in a larger media query range, however, since most media queries adjust structural elements, then a desktop media query with a min-width larger than the container’s max-width is not likely to make a difference.
  4. Include Meta Viewport
    To ensure your site works and scales properly on iDevices (Apple iPads and iPhones), don’t forget to include this meta tag in the HTML head tag area on all your responsive web pages (note that you can customize the values here if necessary):
    <meta name=”viewport” content=”width=device-width, initial-scale=1.0, user-scalable=yes”> 
  5. Remove Width and Height Attributes for Img Tags
    For all img tags in the HTML, remove the width and height attributes in the HTML. Those attributes override the CSS and your images can’t be made to scale if those attributes are in there and set to pixel sizes.
  6. Set Max-Width for Images in the CSS
    In the CSS, create a tag selector to set the images to a max-width of 100%, otherwise they may scale to larger sizes than they were optimized for and pixelate. The selector would go in your general selector area and look like this:
    img { max-width: 100% }
  7. Media Queries from Smallest to Largest Ranges
    While this is not a requirement, it’s more common (though not necessarily industry-standard) to put your media queries in order in your CSS from smallest range (mobile break-point) first followed by the increasing size ranges, ending with the largest (usually the desktop break-point). There are Javascript programs written to target CSS media queries, and Javascript programmers indicate that smallest range first is preferable. Since the ranges don’t often overlap, it doesn’t matter what order they are in for the purposes of the browser, then it’s best to follow this common concept. Also, it’s important to always put your media query CSS below your general CSS (which should be below your reset CSS), because the media queries can often override the general style. This is a requirement. Bear in mind, that if the ranges do overlap (nothing beats the confusion of doing this!) then order may matter.

Making WordPress Testimonial Posting Easy with Word

If you are working with clients or customers and you want to make it easy for them to upload a blog post to your WordPress site, there are useful plugins that can help you do this. However, perhaps the easiest way is to have them do it in Microsoft Word.

 

You may have been in this scenario before: you just did work for a client who was pleased or you had a satisfied customer who you think will provide a written comment about your product. This is the perfect opportunity for a testimonial that you could put on your WordPress site or blog. You could just ask your client or customer to send you a comment by email and post it yourself, but that direct approach may seem awkward. Also, having them use a WordPress plugin interface to post it themselves requires some explanation and carries with it a learning curve.

 

Instead, you could send them a Word document that already has all your blog information in it and let them fill in the blanks, then publish it to your WordPress site themselves. Apart from writing the testimonial, the process of publishing it requires two steps and takes less than 10 seconds. Here are the steps to setting this up:

 

First, in WordPress:

 

  1. In the Dashboard admin panel, create a new user (Users -> Add New). Give this user a generic name, like Testimonial. Set their role to Author and give this user your own email address. A role of Author gives them limited access to your WordPress site if they somehow determine the password through Word.
  2. You’ll need to give the user a password, but make it something you don’t use for anything else (or anything important). It’s possible for someone to learn your password through the Word document you’ll create later, so it’s best to make it something that can be changed easily.
  3. Under Settings -> Writing, be sure to turn on (check the box next to) XML-RPC (remote publishing). This feature is enabled by default in WordPress versions 3.5 and above.
  4. Optionally, if you haven’t already, create a category (Posts -> Category) for your testimonials (something like testimonial makes sense).

 

The rest of the steps are in Microsoft Word:

 

  1. Create a new Blog Post document (File -> New -> Blog post).
  2. You’ll be asked to include your Blog Post URL (WordPress Web address) followed by a /xmlrpc.php.
  3. Put in the Author user name (the user example name here is Testimonial from step 1 above).
  4. Put in the password you created from step 2 above.
  5. Check Remember password. This will allow you to save the password as part of the Word document, so you won’t have to have your client or customer put that information in.
  6. The Word Blog Post document then comes up. You can make it very easy for your client/customer to fill out a testimonial by including the instructions on how to do it as part of the document.
  7. Be sure to provide them with a category. To do that click the button Insert Category — it’s the third one from the left on the main ribbon in the Word document (see the image below). The category you give them should be relevant to their post so it isn’t just published to the generic Uncategorized category in WordPress. This is a category you created previously, or the one you created in step 4 above.
  8. Here’s an example of the Word Blog Post document interface with the instructional testimonial text for your client to fill out — feel free to use any of the wording that makes sense for your purposes (click to enlarge the image below):

 

Word to WordPress Testimonials

 

  1. After you’re finished editing the document, save it with an appropriate file name. Avoid spaces in the file name if you plan to email it. A name like testimonial.docx is a good choice.
  2. Finally, send your client/customer this document. Ask them to fill it in and click Publish (first button on the main Blog Post ribbon) when they are finished. That’s it.

 

You can send this same document out to as many clients or customers as you’d like to solicit testimonials. Since you haven’t given them the password — it’s encrypted in the Word document — it’s also more secure for you.

 

In case someone tries to abuse this Author role later (for example, by spamming your site), you can just change the password or delete the user.

 

By using Word to solicit testimonials from clients or customers, you can make it easy and fast for them and easy and secure for you.

 

Check out this WPMU.org article for more specifics about this process with Word — their article inspired this post.

 

Greg Kerr is a Web design instructor and faculty mentor at Portland Community College.