2008-11-27 180 views
1

您認爲在傳統的WinForms應用程序中向用戶展示功能層次列表的最佳方式是什麼? (菜單系統 - 假定功能可以分成少量的模塊和子模塊,但這些子模塊沒有固定的深度)。在您的應用程序中展示菜單的最佳方式是什麼?

你喜歡傳統的下拉菜單系統,絲帶,停靠工具欄,樹視圖方法或任何其他創新想法?

回答

2

在您的設計中要考慮的重要事項是Usability vs Discoverability

最好解決方案強烈依賴於您的用戶是誰。在城市中心爲遊客自助服務應用程序的UI要求是那些在電站控制屏幕非常不同......

0

您可以隨時選擇越來越多的色帶控制。微軟/ Office界面習慣於成爲用戶對標準的期望(最終)。

+0

...但是:功能區不匹配所有用例。 – BlaM 2008-11-27 11:05:57

1

我經常有一個工具條停靠在頂部,用於那些最常用的功能。還有其他所有的設置熱鍵的下拉菜單。

如果我有一個可以包含不同類型項目的列表,我使用底部停靠的工具欄,根據列表中選定的項目更改其內容。這樣,我只有與任務相關的按鈕/圖標,而不是一堆激怒視圖的禁用按鈕。

我還爲自動填充的項目添加一個上下文菜單,使用與底部工具欄相同的選擇。這樣,我就可以更快地找到「動作」,而無需將鼠標移動到屏幕底部。

我真的很討厭功能區(作爲用戶),所以我不把它當作程序員在我的項目中使用。

0

在我看來,你的問題沒有明確的答案。它總是取決於您向用戶展示的菜單以及預計將使用該應用程序的用戶。

具有標準/常用功能的菜單可能是最佳呈現的Office樣式含義下拉菜單或新的Ribbon樣式。 一個帶有自定義功能的菜單,當您聲明具有不同深度的多個模塊和子模塊時,通常最好將其呈現爲類似TreeView的菜單。

從用戶的角度來看,一個典型的用戶在標準菜單中會做得很好,而更高級的用戶不會介意鍵盤導航等更高級的功能,或者隱藏/顯示菜單或將其停靠到窗戶的另一邊。

1

在我看來,最好的辦法是確保一切都可以通過多種方式完成。

  • 菜單
  • 鍵盤快捷鍵
  • 工具箱...

所以用戶可以選擇它的辦法解決。

我更喜歡在更多應用程序中看到的是,菜單或選項直接附加到用戶正在查看的選定項目(控件)。當然,菜單與特定內容相關。

我已經在我的開源項目Monex中實現了這個,我真的很喜歡自己使用它。看看這個screenshot

+0

+1我也是這麼想的。 ;) – Stefan 2008-11-27 15:24:03

0

菜單欄,工具欄和絲帶用於命令,其中的用戶選擇項目作用於窗口或應用程序整體中顯示的數據對象。您使用哪一個主要取決於您的應用程序中的命令數量。

  • 單獨工具欄:大約20個或更少的命令。爲每個命令按鈕提供圖標和文本標籤。用分隔符表示層次結構。不要超過兩個級別 - 相應地擴展您的層次結構。

  • 菜單欄帶有工具欄:超過約20條但少於約1000條命令。單個菜單上最多有20個菜單項(使用分隔符)通常優於級聯菜單 - 相應地顯示您的層次結構。常用的命令應該有加速器。通常將您的工具欄限制爲不超過30個最常用的命令,主要是命令,否則只能從對話框中訪問。考慮而不是具有用於具有加速器的菜單項的工具欄控件 - 一個好的專家訪問手段通常就足夠了。

  • 功能區:超過1000個命令。功能區僅僅是將不同的菜單欄和工具欄放在單獨的選項卡上。要正常工作,與每個選項卡(功能層次結構的頂部)相關的任務應該是非集成的 - 用戶相對很少從一個切換到另一個。功能區通常更有效地促進以可發現性和基本功能的效率爲代價來發現高級功能。

檢查函數層次結構中的項目是否可以更好地表示爲屬性而不是命令。命令執行一個過程,例如打開,查找和複製,而屬性改變某些東西的特定特徵,例如字體,大小和視角。屬性由窗口中的字段控件(例如,文本框,複選框和下拉列表)而不是菜單項,工具欄控件或功能區控件設置。

這種字段控件(或數據對象的其他表示形式)的窗口是一個內容塊。樹控件可用於控制顯示哪些內容塊。與選項卡控件類似,當用戶頻繁切換內容塊並且不比較內容塊時,它們優先於多個窗口。當內容數量不適合單行選項卡時,樹優先於選項卡控件。

樹中沒有任何空節點。用戶點擊的任何內容都應該顯示一個完整的內容窗格 - 相應地展示您的層次結構,甚至會使用列表框而非樹的極端。

如果用戶傾向於選擇一個內容塊,完成一個任務那裏,然後離開你的應用程序,然後再考慮「家」網頁顯示的所有內容塊的整頁菜單,可能是立體地安排根據您的層次結構,每一個點擊都可以訪問。

相關問題