在開發基於Windows窗體的應用程序時，在設計窗體的主菜單系統時是否有任何標準應該遵循？在確定放置菜單項目的位置時是否有任何標準？
帶菜單系統的大多數Windows應用程序都會有您的標準文件|編輯|查看|工具|幫助菜單。你如何確定任何額外的頂級菜單項的位置？
另外，你如何確定子菜單項的位置？例如，您會遵循哪些規則或原則來確定項目是應該放置在編輯，工具還是您自己的非標準頂級菜單中？
我在這裏尋找兩件事情：
根據Gamecat提到Ribbon的迴應，我將把它擴展到Ribbon。你如何確定哪些標籤按鈕出現？尋找如上所述。
相關問題： https://stackoverflow.com/questions/126797/is-there-a-style-guide-for-guis-somewhere
微軟的Vista用戶體驗指南是： http://msdn.microsoft.com/en-us/library/aa511258.aspx
內容具體到菜單，包括標準菜單，是： http://msdn.microsoft.com/en-us/library/aa511502.aspx
這包括菜單和菜單項，他們的名字，他們的加速器的標準順序。
一些一般性的指導原則：
File是用於影響用戶正在使用的全部內容（通常是文件）或整個應用程序（例如，退出）命令。這也是用戶選擇他們想要的表單的好地方。
編輯是用於選擇內容片段（例如，查找，全選）並對這些片段執行操作（複製，刪除）。不要用它作爲一般的「改變某些東西」菜單（例如，「編輯」偏好或宏）。
查看更改內容的外觀或呈現，同時不更改基礎內容本身（例如，用戶輸入到表單中的內容）。考慮而不是包括在視圖菜單項中用於控制工具欄的存在（工具欄不是內容）。這真的應該與選項/首選項。
雖然它被列爲標準，但我會避免使用工具菜單。這個名字沒有意義，內容往往是隨機垃圾。考慮Office功能區使用的名稱和組織（例如，選項與File等效的選項）。請參閱http://blogs.msdn.com/jensenh/archive/2006/01/31/520061.aspx。
通常將特定於應用程序的菜單項放置在標準菜單中的標準菜單項下方，以便標準菜單項不會中斷用戶的肌肉記憶。但是，如果應用程序特定的菜單項是標準菜單項的變體，則將它放置在標準菜單項的正下方（例如，在查找下方查找下一個或粘貼下方的Paste）
不要害怕爲不適合上述項目創建自己的菜單。菜單通常沒有足夠的寬度，從而產生一種弱信息氣味，尤其是對於非標準菜單項目。八到十個菜單是完全可以接受的。只有三個菜單項的菜單是完全可以接受的;一個有兩個菜單項是不可能的。
級聯或子菜單很難使用。改爲按分隔符分組菜單項。在需要考慮級聯菜單之前，菜單可能有〜15個項目。如果您擁有如此多的菜單項，請首先考慮將某些菜單設置爲單獨的菜單，而不是菜單中的級聯菜單。
在查看之後但在菜單欄上的窗口或幫助之前放置您的應用專用菜單。 我強烈建議您組織和命名非標準菜單的用戶研究（如卡片分類）。
仔細觀察功能區，你會看到它的組織與菜單欄相同，等同於File（徽標菜單），Edit（「Home」選項卡，包括格式）和View ，所以從組織的角度來看，無論您使用的是功能區還是菜單欄，它都沒有什麼不同。
菜單欄仍然是大多數應用程序的最佳選擇。功能區並不意味着比傳統的菜單欄/工具欄組合更少的點擊次數。不要因爲MS推着就跳到功能區。我在http://www.zuschlogin.com/?p=36有詳細資料。
不是一個標準，但你可以使用Office產品作爲指導。
順便說一下，菜單是從過去，它現在是所有功能區。起初我對絲帶持懷疑態度，但現在我認爲這是一個非常好的主意。 （最小化鼠標點擊總是一個好主意）。
尼斯鏈接：http://blogs.msdn.com/jeffdav/archive/2004/12/07/278012.aspx
是的，我知道......我愛的絲帶，但不幸的是我們有些人保持書面年前的應用程序，都無法支持一個Ribbon類型的界面，但仍然希望確保我們在菜單方面遵循標準。 – 2008-11-06 12:53:23
微軟絲帶文件：
此外，什麼類型的接口（菜單欄，緞帶，工具欄，直接指揮等）的文檔應使用不同類型的應用：
有些事情要記住。
這兩種標準化方法都是在桌面軟件開發和實施之前的網絡。這意味着這兩種模式都沒有考慮到網絡環境。傳統桌面環境和基於網絡的環境（瀏覽器的「返回」按鈕）之間有一個很大的區別。
o「取消」也是「返回」的一種方式，「確定」是移動「前進」的一種方式。這種「向前/向後」隱喻是多數形式的「取消」和「確定」功能的基礎。
下面是這一比喻的其他一些擴展：
O時間：在我們的標準的可視化「老」通常描繪在左，「新」被描述在右（大多數圖形描述的時間使用這個從左到右的比喻）
o過程：我們使用從左到右的隱喻時，可視化的漸進式步驟：「第一」在左側，「第二」通常顯示在正確的。
Ø寫作與閱讀：在寫作和閱讀我們「繼續」或「前進」由左到右（除非我們在課程亞洲）
？在電影：電影是可視化的另一種形式。在電影中，運動的標準是：如果一個人「走到某個地方」，她會從屏幕左側移動到右側。如果她要「返回」，她從右到左移動
o取消/ OK模式可能有助於改善有意識的決策：此模型假定您想在決定要選擇哪種操作之前閱讀選項（對於需要用戶充分關注的重要交互而言是可取的，並且可以爲他們提供更多的操作）。取消/ OK模型首先顯示「替代」行爲（左側）...因此，您可以先閱讀它們決定「確定」是你真正想要採取的行動。 OK/Cancel模式可能會讓用戶習慣於點擊他們遇到的第一個選項。同時，接受過使用取消/ OK模型培訓的用戶可以直接進入「確定」按鈕，只要他們確定他們想要做出選擇。
o操作系統改編：Mozilla的Firefox與顯示「確定」和「取消」按鈕順序時使用的操作系統相匹配。換句話說，按鈕的顯示適合您的操作系統培訓您使用的內容。
這是解決這個非常具體的問題，其中訂購此按鈕應該是一項有趣的調查： http://measuringuserexperience.com/SubmitCancel/index.htm
好的寫法，但是，我不確定我看到與此主題有關的菜單系統的相關性，除了它們都與UI設計有關？我不會低估它，因爲它確實包含了很好的內容，儘管它似乎與我無關。 – 2009-01-13 15:01:32
是...菜單的邏輯分組幫助用戶記住事情很容易。 我也不希望有一個「工具」菜單，並傾倒一切不屬於這裏的其他地方... 應該有一個像Mac應用程序菜單或像Office按鈕（2010年的超空間用戶界面），你可以有這些「工具」或偏好。
關於按鈕排序，嘗試下面的平臺約定...... http://blog.mugunthkumar.com/tech/elements-of-usability-design-okcancel-vs-cancelok-is-it-just-a-matter-of-taste/
好帖子！謝謝！ – 2008-11-06 14:11:44