登陸的一些心得

1、一切以良好用戶體驗爲基礎

1. 視覺效果

界面的設計就不用多說了，通常狀況這個屬於美工的活兒，這裏要談的是幾個最基礎的點。

第一，你的頁面兼容性如何？各個元素的長寬、行高等在不一樣瀏覽器上是否表現一致，若是這個都沒有保證，那必定是不合格的。

第二，移動終端上的體驗問題，現在不少頁面 PC 和移動終端都用的一套結構，也就是咱們所說的響應式佈局，本博客就使用了響應式佈局，縮小窗口能夠看到效果，響應式佈局是爲了讓不一樣的移動終端也能獲得一樣的優質體驗，但是不少開發者卻忽略了橫屏時的效果。下面是常見的幾個移動終端的像素比例：

Mobile	px rate
Iphone5	320*568
Iphone4	320*480
Galaxy S 3/4	360*640
Lumia 920	384*640
iPad	768*1024

照顧用戶的響應式佈局除了要考慮這些屏幕的橫屏，還得把豎屏考慮進去。我簡單的作了一個登錄頁面：

正確的帳號是：barret，密碼是：123，你能夠用錯誤的信息先去測試下~

能夠戳這個DEMO：http://qianduannotes.duapp.com/demo/login/login.html

2. 交互

前面那種方式，點擊提交按鈕，送到後臺去驗證，驗證沒有經過則回到登陸頁面，這也算是一種交互，不過這種交互的體驗是特別很差的，每次都得從新刷新頁面，應該利用 ajax 異步去驗證表單。爲了省去用戶的聚焦點擊，能夠按照下面的思路來作：

1. 用戶名爲空，或者格式不對 -》 提示錯誤，清空密碼框，聚焦到用戶名框，並全選用戶名
2. 用戶名不存在 -》同上
3. 密碼錯誤 -》 提示錯誤，清空密碼框，聚焦密碼框
4. 聚焦到密碼框，全選密碼

告訴用戶哪一個地方出了問題，並提早預知用戶遇到這些問題以後會作哪些事情，咱們可以用程序解決的事情，毫不麻煩用戶親自動手操做。當提示用戶名錯誤的時候，用戶確定會回到輸入框從新輸入，這個時候咱們已經聚焦到用戶框，並全選了以前的輸入，方面用戶進行刪除操做。相似這樣的交互，咱們應該提早作預判斷。

3. 狀態提示

什麼是狀態提示？有時候由於網絡緣由，點擊提交 button 以後，ajax 傳輸半天沒有響應，用戶等了半天頁面一點提示都沒有，這個確定會讓用戶焦急的。回頭看看 Gmail，一個把 ajax 發揮到極致的 web應用，在用戶體驗上作的也是至關給力的，登陸郵箱的時候一個 loading 動畫，旁邊還放了一個加載基本HTML（供慢速網絡使用），每個操做都有提示，提示中還有一個撤銷操做的按鈕，數據進行加載的時候，若是加載時間過長，期間會進行屢次不一樣的提示，並在最後給出一個確切的結果，對於一個登錄框而言，須要作到這些：

1. 一個明確的用於狀態提示的 box
2. 等待 3s，結果沒有出來，提示用戶繼續等待
3. 等待 6s，結果沒有出來，提示用戶網絡不順暢通
4. 設置 10s 爲超時，並告知用戶提交表單失敗

這些東西的實現並無太多的技術難度，可是能夠給慢速網絡下的用戶帶來很好的體驗和安全感。

4. 安全傳輸

用戶最擔憂的是帳號密碼被截獲，或者由於密碼一處多用，不但願別人看到密碼的明文，既然用戶擔憂，咱們就應該想辦法來處理。

把密碼和時間戳疊加，而後加密，傳到後臺的是加密的結果以及這個時間戳，以下：

// 前端
t = new Date();
s = encode(pwd + t);
post(s, t)

// 後臺
decode(s) === pwd + t

這樣就能夠保證密碼的隱蔽性，若是 hacker 不知道 decode 函數，即使是拿到了 s 和 t，也是徒勞。關於安全傳輸，以前也寫過相關的文章，OAuth認證原理及HTTP下的密碼安全傳輸。若是要作到在用戶輸入的時候就絕對安全，那就必須使用相似 支付寶安全插件 這樣的東西了。他的原理就是在頁面中嵌入一個控件，這個控件與頁面之間是相互屏蔽的，在控件內部輸入也只有控件拿獲得輸入信息。

5. 數據走緩存

表單提交首選應該是 post，可是也不排除會用 get 方式提交，那麼這個時候就應該考慮數據緩存了，若是請求的 url 相同，程序就會直接從瀏覽器的緩存中拿數據，並給出狀態是 status: 200 OK(from cache)，爲了不這些常識性的問題，記得在請求的參數中加點東西。

_t = new Date*1
_n = Math.random

爲了保證參數的絕對惟一性，甚至能夠把 時間戳 和隨機數疊加起來用

_s = (new Date*1 + Math.random*1E5)/1E5

6. 漸進加強

漸進加強這個詞通常是，不支持 javascript 或者對 javascript 支持度不太好的瀏覽器上利用其它方式實現，或者告訴用戶什麼緣由不能用，就是一種蛻化處理。目前不支持 javascript 的瀏覽器應該是絕跡了，固然也不是絕對，kindle 內置的瀏覽器對 javascript 的支持度就不高，或者根本就不支持。還有一種狀況是用戶禁用了 javascript，這個比例很小，開發者會這麼幹，通常的用戶不會亂改瀏覽器設置。可是咱們的程序，尤爲是關鍵的部位（如搜索，登陸，註冊等）必需要考慮這一少部分羣體。通常採用的方式是：

1）使用 noscript 標籤，這個是最經常使用，也是最實用的。

2）hack 方式，document.write("<" + "!--")

document.write("<" + "!--");
// code...
// 若是瀏覽器不支持 javascript，將顯示這中間的內容
// code...
document.write("--" + ">");

這是一種特別巧妙的處理手段，也是值得推薦的。

7. 瀏覽器後退按鈕

這個在註冊或者登錄的時候是一個廣泛的問題，登錄以後，跳轉到另一個頁面，個人鼠標有兩個側鍵，是用於前進和後退的，有時候會誤點側鍵，這個時候頁面又會回到以前的登陸頁面，但事實是用戶已經登陸了，全部頁面的狀態都應該是已登陸的，無論什麼狀況下都不該該讓用戶在看到這個頁面。用戶的點擊操做會引起上面的問題，而程序 history.go(-1) & history.back() 也會有同樣的bug。

這樣的問題處理方案比較簡單，ajax 拿到 success 的狀態碼時馬上作跳轉，可是這裏不能用 window.location.href，這樣瀏覽器仍是會記錄這個登陸歷史，應該使用 window.location.replace，替換當前歷史記錄。

8. 記住密碼

用戶最煩的就是每次登陸頁面都要輸入長長的帳號密碼，若是沒有勾選「記住密碼」，則用戶的登陸狀態保存在回話的 session 中，關閉頁面或者瀏覽器的時候，回話結束，session 被刪除，這樣當用戶下次登陸的時候又須要從新輸入密碼。表單頁面的「記住密碼」複選框默認狀態應該是已選擇，用戶的潛意識行爲都是要少操做的。

當用戶提交信息成功以後，直接在 cookie 中保存帳號密碼？這樣的作法顯然是不合理的，密碼怎麼可以明文保存呢，有人會想到加密處理密碼而後再保存，或者使用服務器來設置 cookie，這些作法都是能夠的，不過最好的方式是，當用戶成功提交信息時，服務器給前端提供一個 token，這個 token 是用於自動登陸的，咱們只須要保存 token 就好了，這樣就很好的避免了 cookie 中存放用戶隱私信息了。

還有一個要注意的是，當用戶取消了「記住密碼」的複選框時，應該當即清除相關 cookie。

2、其餘相關的幾個點

1. 用戶忘記密碼

若是用戶很長時間沒有來你的網站，他可能會忘記本身設置的密碼，一些奇葩的用戶甚至會忘記本身的用戶名，可是用戶永遠是沒有錯的，出錯的只有咱們的程序和寫程序的人。對於忘記密碼的人，能夠在填寫密碼的旁邊加上一個連接 「忘記密碼？」，讓用戶利用郵箱或者綁定的手機來找到密碼，對於忘記密碼以及用戶名的人，內傷中... @undefined 13# 14# 正解

2. 腳本注入

表單信息應該作正則匹配，或者信息的過濾，防止腳本注入，這個主要是後臺要考慮的問題，就很少說了。

3. 屢次提交

咱們發微博的時候常常會遇到的問題，由於網絡緣由，會屢次點擊發布按鈕，這個問題有多種處理方案：

• 發佈以前先從服務器拿 token，該 token 只有一次有效
• 後端判斷必定時間內用戶發佈的多條信息，相同的信息去重
• ...

3、容易出錯的幾個知識點

1. setRequestHeader

利用 ajax 來 post 信息，有的人可能遇到過，後臺拿不到數據。緣由是沒有重寫 請求頭的 Content-Type，

xhr.open("POST", url, true);
xhr.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xhr.send($.param({
    "user":$("#user").val(),
    "pwd":$("#pwd").val()
}));

通常瀏覽器不支持 GET 方式時 xhr.send 中添加參數，可是 POST 是能夠，也是必須的，若是沒有設置 Content-Type 的頭部，數據送到後端便沒辦法解析成 key-value 的模式，後臺(PHP)經過 $_POST 也拿不到數據。

2. checkbox

這裏也是一個體驗問題，一些人把 checkbox 和他相關的文字分開寫，結果沒有使用 label 來指向，如：

<input type="checkbox" checked="checked" />記住密碼

很顯然，咱們點擊後面的文字是不會讓 input 改變狀態的，有些人會這麼處理：

<label><input type="checkbox" checked="checked" />記住密碼</label>

這樣處理以後，點擊文字固然能夠選中 input，可是這種處理方式是不合理的，label 原本就是標記 input 框用的，他的內容應該是文字，不該該包含 input 這個框，因此合理的作法應該是這樣：

<input type="checkbox" checked="checked" id="rem" />
<label for="rem">記住密碼</label>

4、小結

上面說了一大堆，不少問題都是站在用戶的角度去思考的，咱們是程序員，可是咱們也是用戶，咱們會吐槽，可是咱們也會被吐槽。

把用戶體驗作到極致，這個十分重要，不要放過任何一個細節！