關於Web App
隨著web 2.0時代的到來,越來越多的應用程式都是基於Web環境來構建的。這樣做的好處顯而易見,使用者可以方便地使用瀏覽器來訪問應用,而不需要安裝用戶端程式。而在企業內部,很多應用也都採用了這種模式,以便於安裝和部署,特別是在業務變化頻繁,需要經常對應用程式進行更新的情況下,Web App更是為我們提供了很大的便利。
Web App作為Web環境中的應用,和網站以及傳統的Winform式應用有著千絲萬縷聯絡,同時也有很明顯的區別。
與網站相比:
共同點在於使用者都是通過瀏覽器來訪問,不需要安裝其他用戶端。
區別也很明顯,網站的功能在於展示,使用者訪問網站的目的就在於擷取資訊;而WebApp則不然,使用者訪問它更重要的目的在於互動,執行各種操作,不僅僅要從中擷取資料,還要嚮應用中儲存資料,並讓應用執行自己所需要的功能。
與Winform式應用相比:
共同點在於二者都是應用,都會完成一定的業務功能。
區別的一方面在於安裝和部署的方式,Web App是通過瀏覽器來訪問的,不需要經過繁瑣且耗時的安裝過程,直接就可以使用。而且,當系統升級的時候,使用者也不需要重新部署,只需要在瀏覽器中重新開啟就好。
區別的另一方面在於二者所提供的使用者體驗不同,因為瀏覽器的限制,WebApp帶給使用者的體驗還比不上傳統的Winform式應用,儘管現在有了很多可以在瀏覽器中啟動並執行類似於富用戶端的技術,像Silverlight、Flex等等,但想要提供與Winform式應用一樣豐富的體驗,還有很多需要努力的地方。
關於Web App前端設計
在架構上,不管是何種應用,在構建的時候都會體現出分層的思想。最經典的就是三層架構:表現層、商務邏輯層和資料層,而Web App前端設計所關注的就在於表現層。
前端設計的目標想要設計出合理且易於讓使用者使用的Web App介面,讓使用者獲得最好的體驗,從而更好地使用應用來完成所需要的功能。
為了達到這個目標,有三點原則可供遵循,那就是:簡單、美觀和規範。接下來讓我依次對其進行說明。
原則之一:簡單
簡單的目的就是要方便使用者的使用,但是要簡單到什麼樣的程度呢?用什麼標準來衡量我們的介面設計是否簡單呢?
我認為有兩點基本的標準:
l 不需要思考——介面上所有元素所提供的功能一目瞭然,沒有歧義,易於理解。
l 不需要學習——不需要複雜的培訓,所有的功能遵循操作的習慣,直接上手可以使用。
還記得之前有人把全自動的相機叫做“傻瓜”相機,其實我們所要設計的就是“傻瓜”式的應用介面,進而讓我們的應用成為“傻瓜”式的應用,那樣會贏得更多客戶,而不是讓人望而生畏。
想要達到這樣的標準,我們需要怎麼做呢?
首先,介面上的元素要少,放置太多隻會讓使用者覺得不知所措,需要仔細觀察和思考之後,才知道對哪些元素進行操作才能夠達到自己的目的。
我們經常會在一些產品的介面上看到許多不必要的元素,比方說在輸入連絡方式的時候,有“電話”、“地址”、“傳真”、“手機”、“Email”,這些都沒有問題,如果出現“地址2”、“電話2”等備用的資訊,我們會發現它們對於絕大多數使用者來說都是沒有任何意義的,也不會用到,只是為了以防萬一,對於這些元素,我們大多可以刪除掉。
其次,要讓應用的後台做更多的工作,儘可能地把更多的操作自動化,而不是把所有的任務都交給使用者完成。這樣會減少使用者的操作,同時也就減少了出現誤操作的可能。
接下來我們以Google翻譯為例,來理解一下上述的內容,1所示。
圖1 Google翻譯
首先,在Google翻譯中,介面上的元素很少,可供操作的主要就是“源語言”、“目標語言”、“翻譯”按鈕,以及一個大大的輸入框,每個元素都很容易理解,輸入框也很明顯,讓我們一看到就知道是要把需要翻譯的內容放到其中。
當我們在輸入框中輸入內容的時候,應用的後台功能就開始顯示威力了,它會自動地幫我們識別出語言的種類,然後自動地把翻譯出來的結果放在結果顯示的位置。我們所有做的操作只是輸入了想要翻譯的內容。
試想一下,如果沒有達到簡單的效果的話,我們會怎麼做呢?首先我肯定需要選擇“源語言”和“目標語言”,輸入完所要翻譯的內容之後,再點擊“翻譯”按鈕,然後才能夠看到結果。和Google翻譯所提供的簡單相比,這樣的方式多了很多不必要的操作。
上述的簡單更多關注的是介面元素,其實還有另一個方面的簡單,那就是操作上的簡單。
對於系統的操作,我們會使用輸入工具主要就是兩種:滑鼠和鍵盤。(當然還有觸控螢幕的方式,而且已經在手機和平板電腦上的應用越來越廣泛,但暫時不在我們討論的範圍之內。)那麼我們的目的就很明確了,想要達到操作上的簡單,一方面要減少點擊滑鼠和敲擊鍵盤的次數,另一方面要減少滑鼠和鍵盤操作之間切換的次數。
在此我依然用Google的產品作為例子,請看圖2中Google日曆輸入活動的介面。
圖2 在Google日曆建立活動
比方我們現在要建立的活動是“到會議室開會”,時間在上午7點,那麼我們在Google日曆中所要做的操作就是:點擊日期(滑鼠點擊一次)→輸入內容“上午7點到會議室開會”(鍵盤輸入)→確定(斷行符號一次)。就是這麼簡單,活動的內容和時間都已經分析完畢,新的活動已經建立。
如果是在Outlook中做同樣的一件事,需要什麼樣的步驟呢?圖3顯示的是Outlook“建立約會”的介面。
圖3 在Outlook中建立約會
在Outlook中步驟有:選擇日期(雙擊滑鼠)→輸入主題(鍵盤輸入)→輸入地點(鍵盤輸入)→取消對“全天”的選擇(滑鼠點擊)→選擇開始時間(滑鼠選擇)→選擇結束時間(滑鼠選擇)→輸入內容(鍵盤輸入)→儲存關閉(滑鼠點擊)。
不需要再做過多說明,一切都已經很清楚了。我們不僅多做了很多滑鼠和鍵盤的操作,而且還多次在滑鼠和鍵盤之間進行切換。和Google日曆相比,操作複雜了很多。
簡單這一原則會節省使用者的時間,而時間是最寶貴的,這也是我把“簡單”放在第一位的原因所在。
原則之二:美觀
對於任何一個應用的介面來說,美觀都是非常重要的。應用的介面就像是人的臉,看上去讓人覺得舒服,然後才會有更多的人喜歡它,否則即便功能再強大,使用起來也會讓人覺得不舒服。
然而,美觀並不意味著我們要使用很多的圖片、很多種顏色。使用圖片會降低頁面載入的效率,而使用過多顏色,不僅不會讓人覺得美觀,反而會覺得亂七八糟。
組成頁面的元素可以主要可分為三類:文字、圖片和控制項。所以,想要達到美觀的效果,我們同樣需要基於這三類元素來思考。在此我想借鑒一下《寫給大家看的設計書》一書中所提到的幾點排版原則,那就是:
重複——同樣作用的元素的風格、顏色統一
對比——不同作用的元素,要有鮮明的對比,可以使用字型、顏色等等方面來達到對比的效果。
對齊——靈活使用靠左對齊、靠右對齊、置中對齊等對齊,讓元素的排列顯得整齊、規矩。
親密性——有關聯的元素要儘可能“親密”地排列,而無關聯的元素之間要有足夠的“距離”來產生美。
還是用例子來說明,首先我們來看圖4中的介面:
圖4 樣本介面
這個介面中有不少問題,讓我們採用上面的四點原則來檢查一下。
重複:這一點介面上體現的還不錯,各種文字和介面的風格還是很統一的。
對比:這裡的問題在於上面的標題部分和下面的內容部分之間的對比不夠強烈,僅僅是對字型加粗,不能夠給人一種很醒目的感覺。
對齊:內容部分的文字標籤和控制項都採用了靠左對齊,但第二行的文字過長,看起來比較亂;並且下面的兩個按鈕與內容框之間沒有對齊(應該是靠右對齊)
親密性:文字標籤和控制項本來應該是比較“親密”的關係,但是卻因為都採用靠左對齊的方式,離得比較遠。
針對以上問題,我們可以對上面的介面做出一些調整,5所示:
圖5 調整後的介面
首先我們把標題的字型調大,加強了與內容文字的對比,顯得更加醒目;然後把標籤文字設為靠右對齊,與相應的控制項的親密性大大加強;最後調整最下面的按鈕,使其與內容框右側對齊,達到了美觀的目的。
由此看來,只要我們理解並使用好這九個字,就能夠設計出比較美觀的介面了。
原則之三:規範
作為程式員,大家都知道在項目開始之前要制定比較嚴格的代碼規範,這樣才能夠讓代碼的可維護性更好。但是,這些規範往往都是針對的都是進階語言,像Java、C、C++、VB等等。
其實,Web App的前端頁面同樣也是由程式碼群組成的,只不過是HTML樣式的代碼,對於這些代碼,也同樣需要規範。並且,和編程用的進階語言相比,這裡的代碼還有特殊需要注意的問題:
l ID屬性的設定——在編程的時候,我們都會給變數命名,而在前端介面的代碼中,各個元素也需要有自己的名字,那就是ID屬性。經常會看到介面中的元素只有name屬性,而沒有id屬性;或者id屬性的名稱就是button1、button2之類無意義的名稱,這樣的情況都應該得到規範。
l 瀏覽器的相容性——比方說,在前端介面的代碼中,每個元素的屬性值可以放在引號之中,也可以把引號省略,有些瀏覽器具備比較好的錯誤修正能力,也能夠正確地顯示介面。但是為了達到瀏覽器的相容性,還是建議把所有屬性值都放在引號之中,那樣可以避免不必要的麻煩。想要讓應用能夠在更多的瀏覽器中使用,就一定要有規範來限制,否則很可能就需要限制應用只能在特定的瀏覽器中使用了。
l CSS的使用——對於元素的樣式,要盡量使用CSS來控制,而不能隨心所欲地使用各種格式來控制,否則,一旦想要統一調整介面元素的風格,那就會成為前端開發人員的噩夢。
除了代碼的規範之外,頁面元素的布局也應該規範,不過,我們在很多時候都可以使用CSS來規範,所以在此不再贅述。
在以上的內容中,我簡單地介紹了進行Web App前端設計所需要遵循的三點原則,希望能夠對大家設計Web App的介面起到一些協助作用,進而能夠做出漂亮、擁有良好使用者體驗的系統,讓使用者喜歡使用開發出來的產品。