一、性

§確認郵件：

當用戶注冊時，應(yīng)向他們發(fā)送帶有點擊確認

郵箱的鏈接的郵件。如果用戶更新他們的郵

箱地址，則要再次重復這個工作流程。

§身份管理：

當存儲密碼時，首先對它們進行加鹽和散列

操作，然后再用現(xiàn)在廣泛使用的crypto庫。

如果你不這樣做的話，把身份管理轉(zhuǎn)由給

/GitHub/Twitter/等，用OAuth就能

做到。

§加密：

所有證書問題，還有什么比SSL更好。使用它

吧。還可以使用HSTS。

§憑證：

不要把服務(wù)器身份信息(API密鑰、數(shù)據(jù)庫密

碼等)放到版本控制里，否則就泄密了。

二、工程：動畫

所有的愛，都是神圣的。但別為應(yīng)用里的所

有元素添加動畫。因為大多數(shù)CSS動畫都會出

發(fā)布局重繪;盡可能地限制自己使用

transform和opacity。

避免進行緩慢的過渡運算，如果非要使用，

那么確保它是針對某個屬性的

(如，”transition:opacity 250ms ease-in

”，而不是”transition:all 250ms ease-

in”)。

三、用戶體驗(UX)

§表單：

當提交一個表單后，用戶應(yīng)收到提交后的反

饋。如果提交后不向用戶發(fā)送一個不同的頁

面，那么就應(yīng)該有彈框或alert一些信息，以

便讓用戶知道這次提交是否成功。

§登錄重定向：

如果用戶打算在你的網(wǎng)站打開一個頁面，但

并沒有登錄，那么他們應(yīng)該首先接收到一個

能登錄的頁面，并在登錄后重定向到一個他

們原本想打開的一個頁面(當然，前提是已得

到授權(quán))。

如果他們嘗試登錄，但提供了一個錯誤的密

碼，這時，用戶有可能是忘記了密碼，那我

們就應(yīng)該提供一個視覺線索來提醒他們，要

有一個重置密碼的選項。

四、電子郵件

訂閱設(shè)置：

任何發(fā)送到用戶的email，都應(yīng)該至少包含一

個鏈接，能鏈接到修改他們的郵箱設(shè)置的應(yīng)

用程序頁面，并且每個郵件都有一個單 獨的鏈接，能取消訂閱。 千萬別讓用戶為了取消訂閱而向你發(fā)送郵件 。 五、移動端 雖然你不必開發(fā)移動端…但不管你是否做， 你都應(yīng)該確保這是一個積極的決定，因為這 會對你的應(yīng)用程序設(shè)計和工程有實質(zhì)性影響 。 下面的注意事項是假設(shè)你已選擇移動端作為 你的平臺之一。我碰巧選用Grunt作為我的構(gòu) 建工具，所以我得使用一些Grunt-specific 插件，但你可能使用類似的Java構(gòu)建工具。 六、工程 單頁面應(yīng)用： 現(xiàn)今單頁面(SPA)是王道。它的主要優(yōu)勢是很 少加載整個頁面–只需加載所需資源，并且 無須反復重載相同的資源。如果你才剛剛開 始開發(fā)一個新的web應(yīng)用，那它很可能是SPA 。 七、用戶界面(UI) 分辨率： 當你開發(fā)MVP(Minimum Viable Product– 簡化可實行產(chǎn)品)時，不用先急著兼容各種尺 寸的UI，那是等你的產(chǎn)品一下子火了之后才 需要去做的事情，但要確保支持主流設(shè)備(尺 寸)。 八、UX：寬帶 相對于桌面端，移動端的一個大主題是帶寬 ，它是非常珍貴的資源。因此，不應(yīng)該放過 任何能減少請求的機會，讓它們盡可能地采 用異步請求，并減少請求資源的大小。 九、用戶體驗：表單 這是一個很好的建議：保持表單和工作流程 的簡易性，當你針對移動設(shè)備作為部署平臺 時，這點尤其重要。因為沒有人愿意在手機 上填滿5頁的表單。 我希望這列表對于剛開始開發(fā)款Web應(yīng)用 的同學們都有所幫助，甚至對那些之前不熟 悉前端的一些優(yōu)化技巧的后端或設(shè)計師。 廣州創(chuàng)優(yōu)視覺科技有限公司講述的Web應(yīng)用需要了解的事，希望能帶給你幫助