So when do you use the <i> versus the <em> tags?

Use <em> when you want to place emphasize on particular words within a sentence that would change the meaning of the sentence.  For example, these three sentences mean something slightly different …

Dogs are smart and likable.
Dogs are smart and likable.
Dogs are smart and likable.

And they are using <em> for the italics.

Use the <i> tag for general italicize text when you want to offset italicized text from the rest of the non-italicized text.  Or when text is in a different tone.

HTML5 W3C says to use <i> for text …

“in an alternate voice or mood, or otherwise offset from the normal prose in a manner indicating a different quality of text”

To convey importance, use <strong> instead of <em>.

See also the use of <b> and <strong>.

Well, in HTML5, the <b> tag is a perfectly legitimate tag to use.  And so is the <strong> tag.  So when to use <b> tag and when to use <strong>?

Both will bold text with appearance being the same.  However, the semantic meaning of the two are different.

Use <b> when you want bolded text for cosmetic reasons and when you do not intent to give the text any stronger weight in voice.   HTML5 W3C says to use <b> …

“for utilitarian purposes without conveying any extra importance and with no implication of an alternate voice or mood”

Use <strong> to give text a stronger voice along with a bolded appearance.

1.  respond.js

response.js is a lightweight polyfill which adds support only for min-width and max-width, which is what most people need anyways.  It adds support to IE6-8.   Available on github.

2. css3-mediaqueries.js

If you require more robust support for media queries, then use this one which does not require any additional comments in your media queries because it transparently parse, test, and apply CSS media queries for IE5+, Firefox 1+ and Safari 2.   Available on Google Code.

For example, the following written in the CSS stylesheet …

@media screen and (min-width:768px) {
   h1 { font-size: 2em; } 
}

means to apply the h1 CSS rule only if viewed on screen media that is greater than 768 pixels.

Or you can write the following in the link tag in the head of the HTML document …

<link rel="stylesheet" href="normal.css" media="screen and (min-width:768px)" />

Or can use it in an @import statement as in …

@import url("normal.css") screen and (min-width: 768px);

Device features that we can test for using media queries

Besides min-width, there is also max-width that we can test for.  In addition to “width”, we can also test for the following features (some of which accepts the ”min-” and “max-” prefix) …

• width
• height
• device-width
• device-height
• orientation
• aspect-ratio
• device-aspect-ratio
• color
• resolution

and others.

For example, we can write …

@media screen and (max-device-width: 480px) and (orientation: landscape) { ... }

Notable widths for media queries

When creating responsive web design, some notable widths to keep in mind when using such media queries are …

320px – typical width of smartphone in portrait mode

480px – typical width of smartphone in landscape mode

600 pixels – typical width of small tablets (Kindle and Nook) in portrait mode

768 pixels – typical width of 10 inch tablets such as the iPAD in portrait mode

1024 pixels – typical width of iPads in landscape mode, some laptops, netbooks, and desktops

1200 pixels – full widescreen displays that are typically only available on laptops and desktops.

This article was written in 2012, so these numbers may have changed as devices increase in resolution.

This is fine if the site is a fixed-width site.  Albeit, the text will be super tiny and the user will have to pinch to zoom in to read the parts they want to read.

However, if you are designing a responsive site that resizes and adapts to the width of the device, we should then apply the meta viewport tag.

A meta viewport tag such as …

<meta name=”viewport” content=”320″>

tells the mobile browser to draw on a canvas of 320 pixel rather than 1000 pixel.   We choose 320 pixels since our mobile device screen is 320 pixels.

The problem is that the site will not always be viewed on this device of 320 pixels wide.  Perhaps the user rotates the device to landscape mode and it become 480 pixels wide.  The site will be viewed by a whole bunch of other devices (ipad, tablets, laptops, desktops) that are capable of much more than 320 pixels.

So instead of a fixed number like 320, we write …

<meta name=”viewport” content=”width=device-width”>

Now the mobile browser will draw on a canvas with a width the same size as the width of the screen.

As that is the case, we can also specify that it performs no zooming by setting an initial-scale of 1.

<meta name=”viewport” content=”width=device-width, initial-scale=1.0″>

Like all meta tags, it should be in the head section of the HTML.

It can also be written equivalently as …

<meta name=”viewport” content=”initial-scale=1.0, width=device-width”>

Many people use Google Analytics to track their WordPress traffic stats and that is excellent.  But in order to use Google Analytics, you have to sign up with Google.  However, if you are building a WordPress site for a client who do not use Analytics, you would want a WordPress plugin that show traffic stats in the WordPress Dashboard instead of having to log into Google Analytics.

“WordPress.com Stats” is one such plugin that is created by Automattic, the makers of WordPress themselves.   You can install it on self-hosted WordPress sites. However, it requires you to sign up to WordPress.com and get an API key.   Although free, it sometimes can be difficult to get clients to do that.

So that best WordPress dashboard plugin that I found that monitor stats (and in real-time too) is WP SlimStat.  It has good traffic chart and world traffic map and many of the usual analytic stats similar to Google Analytics.

Alternatively, you can try Track That Stat which is similar to WP SlimStat.

To check on the performance issues, you can see the page load  time and its various components by using FireBug’s net tab.  Slow performance can be due to large image sizes, blocking scripts, content management systems, slow database, and slow web host.

1. Large image sizes can cause pages to be slow.

Before putting any images on the webpage, you need to optimize the size and quality of the image for the web.   What you want is to make the image have the smallest filesize as possible — less than 50KB is ideal.

This means using Photoshop or Firework to size the image down to the size that it is actually needed.   If you only need a 200 pixel wide image on your page, do not use an 2000 wide image (which is often the size that comes out of your camera) and just let the image tag width attribute resize the image.

Second, you want to decrease the quality slightly to reduce filesize.  It is often a trade-off between quality and filesize.  Image for the web does not need to be as high quality as images for print.  Again do this in Photoshop and Firework, and they will often indicate the estimated filesize per quality adjustment.

However, if your page has a lot of images, then even well optimized images can add up.  In that case, you can use advance techniques such as image sprites.  This technique lumps many images into one image in order to decrease number of server requests for images.

Although Flash content are not really images, you also want to check the filesize of your Flash swf files if you have any.   Sometimes Flash filesizes can be reduced by reducing the image sizes that the Flash is using.

2.  Blocking Scripts

When your site has a lot of scripts needed to do a lot of fancy things, it can add to the page load time.

Take a look at the types of scripts that are being loaded by each page.  Scripts can be calls to JQuery, Javascripts, YUI, mootools, etc.

Try putting the scripts at the bottom of the page instead of in the head if possible.  That way the page loads before loading the scripts.

If you are using JQuery script library, experiment with calling the JQuery library that is directly on Google’s free CDN (content developer network) instead of hosting the JQuery library on your own shared webhost server.    Sometimes Google’s CDN may be faster than your own webhost server, sometimes not.   It depends; so you have to experiment.

3.  Content Management Systems

If you are running a content management system such as WordPress, Joomla, Drupal, ExpressionEngine, and the like, they run an interpreted language called PHP.  The server has to parse and run PHP code.  This put additional overhead in page load times.

4. Slow Databases

Further, content management systems will be using a database on your server.  In fact, nearly each page load will be making one (and on occasions multiple) queries of the database.

If your database is on a shared web host where it services hundreds of websites, then the database can be overloaded.

5.  Slow Web Hosts

Shared web hosts are the least expensive category of webhost and they are entry-level web hosts.  They are the most common and most popular.   However there are some disadvantages of shared web hosts.  It is due to the fact that one server supports multiple websites — sometimes hundreds of sites. If the hosting company puts too many websites on one server, the performance of that server can degrade, causing your websites to load slowly.  If any website on that server experiences a huge traffic spike, it will affect performance for all the websites on that server, including yours.

Possible Remedies

If your own site is the one experiencing large traffic increases causing performance problems, it may be outgrowing the shared web host.  In that case, it may be time to upgrade to an higher category webhost.  The next step up is VPS, virtual private servers.   And the next step higher is dedicated servers.  However, there are advantages and disadvantages of upgrading to VPS as mentioned here.

It is an important decision and there is work involved in upgrading.  Before upgraded from a shared web host, you might want to try using caching technology if you are running a content management system.

Server-side caching helps eliminate the overhead of running PHP and querying the database and slow web hosts.   Instead of interpreting PHP and querying the database on every page load, it will generate static saved snapshots of those pages.   This will work great if your site does not have a lot of dynamic content.

In Joomla, make sure you turn on caching.  In WordPress, try installing WordPress SuperCache plugin.

There are two constraints that can limit the file upload size: 1) the code in the web application, and 2) the web host server configuration. The actual limit would be the lower of the two.

Setting Media Upload File Size in Joomla

If the web application is a content management system such as Joomla, then the administrator may be able to set the upload file size in the administrator settings. For Joomla 1.5, it would be in “Site -> Global Configuration -> System -> Media Settings -> Maximum Size”.

PHP Upload File Size

Linux web host server that runs PHP, has a PHP.ini configuration file. Among its configuration parameters are upload_max_filesize and the post_max_size. These can limit the maximum file size that can be uploaded to the server via a webpage regardless of the code of the webpage. So try fiddling with these two parameters in the php.ini file.

Note that there can be multiple locations where the php.ini configuration file exists. You may have to change it in more than one place. You can determine the values of the configuration file that are in effect, by placing a PHP file that displays phpinfo() at the desired location that you want to check. The phpinfo() display can also tell you the php.ini file location. Remember to remove this after checking.

The upload_max_filesize specifies the maximum size of the uploaded file.

The post_max_size sets the maximum size of posted data which affect the file upload site.

Because uploading large files require execution time, max_execution_time and max_input_time can also affect the upload. As can memory_limit.

Another parameter that might affect the upload is file_uploads. Make sure that parameter is set to be “1″.

Alternatives if unable to adjust Max limit of Upload File Size

Depending on the web host, some may not let you adjust the php.ini file settings. You can zip up the file to be uploaded and hope that the compressed size is smaller than the limit. Alternatively you can manually upload the file to the server using an FTP client. See tutorial on how to use the free FTP client FileZilla.

Aside from the Public group which is just your normal site visitor, Joomla has four user groups for access to the front-end: Registered, Author, Editor, and Publisher (listed in order from lowest authority to highest authority).  These users login via the front-end login form (which can be located in a hidden location).

Joomla has three user groups for access to the back-end administration: Manager, Administrator, and Super User (listed in order from lowest to highest authority).  These users login via the backend admin control panel access at for example: http://www.exmaple.com/administrator     These users can login via the front-end as well.  But when they do so, they have the authority of a front-end publisher.

User members are placed into one of these groups.  When they are done so, they get the authority of that group.   For example, users in the Registered group can not edit nor publish content, but they may have access to view restricted content.  Publishers have full authority over what content is shown in the site and full authority to edit any content.  Super User has the ability to basically do everything, including installation of plugins and system configurations.

Learn more about access control groups of Joomla 1.5 in this article on the Joomla forum.

With Joomla 1.6, you can unlimited user-defined groups and an user can be assigned to multiple groups.   If you install the Joomla sample data, you’ll get the user-defined group of “Shop Suppliers” and “Customer Group” for example.

Beside group, there are also Access Levels.  In Joomla 1.6, you can have unlimited user-defined access levels.  Whereas in Joomla 1.5 you have three fixed Access Levels (Public, Registered, Special).   Groups are assigned to Access Levels.

And then there are “Permissions” of which there are four: Not Set, Inherit, Deny, Allow.

See Joomla 1.6 tutorial on Access Control.

Joomla content are articles organized into Categories.  An article belongs in a Category.

Joomla Template and Module System

Joomla uses a template system that defines the look-and-feel of the skin of the front-end design of the website.

Learn how to customize templates with this tutorial linked here.

After setting the template, administrators can set and configure “modules” in the module slots of the layout.  Modules are like widgets with specialized functionality such as a login form, breadcrumbs, polls modules, random image, advertisements, latest news, popular articles, etc.

Functionality of Joomla can be extended via custom third party components, modules, and plugins.

Joomla Access Control Levels

Joomla has a very flexible and sophisticated access control system to has fine-grain control over the various access levels of various member. It has changed a bit from Joomla 1.5 to 1.6.

See article to learn more about Joomla Access Control Levels.

Joomla Features

Joomla has ability for search engine friendly URLs and caching built in.  It has URL redirection.  It also has ability to turn site offline for maintenance.  Joomla has support for multi-lingual sites.

Note:

Written in July 2011 and relevant to Joomla 1.6