尝试将 GUI 保持在系统外观内是否值得？
每个主要程序都有自己的反正......（visual studio，iexplorer，firefox，symantec实用程序，adobe......）
还是应该只将框架和对话框留在系统外观范围内？
更新：
一个简单的例子，如果你想在你的选项卡上添加一个关闭按钮，通常你会根据你当前的桌面主题来做。但是如果用户有不同的主题，你的关闭按钮就不合适了，它就不再适合系统的外观了。
我玩过 uxtheme api，但你无能为力，而且我看到的一些主题是不完整的集合。
因此，为了解决这个问题，我认为最好的方法是像visual studio/firefox/chrome那样用你的主题来滚动你自己的标签控件......
我认为，除非您的程序成为用户生活中非常重要的一部分，否则您应该努力尽量减少“惊喜”并最大限度地提高可识别性（这甚至是一个词吗？）。
因此，如果您正在制作可供 1.000 人每天使用 10 分钟的东西，请选择系统外观和机制。
另一方面，如果你正在制作一个 100 人每天使用 6 个小时的东西，我会开始探索我可以塞进哪些 UI 改进和快捷方式来让这 6 个小时更容易处理。
但是请注意，UI 修复不能以牺牲性能为代价。当有人认为在 .Net 中简单地覆盖 OnPaint 事件就足够时，这几乎总是如此。
在不知不觉中，您再次拦截了 NC_PAINT 和 NC_BACKGROUNDERASE 以及所有这些小技巧，以使其与内置控件一样快。
我倾向于同意这里的其他人——尤其是 Soraz 和 Smaci。
不过，我要补充一件事。如果您确实觉得 OS L&F 过于受限，并且您有充分的理由超越它，我会努力遵循“起搏和领先”的原则（我在此从 NLP 上下文中借用）。
这个想法是，您仍然希望尽可能多地利用您的目标受众对主机操作系统的熟悉程度（这方面的例外情况很少见，正如 Smaci 已经涵盖的那样）。因此，您尽可能多地使用“标准”控件和行为（这是“步调”） - 但在必要时以仍然尽可能“适合”的方式扩展它（领先）。
您已经提到了这个原则在工作中的一些很好的例子——Visual Studio，甚至在某种程度上是 Office（Office 是“特殊的”，因为在这里切齿的新 UI 样式通常会重新回到未来的操作系统版本中——或者 de-事实标准）。
我提出这一点是为了对比那些“按自己的方式做”的应用程序类型——通常是因为它们是从另一个平台移植过来的，或者是在 GUI 和核心中被编写成跨平台的。Java 应用程序通常属于这一类，但它们并不是唯一的。它不像以前那么糟糕，但即使在今天，大多数专业音频应用程序都有混合 UI，显示了它们的血统，因为它们多年来一直从一个平台移植到另一个平台。虽然这些示例可能有很好的商业原因，但它们的用户界面往往很糟糕，如果可能的话，应该避免走这条路！
最重要的原则仍然是遵循最不意外的路径，并考虑您的用户对操作系统的熟悉程度，以及他们在操作系统上使用您的应用程序的时间与其他人的比例。
是的，如果只是因为它使操作系统能够使用任何内置的可访问性功能，如文本到语音。对于需要可访问性功能来拥有另一个破坏他们习惯的所有工具的 UI 的人来说，没有什么比这更烦人的了。
我想说这取决于用户、应用程序和平台。界面对用户来说应该是直观的，只有在适合这些用户的情况下，才与遵循系统 UI 标准相同。例如，在过去，我曾参与开发用于在 Windows CE 手持设备上交付乳制品和面包的手持系统。在这种情况下，用户通常不具备计算机知识，并且教育背景薄弱。用户界面通过简单的语言专注于易用性，并以预先存在的纸质表单系统为模型。它没有尝试遵循 Windows 的外观和感觉，因为这不合适。
目前，我为一个通常受过第三级教育且计算机知识渊博的用户群开发非常图形化的软件。这里的期望是该软件将坚持并扩展 Windows 的外观和感觉。
软件应该尽可能简单直观，如何实现这一点完全取决于上下文。
我想回答另一个问题（不是真正的 Stackoverflow 协议，但我认为，在这种情况下，这是合理的）
问题是“是否值得打破操作系统的外观和感觉？” 换句话说，
不要简单地做到“与众不同”
一般来说，是的。但是，尽管没有针对其运行的所有操作系统进行格式化，但偶尔有一些程序运行良好。例如，emacs 的运行与 OS X 或 Windows（甚至可能是 gnome/KDE）上的每个界面指南都完全相反，而且它不会很快消失。
我强烈建议让您的应用程序看起来像原生的。
将应用程序移植到新平台的开发人员似乎犯的一个常见错误是，新应用程序的外观和感觉应该与旧平台上的一样。
不，新应用程序的外观和感觉应该与用户在新平台上习惯的所有其他应用程序一样。
否则，你会得到像 Windows 上的 iTunes 这样的可憎之物。相同的 UI 设计可能在一个平台上完全正确，而在下一个平台上则大错特错。
您会发现您的用户可能无法指出他们不喜欢您的应用程序的原因，但他们只是觉得很难使用。
是的，有有效的例外，但它们很少见（果然，它们往往是 Office 和 Firefox 等主要应用程序，而不是小应用程序）。如果您不确定必须在 StackOverflow 上提问，那么您的应用程序不是其中之一。
如果您使用（或开发）Mac，那么绝对是的！
这也应该适用于 Windows。
这取决于您定义系统外观的范围有多广……但总的来说，您应该保留它。
不要因为区别于他的习惯而让用户感到惊讶。这就是我们称他为用户的原因之一;-)
Firefox 和 Adobe 产品通常不这样做，因为它们针对的是几个平台，这些平台都有自己的 L&F。但是 Visual Studio 保留了典型的 Windows L&F。而且，只要您只为 Windows 开发，您也应该这样做。
除了 Windows 上没有明确定义的外观之外，您应该始终尝试遵循主机平台原生 L&F。但是请注意，外观与外观一样重要。以违反直觉的方式运行的程序与拥有自己丑陋小部件的程序一样令人讨厌。
Fraps 是一个很好的例子（恕我直言），该程序实际上非常有用，但违反了几个用户界面准则并且看起来非常丑陋。
如果您正在为 Apple 的 Mac OS X 或 Microsoft Windows 进行开发，供应商会提供接口指南，任何应用程序都应遵循这些指南才能成为“本机”。
请参阅在确定菜单项的放置位置时是否需要遵循任何标准？了解更多信息。