Windows 應用程式中 UX 設計的思考方式 - ToC / ToB / 監控 / 現場終端 / 常駐工具中優先什麼的判斷表

· · UX, Windows 開發, UI 設計, 無障礙, 業務應用程式

思考 Windows 應用程式的 UX 時,一開始從「看起來現代嗎」「留白漂亮嗎」進入的話,容易把順序搞錯。

在 Windows 桌面,UX 不是只靠外觀決定。

  • 能用鍵盤完結到哪裡
  • 以滑鼠為前提,還是以觸控為前提
  • 長時間使用,還是偶爾用幾分鐘
  • 監控、輸入、還是現場終端
  • 出錯時什麼會壞
  • 是否能承受文字放大、對比主題、輔助技術

這些全部合起來是 UX。

更麻煩的是 ToC 和 ToB 重心不同。 但是這裡想成「ToB 所以資訊塞滿就好」「ToC 所以柔和輕量做就好」的話,通常某處會出事。

例如同樣是 ToB,

  • 會計輸入或收發貨管理這類的事務系應用程式
  • 工廠、倉庫、接待、檢查裝置這類的現場終端
  • 24 小時監控或維護對應的運營畫面

中,好的 UX 的條件相當不同。

相反 ToC 中,

  • 個人用的小工具
  • 影像編輯、音樂製作、投資分析這類的上級者偏向工具

中,UI 的密度和快捷鍵需求也完全不同。

Microsoft 的 Windows 向設計指南也重視 Windows 應用程式的設計要 直覺且易於存取、跨輸入方式和外形規格一致運作12

本文將 Windows 應用程式的 UX 整理為 各用途的判斷表。 目的是讓設計審查或畫面設計的初期階段容易區分「這個應用程式該優先什麼」。

1. 先講結論

相當實務偏向地先粗略說是這樣。

  • ToC 中先優先 首次理解的易度、安心感、設定的少、導線的自然
  • ToB 中先優先 持續效率、誤操作防止、鍵盤對應、穩定的配置
  • 但是 ToB 的現場終端 比起密度更優先 明快、大的操作對象、短的導線
  • 但是 ToC 的上級者向工具 比起簡單更優先 資訊密度、快捷鍵、客製化性
  • Windows 應用程式中包含 鍵盤 / 滑鼠 / 觸控 / 文字放大 / 對比主題 / 輔助技術 思考 UX,之後設計不易壞134567

最初真正該決定的不只 ToC 還是 ToB。 先想語言化的是以下 5 個。

  1. 誰使用(初學者、熟練者、混在)
  2. 在哪使用(桌上、會議室、現場、工廠、接待、戶外)
  3. 用什麼操作(鍵盤、滑鼠、觸控、筆、條碼、輔助技術)
  4. 使用多少(首次中心、偶爾、每天、整天)
  5. 出錯時的成本是什麼(輕、重、危險、稽核對象)

看見這 5 個,UI 的密度、導航、快捷鍵、確認對話方塊、客製化性的優先順位會相當容易決定。

2. ToC / ToB 是入口,但不是答案

ToC / ToB 這種分法作為最初的入口很方便。 但 決定 UX 正確答案的力量比起買家的種類,使用方式的種類更強

例如粗略以 2 軸看的話是這種感覺。

  首見重視 持續效率重視
ToC 個人用工具、設定應用程式、同步工具 影像編輯、音樂製作、投資分析、開發支援工具
ToB 接待終端、倉庫終端、檢查終端、資訊站 會計輸入、收發貨、監控、分析、支援運營

也就是,

  • ToC = 總是輕的 UI
  • ToB = 總是高密度 UI

不是。

Windows 應用程式的設計指南也重視 能跨設備、輸入種類、外形規格一致使用,從無障礙觀點看也不只是障礙有無,包含 明亮的戶外、共享空間、安靜的地方、吵雜的地方 這類環境約束一起思考很重要。12

所以看過 ToC / ToB 後,再以下軸切開比較推薦。

越偏首見重視 越偏持續效率重視
學習成本 重視不用說明就能使用 允許某種程度的熟練
資訊密度 少、縮小 多、重視一覽性
鍵盤操作 輔助性 相當重要
客製化 少或自動最佳化 想調整欄、顯示、佈局、快捷鍵
誤操作對策 安心感、易還原 防事故、稽核、確認、權限控制
畫面轉移 自然淺 優先作業效率,密也可

先切開這裡,會議中的「感覺現代」「感覺業務風」議論會大幅減少。

3. 以一頁看的各用途判斷表

先放實務上最好用的表。

用途 典型使用者 最優先事項 適合的 UI / 導航 想避免的
ToC 向工具 / 個人用應用程式 首見使用者、低~中頻率使用 不迷惑能開始、安心感、設定少 單一畫面、上部導航、淺的導線 資訊過多、專門術語滿滿、設定畫面的叢林
ToB 事務輸入・後勤 每天使用的事務擔當、支援擔當、操作員 持續效率、鍵盤完結、防誤輸入 左側導航、清單/詳細、一覽 + 明細、快捷鍵 只有留白多的卡片 UI、隱藏的操作、每次的模態確認
ToB 監控・運營 維護擔當、監控擔當、值班對應 不遺漏異常、知道狀態轉移、安全的操作 儀表板 + 下鑽、左側導航、時序・日誌 只用顏色傳達狀態、花俏的演出、危險操作外觀輕
ToB 現場終端・裝置 UI・資訊站 站立作業、戴手套、急作業、非 IT 專門使用者 易見、大的操作對象、短的導線、不易失敗 觸控前提的單功能畫面、精靈型、明確的狀態顯示 小的按鈕、hover 前提、深的選單、多的自由輸入
專家向編輯・分析工具 熟練使用者、長時間使用 資訊密度、快捷鍵、客製化、作業持續性 頁籤、多窗格、左側導航、內容選單 為初學者隱藏過度、把功能趕到深的層
常駐工具・通知區應用程式 短時間偶爾碰的使用者、背景使用 能立刻開啟、不打擾、知道背景狀態 通知區選單、飛出、最小的主畫面 總是出現在前面、通知連打、瑣事搶主畫面

光這個表方向就相當看得見。 特別重要的是 即使是 ToB 現場終端高密度 UI 也不是正解、以及 即使是 ToC 上級者工具效率比起輕量才是正義

4. 各用途的設計方針

4.1 ToC 向工具 / 個人用應用程式

ToC 的小 Windows 應用程式中,先是 「啟動後立刻能用」 相當強。

特別想重視的是以下點。

  • 最初的 1 畫面就知道是做什麼的應用程式
  • 主要操作縮到 1 個或 2 個
  • 空狀態不是不親切
  • 危險的操作能取消
  • 不要從一開始就把設定項目全部顯示

這裡易做的是把技術上能做的全部排出來。 但是 ToC 的輕量工具中,比起 多功能 立刻能用 更容易成為價值的場面多。

Windows 的導航設計中,所有應用程式沒有共通的正解,先是 一致性、簡單、明快 被重視。使用標準控制項或標準位置,預測會容易。8

所以 ToC 向中,

  • 小的話是單一畫面
  • 區段並列的話上部導航
  • 設定階段性顯示
  • 主要動作明亮,其他安靜

這種程度的整理通常就夠。

但是 ToC 中變成 照片編輯、影片編輯、作曲、投資分析、開發支援 這類上級者向應用程式的話事情會改變。 那種情況比起 ToC 這個標籤,看 熟練度使用時間 比較接近正解。

4.2 ToB 事務輸入・後勤

事務系 ToB 應用程式重要的比起外觀的輕快是 作業不停

每天使用的使用者幾天就會習慣 UI。 之後有效的是以下這些。

  • 只用鍵盤能走到哪裡
  • 是否容易在一覽和明細間來回
  • 重要的欄或狀態是否一眼就知
  • 是否能保持篩選或排序
  • 錯誤是否能當場修正

Microsoft 的鍵盤無障礙指南也把應用程式 鍵盤能到達所有功能 視為重要,推薦實作 Tab 順序、焦點、用 Enter / Space 操作、快捷鍵。3

另外,存取鍵不只無障礙,對喜愛鍵盤的進階使用者的效率提升也有效。適當場所也推薦包含自訂控制項支援存取鍵。9

事務輸入系中,作為導航 清單/詳細 相當強。 Windows 的導航指南也說清單/詳細適合 頻繁切換項目同時做詳細顯示或更新的用途,適合 郵件收件匣、聯絡人清單、資料輸入 這類情況。8

也就是說,這種構成相當自然。

  • 左邊放功能分類
  • 中央放一覽
  • 右邊或下方放明細 / 編輯
  • 上方放搜尋、篩選、主要命令
  • 常用的操作支援快捷鍵

相反想避免的是以下這些。

  • 每 1 操作 1 對話方塊
  • 欄太少一覽性低
  • 主要操作只在右鍵深處
  • 只用圖示表達意義
  • Tab 順序亂七八糟 Enter 和 Space 都不動

關於輸入錯誤,繫結欄位的驗證錯誤不用對話方塊而在畫面內顯示 比較自然。Windows 的對話方塊指南也推薦密碼欄等 結合脈絡的驗證錯誤不使用對話方塊,使用行內顯示10

4.3 ToB 監控・運營

監控・運營畫面的 UX 比起「易用」更早,不遺漏、不弄錯、不停 重要。

這裡想優先的大致以下。

  • 異常的有無一眼能知
  • 能知異常的重要度
  • 不只現在值,能追變化或時序
  • 危險操作的導線不太輕
  • 能立刻飛到日誌、歷史、原因調查

這類畫面中,狀態表現 是 UX 的中心。 狀態盡量用 顏色 + 文字 + 圖示 + 時刻 複數要素表現比較安全。 只用顏色表示狀態,容易發生遺漏或辨識錯誤,無障礙上也弱。11

導航,監控對象多的話左側導航,個別對象的深挖用下鑽,詳細用日誌或時序顯示,這樣整理比較易處理。 Windows 的導航指南也說左側導航適合 最上位項目多 或頁面切換不頻繁的構成。8

操作面,把命令只放一個地方也危險。 Windows 的命令設計指南推薦命令 能從按鈕、內容選單、快捷鍵、手勢等多個面使用、推薦 把所有相關命令放入內容選單或 CommandBarFlyout。只依賴 hover 出現的操作,觸控終端或輔助技術無法使用。1213

危險操作的確認對話方塊在這裡也重要。 但「總之什麼都確認」反效果。 真正想確認的是 停止、刪除、切換、遮斷、改寫 這類偏不可逆的操作。 要出對話方塊的話,

  • 在最初的 1 行明確寫發生什麼
  • 按鈕文字不是 OK / Yes 而是 刪除 / 停止 / 遮斷 這樣具體
  • 一定放安全側的按鈕

這 3 個至少要守。10

4.4 ToB 現場終端・裝置 UI・資訊站

現場終端在 Windows 應用程式 UX 中也相當別種。

  • 不坐
  • 可能戴手套
  • 只有單手空著
  • 不仔細看畫面
  • 有時間壓力
  • 在明亮現場或吵雜地方使用

這些條件普遍存在。

Microsoft 的無障礙指南也說好的 Windows 應用程式不只障礙有無,考慮 明亮的日照、共享空間、噪音、靜寂、烹飪中 這類狀況包含的環境約束很重要。2

另外觸控設計中有,

  • 觸控沒有 hover
  • 手指或手 遮擋(occlusion) UI
  • 畫面的一部分 手的姿勢上難以按
  • 視覺回饋重要

這類差異。4

所以現場終端中大致以下方向強。

  • 按鈕或清單項目要充分大
  • 接近 1 畫面 1 目的
  • 清楚顯示操作後的反應
  • 流程階段化
  • 輸入盡量從 自由輸入偏向選擇、掃描、定型
  • 狀態在畫面上部或中央明快顯示

相反想避免的是,

  • 小的文字
  • 小的點擊區域
  • 依賴 hover 前提的工具提示
  • 深的層級
  • 1 畫面大量資訊
  • 長的自由輸入

ToB 所以密度高比較好的粗略發想最容易失準的是這個領域。 這裡反而是 業務應用程式中也相當明快優先

4.5 專家向編輯・分析工具

專家向工具中,「請讓我易懂」比「請不要讓我停手」弱的情況有。

例如,

  • CAD
  • 波形解析
  • 影片編輯
  • 影像處理
  • 音樂製作
  • 開發支援
  • 資料分析
  • 稽核 / 診斷工具

這類。

這類應用程式中以下有效。

  • 資訊密度
  • 多窗格
  • 頁籤
  • 內容選單
  • 快捷鍵
  • 佈局保存
  • 欄或顯示項目的客製化
  • Undo / Redo
  • 作業狀態的還原

Windows 的導航指南也說 頁籤 適合想開關・排列多個頁面或文件的情況。8 另外 Windows 的命令設計中推薦命令在多個 UI 面共享,讓輸入方式不同也能到達同樣操作。12

這類工具中易做的是為了對初學者友善 把所有的藏在深的選單。 但是熟練者每天做幾百次相同的操作。 對他們來說重要的比起最初 5 分鐘的友善,使用 100 小時後也不疲倦

所以上級者向中

  • 高頻率操作放近
  • 輔助功能稍微深
  • 高度功能不刪除而整理
  • 保存顯示佈局
  • 鍵盤操作厚實

這樣設計容易有效。

4.6 常駐工具・通知區應用程式

常駐系中不要過度顯現應用程式的存在感反而是 UX。

例如,

  • 同步狀態
  • 連線狀態
  • 備份
  • 音訊 / 攝影機 / 裝置切換
  • VPN / 代理 / 啟動器
  • 通知中心

這類應用程式中主畫面常常不是主角。

想優先的是,

  • 能從通知區或小選單立刻碰
  • 知道現在的狀態
  • 只在必要時通知
  • 能從通知直接到必要操作
  • 主畫面不過度搶前面

相反想避免的是,

  • 瑣事出對話方塊
  • 每次啟動都開主畫面
  • 看不見背景動作的狀態
  • 通知太多全部被忽視

這類應用程式比起「擁有多少功能」,是否不打擾 更容易左右 UX。

5. 導航的判斷表

Windows 的導航指南說 對所有應用程式有效的 1 個導航設計不存在,以 一致性、簡單、明快 為原則。此外在使用者期待的位置放標準控制項,成為易於預測的 UI。8

實務上大致以下表切開比較容易整理。

模式 適合的情況 典型用途 注意點
單一畫面 + 篩選 主目的 1 個,功能也少 小的 ToC 工具、轉換工具、設定輔助 不要什麼都塞到 1 畫面
上部導航 同層級的頁面並列,想全部顯示 ToC 應用程式、小~中規模設定畫面 項目太多透視性變差
左側導航 最上位項目多,功能群明確 ToB 管理畫面、監控、管理控制台 深的層級用麵包屑或標題輔助
清單/詳細 頻繁切換項目同時看詳細或更新 收件匣、客戶一覽、單據一覽、資料輸入 清楚區分選擇狀態和編輯中狀態
頁籤 想同時開多個文件或作業對象 編輯器、分析工具、比較畫面 不要硬把所有功能頁籤化
麵包屑 層級深、容易失去當前位置 層級資料、分類樹、檔案管理 2 層以上深時有效

Windows 的導航指南特別顯示以下區分使用。8

  • 上部導航: 想所有導航項目顯示在畫面時
  • 左側導航: 最上位項目多時、不頻繁切換頁面時
  • 清單/詳細: 項目切換多、需要詳細顯示或更新時
  • 頁籤: 想動態開關多個文件或頁面時
  • 麵包屑: 在深的層級中想易懂顯示返回路徑時

簡言之導航不是「外觀的喜好」,而是 資訊結構和作業結構的反映

6. 輸入裝置和命令設計的判斷表

Windows 應用程式盡量支援多輸入方式比較靈活易用。Microsoft 的指南也推薦考慮 手勢、語音、觸控、觸控板、滑鼠、鍵盤 等盡可能多的輸入。14

另外 Windows 的平台控制項一定程度吸收多個輸入方式,自然使用標準控制項 是先強。48

實務上易用的整理是以下。

前提 優先的操作 這樣設計 想避免的
以鍵盤 + 滑鼠為主 Tab、Enter、Space、快捷鍵、右鍵 提高一覽性、主要操作支援快捷鍵、右鍵也厚實 只能用滑鼠按的、只有小圖示的操作
以觸控為主 大的目標、直接操作、可見的回饋 不依賴 hover、清楚顯示狀態變化、流程縮短 小的按鈕、依賴 hover、靠邊的細緻操作
混合環境 為同一命令準備多個路徑 並用工具列 + 內容選單 + 快捷鍵 只存在於 1 種輸入方式的重要操作
有自訂控制項 焦點、無障礙屬性、輔助技術對應 用標準控制項包、確認 UIA、加入 Focus 可視化 放可點圖片直接放、沒焦點

鍵盤方面特別以下重要。39

  • 只用鍵盤能到達所有功能
  • Tab 順序與視覺順序不要太偏差
  • Enter / Space 該按的元素能按
  • 重要功能有快捷鍵
  • 高頻率操作準備存取鍵或加速鍵

觸控方面以下重要。4

  • 沒有 hover
  • 手指或手遮擋 UI
  • 可按位置感覺比外觀窄
  • 需要視覺回饋
  • 適合直接操作的 UI 和適合間接輸入的 UI 不同

命令設計中 Windows 的命令指南相當參考。 特別重要的是 讓命令能從多個 UI 面使用12

  • 能從按鈕按
  • 內容選單也有
  • 也能用快捷鍵呼叫
  • 必要時也有滑動或手勢

然後推薦 把所有相關命令放入內容選單或 CommandBarFlyout。依賴只有 hover 中可見的操作,觸控專用終端會卡住。12

7. Windows 應用程式最低限不想漏的 UX 項目

從這裡整理不論用途最低限想掌握的。

7.1 能用鍵盤完結嗎

Windows 桌面中鍵盤不是「有就方便」而是相當本質。

Microsoft 的鍵盤無障礙指南也說鍵盤對應不只為了視覺或運動能力受限的使用者,以效率為目的選擇鍵盤的使用者 也重要。3

最低限想看的是以下。

  • Tab 順序是否自然
  • 有焦點可視化嗎
  • 能用 Enter / Space 按嗎
  • 有快捷鍵嗎
  • 右鍵相當的操作鍵盤也能呼叫嗎

樸素但這裡崩壞 ToB 的 UX 會相當痛。

7.2 文字放大、對比主題、無障礙

Windows 應用程式中文字大小或對比確實跟隨就能讓 UX 相當穩定。

Microsoft 的指南中推薦 可見文字的對比比至少 4.5:1,要求文字放大時 控制項或容器也一起重設大小・重新配置56

此外對比主題中推薦,

  • 不要把顏色硬編碼
  • 使用 SystemColor / Brush 資源
  • 用 4 種對比主題試

7

這裡易崩的是,

  • 以固定寬度為前提的標籤
  • 像素固定的按鈕高度
  • 只用顏色傳達意義的設計
  • 自訂繪製不跟隨主題的 UI

這一帶比起「無障礙對應」,看作 做長期不壞的 Windows UI 的基礎工程 比較合適。

7.3 不濫用對話方塊

對話方塊方便但用太多會變成作業的敵人。

Windows 的對話方塊指南中對話方塊是 需要通知、批准、追加資訊輸入時的模態 UI,推薦至少放 1 個 安全非破壞性的操作(Close、Cancel 等)。此外推薦按鈕文字用 具體的回應10

重要的是 什麼都不要對話方塊化

特別是,

  • 欄位單位的輸入錯誤
  • 當場能修正的格式錯誤
  • 暫時性的注意

盡量靠向行內顯示比較自然。10

7.4 重要命令有多個路徑

Windows 的命令設計中重要命令 能從各種輸入方式或 UI 面呼叫 被重視。1213

這在實務上相當重要。

例如「刪除」的話,

  • 工具列
  • 內容選單
  • Delete 鍵
  • 必要時滑動

有多個路徑,使用感會穩定。

相反,

  • 只在 hover 時右端出現
  • 只在右鍵出現
  • 鍵盤永遠到達不了

這類設計輸入方式一變就突然弱。

7.5 用測試工具確認

無障礙比起在腦中想「大概沒問題」,用工具看更快。

Microsoft 的無障礙測試指南介紹用 Accessibility Insights for Windows 的 Live Inspect、FastPass、Troubleshooting,另外也能用 SDK 的 Inspect 確認 UI Automation 的屬性或導航結構。15

至少,

  • 用 Accessibility Insights 大致掃
  • 用 Inspect 確認主要元素的名稱、角色、模式
  • 只用鍵盤走通主要流程
  • 試文字放大和對比主題

這些做了後退會減少。

7.6 放入恢復性

這比起 Microsoft 的 1 行檢核表,在 Windows 桌面的實務上相當有效的話題。

UX 不只是「能舒服按的按鈕」,由 出事也能回來 決定。

例如,

  • Undo / Redo
  • 自動保存
  • 編輯中狀態的保持
  • 篩選 / 排序 / 欄寬的還原
  • 中斷和再開
  • 長處理的進度和取消

比外觀更影響 UX。

特別 ToB 或專家向中,再操作的壓力 直接成為 UX 的差。

8. 常見的設計錯誤

8.1 因為是 ToB 所以高密度就好,這樣固執

這只有一半對。

每天使用的熟練者向的話高密度有效。 但現場終端、接待終端、裝置 UI 中密度反而是敵。

不是看 ToB 這個標籤,看 熟練度、輸入方式、使用環境 比較不會失準。

8.2 因為是 ToC 所以把功能藏太多

個人用中,若是熟練者向工具,效率最優先。

什麼都往「簡單顯示」方向偏的話,

  • 高頻率操作遠
  • 每次挖選單
  • 一直切換畫面

這種安靜的地獄開始。

8.3 做以 hover 為前提的操作

觸控沒有 hover。 此外只用指標出現的 UI 與輔助技術相性也容易差。412

重要操作常時可見,或至少讓它有多個路徑比較安全。

8.4 只用顏色傳達狀態

監控畫面特別多,但只用紅 / 黃 / 綠傳達意義很危險。

配合文字、圖示、時刻、件數、說明,遺漏和誤認都會減少。11

8.5 把驗證錯誤全部做成對話方塊

事務輸入系中常見。 每次輸入都出對話方塊的話作業節奏完全毀壞。

脈絡閉合的錯誤在畫面內當場顯示比較自然。10

8.6 用固定大小的佈局做

100% 顯示的開發環境漂亮,但

  • 文字放大
  • 高 DPI
  • 對比主題
  • 本地化

中簡單就崩。67

外觀完成度越提高固定前提越是毒。

8.7 做太多自訂控制項

Windows 的標準控制項具備比外觀更多的行為。

  • 焦點
  • 鍵盤
  • 主題跟隨
  • UI Automation
  • 與輔助技術的連接

都照料,沒理由全部自作,UX 和無障礙的債會增加。83

9. 著手前決定的 8 問

最後放設計審查一開始放著方便的 8 問。

提問 代表性答 對 UX 有效的
1. 誰使用 初學者 / 熟練者 / 混在 資訊密度、術語、初期導線、說明量
2. 在哪使用 桌上 / 會議室 / 現場 / 戶外 / 接待 按鈕大小、文字大小、亮度、輸入方式
3. 用什麼操作 鍵盤 / 滑鼠 / 觸控 / 筆 / 掃描器 Tab 順序、快捷鍵、點擊區域、依賴 hover 的可否
4. 使用多少 首次中心 / 偶爾 / 每天 / 整天 優先易發現還是效率
5. 出錯的成本是 輕 / 重 / 危險 / 稽核對象 確認導線、Undo、權限控制、日誌
6. 1 畫面的資訊量 少 / 中 / 多 卡片型、一覽中心、還是分割
7. 需要客製化嗎 不必要 / 一部分必要 / 強烈必要 欄選擇、佈局保存、快捷鍵、設定粒度
8. 無障礙要件 最低限 / 強烈必要 / 公用 文字放大、對比、UIA、朗讀、驗證工時

先回答這 8 問,

  • 導航淺比較好嗎
  • 一覽 + 明細好嗎
  • 快捷鍵要做厚嗎
  • 對話方塊在哪用
  • 客製化允許到哪

相當自然決定。

10. 總結

Windows 應用程式的 UX 設計中重要的, 比起「是否漂亮」,先決定「那個人在那個地方用那個輸入方式能不停使用嗎」

粗略整理是這樣。

  • ToC 優先首次理解和安心感
  • ToB 事務系 優先持續效率和鍵盤對應
  • ToB 監控 優先防遺漏和安全操作
  • ToB 現場終端 優先大操作對象和短導線
  • 專家向工具 優先密度、快捷鍵、客製化
  • 常駐工具 優先不打擾

不論用途共通有效的是以下。

  1. 自然使用標準控制項
  2. 鍵盤能完結主要操作
  3. 不會被觸控或輔助技術卡住
  4. 文字放大或對比主題下不崩
  5. 為重要命令準備多個路徑
  6. 出事也能回來

UX 不是裝飾而是 操作的契約。 那個契約與使用者、環境、輸入方式越契合,Windows 應用程式會樸素但強地易用。

11. 參考資料

  1. Microsoft Learn, “Windows 應用程式的設計概要 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/  2 3

  2. Microsoft Learn, “Accessibility - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/accessibility/accessibility  2 3

  3. Microsoft Learn, “Keyboard accessibility - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/accessibility/keyboard-accessibility  2 3 4 5

  4. Microsoft Learn, “觸控操作開發者向指南 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/develop/input/touch-developer-guide  2 3 4 5

  5. Microsoft Learn, “Accessible text requirements - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/accessibility/accessible-text-requirements  2

  6. Microsoft Learn, “Text scaling - Windows apps” https://learn.microsoft.com/en-us/windows/apps/develop/input/text-scaling  2 3

  7. Microsoft Learn, “對比主題 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/accessibility/high-contrast-themes  2 3

  8. Microsoft Learn, “Windows 應用程式的導航基本 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/basics/navigation-basics  2 3 4 5 6 7 8

  9. Microsoft Learn, “Access keys design guidelines - Windows apps” https://learn.microsoft.com/en-us/windows/apps/develop/input/access-keys  2

  10. Microsoft Learn, “Dialog controls - Windows apps” https://learn.microsoft.com/en-us/windows/apps/develop/ui/controls/dialogs-and-flyouts/dialogs  2 3 4 5

  11. Microsoft Learn, “Developing inclusive Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/accessibility/developing-inclusive-windows-apps  2

  12. Microsoft Learn, “Commanding in Windows apps using StandardUICommand, XamlUICommand, and ICommand” https://learn.microsoft.com/en-us/windows/apps/develop/ui/controls/commanding  2 3 4 5 6

  13. Microsoft Learn, “Commanding basics - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/basics/commanding-basics  2

  14. Microsoft Learn, “Multiple inputs design guidelines - Windows apps” https://learn.microsoft.com/en-us/windows/apps/develop/input/multiple-input-design-guidelines 

  15. Microsoft Learn, “無障礙測試 - Windows apps” https://learn.microsoft.com/en-us/windows/apps/design/accessibility/accessibility-testing 

共用相同標籤的最新文章。能以相近的主題延伸理解。

與本文相近的主題頁面。以本文為起點,可進一步連到相關服務與其他文章。

本文連結到以下服務頁面,歡迎從最接近的入口查看。

作者檔案

本文作者的個人檔案頁面。

Go Komura

小村軟體有限公司 代表

以 Windows 軟體開發、技術諮詢與故障調查為中心,在難以重現的故障調查與既有資產仍在運作的專案上具有優勢。

回到部落格一覽