微軟在 SQL Server 2005 Service Pack 2 推出的時候也釋出了一套免費的 Performance Dashboard Reports 自訂報表，透過此報表可以很輕易的分析出整台 SQL Server 的執行效能，是一個非常非常實用的效能分析工具，幾乎是每位 DBA 必備的工具之一，可惜的是到了 SQL Server 2008 之後就不再更新，以致於無法正常安裝到 SQL Server 2008 之後的版本，本文章將說明正確的安裝步驟，讓此報表也能夠在 SQL Server 2008 上正確執行。

在我們下載完 SQL Server 2005 Performance Dashboard Reports 之後，直接點擊 *.msi 檔進行安裝，安裝到選取安裝路徑時，請記得要選取正確的 SQL Server 2008 的安裝目錄才行，如下圖示請點選 Browse 按鈕：

然後預設的安裝路徑為 C:\Program Files (x86)\Microsoft SQL Server\90\Tools\PerformanceDashboard\ 我們只要把該路徑的 90 修改成 100 即是 SQL Server 2008 的預設安裝路徑，不過其實安裝在哪裡都沒什麼關係，因為之後報表還是需要被手動載入，但基本上我不會亂裝到其他的路徑：

安裝完後在安裝目錄下會看見一個 setup.sql 指令檔，這個指令檔必須手動到 SQL Server 執行，才會在 msdb 資料庫建立起 Performance Dashboard Reports 所需的函數與預存程序：

若在 SQL Server 2005 資料庫伺服器執行這個指令檔 ( Service Pack 2 以後的更新 ) 並不會有任何問題，但是在 SQL Server 2008 的資料庫伺服器就會遇到以下錯誤：

    Msg 207, Level 16, State 1, Procedure usp_Main_GetCPUHistory, Line 6
無效的資料行名稱 ‘cpu_ticks_in_ms’。
Msg 15151, Level 16, State 1, Line 1
無法 尋找 物件 ‘usp_Main_GetCPUHistory’，因為它不存在或您沒有權限。

這個錯誤的主因出在於原本在 SQL Server 2005 裡有個 DMV (Dynamic Management Views) 叫做 sys.dm_os_sys_info，在這個版本的 DMV 有個 cpu_ticks_in_ms 欄位，但在 SQL Server 2008 之後的版本該欄位被修改成 ms_ticks，所以你必須手動修改 setup.sql 指令檔，在 第 218 行的地方將該欄位修正，修正後重新執行一次就可以建立完成。

接著就是利用 Management Studio 從伺服器層級開啟自訂報表，如下圖示：

然後切換至 Performance Dashboard Reports 的安裝目錄並選取 performance_dashboard_main.rdl 報表

按下開啟舊檔後，報表就會立即出現正確的效能分析報告，如下圖示（點圖可放大顯示）

這裡其實包含好幾份子報表，都是相互連動的，所分析出來的資訊之寶貴無法言寓，有心想研究的人建議可參考安裝目錄下的 PerfDash.chm 文件，這裡有每一份報表的詳細說明：

在點選進 (Drill down) 子報表之後，如果要回上一頁，可以按報表左上角的「向後巡覽」按鈕，這樣就可以不用每次重新開啟報表：

在眾多報表之中，我覺得最有用的應該就是 Missing Indexes (遺失的索引)：

這份報表可以幫我們找出有哪些表格遺失了某些「可能需要」的索引（切記：越多的索引代表資料寫入速度越慢），然而在分析出所有遺失的索引後，你可以在 Proposed Index 欄位發現他連建立索引的語法都幫你寫好了，可惜的是你無法直接從報表上複製文字下來，只能先匯出 Excel 再複製其 T-SQL 語法：

由 於你不應該把所有「可能遺失的索引」都建立起來，因此以下提供一個基本的判斷原則，幫助你選擇到底有哪些索引應該被建立，這調校原則雖然適用於許多情況， 但該原則還是僅供參考，設定不好而導致資料庫寫入速度變慢請不要找我負責，因為資料庫的效能調校不僅僅只有這樣的判斷邏輯，還有許多其他的環境因素都有可 能影響到調校的策略，像是：硬碟存取速度、應用程式特性、系統資源分配情況、…等等

• 當 Avg Total User Cost 欄位的數值超過「個位數」以上，就算是蠻高的成本，可以考慮建立索引
• 當 Avg User Impact 欄位的數值超過 80 以上，也算是蠻高的衝擊，也可以考慮建立該索引

不過再進一步分析 Unique Compiles、User Seeks、User Scans 數量過低的情況，其實建立索引不見得對整體執行效能有幫助（因為該索引的使用率過低），反而會導致寫入效能低落的情況，這時你也可以選擇不建立該索引：

§ 最後提醒 §

這些統計資訊的資料來源大多來自於 SQL Server 裡所謂的 動態管理檢視 ( DMV )，這些資訊是從資料庫實體 (Instance) 啟動之後所累積的動態資訊，所以 SQL Server 跑得越久，所收集到的資訊越精準，也越能找出在啟動 SQL Server 服務之後到現在所累積的效能問題有哪些。

Reference from: http://blog.miniasp.com/post/2011/08/24/Performance-Dashboard-Reports-for-SQL-Server-2008.aspx#continue

Microsoft Web Application Stress Tool 是由微軟的網站測試人員所開發，專門用來進行實際網站壓力測試的一套工具。透過這套功能強大的壓力測試工具，您可以使用少量的Client端計算機仿真大 量用戶上線對網站服務所可能造成的影響，在網站實際上線之前先對您所設計的網站進行如同真實環境下的測試，以找出系統潛在的問題，對系統進行進一步的調 整、設置工作。
Microsoft Web Application Stress具有以下幾個特性：
* 可以數種不同的方式建立測試指令：包含以手動、錄制瀏覽器操作步驟、或直接錄入IIS的記錄文件、錄入網站的內容及錄入其它測試程序的指令等方式。
* 支持多種客戶端接口：標準的網站應用程序C 的客戶端，使用Active Server Page 客戶端，或是使用Web Application Stress對象模型建立您自定的接口。.
* 支持多用戶利用多種不同的認證方式仿真實際的情況，包含了DPA, NTLM 及 SSL等。
* 支持使用動態的cookie仿真定制網站實際運作場景及對話（session）的支持。
* 在客戶端的計算機以NT 服務的方式執行仿真的工作，可在不中斷測試的情況下將某些客戶端的測試計算機刪除。
* 透過集中式的Microsoft Web Application Stress 治理員，您可以使用任意數目的客戶端計算機同時進行測式的工作。
* 具有Bandwidth throttling （帶寬遏流）的功能以仿真用戶使用調制解調器上線的效果。
* 內建的query-string 編輯器可幫助您建立name-value pair組合的模板，并可在不同的場景測試中重復使用。
* 可程序化的對象模式讓您可以建立您自己的測試客戶端。
* 匯總的測試報告及豐富的性能測試資料。
* 支持域名系統(DNS)讓您可以測試整個群集（Cluster）的機器。
* 使用Page group的方式來控制文件的組及測試指令的執行程序。
* 可自定的header讓您可以仿真各種不同種類的瀏覽器。
* 可自定的指令延遲讓您以更接近真實環境的方式進行測試。
網站測試概述
為了正確使用WAS進行網站的壓力測試，您需要對于網站測試的方法有一初步的了解。以下的討論將包含一些基本的概念以供參考。
網站的測試可大略分成三個主要的類別：
* 網站性能測試 (Performance testing)
* 壓力測試下的網站穩定性 (Stability or stress testing)
* 網站承受能力評估 (Capacity planning)
網站性能測試的第一件工作就是使用測試工具對網站加壓以測量網站伺服器每秒可以承受的請求(Request Per Second) 的最大值。第二件工作就是找出系統性能限制的原因所在，舉例來說，CPU、內存、或是后端系統所造成的反應延遲等。
在 許多狀況下，網站伺服器的CPU是主要的性能瓶頸。測試時您可以持續加壓直到性能表現開始下降，再慢慢的降低壓力的程度。此時您所測試出來的最大性能即為 該網站所能達到的最高值。在實際測試時，您可以通過增加壓力線程(thread)，或是增加執行WAS測試程序的客戶端來加壓。
在網站伺服器 端，您可以使用性能監視工具如Performance Monitor來監視如 \”System: % Total Processor Time\” 及 \”Web Service: Connection Attempts/sec\” 或 \”Active Server Pages: Requests Queued\”等指針。假如CPU的資源指針已達到80%到85%，則CPU的處理能力最有可能就是整個系統的瓶頸所在。若是在壓力測試的過程中CPU 所被使用的比例不高而”Requests Queued”的指針一直居高不下，可能是程序正在調用伺服器上的COM組件而這個組件無法有效的執行完所有的命令，因而造成了系統性能的降低。在這種情 形下，伺服器上的COM組件才是真正的瓶頸。
目前市場上最熱門的定制網站應用程序也會對網站的性能表現有重大的影響。WAS包含了數種特性可有 效的幫助您測試定制的網站應用程序。例如，您可以建立用戶，讓WAS可以設置并儲存每一個用戶的cookie。您也可以使用QueryString 編輯器幫助您建立并儲存數個不同的name-value pair以便在每一次執行request時進行測試。

Reference from: http://mid.lt263.com/mb/cmsjiaocheng/20082.html; How to install: http://www.yaosansi.com/post/1281.html

Wednesday, June 18, 2008 | 4:56 PM

Labels: Ads quality, Announcements

*本文章只適用於使用  Apache (多用於 Linux) 為 web server 的網站。

以友站 關鍵字廣告基地 為例，當這個網站架設好後，我們知道我們的官方網址是：http://www.clicks.com.tw

但是一般來說，我們可以以下四種方式輸入網址到達首頁：

http://www.clicks.com.tw/
http://www.clicks.com.tw/index.php 或 index.html 或 index.htm
http://clicks.com.tw/
http://clicks.com.tw/index.php

我們知道目前搜尋引擎基礎上以 backlink 連結來賦予網頁的權重，由於我們無法控制第三方採用哪一個網址來跟我們的網站進行連結，因此就可能出現 相同網頁、不同網址、不同權重的情況出現。『 相同網頁、不同網址、不同權重』這個問題，對瀏覽者來說可以說無傷大雅，但是在搜尋引擎就會造成權重分散的情形。

對搜尋引擎來說，上述四個網址代表著四個不一樣的網頁。

而對網站瀏覽者來說，對網址的具體印象也會不一。

筆者就曾經有過 http://www.xxxx.com.tw/  (PR =4) 跟 http://www.xxxx.com.tw/index.php (PR = 5) 出現不同  Page Rank 的問題。同一個網頁不同的 PageRank 代表著浪費了辛苦累積的 backlink。

這個情況在 Linux 伺服器 (準確點應該是說使用 Apache Web Server 的伺服器) 就要透過 301 redirect 來解決。所謂 301 redirect 的意思是告訴搜尋引擎這是永久性 (301) 的轉址 (redirect)。

在放置首頁  index.php 或 index.html 的目錄下，一般有一個 .htaccess 的隱藏檔案。這個 .htaccess 屬於隱藏檔案，在 FTP 軟體上也許要設定可以觀看隱藏檔案才會發現它的存在。看不到也不用驚訝，也許本來的設定就沒有。

將 .htaccess 檔案下載回來，用 notepad 或者 Editplus 這些純文字編輯軟體就可以加入，非常簡單。請注意如果本身 .htaccess 已經有其他設定，首先需要備份萬一發生問題可以將備份檔上傳，再來就是將以下的指令放到檔案最下方即可，不要刪除本來的設定。

Options +FollowSymLinks
RewriteEngine On
# 以下是將沒有www 的網址加上有 www
RewriteCond %{HTTP_HOST} ^clicks.com.tw$ [NC]
RewriteRule ^(.*)$ http://www.clicks.com.tw/$1 [R=301,L]
# 以下是將有 index.php 的網址轉成沒有
rewriteCond %{THE_REQUEST} ^[A-Z]{3,9} /index.php HTTP/
rewriteRule ^index.php$ http://www.clicks.com.tw/ [R=301,L]

請將 clicks.com.tw 網址換成您自己的網址。

新的 .htaccess 檔案上傳後，不論輸入四個當中哪一個網址，都會自動轉成官方的http://www.clicks.com.tw/ ，而搜尋引擎也會將權重全部集中在這個網址上。

由於這個情形幾乎每個網站都會出現，所以應該出現在每個網站完成的 check list 上，視為標準動作。

參考：How To Redirect index.php to directory

http://www.webmasterworld.com/apache/3495904.htm

Reference from: http://seo.list.tw/301-redirect/

我們都知道 Google 已經將網站的載入速度納入搜尋引擎排名 以及 Google Adwords 網頁品質的計算因素裡面。我們又如何得知 Google 那邊對我們的網站測出了什麼樣的速度？

Google 上個禮拜在 Google Analytics 發布了一個新的功能 – Site Speed (網站速度)。網站管理者需要在原有的 tracking code 上面加入 _gaq.push(['_trackPageLoadTime']); 這段程式碼，數個小時後，進入 Google Analytics 的新 Beta 版本就可以看到網頁載入時間的統計資訊。

這段程式碼目前並沒有預設在 tracking code 裡面，就算你是 Google Analytics 的新用家，還是需要在Google Analytics介面提供的tracking code 上面額外再加上 _gaq.push(['_trackPageLoadTime']); 這一段。

Reference from: http://seo.list.tw/google-analytics-site-speed/

RAID 10/01其實可細分為RAID 1+0或RAID 0+1。

RAID 1+0是先鏡射再分割資料。是將所有硬碟分為兩組，視為是RAID 0的最低組合，然後將這兩組各自視為RAID 1運作。RAID 1+0有著不錯的讀取速度，而且擁有比RAID 0更高的資料保護性。

RAID 0+1則是跟RAID 1+0的程式相反，是先分割再將資料鏡射到兩組硬碟。它將所有的硬碟分為兩組，變成RAID 1的最低組合，而將兩組硬碟各自視為RAID 0運作。RAID 0+1比起RAID 1+0有著更快的讀寫速度，不過也多了一些會讓整個硬碟組停止運轉的機率；因為只要同一組的硬碟全部損毀，RAID 0+1就會停止運作，而RAID 1+0則可以在犧牲RAID 0的優勢下正常運作。

RAID 10巧妙的利用了RAID 0的速度以及RAID 1的保護兩種特性，不過它的缺點是需要的硬碟數較多，因為至少必須擁有四個以上的偶數硬碟才能使用。

Reference from: http://zh.wikipedia.org/wiki/RAID

The +1 button lets users recommend the content they like on the web, helping
to improve Google search for their friends and contacts. It appears on Google
search, Google search ads, and other sites across the web.

When users click the +1 button for a particular webpage, their names and
profile pictures will appear as part of personal annotations in their friends
and contacts’ search results. Users will see their names and pictures beneath
the ads and organic links associated with the webpage. The final landing page’s
URL can also appear on the Google profile of any user who +1′s your ad or
organic result and chooses to share +1′s on her profile.

Whenever possible, the +1 button is associated with a site’s final landing page. This means a user can recommend a webpage by clicking the +1 button on that page, or the +1 button next to a Google search ad or search result associated with that page. For example, if a user +1′s an organic search result with the same final landing page as your ad, the +1 count associated with both the organic search result and the search ad will increase.

Reference from: https://adwords.google.com/support/aw/bin/answer.py?hl=en&answer=187588

More info please see here: https://adwords.google.com/support/aw/bin/topic.py?hl=en&topic=1152956

How to use please see here: http://www.google.com/intl/en/webmasters/+1/button/index.html

Additional info please see here: http://www.google.com/intl/zh-TW/+/learnmore/

At some stage in your career, it’s likely you’ll be asked by a client to design a HTML email. Before you rush to explain that all the cool kids are using social media, keep in mind that when done correctly, email is still one of the best ways to promote you and your clients online. In fact, a recent survey showed that every dollar spent on email marketing this year generated more than $40 in return. That’s more than any other marketing channel, including the cool ones.

There are a whole host of ingredients that contribute to a good email marketing campaign. Permission, relevance, timeliness and engaging content are all important. Even so, the biggest challenge for designers still remains building an email that renders well across all the popular email clients.

Same same, but different

Before getting into the details, there are some uncomfortable facts that those new to HTML email should be aware of. Building an email is not like building for the web. While web browsers continue their onward march towards standards, many email clients have stubbornly stayed put. Some have even gone backwards. In 2007, Microsoft switched the Outlook rendering engine from Internet Explorer to Word. Yes, as in the word processor. Add to this the quirks of the major web-based email clients like Gmail and Hotmail, sprinkle in a little Lotus Notes and you’ll soon realize how different the email game is.

While it’s not without its challenges, rest assured it can be done. In my experience the key is to focus on three things. First, you should keep it simple. The more complex your email design, the more likely is it to choke on one of the popular clients with poor standards support. Second, you need to take your coding skills back a good decade. That often means nesting tables, bringing CSS inline and following the coding guidelines I’ll outline below. Finally, you need to test your designs regularly. Just because a template looks nice in Hotmail now, doesn’t mean it will next week.

Setting your lowest common denominator

To maintain your sanity, it’s a good idea to decide exactly which email clients you plan on supporting when building a HTML email. While general research is helpful, the email clients your subscribers are using can vary significantly from list to list. If you have the time there are a numberof tools that can tell you specifically which email clients your subscribers are using. Trust me, if the testing shows almost none of them are using a client like Lotus Notes, save yourself some frustration and ignore it altogether.

Knowing which email clients you’re targeting not only makes the building process easier, it can save you lots of time in the testing phase too. For the purpose of this article, I’ll be sharing techniques that give the best results across all of the popular clients, including the notorious ones like Gmail, Lotus Notes 6 and Outlook 2007. Just remember that pixel perfection in all email clients is a pipe dream.

Let’s get started.

Use tables for layout

Because clients like Gmail and Outlook 2007 have poor support for float, margin and padding, you’ll need to use tables as the framework of your email. While nested tables are widely supported, consistent treatment of width, margin and padding within table cells is not. For the best results, keep the following in mind when coding your table structure.

Set the width in each cell, not the table

When you combine table widths, td widths, td padding and CSS padding into an email, the final result is different in almost every email client. The most reliable way to set the width of your table is to set a width for each cell, not for the table itself.

<table cellspacing="0" cellpadding="10" border="0">
<tr>
 <td width="80"></td>
 <td width="280"></td>
</tr>
</table>

Never assume that if you don’t specify a cell width the email client will figure it out. It won’t. Also avoid using percentage based widths. Clients like Outlook 2007 don’t respect them, especially for nested tables. Stick to pixels. If you want to add padding to each cell, use either the cellpadding attribute of the table or CSS padding for each cell, but never combine the two.

Err toward nesting

Table nesting is far more reliable than setting left and right margins or padding for table cells. If you can achieve the same effect by table nesting, that will always give you the best result across the buggier email clients.

Use a container table for body background colors

Many email clients ignore background colors specified in your CSS or the <body> tag. To work around this, wrap your entire email with a 100% width table and give that a background color.

<table cellspacing="0" cellpadding="0" border="0" width="100%">
<tr>
 <td bgcolor=”#000000”>
 Your email code goes here.
 </td>
</tr>
</table>

You can use the same approach for background images too. Just remember that some email clients don’t support them, so always provide a fallback color.

Avoid unnecessary whitespace in table cells

Where possible, avoid whitespace between your <td> tags. Some email clients (ahem, Yahoo! and Hotmail) can add additional padding above or below the cell contents in some scenarios, breaking your design for no apparent reason.

CSS and general font formatting

While some email designers do their best to avoid CSS altogether and rely on the dreaded <font> tag, the truth is many CSS properties are well supported by most email clients. See this comprehensive list of CSS support across the major clients for a good idea of the safe properties and those that should be avoided.

Always move your CSS inline

Gmail is the culprit for this one. By stripping the CSS from the <head> and <body> of any email, we’re left with no choice but to move all CSS inline. The good news is this is something you can almost completely automate. Free services like Premailer will move all CSS inline with the click of a button. I recommend leaving this step to the end of your build process so you can utilize all the benefits of CSS.

Avoid shorthand for fonts and hex notation

A number of email clients reject CSS shorthand for the font property. For example, never set your font styles like this.

p {
 font:bold 1em/1.2em georgia,times,serif;
}

Instead, declare the properties individually like this.

p {
   font-weight: bold;
   font-size: 1em;
   line-height: 1.2em;
   font-family: georgia,times,serif;
}

While we’re on the topic of fonts, I recently tested every conceivable variation of @font-face across the major email clients. The results were dismal, so unfortunately it’s web-safe fonts in email for the foreseeable future.

When declaring the color property in your CSS, some email clients don’t support shorthand hexadecimal colors like color:#f60; instead of color:#ff6600;. Stick to the longhand approach for the best results.

Paragraphs

Just like table cell spacing, paragraph spacing can be tricky to get a consistent result across the board. I’ve seen many designers revert to using double <br /> or DIVs with inline CSS margins to work around these shortfalls, but recent testing showed that paragraph support is now reliable enough to use in most cases (there was a time when Yahoo! didn’t support the paragraph tag at all).

The best approach is to set the margin inline via CSS for every paragraph in your email, like so:

p {
 margin: 0 0 1.6em 0;
}

Again, do this via CSS in the head when building your email, then use Premailer to bring it inline for each paragraph later.

If part of your design is height-sensitive and calls for pixel perfection, I recommend avoiding paragraphs altogether and setting the text formatting inline in the table cell. You might need to use table nesting or cellpadding / CSS to get the desired result. Here’s an example:

<td width="200" style="font-weight:bold; font-size:1em; line-height:1.2em; font-family:georgia,'times',serif;">your height sensitive text</td>

Links

Some email clients will overwrite your link colors with their defaults, and you can avoid this by taking two steps. First, set a default color for each link inline like so:

<a href="http://somesite.com/" style="color:#ff00ff">this is a link</a>

Next, add a redundant span inside the a tag.

<a href="http://somesite.com/" style="color:#ff00ff"><span style="color:#ff00ff">this is a link</span></a>

To some this may be overkill, but if link color is important to your design then a superfluous span is the best way to achieve consistency.

Images in HTML emails

The most important thing to remember about images in email is that they won’t be visible by default for many subscribers. If you start your design with that assumption, it forces you to keep things simple and ensure no important content is suppressed by image blocking.

With this in mind, here are the essentials to remember when using images in HTML email:

Avoid spacer images

While the combination of spacer images and nested tables was popular on the web ten years ago, image blocking in many email clients has ruled it out as a reliable technique today. Most clients replace images with an empty placeholder in the same dimensions, others strip the image altogether. Given image blocking is on by default in most email clients, this can lead to a poor first impression for many of your subscribers. Stick to fixed cell widths to keep your formatting in place with or without images.

Always include the dimensions of your image

If you forget to set the dimensions for each image, a number of clients will invent their own sizes when images are blocked and break your layout. Also, ensure that any images are correctly sized before adding them to your email. Some email clients will ignore the dimensions specified in code and rely on the true dimensions of your image.

Avoid PNGs

Lotus Notes 6 and 7 don’t support 8-bit or 24-bit PNG images, so stick with the GIF or JPG formats for all images, even if it means some additional file size.

Provide fallback colors for background images

Outlook 2007 has no support for background images (aside from this hack to get full page background images working). If you want to use a background image in your design, always provide a background color the email client can fall back on. This solves both the image blocking and Outlook 2007 problem simultaneously.

Don’t forget alt text

Lack of standards support means email clients have long destroyed the chances of a semantic and accessible HTML email. Even still, providing alt text is important from an image blocking perspective. Even with images suppressed by default, many email clients will display the provided alt text instead. Just remember that some email clients like Outlook 2007, Hotmail and Apple Mail don’t support alt text at all when images are blocked.

Use the display hack for Hotmail

For some inexplicable reason, Windows Live Hotmail adds a few pixels of additional padding below images. A workaround is to set the display property like so.

img {display:block;}

This removes the padding in Hotmail and still gives you the predicable result in other email clients.

Don’t use floats

Both Outlook 2007 and earlier versions of Notes offer no support for the float property. Instead, use the align attribute of the img tag to float images in your email.

<img src="image.jpg" align="right">

If you’re seeing strange image behavior in Yahoo! Mail, adding align=“top” to your images can often solve this problem.

Video in email

With no support for JavaScript or the object tag, video in email (if you can call it that) has long been limited to animated gifs. However, some recent research I did into the HTML5 video tag in email showed some promising results.

Turns out HTML5 video does work in many email clients right now, including Apple Mail, Entourage 2008, MobileMe and the iPhone. The real benefit of this approach is that if the video isn’t supported, you can provide reliable fallback content such as an animated GIF or a clickable image linking to the video in the browser.

Of course, the question of whether you should add video to email is another issue altogether. If you lean toward the “yes” side check out the technique with code samples.

What about mobile email?

The mobile email landscape was a huge mess until recently. With the advent of the iPhone, Android and big improvements from Palm and RIM, it’s becoming less important to think of mobile as a different email platform altogether.

That said, there are a few key pointers to keep in mind when coding your emails to get a decent result for your more mobile subscribers.

Keep the width less than 600 pixels

Because of email client preview panes, this rule was important long before mobile email clients came of age. In truth, the iPhone and Pre have a viewport of 320 pixels, the Droid 480 pixels and the Blackberry models hover around 360 pixels. Sticking to a maximum of 600 pixels wide ensures your design should still be readable when scaled down for each device. This width also gives good results in desktop and web-based preview panes.

Be aware of automatic text resizing

In what is almost always a good feature, email clients using webkit (such as the iPhone, Pre and Android) can automatically adjust font sizes to increase readability. If testing shows this feature is doing more harm than good to your design, you can always disable it with the following CSS rule:

-webkit-text-size-adjust: none;

Don’t forget to test

While standards support in email clients hasn’t made much progress in the last few years, there has been continual change (for better or worse) in some email clients. Web-based providers like Yahoo!, Hotmail and Gmail are notorious for this. On countless occasions I’ve seen a proven design suddenly stop working without explanation.

For this reason alone it’s important to retest your email designs on a regular basis. I find a quick test every month or so does the trick, especially in the web-based clients. The good news is that after designing and testing a few HTML email campaigns, you will find that order will emerge from the chaos. Many of these pitfalls will become quite predictable and your inbox-friendly designs will take shape with them in mind.

Looking ahead

Designing HTML email can be a tough pill for new designers and standardistas to swallow, especially given the fickle and retrospective nature of email clients today. With HTML5 just around the corner we are entering a new, uncertain phase. Will email client developers take the opportunity to repent on past mistakes and bring email clients into the present? The aim of groups such as the Email Standards Project is to make much of the above advice as redundant as the long-forgotten <blink> and <marquee> tags, however, only time will tell if this is to become a reality.

Although not the most compliant (or fashionable) medium, the results speak for themselves – email is, and will continue to be one of the most successful and targeted marketing channels available to you. As a designer with HTML email design skills in your arsenal, you have the opportunity to not only broaden your service offering, but gain a unique appreciation of how vital standards are.

Reference from: http://www.campaignmonitor.com/design-guidelines/