Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

How To Optimize Mobile-Only Websites

A few years ago, mobile devices were just used for phone calls. But nowadays, the traffic that our websites receive from smartphones just keeps increasing to a level that their importance cannot be denied anymore. And with new technologies and opportunities come new challenges and questions.

To make things easier, we are sharing here a list of questions and answers about how to optimize mobile-only versions of your websites, taking into account technical, user experience and SEO considerations.


Why would redirecting to a mobile version make sense?

Responsive web design presents several advantages when compared to creating a detached, alternative version just for your mobile users:

  • Maintenance can be simplified. Even when responsive websites can increase the level of complexity, only one website would have to be modified. Content-wise, all your contents would remain on just one place, making it easier to expand and update your site for both, regular users and mobile users.
  • SEO can be simplified. Presenting a single version of your website for all your users with (mostly) the same content avoids the hassle of notifying search engines about both versions, making clear which one is the main version and which one is the mobile-optimized version.
responsive design

However, even when responsive web design is probably the only trend that will survive in the not-so-distant future, creating a responsive web design instead of a mobile version may not be the best option under certain circumstances:

  • Budget constraints. Responsive designs require additional planning in advance and testing in a broad array of devices and screen resolutions, for all the kinds of content.
  • Outdated phones. If most of your users still rely on feature phones or old smartphones, but still do want to navigate a mobile version of your site, then you better make that version very lightweight and fast, specifically designed with simplicity and speed in mind.
  • Legacy code. If you already do have a mobile version in your website, or a website that would be very hard to turn into a responsive website, then working with your existing versions would make sense.
  • Context restrictions. The goals of your users while on the go may differ from the goals of other users accessing your website from a desktop computer. There are some additional interface and context restrictions as well: typing on a small touchscreen while walking down the street may render your web forms useless; reading on a tiny mobile screen may render your detailed, long pages overwhelming.

If you are under one of these previous scenarios, you will definitely want to keep using your separate mobile website version, and optimize it as much as possible so:

  • You will be serving easy-to-navigate content to your users.
  • It will be easy to discover for search engines.
  • Your mobile version won't compete with your original version, cannibalizing your search engine results.

Here is a list of frequently asked questions about how to optimize the performance of a standalone mobile version.


Should you display different content for mobile browsers in the same URL, or redirect them to a different, mobile-only URL?

There are two approaches to serve mobile optimized content to your site users: keeping them in the original URL but sending them different, mobile optimized content, or redirecting them to a different URL where they would find mobile optimized contents.

mobile URL redirection

The first approach has a SEO-related advantage: all links pointing to one of your mobile URLs will also pass their ranking to the main URLs, since both are the same.

However, this approach also has bigger risks as well. Issues with this configuration, like failing to tell apart your mobile users appropriately, may lead to search engines think that you are sending shallow content to all users, or creating a URL masking scheme.

There could be issues with your mobile users as well. Without the URL providing additional feedback about the version they are browsing, your users might be confused about thinking this is the only version of your website (if your "go to original version" link weren't very visible.)

That's why redirecting to a mobile-only URL still makes sense, as it can be technically easier to work with, pretty clear to understand, and very well organized. But you need to make sure such an URL is marked as just for mobile browsers, as an alternative version, so it won't compete with your regular URLs in search engine rankings.


Should you create different versions for feature phones and smartphones?

While smartphones boast not-so-tiny touchscreens and powerful processors, those old mobile phones out there, the so called feature phones, will lack enough screen real estate or processing power to deliver a good browsing experience in most websites.

The answer to this question depends on your business. Your browsing stats will be priceless for this purpose. Most stats tracking software will give you a detailed breakdown about the hardware that your visitors are using to navigate your site. If that list contains a decent percentage of old mobile phone users, then creating a version optimized for featured phones would make sense.

However, mobile phones are quickly evolving. It depends on your target market and on the country where your business is located, but chances are that feature phones will quickly disappear in favor of more powerful smartphones. And taking into account that the processing power of smartphones is coming closer to being little desktop computers, chances are that your future website design plans should consider only smartphone-optimized versions.

Feature phones vs. smartphones

At the end, this is what the other big web design trend of responsive design is already hinting: in a not-so-distant future, desktop versions and mobile phone versions would only be distinguished by the layout used to present information. In the meantime, a single alternative fast-loading and concise mobile version should suit the needs of all your mobile users.


How is a mobile URL marked as a mobile, alternative version?

Tagging mobile pages

Google recommends tagging pages with alternative versions following this approach:

  • The regular, original page should signal that there is a mobile-friendly version serving similar content.
  • The mobile-optimized versions should point at their related regular pages, marking them as the main, canonical pages.

Screen size is used to discriminate mobile phones, while the media type handheld is used to target feature phones. In the most common scenario where there's just a mobile-friendly version, these are the alternate link tags that you would include in your main, regular version:


 <link rel="alternate" media="only screen and (max-width: 640px)" href="http://www.mobileURLHere" />

<link rel="alternate" media="handheld" href="http://www.mobileURLHere" />

And this is the canonical link that you would include in the mobile version:


<link rel="canonical" href="http://www.mainURLHere" />

You can also tag mobile versions in your sitemap.xml as alternative versions. Each alternative mobile version should be associated to its related regular version, so the sitemap of your website would look like this:


<?xml version="1.0" encoding="UTF-8"?>

<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"

  xmlns:xhtml="http://www.w3.org/1999/xhtml">

<url>

<loc>http://www.mainURLHere</loc>

<xhtml:link

    rel="alternate"

    media="only screen and (max-width: 640px)"

    href="http://www.mobileURLHere" />

</url>

</urlset>

It is important to make sure you are redirecting exactly to the URL specified in these alternate tags, or you could be sending confusing information to the search engines, and you could even risk getting your website flagged as spam.


If there is no corresponding original page, where should a canonical tag inside the mobile version point to?

If your mobile site doesn't mirror your original site in full (that is, having a mobile-optimized page per each original page) then the quickest approach would also be the safest: small mobile websites can redirect all their pages to your main url in your original version, ensuring all of them pass pagerank to your main webpage.

canonical links

Take into account that, in an ideal case scenario, every single page of your main website should be having a mobile-optimized page. Other scenarios can lead to bookmarks that don't work as expected across different devices, or, as Google calls them, irrelevant redirects – unless your mobile version is specifically crafted to serve an optimum version considering your mobile users' context and market niche.


Update: in this official blog post titled Changes in rankings of smartphone search results Google updated what they consider an irrelevant redirection. According to this report, mobile-accessed pages without a mobile version available shouldn't redirect to your main mobile page, as that would be considered an irrelevant redirection. The recommended approach for pages without mobile versions is to lead the user to the original, non-mobile-optimized page.

Other than that, the recommended suboptimal approach according to Google is having a mobile-optimized page for every single of your regular pages (thus removing the risk of irrelevant redirections.) And the optimum recommended scenario would follow a fully responsive website approach, with a single version that would work nicely on all devices.


How can you detect mobile browsers to serve them different contents?

Mobile browsers identify themselves through their own user agents. By identifying their user agent you can send them different contents or redirect them to a new page.

You don't need to create a whole list of user agents by yourself. There are some scripts out there that would take care of that for you. Detectmobilebrowsers.com is an open-source mobile browser detection library that will do the trick, offering scripts in several different programming languages (Apache server scripts, Javascript, ASP, PHP, etc.)

detect mobile devices

Be careful with this tactic, though, since new mobile devices, not considered in this list, might eventually appear. There's a slim chance of your mobile detection script running outdated and classifying new devices into the wrong category. So make sure you keep updated detection rules as well.


Should Google's mobile crawler be considered in mobile browser redirection scripts?

Google has a Googlebot-mobile webcrawler, specifically dedicated to crawling mobile versions, which is completely independent from their regular Googlebot. So it would make sense that this crawler reached the mobile version of your website.

mobile website crawler

However, Googlebot-mobile presents itself using the user agent of regular, well-known smartphones. You don't need to discriminate Googlebot-mobile in your browser-detection scripts. Google warns that doing so can be flagged as URL cloaking, which would bring you a penalty from Google.



Server-side redirection or Javascript redirection?

There are a couple of different approaches when redirecting your mobile users to a different mobile version. You can perform the appropriate user agent checks on your visitor's web browser by using a Javascript redirection. Or you can go ahead with a server-side redirection, so your web server performs the browser agent checks (either directly on the server engine by using .htaccess rules, or in a server-side programming language, such as .NET, PHP, Ruby and so on.)

The problem with a Javascript redirection is that part of your original page needs to load before your mobile user is redirected to the appropriate version. On the other hand, a server-side redirection would leave the user agent checks and processing to the server itself, preventing your user from loading unnecessary content.

Javascript redirect
Server-side redirect

Taking into account that mobile users have limited bandwidth and processing power, server-side redirects are the preferred approach since they will be faster.


Permanent 301 redirect or temporary 302 redirect?

There are two main different types of server-side redirects that are triggered by specific HTTP response headers directly sent from the server:

  • A 301 redirection is a permanent redirection, indicating that the original URL doesn't matter anymore, so all queries should be redirected to the new URL.
  • A 302 redirection is a temporary redirection, just signalling that visits to the original URL are redirected to a new URL at the present time, but that this is a temporary situation expected to be reverted.

If you use response codes to redirect your mobile users to the appropriate, mobile version, in Google's own words:

For this purpose, it does not matter if the server redirects with an HTTP 301 or a 302 status code.

So it really doesn't matter what kind of redirection you are using to send your users to your mobile version.

Temporary 302 redirect

However, let's consider a worst case scenario: if some misconfiguration or glitch in the process is preventing both versions of your site from being understood the right way from a search engine's perspective, using a permanent 301 redirect from your regular version to your mobile version would send most or all your pagerank, traffic or users to your alternative, simpler, mobile-optimized version. Such a scenario would be a disaster for your SEO strategy.

That's why using a 302 temporary redirect pointing towards your mobile version is a better strategy in terms of risk prevention.


Should you include a vary HTTP header in mobile URLs?

Google mentions in its guidelines that, in case you use any kind of redirect, any redirecting webpage should also be outputting a Vary HTTP header to notify potential search engine crawlers that mobile crawling is also in order, since the page can lead to different results depending on the user agent used to browse it. This way, every mobile page would be crawled, and the structure of your site would be better understood.

Vary response header

This also holds true for websites using the same URL to serve optimized content for both, mobile users and regular users (dynamic serving.) In this case it can become even more important, as there wouldn't be any other way to tell the search engine spiders that a mobile version exists for the present page. You would also make sure that the mobile optimized version wouldn't be considered as masked content or as the main version related to this URL, since you would be announcing its existence through this header.

The Vary header should be sent indicating that the contents in that page can vary depending on the user-agent, so it should look this way:

Vary: User-Agent

Should you include a link to the original, regular version in your mobile-optimized version?

Definitely. Some users will still want to access the full contents of their main version if they feel that they are missing part of the content, or if they just have a smartphone powerful enough for regular browsing.

If your mobile-optimized version is simple and short enough (as it should be,) the link to the original article / normal version could be safely included at the bottom of the page: there wouldn't be any need to go to the regular version if the mobile version provided enough information by itself. Going to a normal version is rarely a decision taken in the first second.

link to normal version

Make sure to display this link to your main version in a very visible way, though. You really do want to make your users know there's still a different, potentially more complete and eye-catching version that they could visit if they wanted to. This becomes specially important if you are serving your mobile contents from the same URL, as the URL wouldn't offer any additional clue about the existence of a regular version.


Where should a link from the mobile version to the regular version exactly point?

In the ideal case of having a mobile website composed of a mobile page per each regular page, the links pointing to the regular versions from the mobile pages should precisely target their corresponding regular page, talking about the same subject and offering similar content.

However, things can be a little bit more complicated if your mobile website comprises just a subset of your whole regular site, which can still make sense to offer a simplified, more straightforward version of your contents to the specific market niche composed of your mobile visitors.

If there were no matching page, offering a link to the homepage of your website from its mobile version could seem like a good idea, since the homepage presents the most easy-to-access gateways to all your content.

link to mobile version

But that's not enough. Consider the following scenario: a user performs a specific search from his web phone, clicks a specific search result, and is then redirected to the homepage of your mobile version instead. This can be okay as long as your user appreciates the ease of navigation of your mobile version, and as long as he finds relevant information. But, what if he just wants the answer to his original, specific query, and thinks that his smartphone should be able to handle browsing the full, regular webpage? Giving him a link to your main homepage will feel like a burden.

That is why you should also offer a link to the page your mobile users were trying to reach before being redirected to the mobile version of your website. You can annotate the page where a redirection was started (for example, in a parameter, cookie or session variable.) Mobile users pleased by the ease of use of your mobile version would remain there with no problem. And mobile users wanting to reach the original contents that triggered their click in the search engine results would still have the option to view the original contents they were originally thinking about.


How to allow mobile users browse your regular version?

Mobile users should be redirected towards your mobile-optimized version. So when one of your mobile users prefers trying to navigate your full website using a powerful smartphone, and clicks a link to your regular version, how to prevent him being redirected back to the mobile version, and stuck in an endless loop?

One of the most straightforward approaches to solve this issue is to add an additional parameter to override this redirection for users who explicitly request to see full versions from their mobile phones. Just a query parameter appended to the target URL can be enough. The target, regular webpage would check for the existence of this parameter. If found, any redirection would be skipped this time, allowing your mobile user to navigate the regular version of your website.

Nevertheless, that might not be just enough. That same user could still want to keep navigating other regular sections of your website. If such parameter weren't kept, your user could be redirected back to a mobile version when clicking a new link.

So once a regular version is requested by including a parameter to override mobile browsing, this preference should be stored in a cookie for your user, or even just in a session variable. So your user won't have to worry about being redirected to your mobile version again.

If a cookie or session variable were set for that user, no regular page would redirect such specific mobile user.

storing mobile preferences

On the other hand, this user can still go back anytime to your mobile version, not by an automated redirect, but by pressing his “back” button on the web browser of his mobile phone. This is a rare scenario that might only happen if your user decides that the regular version is too much for his phone after explicitly requesting it, but being covered about this case is still worth for optimum user experience purposes.


What about redirecting desktop / regular users accessing your mobile version to your regular version?

This is what Google calls bidirectional redirects. It prevents your desktop users from landing on a mobile-optimized version, which in their large screens would look rather limited or empty, and thus, wouldn't create the appropriate first impression.

If you have an updated mobile agent detection, then bidirectional redirects can make sense. It is very strange that a desktop user would rather see the incomplete or limited mobile version instead of the full, original version of your website.

redirecting desktop users

Independently from that redirection for desktop users, some mobile phone users would still like to access your regular pages. Having a link offering to visit the normal version instead would come here into play.

The only catch about bidirectional redirects is that you need to make sure your code is working perfectly. If not, you could leave your users stuck in the wrong site version or in a redirection loop.


Are tablet browsers mobile browsers too?

Tablets have some points in common with mobile browsers: they provide their users with some mobility, not-so-big touchscreens, and less processing power than desktop computers.

However, most modern tablets already allow regular navigation in regular webpages with ease. Their processing power is enough to move normal webpages, and their screens (even the 7-inch ones) are big enough to provide good website readability.

That's why I suggest not treating tablets as mobile devices, and to exclude them from your user-agent detection scripts.

tablet users

Besides, it is still possible to redirect tablet users to your mobile version as well. This can make sense if your regular version is not so tablet-friendly (if it takes too long to load, if it features Flash content that won't work in iPads, or if it just targets a niche where you wouldn't include your tablet users.)

If you are using the user-agent-detection script previously mentioned, detectmobilebrowsers.com, you would just need to add the following code to the first regular expression to treat iPads, Kindle Fire, Playbooks and Android tablets as mobile devices as well:


|android|ipad|playbook|silk

How to kill Windows process automatically with a .BAT file

One of the easiest ways to speed up Windows is closing unnecessary taks and processes. That's why sometimes we want to kill many Windows programs / processes, but we do not want to disable neither manually nor forever. It could be a group of programs that we rarely use, but which require some system process running permanently. So when we turn on the computer with other task in mind, we don't want these unneeded processes consuming Windows resources continuously.

That's why we are going to create a batch file (.BAT) which with a double click on it will kill as many Windows processes as we want.

So let's open Windows Notepad (Shortcuts: "Start Menu / Run / Notepad" or "Windows Key + R / Notepad") and then typing:

TASKKILL /IM "process name" /F

Example:

TASKKILL /IM MSPAINT.EXE /F

"IM" lets us input the name of the Windows process to kill, and "/F" enforces such process closing action and kills them forcefully preventing confirmation prompts or hanged.

If we want to specify a group of programs to close, we should only repeat the previous line of code with each process name, inside the same file.

Example file:

TASKKILL /IM MSPAINT.EXE /F TASKKILL /IM NOTEPAD.EXE /F TASKKILL /IM CALC.EXE /F

Once this file is ready, we should keep it using File / Save as...

And after the name chosen for this file we should appen the .bat file extension. That's how we create a Batman file... well, no, a .BAT file (batch process).

To save a .bat file using notepad we have to change the file type, which is by default Text Files (*.txt), choosing All Files. This is very important. Otherwise, we would just creating a text document called "whatever.bat".txt, and that won't work.

Let's also pick the ANSI encoding type for this process kill bat file.

And finally, we click on the save button to store the file.

How to save a bat file

By default, this creates a file with an icon like this icon, depending on your own system icon configuration set.

Now, whenever we want to close every Windows process specified in the file, we only need to double click that file, and it will perform the automatic process killing for us.

Running a .BAT file is like running the Windows command prompt code to close all the processes, but these batch files perform all the necessary actions automatically, in no time.

We can also check a complete and detailed list of the values and parameters that we could add after "TASKKILL" just clicking in Start / Run (Windows + R), typing cmd (to run the Windows command prompt), and typing at this window: TASKKILL/?.

Running processes with .BAT

If we want to reopen every Windows process previously killed with our .BAT file, with no need to reboot Windows, we can automatically perform the reverse operation, creating another .BAT (same process as before) this way:

START "Name" "C:\...path.exe" START "Name" "C:\...path.exe" START "Name" "C:\...path.exe"

To specify the full path of the target program we can only use ASCII text, with no accents or other special characters.

Example:

START "Paint" "C:\WINDOWS\System32\mspaint.exe" START "Notepad" "C:\WINDOWS\notepad.exe" START "Calculadora" "C:\WINDOWS\System32\calc.exe"

NOTE: This trick to run or kill Windows process also works to create a .BAT file to automatically open our most used apps (using the "START" Windows command), and another .BAT to kill these programs (the TASKKILL command file).

Chrome Javascript experiments

When you mix a web browser that quickly handles Javascript (Chrome) with the features of the latest HTML and CSS versions plus advanced Javascript libraries, you can obtain Javascript based webpages that seem programmed in Flash ActionScript.

Still skeptical? Then check out these Chrome Javascript experiments site. I really like this Javascript balls experiment.

How to reorder MySQL table columns in MySQL databases

The data structure of any application is the hardest part to change. Nevertheless, new needs arise all the time, and so, adding new table columns to an existing MySQL database is a common task.

But what about reordering the table column order in MySQL after you have already created and added the new columns to an existing table? Doing so is an advisable procedure in order to keep together very related data fields in your MySQL table structure.

While I tend to perform many MySQL database management tasks using phpMyAdmin, I haven't found any phpMyAdmin feature to change the column order of an existing database. Fortunately, you just need to execute a very simple MySQL instruction to specify a new column order:

ALTER table `table_name`
       MODIFY COLUMN `column_name` your_data_type
       AFTER `other_column_name`

Just replace the following fields by your actual MySQL data:

  • table_name: the name of your MySQL table being modified.
  • column_name: the name of the MySQL table column that you want to reorder.
  • your_data_type: the MySQL data type of the data stored in the moved column, such as int, varchar(lenght), text, etc.
  • other_column_name: the column name that will be just before the new position of your reordered column.

A MySQL table column reorder example

Here is an example of an actual MySQL query to change the table column order. Let's say I want to move the column called "user_password" just after the "user_name" column to keep strongly related columns grouped:

reorder mysql table columns
ALTER table `registered_users`
       MODIFY COLUMN `user_password` varchar(25)
       AFTER `user_name`

This will reorder the columns in your current MySQL table structure, but it will not alter the row order of your table records: the stored data order will remain unaltered. Reorder MySQL table columns to visually group strongly related fields. So reordering is just a way of changing the column order of an existing MySQL table, and it won't modify your query performance.

Column reorder is mainly a matter of coherence and logical organization. On the contrary, altering the stored data order may optimize (or negatively impact) such MySQL query performance.

How to set MySQL auto increment in phpMyAdmin

A common practice in database design is to set primary keys (PKs) with auto increment enabled. This way, you don't have to worry about specifying a new unique primary key value each time you insert a new record in such table.

While phpMyAdmin is a very powerful and easy to use MySQL database management tool, "where could I set auto increment in phpMyAdmin" is still a frequent question. And here is the solution.

In the latest phpMyAdmin versions there is a new A_I Checkbox. Mark this option as enabled when creating or editing your primary key table column and that numeric field will automatically increment its value each time a new record is inserted.

Setting auto increment in phpMyAdmin

You can check that the auto increment property was successfully setup in the EXTRA column of the table column properties (after selecting a table, inside the structure tab). If the auto_increment text appears here, the configuration was successful.

In previous phpMyAdmin versions, auto_increment was an additional option inside the dropdown menu of the EXTRA category (the last column in the field creation menu). To access the "edit table field menu" you can click the pencil icon in the desired table field row, inside the Structure tab.

Anyway, you can always run an SQL command to update the auto increment status of the desired column by selecting the SQL tab and writing an SQL query like this one:

ALTER TABLE `table_name`
    CHANGE `pk_column_name` `pk_column_name`
           INT(key_length) NOT NULL AUTO_INCREMENT

Just replace "table_name" by the name of the current table being edited, "pk_column_name" by the column name of your primary key column and "key_length" by your integer primary key length (the default int length is 11).

You should also make sure that the auto incrementing field is in fact the primary key of the current table. You can reset the table primary key by clicking on the table key icon of the desired field row.

Take also into account that only one auto incrementing field may be specified in each MySQL table. Nevertheless, auto incrementing only makes sense when used with numeric primary keys, and only a primary key field may be specified for each MySQL table as well.

Finally, if you want to change the current Auto Increment Value (i.e.: to make your auto increment field start from a specific numeric value) just select the phpMyAdmin Operations tab, type in the AUTO_INCREMENT field the new starting value of your auto incrementing field, and you are ready to go.

XAMPP MySQL deactivated error

Installing XAMPP is a quick way to setup an Apache Server with PHP and a MySQL database.

But sometimes there's some kind of configuration error or bug that doesn't allow to start the MySQL service. Checking the status with the XAMPP control panel will display a message of "MySQL database DEACTIVATED".

How to fix the XAMPP MySQL deactivated bug

While I'm not sure about the causes of this error, there is a quick fix to activate MySQL in XAMPP following 2 simple steps.

  • First, try not to configure your MySQL database as a service. This is asked during the XAMPP installation. So don't select the checkbox of installing MySQL databases as a system service.
  • Second, create a basic configuration file for your new MySQL installation (you can do this automatically using Win MySQL admin).

Yes, there's an automated way to generate a basic config file for MySQL using tools installed by default in XAMPP. Just go to [XAMPP installation folder] / mysql / bin and run winmysqladmin.exe. Type a new username and password, and let the MySQL admin program generate the default mysql initialization file.

And that's it! A MySQL disabled as a Windows service, and a default configuration file with MySQL username and password defined should change your XAMPP SQL status from "MySQL database deactivated" to MySQL database ACTIVATED.

How to check that MySQL status is active

You can check the status of the MySQL databases opening the XAMPP control panel: MySQL should have a green running tag next to it.

Notice that I wouldn't keep using the Win MySQL Admin once you turned your MySQL service active: it's an old, discontinued application that seems to throw random Windows errors. But don't worry: just close the Win MySQL Admin window and keep using the built-in phpMyAdmin from the XAMPP default installation.

You can open the phpMyAdmin menu to check the active status of the MySQL databases from the XAMPP Apache main menu: start the Apache server, open the main server page using your web browser (just type "localhost" by default in your web browser address bar) and click the phpMyAdmin link to check that your MySQL databases are enabled.

I hope this helped you to activate your MySQL databases in XAMPP! Now, have a happy coding and local server testing!

HTML and CSS in emails: compatibility list of email clients

Probably you are familiar with this common scenario: you create a really well designed e-mail newsletter using your most advanced HTML and CSS skills, and then you find out that your recipient's email client is just breaking the whole email design and layout.

While sticking to a very simple plain text email would do the trick, you should not get rid of every HTML design element of your emails just because some mail clients are not compatible with specific CSS or HTML code. The key is to know which HTML and CSS features work on the main email clients.

This email compatibility list is a very useful resource, as it provides graphic examples of how a sample email would be rendered on popular email clients, and it's constantly updated to take into account the latest compatibility improvements of such e-mail clients.

At the present time, this list shows some interesting conclusions, such as that the Gmail mail client would only read inline CSS: Gmail ignores CSS included inside the head element, and removes CSS classes and ID's from the original HTML of the email.

By the way, if you are looking for a reliable free email client application, I would choose Mozilla Thunderbird.

Is there any HTML or CSS that works on any mail client?

So, how could we create appealing e-mails that would work on any e-mail client? The truth is that currently every main e-mail client supports HTML tables with inline background colors defined.

These tables would admit some background images in many e-mail clients. Images are very powerful when they are used to spice up the email body. But don't rely just on images: use elements that would degrade gracefully, so your HTML email would still be readable in any email client.

With no doubt, CSS is the future of HTML in terms of code maintenance and element positioning. But for sending HTML emails, it could be better to stick to a very simple (yet effective) HTML table based email content.

Reliable emails based on HTML tables

My advice is to use HTML tables in emails: most email clients will render the results flawlessly. And let's keep an eye on the compatibility list of CSS in email clients: the day of fully CSS based emails could be near.

Turn YouTube video quality into HD Youtube in 1 simple step

Did you know that just adding &fmt=18 at the end of a YouTube video URL will turn such video in a High Quality YouTube video?

Let's see an example of how a High Quality YouTube video URL looks like:

http://www.youtube.com/watch?v=W6nppcKOYGo&fmt=18

And that's all! It is that simple.

YouTube video quality in detail: quality comparison

Let's take a closer look inside the two different YouTube video formats and see how much improvement you can obtain adding just &fmt=18:

Normal quality YouTube video:

  • Video format: Flash Video (.flv).
  • Video codec: FLV1.
  • Frames per second: 15 fps.
  • Video resolution: 320 x 240 pixels.
  • Video audio: MP3 at 22050 Hz.

High quality YouTube video:

  • Video format: MPEG-4 (.mp4).
  • Video codec: AVC1.
  • Frames per second: 29.97 fps (as NTSC).
  • Video resolution: 480 x 360 pixels (50% higher!).
  • Video audio: MP3 at 44100 Hz, 2 channels, 1411 kbps.

The High Quality YouTube video is approximately double the size in MegaBytes of the normal quality video. But the video quality improvement is worth the effort: the new video has bigger screen dimensions and much better video bitrate (and thus, much less video compression artifacts).

Flash video is the best format to optimize bandwidth, but the other YouTube MPEG-4 video codec is doing a great job keeping the quality high.

See it by yourself! Here is a normal quality YouTube video, and this is the same YouTube video in High Quality.

Unfortunately, this trick won't work to embed High Quality YouTube video in an external site. The good news are that our old tricks to embed HD Flash video still work.

Nevertheless, it seems that YouTube is taking advantage of the fast modern networks too, and this &fmt=18 is a big step towards an HD YouTube!.

Flash video bandwidth saving tricks: scale video size

It's great to have high quality Flash videos embedded in your site, but keep in mind that each time a good quality video is downloaded, it consumes a lot of bandwidth. You can eventually get an annoying message of bandwidth limit exceeded, which would either make your server unavailable during the rest of the month, or cost you an additional fee according to the bandwidth quota exceeded.

The idea is to achieve an appropriate balance between the video quality (the amount of video compression) and the total video file size in bytes (the total amount of bandwidth consumed by a full video download).

The trick is to create a Flash video file with an average bitrate and small screen size. Then, scale the Flash video size when embedding the video on your website.

Flash video: scale size to save bandwidth

These are the steps that you should follow to save video bandwidth while keeping the embedded Flash video quality high:

  • Convert your video to Flash Video (.FLV) using a video bandwidth around 400 kbps.
  • Reduce the video size of the .FLV file. The screen dimensions of the .FLV video can be as little as the desired video dimensions divided by 1.25.
  • Specify the desired Flash video dimensions (not the real, reduced .FLV video size) as the video dimensions when embedding your video in your webpage. Here are some tips on configuring the playback controls to embed high quality Flash videos.

And that's it. The 2 main ideas of this trick are just so simple and effective:

  • Use an average streaming bandwidth on a small video to achieve a good compression quality.
  • Don't use the original dimensions of your Flash video: scale size to match the desired video size.

Modern networks can play a Flash video of 400 kbps in real-time streaming or with little preload time. The video quality will be kept high as well, because the real screen dimensions of the video are small. With such a good compression quality you will have little artifacts on your Flash video. You will even keep the video subtitles and other video texts clearly readable.

On the other hand, the distortion of the scaled video is less annoying than the compression artifacts. Just don't scale your video size more than a 125% of the real video size, or you could start getting too much pixelation.

The result is a Flash video of the desired screen dimensions with little compression artifacts: a good quality video with optimized video bandwidth.

Video in Blogger: embed Flash video and a Flash Video Player

Videos can be an awesome kind of content to include in your blog. Embedding YouTube videos in Blogger is very easy. However, using YouTube videos has some drawbacks:

  • The actual resolution of YouTube videos is limited to 320 x 240 pixels.
  • The video suffers from strong compression (limited to 250 kbps).
  • The YouTube watermark may overlap your video.
  • The customization of the video playback controls is limited.

The FLV video format (Flash Video) offers a great amount of compression while keeping the video quality high. So I would really suggest you to create your own Flash Videos in this FLV format, host these videos on your own webserver, and then embed the FLV video in Blogger. Follow these steps to embed high-quality videos in your blog:

How to embed FLV videos in Blogger

Step 1 - Convert your video into FLV format

The first step is to convert your video into FLV format. Adobe Flash Editor has an Import Video function that quickly converts the original video into FLV. Nevertheless, the Flash IDE is an expensive application, so I would suggest you to use some free video encoder to turn your original video file (.avi, .mpg, .mov, ...) into FLV.

SUPER would be my FLV video encoder of choice.

Convert your video into Flash Video and upload the resulting .FLV file to your server. Just be careful with your bandwith quota, as video content may be rather heavy.


Step 2 - Create the playback controls

Once you have a FLV video, you will need to create the playback controls, so you can play, stop and pause the video, see how much video has been preloaded, control the video volume and so on.


Flash can also create some video playback controls, but they won't be much useful, as you cannot use an absolute path to link to Flash video controls. So you cannot embed the Flash video controls directly on your blog, because you won't be able to link to the original SWF file containing the playback controls.

The solution is to use an open source FLV video player. I would recommend you to use the OS FLV Player, which is a truly open source, customizable and reliable FLV video player. And you don't need even to have the Flash Editor to use this module. You will just need to upload the file with the playing controls to your server (player.swf).

I will teach you how to configure OS FLV in the following step, so it will be easy to embed this video player in Blogger.


Step 3 - Add it to Blogger: Embed Flash Video

OS FLV Player provides some php scripts that automatically create the HTML code to embed the FLV video on your webpage. But, since we are going to host the video playback controls, as well as the FLV video on a webserver that is not in the same domain as Blogger, we will need to embed the video in Blogger by hand. This is the code that you should embed on your Blogger post to include the video:

<object width="[Width of your video]" height="[Height of your video]" id="flvPlayer">
   <param name="movie" value="[Absolute path to player.swf]" />
   <param name="FlashVars" value="&movie=[Absolute path to your .FLV video]">
   <embed src="[Absolute path to player.swf]" flashvars="&movie=[Absolute path to your .FLV video]" width="[Width of your video]" height="[Height of your video]" type="application/x-shockwave-flash">    </embed>
</object>

Just change the following parameters:

  • Use the same width and height values that your .FLV video.
  • The absolute path to the SWF file with the OS FLV playback controls (example: http://www.mydomain.com/player.swf).
  • The absolute path to your FLV video file (example: http://www.mydomain.com/myVideo.flv).

Step 4 - Customizing the video player in your blog

You may want to adjust the look and feel of your playback controls in order to make the embedded Flash video match the style of your blog. As the OS FLV Player is an open source player, you could edit the source .FLA file by yourself (player.fla), creating a new skin for the Flash controls. However, you will need the Flash IDE to edit this source file.

There is also a very simple way to customize the colors of the elements inside the video playback controller just by tweaking a couple of parameters. Here is the sample code:

<object width="640" height="480" id="flvPlayer">
   <param name="movie" value="http://www.mydomain.com/player.swf" />
   <param name="FlashVars" value="&movie=http://mydomain.com/myVideo.flv&fgcolor=0x333333&bgcolor=0x999999">
   <embed src="http://www.mydomain.com/player.swf" flashvars="&movie=http://mydomain.com/myVideo.flv&fgcolor=0x333333&bgcolor=0x999999" width="640" height="480" type="application/x-shockwave-flash">    </embed>
</object>

The parameters that you should adjust are the following:

  • The foreground color (fgcolor, set to 333333 in the example).
  • The background color (bgcolor, set to 999999 in the example).

Conclusions

It's easy to embed your FLV videos in Blogger. You just need to convert your videos into FLV files and embed an open source video player. This technique offers many benefits:

  • You can embed high-resolution video in your blog.
  • As you control the compression, you can embed high-quality Flash videos.
  • You can get rid of third-party watermarks in your FLV videos.
  • The appearance of the video playback controls is fully customizable, so it can match the look and feel of your blog.

Take advantage of these techniques and start embedding high-quality video content in your blog!