1. 概念的關係 1.1. 概念是獨立的,彼此間無須相互依賴 1.1.1. 一個概念是應該獨立地被理解、設計和實現的 1.1.2. 獨立性是概念的簡單性和可重用性的關鍵 1.2. 軟體存在依賴性 1.2.1. 不是說一個概念需要依賴另一個概念才能正確運行 1.2.2. 只有當一個概念存在時,包含另一 ...
1. 概念的關係
1.1. 概念是獨立的,彼此間無須相互依賴
-
1.1.1. 一個概念是應該獨立地被理解、設計和實現的
-
1.1.2. 獨立性是概念的簡單性和可重用性的關鍵
1.2. 軟體存在依賴性
-
1.2.1. 不是說一個概念需要依賴另一個概念才能正確運行
-
1.2.2. 只有當一個概念存在時,包含另一個概念才有意義
1.3. 概念依賴關係圖簡要概括了軟體的概念和概念存在的理由
- 1.3.1. 概念依賴關係圖有助於規劃設計和構造軟體的順序、識別概念分組以及解釋概念結構
1.4. 概念組合允許單個概念在相互關係中發揮特定的作用
1.5. 概念組合本身是對稱的,因為同步的操作是平等的
- 1.5.1. 概念組合可以引入不對稱性,因為一個概念可以增強另一個概念的功能
2. 從概念到軟體
2.1. 在大多數情況下,漸進式的開發會更好,因為這樣開發人員能在早期就獲得對其設計工作的反饋,評估已部署部分的價值,併在發現問題時及時處理
-
2.1.1. 漸進式開發並不是單純地增加概念
-
2.1.2. 無節制地增加概念可能導致優秀產品的瓦解
2.2. 建立概念清單
-
2.2.1. 通用概念清單
-
2.2.1.1. 使用通用的概念不僅可以重用以前軟體中的設計知識,還有助於簡化設計
3. 概念依賴關係圖
3.1. 由於每個概念都是通用且獨立的,所以在傳統的軟體工程意義上不存在概念間的依賴關係
3.2. 概念之間存在其他依賴性,這與概念本身無關,而與它們在整個軟體中的作用有關
3.3. 一個概念的存在可能依賴其他好幾個概念
-
3.3.1. 將其中一個依賴關係標記為主要依賴(實線箭頭),將其他依賴關係標記為次要依賴(虛線箭頭)
-
3.3.2. 次要依賴表示一個概念不太重要的存在理由
-
3.3.3. 沒有用戶概念意味著無法進行身份驗證
-
3.3.4. 沒有投票概念意味著用戶無法為答案做出貢獻
-
3.3.5. 沒有錄音概念意味著提問中的鳥鳴聲必須用文字描述,或者要鏈接至網路上的其他文件
3.4. 概念的任何子集都可以構成一個完備的軟體,只要不存在指向該子集的依賴方
-
3.4.1. 產品線的每個完備子集代表這些特定概念可能構建的軟體
-
3.4.2. 子集還可以表示軟體開發的不同階段
-
3.4.3. 在開發的任何時間點,你都希望擁有一個完備的子集,以便將其作為一個完整的單元進行評估
4. 概念的映射
4.1. 從底層概念到物理界面
4.2. 概念需要映射到具體的用戶界面,將操作映射為單擊按鍵等手勢,並將概念狀態映射到各種顯示視圖
4.3. 應用用戶界面設計原則時,概念有助於聚焦映射問題
4.4. 試圖使用戶界面比底層概念更簡單可能會適得其反
4.5. 映射必須考慮典型的使用模式
4.6. 用戶界面儘管很具有表現力,但可能無法將一切變得清晰,界面中的工具包可能會限制映射設計
-
4.6.1. 有時甚至需要在用戶界面中添加明確的註釋
-
4.6.2. 創建用戶界面不僅包括視覺的設計,它的本質是設計一種從底層概念到物理界面的映射
4.7. 人機交互研究人員對映射的設計進行了廣泛的研究,他們制定出的指南主要適用於設計的物理層次和語言層次,這一指南同樣適用於通過概念設計的系統
4.8. 概念提供了機會以完善設計的概念層次與物理層次、語言層次的關係
5. 解決模棱兩可的操作
5.1. 使用集合概念的軟體Zotero可以將論文的引文組織為集合
5.2. safari提供了書簽的集合
5.3. Adobe Lightroom允許用戶定義照片或電影的集合
5.4. 集合概念與文件夾概念的顯著不同是,在集合概念中,一個項目可以屬於多個集合
6. 概念熟悉性
6.1. 好用的概念常常可以重用
6.2. 一個好的設計師不僅知道如何發明新概念,而且知道什麼時候無鬚髮明新概念
- 6.2.1. 如果你的目的可以通過一個現有概念來實現,那麼你最好再次使用這個概念
6.3. 概念與其他任何發明一樣
- 6.3.1. 不同的是,概念提供了一種將軟體設計的知識和經驗變得簡單且連貫的方法,從而提供了更具細粒度的重用機會
6.4. 使設計可用的最簡單的方法是使用熟悉的、現有的概念
- 6.4.1. 使用用戶充分理解的概念可以降低設計不合理的概率,並使設計對用戶來說更加直觀
6.5. 看起來瞬間爆發的靈感實際上往往來自經年累月的經驗培養出的洞察力
-
6.5.1. 一個偉大的設計師會記住一系列設計,隨時準備應對遇到的每一個新的設計問題
-
6.5.2. 只有當標準方案不足以解決問題時,他才會尋求新的解決方案
6.6. 軟體與任何其他設計領域沒有什麼不同
-
6.6.1. 應用以前設計的經驗教訓,你首先需要能夠將設計思想提取為可重覆使用的關鍵點,這就是概念的目的
-
6.6.2. 概念是特定設計問題的特定解決方案,它不是一個大而模糊的問題,而是一個個會在許多情況下反覆出現的小而明確的需求
6.7. 創造一個新概念來實現一個現有概念可以完美實現的目的不僅是浪費精力,還容易讓已經熟悉現有概念的用戶感到困惑
6.8. 當將概念映射到用戶界面時,對非常規小部件的需求可能表明其基本概念本身就是繁雜和非常規的
7. 概念的重用
7.1. 概念的重用是非常廣泛的,尤其是在Web軟體中
7.2. 相同的概念可能以不同的形式出現
-
7.2.1. 聊天室概念變成了WhatsApp或Google Groups或Facebook中的小組概念以及IRC或Slack中的頻道概念
-
7.2.2. Twitter提供了一個將其設計與現有概念聯繫起來的很好的例子:關註概念
7.3. 在你發明一個新概念以前,查看現有的概念,看看是否有一個概念滿足你的需求
7.4. 請記住,你需要的概念可能來自一個非常與眾不同的領域
8. 避免發明新概念
8.1. 當設計師在重用現有概念與發明新概念之間做選擇時,最好選擇重用通用概念,除非確定現有概念不能有效實現目的
8.2. Keynote的行為大多簡單且可預測
- 8.2.1. 他們沒有從頭開始設計,這也是蘋果的組概念更直觀的原因
8.3. 如果現有概念似乎僅部分滿足你的目標,相較於修改或擴展它,請探索它是否可以與另一個現有概念組合起來提供你需要的功能
9. 概念實例的一致性
9.1. 當設計中出現的概念是熟悉的通用概念的實例時,它應該嚴格遵守通用概念的行為方式,除非有很好的理由不這樣,並且它與通用概念的偏差非常明顯
9.2. 沒有所謂的對與錯,關鍵在於對概念的熟悉程度以及隨之而來的預期
9.3. 預期是軟體設計中必須認真對待的強有力因素
9.4. 當概念的行為不可預測且出現不同種行為的可能性似乎相同時,概念設計很可能是錯誤的
- 9.4.1. 一個好的設計具有必然性的品質