1. 設計站點前的準備工作
在設計一項既要面向移動設備又要面向PC的服務的時候，首先需要進行移動設備用戶界面的設計。把面向移動的服務擴展到PC環境通常要比其相反方向擴展要容易一些。
如果起始站點是一個PC Web站點，強烈建議把PC服務分解成若干部分。在移動環境中，僅挑選那些可以作爲服務核心的部分。在設計移動服務時，要把注意力集中在這些核心部分上。
研究市場上各種移動瀏覽器的物理特性，以便用XHTML和CSS進行有效的應用軟件設計。你需要知道文檔、樣式表以及圖像的最大許可大小，可以用於顯示內容的屏幕空間的物理大小，以及爲其它物理實體，如軟鍵文本、圖標、標題等，預留的屏幕空間。諾基亞手機有一個包含圖標的標題行，標題行還可以包含XHTML頁面的標題。還有一個用於顯示XHTML頁面（不包括標題）的內容區域，以及包含一個或多個軟鍵文本的區域，軟鍵的個數取決於移動設備的類型。
可以從http://www.forum.nokia.com/下載諾基亞移動因特網工具包。還可以在若干諾基亞設備仿真器中的任一個上測試你編寫的內容是如何顯示的，仿真器也可從上述的Web站點下載。
2 .設計優秀站點的基本原則
XHTML MP 和CSS的引入創建了多種新的用戶界面結構。XHTML MP包含的元素比WML多，並且利用CSS，可以通過多種方法修改元素的可視化顯示。XHTML MP爲服務提供者提供了更多把他們的服務變得更有吸引力的可能性，但同時，XHTML MP也增加了設計的複雜度，從而在可用性上面臨更多的挑戰。
3 .關注導航模型
應該基於一致、易學的導航模型創建便於使用的用戶界面。這比使用XHTML的所有花哨的顯示功能都重要。
移動用戶的需求及期望與使用臺式PC的用戶不同。移動用戶不是瀏覽者，他們更希望能夠快速、輕鬆地訪問特定信息。因此，應提供簡潔、精確且快速的信息。
避免在過多頁面或閃爍屏幕中顯示核心服務內容；然而，可以在其中顯示一個小logo或其它的加亮商標，以使用戶熟悉服務。無論如何，應能立刻顯示用戶要求查看的重要信息。
在移動設備中，數據的輸入非常有挑戰性，並且比較費時，故在創建站點時，儘可能少地要求用戶輸入，尤其是文本輸入。
如果可能，在用戶做選擇時，應避免讓用戶打字，考慮利用選擇列表、複選框或單選按鈕讓用戶從默認的列表中做出選擇，或提供一個默認列表和一個輸入框。
當不得不要求輸入的情況下，利用屬性-wap-input-format設置輸入模板，例如，*N代表數字輸入。這樣可以避免手動轉換輸入模式。
CSS的屬性–wap-input-format爲用戶輸入的數據定義了一個輸入模板，從而去除了爲文本或數字轉換輸入模式的需要。因爲一些非諾基亞XHTML MP瀏覽器的早期版本不支持該屬性，它們支持舊屬性format="…"，因此，對同一格式字符串，應同時定義CSS屬性–wap-input-format和屬性format。關於WAP Format輸入模板的語法，可參見WAP June 2000 specification [WML] 或 WAP Overview [WAPOver]。
許多用戶以分鐘爲單位支付移動服務，因此，如果他們無法在短時間內獲得要查找的信息，就會停止使用該服務——這也是遵守以上要點的一個重要原因。
4 .設計導航層次
導航模型是用戶瀏覽XHTML頁面的方法，XHTML頁面由服務、通過鏈接進行的交互、菜單和數據輸入組成。在設計導航模型時，牢記以下原則：
在整個服務中保持導航模型的一致性。
對於XHTML服務，避免加入返回到之前訪問過的頁面的鏈接，因爲諾基亞移動瀏覽器有一個永久的Back軟鍵，可以自動地實現該操作。
避免創建過於“深”的服務。如果一個服務包含的層次多於4或5個，用戶通常就難以保留服務的總體印象。
加入返回到服務的起始頁或其它主要分支頁面的導航，這樣用戶就可以輕鬆地返回到他們的起始點。導航層次越多，就越需要一個返回到起始頁的方法。
5 .針對小尺寸屏幕的設計考慮
預測顯示，全世界移動設備的數量將很快超過PC的數量，這給適用於小尺寸屏幕的界面友好的應用軟件帶來了巨大的商機。當然，在小尺寸屏幕上設計富有創造性的應用軟件更有挑戰性，但爲移動設備設計具有吸引力的應用軟件並非不可能。牢記下列條款：
確保用戶進入頁面時有可見內容。
在<head>元素中用<title>元素爲每個頁面定義一個短小標題。通常，標題不應多於14個字符，除非你能夠定製頁面使其適應用戶設備的特定特徵。
在一個服務的所有XHTML頁面中使用一致的樣式。一致性增加了易用性——尤其是對於重複使用該服務的用戶。
儘量減少水平滾動的需要。水平滾動除了比較費時之外，用戶還將難以判斷他們在整個頁面中的位置。如果可能，設計的內容不要寬於或長於目標設備的顯示屏。
利用元素的對齊屬性（lef， right， center）來增加可讀性，但不要在同一頁面中使用多於兩個或三個屬性，因爲這阻礙了用戶獲取組織結構。
使用空白空間，尤其是在高而窄的圖像旁邊。可以通過在<img>元素中使用屬性align實現此目的，例如： <img align="left" src="sky.gif" alt="Sky Picture"/> 此外，可以在CSS中爲<img>元素設置懸浮屬性和其它屬性來實現此目的（以及更多其它目的）。懸浮圖像允許在圖像旁邊顯示文本 ，從而利用了整個顯示區域。
避免過多使用文本強調屬性，如粗體，斜體和下劃線等，因爲這降低了小顯示屏上內容的可讀性。
如有可能，儘量使用短小、精確的字詞，避免使用冗長、複雜的字詞。
避免在同一頁面中使用過多不同顏色。儘管顏色可以給一個服務帶來更多“活力”，但是過多顏色會導致超載。使用顏色時要儘量保持一致性，例如，整個服務中的相同XHTML元素使用同一種顏色。
不要用名字描述顏色，例如，“按下紅色鏈接繼續”。沒有彩色顯示屏的客戶終端會以黑色和白色顯示彩色內容。
6 .保持較短的文檔大小
因爲移動設備中可用的內存有限，故應使文檔儘可能短。然而，因爲XHTML MP與WML不同，它不能在一個文檔中支持多“卡片”，故把內容分爲多個獨立頁面將會使載入的速度減慢。因此，應把所有相關信息結合在同一頁面中，並利用分段錨來幫助跳轉至相關章節部分。
保持文檔較短的有用方法包括：
代碼中不要包含長註釋。儘管在代碼中添加註釋通常是良好的編程習慣，但對於移動設備來說，這是不適用的。
在縮進時利用tab而非空格，或者不使用縮進。空格越多，文檔大小增加越快！
文件名、CSS類和CSS ID應使用簡短名稱。
在可能的地方，用層疊規則定義樣式，而不是在元素中用類或屬性ID。例如，在WAP CSS樣式表中，使用如下的屬性：
p (color:red)
而不是下列的類屬性：
.red {color:red}
這樣就沒有必要在文檔中的每個<p>元素內定義字符串class="red"。
7. 爲移動電話設計應用軟件
當開發人員要決定移動終端的各種應用軟件應包含什麼信息時，他們應考慮用戶在什麼情況下使用移動電話。服務內容應滿足目標用戶羣的需要，並且應該對最常見的任務進行最優化。由於較小顯示設備便於移動，所以，在沒有PC機的情況下，用戶可能會首先使用移動電話訪問英特網以及獲取急需信息。相應的範例包括快速訪問航班信息、查看簡訊和天氣情況等。但用戶使用移動電話上網衝浪的可能性要小。
8. 保持用戶任務流的流暢及圖像的合理使用
彩色頁面看起來很誘人，但當圖像傳輸使得服務減慢時，彩色頁面也許並不讓人覺得很舒服。根據可用性研究1， 用戶不太熱衷於那些由於圖像傳輸而中斷他們任務流的服務。特別地，當用戶在搜尋目標頁面時，大的圖像就不太合適。含有信息價值的圖像是令人青睞的，但在多數情況下，用戶或是關掉圖像以節省時間和金錢，或是不等圖像下載就切換到下個頁面。在下載所有圖像之前允許用戶繼續瀏覽頁面，是很重要的。
大表格也許會產生相似的問題——也就是說，在某一頁面下載完之前，用戶的操作被凍結；或者在頁面下載完之前不能繼續進行其他操作。因爲移動電話顯示屏的大小不同，所以開發人員應確保即使是在最小的顯示屏上，也能夠閱讀數據表格；通常這些數據表格要進行壓縮以符合顯示屏的要求。
9 .結構對新用戶要簡單但也不能忽視熟手用戶
在移動通信服務中，淺層結構似乎常常比深奧結構更容易理解。鏈接和頁面應該冠以描述性的名稱，這樣可以幫助用戶找到他/她需要的信息。
很難說在一個鏈接列表頁面上應該提供多少個鏈接。如果鏈接明顯屬於同類且容易瀏覽（每個鏈接佔一行，以字母順序，或另外以邏輯順序排列，這樣用戶就不必把每個鏈接都讀一遍），那麼，比較好的方法是在一個頁面上提供30個鏈接，而不是每個頁面上提供5個鏈接，總共需要6個頁面。如果有好幾十個鏈接，在顯示這些鏈接前提供排序選項是個不錯的主意。如果鏈接能放置在一行上，則選擇起來一目瞭然，頁面也更美觀.
WAP 2.0沒有<do>元素，相反，它們由access keys取代。然而，大多數用戶似乎並不瞭解access keys元素，並且無法找到他們。爲了幫助用戶理解accesskeys的概念，開發人員應確保accesskeys在屏幕上可見，而且以類似電話鍵的形式出現。
如果有可能，應提供搜索功能。熟手用戶很欣賞這個功能，正如新手用戶瀏覽著名站點一樣。
10. 在頁面上提供足夠信息
交互式頁面應該簡短，信息頁面應該較長32。不建議使用門面頁面來啓動站點，門面頁面除了問候訪問者和顯示logo外，沒有其他作用。較好的方式是用戶能夠直接訪問服務。
在XHTML下，信息以頁面形式下載，而不是以WML下的deck形式。這意味着向用戶提供單個頁面上的信息以支持他們的任務流就顯得更爲重要。由於XHTML頁面是各自獨立下載的，所以在XHTML頁面間來回切換可能會消耗更多的時間。後向導航尤其存在這種情況，在這些情況下頁面不能緩存，例如，與付帳或提供私人信息有關的系統就是這種情況。
任何頁面的第一屏（最頂端）都是最重要的。所有經常使用的導航鏈接、搜索域、登錄屏幕和大量信息都駐留在那兒。用戶可在頁面的剩餘部分加載之前向前瀏覽，並且無需滾動頁面。
應避免在頁面頂端放置橫幅廣告或沒有任何信息的圖形。最好是把廣告放在頁面的左側或右側邊框。
上下滾動頁面是困難的，因此帶有表格的交互式頁面不應該太長，因爲用戶不能確信他們是否已經填完長表格上的每個域。如果表格所佔空間超過兩屏，用戶可能容易失去控制感。
用戶訪問的目標頁面應該具有足夠多的信息。例如，如果目標頁面包含故事或用法說明，則應該在一個頁面上顯示所有內容。當用戶瀏覽一個長而信息量較大的頁面時，能夠在頁面內引導用戶的子標題將幫助用戶瀏覽頁面。
信息是以單個頁面下載而不是以deck下載的這個事實是影響導航以及WML和XHTML之間結構性差異的最大單個變化。
11 .爲用戶操作提供信息反饋
開發人員應該對用戶操作、以及錯誤和問題情況提供正確的反饋。例如，在用戶點擊鏈接之後，頁面標題應該與鏈接名相同。減小導航步驟應該不增加用戶的不安全感，例如，用戶操作的確認頁面是必要的，儘管這些頁面需要再次點擊。如果確認頁面丟失，用戶也許覺得她/他需要檢查，以確認這一行爲是否發生——這會導致更多次的點擊。應該認用戶覺得他們始終在控制着系統
如果出現問題，應提示用戶下一步該怎麼辦。向用戶解釋期望輸入的格式以及對必填項進行標記可阻止錯誤發生。
12. 儘可能減少圖像數量和減小圖像容量大小
應該認真考慮一個XHTML頁面上圖像數量和容量大小。頁面上的每一幅圖像就產生一次獨立的來回，這反過來使整個頁面的顯示速度減慢。因此，應該儘量減少來回的數量。還要注意的是，當每次一幅圖像到達移動設備時，整個頁面的內容可能需要重新排列，這會佔用時間和處理器資源。因此，一個僅有幾幅圖像的頁面也許比一個有許多更小圖像的頁面下載得更快。如果有可能，建議在全部服務中各個頁面上使用相同的圖像；那麼一個特定的圖像只需下載一次且能夠保存到高速緩存器中。例如，如果自定義的圖像被用作bullet，則在整個服務中應該使用相同的圖像。
TCP/IP 連接也許會造成頁面下載速度的不同，即使其數據量相同。例如，下載一個包含四個圖像（每個圖像大小爲2 KB 的XHTML頁面）要比下載一個包含八個圖像（每個圖像大小爲1KB的頁面）的速度要更快。
如果使用WAP網關，則WAP網關應與GPRS支持GGSN放得近一點。在這個例子中，“近”是指數據延遲及數據包丟失的概率。由於HTTP重傳，丟失信息會產生附加延遲。WAP網關和內容服務器間的時延應儘可能的小。
13 .定義圖像高度和寬度屬性
建議內容開發人員在標記語言中明確地指定圖像的高度和寬度，以使瀏覽器爲圖像預留適當的空間。如果在圖像標籤中使用高度和寬度參數，那麼XHTML瀏覽器就能在下載圖像之前爲圖像預留空間。因此，在圖像下載之前頁面就能夠顯示出來，當然，圖像在下載後也能夠出現在頁面上。這並不影響XHTML頁面的完整下載和處理時間，但卻大大改善用戶的感受，因爲在下載圖像之前用戶可瀏覽頁面。例如：
<img src="pics/header_main_page_001.gif" width="175" height="41" />
14 .謹慎使用表格
XHTML頁面瀏覽器支持表格和嵌套表格的使用。在定義表格單元寬度，尤其是處理嵌套表格時，開發人員應謹慎行事。
CSS single-pass (固定)算法能夠用於設計表格佈局以便優化CPU利用率。然而，與CSS multi-pass (動態)表格佈局算法不同，固定表格佈局算法根據表格的第一行來確定表格的列數及其大小。因此，通過使用具有明確列寬的矩形表格可以獲得最佳性能。
如果要用嵌套表格，當明確指定子表格的寬度時，開發人員應避免用子表格寬度的一定比例來指定其父表格的寬度。因爲設備具有不同的屏幕尺寸，所以百分比不一定能夠表示相同數量的象素。因此，建議在父表格及其嵌套表格中使用絕對寬度（像素）以確保內容能正確顯示。注意必須確保表格的總寬度與所有列的寬度加上邊框和單元格間隔的總和是一樣的。一般而言，當表格嵌套層數增加時，頁面的複雜度和顯示頁面所需的處理時間也會增加。爲了確保能夠及時顯示頁面，應該避免使用嵌套很深的表格。
另外，表格的邊框不應該太粗，因爲對於顯示屏尺寸受限的設備來說，其邊框寬度容易佔用很多像素，從而使得實際可用的內容區變得太小。
15 .考慮添加樣式定義選項
開發人員可以用各種方式來定義自己的樣式，例如：使用外部樣式表、使用文檔頭部的樣式元素，或通過使用指定元素的行間樣式屬性等。一般而言，雖然使用外部樣式表無論何時都有可能把樣式從標記語言中分離出來，這是一種好的方法，但應注意權衡考慮。如果樣式定義包含在XHTML代碼中，則XHTML頁面的顯示就更快，但是外部樣式表的使用提供一種在整個服務中更改樣式的便利方法。在整個服務中應該使用相同的外部樣式表以避免把多個樣式表下載到電話上。外部樣式表僅需下載一次並能夠保存在高速緩存器中。
16 .刪除代碼內不必要的空白區和代碼內的註釋
確保代碼內沒有多餘的空白區非常重要。雖然空白區在屏幕上是不可見的，但仍要被處理，因爲瀏覽器要對空白區進行分析、排版、CSS分配和顯示等。
XHTML代碼內註釋數量應儘量地少，以使代碼儘可能地緊湊。
17 .使用HTTP標題指示來支持頁面緩存
瀏覽器能夠把已經閱讀的XHTML頁面放在緩存器中。然而，內容開發人員不應假定頁面緩存是默認的。如果可能，應與文檔一起發送明確的緩存標題以確保頁面在客戶端能夠緩存。另外，應將過期時間設置爲至少數天，這是爲了確保在跨越多個時區的情況下，內容能夠緩存一段適當的時間。
瀏覽器不支持在Meta 標籤內 (例如，使用 HTTP-EQUIV)放置緩存指示，但可用HTTP標題控制緩存。HTTP 服務器可設置"Cache-control: no-cache" HTTP標題指示，而此服務器放置了能夠定義“頁面不進行緩存”的頁面。
緩存使用“最近最少使用”算法，這意味着最少使用的項首先被清除。建議重複使用所有XHTML頁面內的圖像和外部CSS，以確保它們留在緩存中，以便每次使用它們時不需要重新下載。
注：在Series 60移動設備中，默認設置是緩存內容，除非在HTTP頭中有其它要求。而在Series 40移動設備中，默認設置是不緩存內容。
18. 使用Unicode 2.0字符集編寫XHTML的內容
諾基亞XHTML瀏覽器支持ASCII 和 Unicode 2.0字符集。因此，爲了確保XHTML最大程度的互操作性，應該使用非拉丁語的Unicode來創建所有的XHTML內容。對於拉丁語，也可使用ASCII來創建 。有些網關和代理能把本地字符集轉換成Unicode ，但並非所有的字符集都能轉換。所以，保證終端接收Unicode的唯一方法就是用Unicode創建內容。有關Unicode和其他非拉丁語的更多信息，可在下列書中找到：
CJKV Information Processing, Lunde, Ken. 1st edition. O’Reilly & Associates (December 1998)
Unicode: A Primer, Graham, Tony. John Wiley & Sons (March 2000)
19 .使用正確的MIME類型和經過驗證的XHTML代碼
由OMA定義的XHTML MP內容的首選MIME類型爲：“application/vnd.wap.xhtml+xml”。這一類型可以用於向XHTML用戶代理提供XHTML MP文檔支持。另外，也可使用 “application/ xhtml+xml”。在一些 Series 60 瀏覽器上，必須使用MIME類型“application/vnd.wap.xhtml+xml”以確保正確的XHTML MP內容視圖。MIME類型“text/html”也是可用的，但是，對於XHTML來說，這種類型應被保留，以便用於在現有的HTML用戶代理上的顯示功能。應注意“text/html”格式的XHTML文檔將不作爲XML格式來處理。例如，這意味着用戶代理也許不能檢測到形式上不像錯誤的錯誤。對於既想支持XHTML用戶代理又想支持HTML用戶代理的軟件開發人員來說，可以通過讓HTML文檔作爲“text/html”類型，XHTML文檔爲“application/vnd.wap.xhtml+xml”類型來使用內容協商機制。
建議所有XHTML MP內容使用*.xhtml的文件擴展名。爲了避免出現任何互操作性問題和提高性能，應該對XHTML代碼進行驗證。例如，可用http://validator.w3.org上的 W3C驗證器來驗證XHTML內容。如果動態地創建XHTML內容，則生成的代碼是合法的DTD XHTML MP 1.0代碼。
20 .使用描述性頁面標題和元素標籤
頁面標題描述所顯示的頁面內容。在WML中推薦使用標題，而在XHTML中強制使用標題。標題幫助用戶瀏覽應用軟件，因爲它們會提醒用戶她/他處於應用軟件的什麼位置。一個較好的方法就是標題用應該用服務的名稱開頭並且應該很短。用戶以前選擇的欄目將決定標題文本。例如，標題“書籤”告訴用戶顯示屏包含了應用軟件的一個書籤列表，以及前一次選擇的選項項目是“書籤”。
標題文本應該使用比例字體，如果標題文本太長，文本會被自動刪減。通常，刪減標題的效果要比縮寫更好，因爲用戶可能會對不熟悉的縮寫困惑不解。
雖然建議元素標籤使用縮略詞，但不應該使用目標用戶羣不大熟悉的首字母縮寫詞。相同的標籤應該總是用於相同的操作，尤其是諸如Delete、Remove、 Erase、Clear和 Destroy的功能標記。
21 .使用多段/混合方式更快下載XHTML頁面
多段方式可以用來請求和傳送單一多段消息中的XHTML頁面內容，它可以取代目前的多個獨立頁面對象請求。這使得頁面下載的速度更快。例如，如果一個XHTML頁面包含文本、7幅圖片和一個至外部樣式表的鏈接，則所有內容可以通過一次請求獲得而無需提供9次單獨的請求。爲了使用這一功能，Web服務器和瀏覽器都要支持多段方式。內容開發人員必須考慮到將頁面中的所有可顯示內容編碼爲多段消息。
如需查明哪款諾基亞手機支持multipart/mixed MIME類型，參閱www.forum.nokia.com/documents中的文檔Browser MIME Types In Nokia GSM Phones。
22 .進行可用性測試
對新的應用軟件進行可用性測試總是正確的選擇。沒有參與設計和開發應用軟件的人往往會注意到潛在的可用性問題，這些問題對於那些非常瞭解設計的人常常不是顯而易見的。可用性測試應該在開發過程中儘可能早地進行。這樣，在開發時間表內能夠完成根據測試結果需要進行任何必要的更改。應該邀請能夠代表未來最終用戶的測試人員進行測試。如果日程安排不允許進行大量測試，至少應進行小規模測試。