我有興趣聽取開發人員關於設計用戶界面，可用性和可維護性的意見和經驗。可用性：使用「應用」按鈕或每次更改後保存更改？
通常的做法是讓用戶調整選項，當表格變得「髒」後，啓用「應用」按鈕，用戶可以通過按下取消退出。這是Windows平臺上最常見的方法（我相信MS可用性準則也會這樣做）。
另一種方法是在對選項進行每個更改後應用更改。例如，用戶選中某個複選框，並應用更改。用戶更改某些文本框的值，並在框失去焦點後應用更改等。您可以獲得該點。這種方法在Mac OSX上最常見。不管我個人的意見如何（蘋果的可用性更好，但我通常寫的軟件都是針對Windows用戶），你們怎麼看？
編輯：我完全意識到，這不是一個真正的問題，而是要求討論，而且它的位置可能不在SO上，其政策是隻有答案和問題。但我相信這可能是有用的討論，主要是因爲在提問之前我找不到任何類似的內容。
兩者都有自己的位置，並且它們都用於多種平臺（它們並不是PC和Mac之間的區別）。
「應用」按鈕方法允許您進行一些更改，應用它們，而不必重新打開對話框進行一些更改。這對於嘗試解決問題很有用，但是當您希望用戶對他們的選擇進行有條不紊的思考時（或者感到安全） - 用戶可以準確地掌控他們應用更改的時間。在某些情況下，您可能不希望在進行更改之前進行修改，或者在用戶需要知道他們想要的設置的情況下，而不需要「實驗」的情況下，這一點很重要。這些對話框通常也有一個取消按鈕（希望）可以撤消自打開對話框後所做的任何更改。這些對話框通常是模態的，所以用戶被鎖定在對話框中，直到他們做出選擇。
即時效果對話框允許用戶根據自己的選擇嘗試並查看「實時」更新。當用戶想要測試選項以瞭解它們會產生什麼效果時，這非常棒。您必須小心使用視覺樣式以向用戶明確他們正在「正在運行」，並且他們必須小心，因爲他們無法退出其變更。這種類型的對話框的Microsoft方法是有一個「關閉」按鈕，這使得即時效果方法變得明顯。這些對話通常不是模態的，即它們被視爲「實時編輯面板」而不是對話框。
通常，UI傾向於圍欄的實時編輯面，因爲它允許用戶通過諸如按下特殊按鈕來提交更改等技術來實驗性和不受阻礙（例如，請參閱Win7中的控制面板 - 很難與XP相比任何模態對話框）
然而，最終這兩個選項之間的選擇真的取決於您希望控制的設置類型。即，如果您在某些文本上設置字體樣式，那麼您確實想要處於實時實驗端，但如果您正在配置重要的相關信息組（例如，您的DNS服務器地址和子網掩碼）你可能想要使用一些需要你思考/瞭解並有意應用你的改變的東西（因此用戶可以輸入並仔細檢查這些信息，因此他們可以同時改變幾個相關的信息片段。另外，如果你提交了一個DNS服務器地址以用戶輸入的方式生效，他們將失去網絡連接，直到他們獲得所有數字爲止 - 生活對此沒有意義）。
當用戶必須配置網絡設置時，Apple本身正在使用「更安全」的方法。 http://www.riscos.org/networking/osx.html在許多其他地方，選項立即生效。 – 2010-06-17 22:55:32
符合平臺預期。
我也同意Apple在可用性方面的優越性，但您的決定應該基於您的目標平臺所展現的最常見行爲。您應該始終以最小的用戶體驗出乎意料的用戶，而對於大多數Windows用戶，我猜這就是堅持OK/Apply/Cancel的行爲。
如果您有跨平臺的應用程序，請分別使用GUI，以尊重匹配平臺期望口頭禪。是的，這是額外的工作，但它表明你在乎。
我同意一般情況下您需要匹配平臺預期。
個人，但是，一般我喜歡使用適用的/保存的原因有兩個： 1）一種部分地施加變化可能是破壞性的（以延遲或在實際屏幕工件） 2）某些狀態或它們的組合可以不有效（或者它們可能對用戶的看法無效）。 3）如果您提供某種展開更改或用有意義的名稱保存更改的方式，則可以根據用戶選擇何時應用或保存的方式對其進行邏輯分組。作爲一名開發人員，我喜歡事物的提交/回滾方法，而且我也喜歡在我的UI中使用這種方法。
我只能想到兩個很好的原因有應用按鈕：
這些都不是很常見。幾乎任何選項都可以在Histalally 1中使用。但是現在電腦速度更快，而且很少有相關性。如果變化的影響可以立即看到，爲什麼有人不想要那樣？所以gui（但通常不是代碼）可以通過跳過apply步驟來簡化。我不認爲用戶真的需要取消按鈕是很常見的，部分原因是它有點模糊。如果我進行一項更改，應用，進行其他更改並按取消，我應該期待什麼？第一次更改是否會恢復（在大多數應用程序中，答案是否定的，因爲更容易實現）？
如果是的話，那就是有了應用按鈕，那麼一切都被清除了，然後按OK /取消呢？或者我們需要考慮另一種選擇，即窗口關閉，在這種情況下，第一次更改會保留，但第二次更改會恢復？
如果不是，則基本套用將被還原的書籤設爲取消按。但是這種複雜的行爲真的需要在任何現實生活中使用嗎？
保持這種複雜的歷史原因是否理智，因爲用戶（據信）期望它？我看到用戶總是按下應用，然後確定。爲什麼？也許只是因爲GUI太複雜。或者，因爲不確定「應用」是否意味着「應用和解除對話」（在某些應用中它會這樣做），並且確定可能不會應用更改（我已經看到了錯誤的應用程序，如果沒有應用就可以關閉窗口，也許他們也有）。至少我不認爲用戶總體上對這些複雜選擇的準確邏輯有影響，因此他們不需要它，也不需要在那裏。人們傾向於主要區分「積極」（是，好，向前，應用）和「否定」（否，取消，放棄，返回）行動是對話，有多個要麼需要用戶提供更多的支持。有趣的是，交換一個positiva行動與另一個似乎並沒有太多影響用戶的看法。如果一個帶有按鈕yes/no的對話框改變爲ok/cancel，許多用戶甚至不會注意到。
關於可用性（這是更重要的恕我直言）。如果做錯了，可維護性即時應用可能非常混亂，但也非常乾淨和可維護，然後做對。如果應用程序採用一次性應用程序寫入，則通常只有一個功能。對每一個小變化調用這樣的函數當然不是非常有效。我所看到的這一點常常通過將功能分解爲幾個不同的功能來解決，以便應用不同的內容，理想情況下是針對可以進行的每種改變的一種專用功能。這會使應用程序響應更快，但維護起來很可怕。所以不要去那裏。一個簡潔的解決方案是使用MVC（模型 - 視圖 - 控制器）併爲每個配置項目創建一個模型，並將它們綁定到配置表單中的字段以及應用程序的相關部分（以及配置存儲備份 - 結束，所有的變化都會自動保存）。如果在所討論的環境中沒有可用的MVC，絕對值得一寫。
+1用於在整個表格填充後保存更改，而不是每個字段。
但是，只要字段失去焦點，應該進行驗證，以便在出現任何錯誤時立即提供反饋。
我幾乎可以肯定這是重複的，但是，這個話題是爭論性的，並且最終沒用，因爲正確的答案總是「在給定的平臺上做標準的事情」。 – 2010-06-17 22:24:48
我很樂意閱讀有關該主題的整個討論，但是，我一直無法找到一個。我提出這個問題要求人們的意見，因爲這不是一個真正的問題，我不期望得到確切的答案。另外，這不是第一個「無用」的問題。 – 2010-06-17 22:29:19
「它已經發生了」的態度並不好，或者在我看來，是任何事情的藉口。我很欣賞你可能對這個領域感興趣，我希望你能找到你想要的信息。 – 2010-06-17 22:32:06