UI小知識 — State與Status有什麼不同?

不知道大家在做圖時,有沒有遇到命名的問題,到底說明組件的狀態要用 state 還是 status?這兩個名詞的翻譯都是「狀態」,但使用上好像有點不太一樣,很有趣的是,這個問題不是只有介面設計師會有,工程師也會有相同問題,應該說只要母語不是英文的人,都很容易混淆,所當你上網 google「state vs status」時,不同領域的人,就會給你不同的解釋與答案,而這篇文章就是要用介面設計的角度,來討論 state 跟 status 的差異。

名詞定義

首先我們先看一下這兩個名詞在作為「狀態」使用時的定義:

State | 狀態
【名詞】【可數】
(英)| The mental, emotional or physical condition that a person or thing is in
(中)| 人或物的心理、生理或是物理條件狀態
來源 | https://www.oxfordlearnersdictionaries.com/definition/english/state_1?q=state

Status | 狀態
【名詞】【不可數】
(英)| The situation at a particular time during a process
(中)| 一個流程裡特定時間的情況
來源 | https://www.oxfordlearnersdictionaries.com/definition/english/status?q=status

從字典的解釋中我們可以知道 state 與 status 在英文的解釋與詞性其實是不一樣的,state 強調的是不同條件下的狀態,是可數名詞,所以一個人或物的狀態可以被分為幾種明確的狀態,例如水有不同的狀態:液態、固態、汽態,這時候就會使用 state;而 status 通常會使用在某個時間點狀態下的結果,所以不同的時間點,可能會對應出不同或是相同的結果,是不可數名詞,例如 Marital Status(婚姻狀態), 這時指的就是某個時間點下婚姻的狀態。

從字義上似乎可以這樣理解,state 比較像是一個條件狀態的集合包,一個人或物體或許在某些條件下,會有不同的狀態,但狀態沒有顯現出來不代表不存在,而是只能在特定的條件來進行切換,而 status 比較像是一個流程中特定時間下的結果,就算有不同的狀態,但這些狀態不能同時存在,而且在狀態之間可能會有相依關係,例如前面的婚姻狀態,可能是單身、已婚、離婚、喪偶,一個時間點下只會存在一種狀態,不會同時單身又已婚。

工程師的 State 與 Status

工程師也常常在變數命名時到相同的問題,像是在 StackExchange 裡關於這個問題就有很多答案,而我覺得最為好的答案是這個

  • state is used to describe a stage in a process (e.g. pending/dispatched).
  • status is used to describe an outcome of an operation (e.g. success/fail).

在工程裡面,state 比較強調的是一個 process(程序) 裡面的 stage(階段),而 status 比較強調的是 outcome(結果),其實跟前面的定義有點像,但這邊的 state 的 process 會比較像是一個事件集合所包含的不同階段,這些階段是同時存在的,只是發生的條件不同,而 outcome 的結果就只有 success/fail,狀態不會並存。

而在web端常見的 HTTP狀態碼(HTTP response status codes),就有五種常見的狀態(status)碼:

  1. 資訊回應 (Informational responses, 100199),
  2. 成功回應 (Successful responses, 200299),
  3. 重定向 (Redirects, 300399),
  4. 用戶端錯誤 (Client errors, 400499),
  5. 伺服器端錯誤 (Server errors, 500599).

英文使用的就是 status ,不是用 state,因為這些狀態是結果,每一次的訪問,只會有一個結果,不會同時存在。但有沒有可能是用 state ?前面HTTP 回應的結果是從客戶端(client-side)所回應的結果,但如果是從服務端(server-side)來看, HTTP 的回應狀態,的確可以視為一個 process 裡不同的 stage ,這時如果使用的是 state 似乎也很合理。

介面設計師的 State 與 Status

介面設計師在做組件(compoenent)的設計時,九成以上是使用 state,因為我們關注的是組件有那些條件狀態,而每個條件下對於組件就會給予不同的樣式(style),例如:按鈕狀態(button states):

不同的button state

這些狀態的集合,就會是一顆按鈕,而在不同的控制情境下,出現的按鈕的狀態就會不同,相同特性還有表單(form)的輸入框(input),也會有不同的 state,那介面設計師什麼時候會用到 status ?通常會用在描述畫面的狀態時,像是結果頁(result pages)所對應到的資料的回應狀態,我們就有可能會使用到 status,例如:交易成功頁(success page)、交易失敗頁(failure page)、錯誤狀況頁(error page)…等等,但我們統稱這些畫面是 response status pages / result pages ,跟前面的 HTTP response status codes 有點類似,但其實這是從產品流程的角度來描述頁面,但從介面設計師的角度這些狀態的頁面,也能說是頁面的不同state。

UI Stack 裡的 State

另外,介面設計師可能也有聽過 UI Stack,是由產品設計師 Scott Hurff 在他的文章《How to fix a bad user interface》提出來的概念,主要的內是說明如何透過 UI Stack 來修正 UI 體驗,這邊先不細談他的概念,但他提出來的 UI Stack 裡,每個 UI (a page/screen)畫面應該要包含 5 種 states ,這邊使用到的詞就是 states 而不是 status,所以我們可以知道,這邊他想強調的是一個畫面所該包含的所有狀態結構,所以即使是結果頁,也應該要有這五種狀態 ,這篇文章明確的定義出 UI 應該要有的五種狀態,就好像水被定義有三種確定的狀態一樣。(這篇是介面設計師必讀的文章)

UI Stack

結論

寫這篇文章,主要也是因為我在做設計時, 對於這些名詞的選用也會感到困擾,後來發現其實許多人也有遇到相同的問題,畢竟我們的母語不是英文,這麼細微的差異其實不容易發現,像是之前寫需求與動機的文章,文中也有提到,需求所對應到的英文單字是「needs」、「demand」、「requirement」,雖然中文都翻為需求,但在英文的意義上是截然不同的解釋,但多數的人可能都選擇混用,所以導致概念上有點混亂,這篇文章也是想透過一些例子說明,來讓大家稍微了解 state 與 status 的差異。

發表者:Rei

介面設計師

留言

在下方填入你的資料或按右方圖示以社群網站登入:

WordPress.com 標誌

您的留言將使用 WordPress.com 帳號。 登出 /  變更 )

Google photo

您的留言將使用 Google 帳號。 登出 /  變更 )

Twitter picture

您的留言將使用 Twitter 帳號。 登出 /  變更 )

Facebook照片

您的留言將使用 Facebook 帳號。 登出 /  變更 )

連結到 %s

%d 位部落客按了讚: