是否值得保留操作系统的外观和感觉？
是否值得尝试将 GUI 保留在系统外观内？
无论如何，每个主要程序都有自己的...... （Visual Studio、iexplorer、firefox、symantec utility、adobe ...）
或者只是框架和对话框应该留在系统的外观范围内？
更新：
一个简单的例子，如果您想向选项卡添加关闭按钮，通常您可以根据当前的桌面主题进行设置。 但如果用户有不同的主题，你的关闭按钮就不合适了，它不再适合系统外观。
我使用了 uxtheme api，但你无能为力，而且我看到的一些主题是不完整的集合。
因此，为了解决这个问题，我认为最好的方法是像 Visual Studio/Firefox/chrome 一样，将您自己的选项卡控件与您的主题结合起来...
Is it worth to try to keep your GUI within the system looks ?
Every major program have their own anyways...
(visual studio, iexplorer, firefox, symantec utilities, adobe ...)
Or just the frame and dialogs should be left in the system look 'n feel range ?
update:
One easy exemple, if you want to add a close button to your tab, usually you make it against your current desktop theme. But if the user has a different theme, your close button is out of place, it doesn't fit the system look anymore.
I played with the uxtheme api, but there is nothing much you can do, and some themes i've seen are incomplete sets.
So to address this issue, the best way i see, is to do like visual studio/firefox/chrome roolup your own tab control with your theme...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（11）
我认为，除非您的程序成为用户生活中非常重要的一部分，否则您应该努力最小化“惊喜”并最大化可识别性（这甚至是一个词吗？）。
因此，如果您正在制作可供 1000 人每天使用 10 分钟的产品，请采用系统外观和机制。
另一方面，如果你正在制作 100 个人每天使用 6 小时的东西，我会开始探索可以添加哪些 UI 改进和快捷方式，以使这 6 小时更容易处理。
但请注意，UI 修复不得以牺牲性能为代价。 当有人认为简单地重写 .Net 中的 OnPaint 事件就足够了时，几乎总是这种情况。
在您不知不觉中，您再次拦截了 NC_PAINT 和 NC_BACKGROUNDERASE 以及所有这些小技巧，使其与内置控件一样快。
I think, that unless your program becomes a very major part of the users life, you should strive to minimize "surprises" and maximimze recognizability (is that even a word?).
So, if you are making something that is used by 1.000 people for 10 minutes a day, go with system looks, and mechanisms.
If, on the other hand, you are making something that 100 people are using for 6 hours a day, I would start exploring what UI improvements and shortcuts I could cram in to make those 6 hours easier to deal with.
Notice however, that UI fixes must not come at the expense of performance. This is almost always the case in the beginning when someone thinks that simply overriding the OnPaint event in .Net will be sufficient.
Before you know it you are once again intercepting NC_PAINT and NC_BACKGROUNDERASE and all those little tricks to make it go as fast as the built-in controls.
我倾向于同意其他人的观点，尤其是索拉兹和斯马奇。
不过我要补充一件事。 如果您确实觉得 OS L&F 过于受限，并且您有充分的理由超越它，那么我会努力遵循“节奏和领导”原则（我在这里借用了 NLP 上下文） 。
这个想法是，您仍然希望尽可能地利用目标受众对主机操作系统的熟悉程度（正如 Smaci 已经介绍的那样，很少有例外）。 因此，您尽可能多地使用“标准”控件和行为（这就是“节奏”） - 但在必要时以仍然尽可能“适合”的方式扩展它（领先）。
您已经在工作中提到了这一原则的一些很好的例子 - Visual Studio，甚至在某种程度上 Office（Office 是“特殊的”，因为在这里崭露头角的新 UI 样式经常会回到未来的操作系统版本中 - 或者 de-事实标准）。
我提出这一点是为了对比那些只是“按照自己的方式行事”的应用程序类型——通常是因为它们是从另一个平台移植的，或者是在 GUI 和核心中被编写为跨平台的。 Java 应用程序通常属于这一类，但它们并不是唯一的。 它并不像以前那么糟糕，但即使在今天，大多数专业音频应用程序都有混合的 UI，显示出它们多年来从一个平台移植到另一个平台的血统。 虽然这些示例可能有很好的商业原因，但它们的用户界面仍然很糟糕，如果有可能的话，应该避免走这条路！
最重要的原则仍然是遵循最不令人惊讶的路径，并考虑用户对操作系统的熟悉程度，以及他们使用您的应用程序与操作系统上其他应用程序的时间的比率。
I tend to agree with others here- especially Soraz and Smaci.
One thing I'll add, though. If you do feel that the OS L&F is too constraining, and you have good grounds for going beyond it, I'd strive to follow the priciple of "Pacing and leading" (which I'm borrowing here from an NLP context).
The idea is that you still want to capitalise as much as possible on your intended audidences familiarity with the host OS (there will be rare exceptions to this, as Smaci has already covered). So you use as much as possible of the "standard" controls and behaviours (this is the "pacing") - but extend it where necessary in ways that still "fit in" as much as possible (leading).
You've already mentioned some good examples of this principle at work - Visual Studio, even Office to some extend (Office is "special" as new UI styles that cut their teeth here often find their way back into future OS versions - or de-facto standards).
I'm bringing this up to contrast the type of apps that just "do it their way" - usually because they've been ported from another platform, or have been written to be cross-platform in GUI as well as core. Java apps often fall into this category, but they're not the only ones. It's not as bad as it used to be, but even today most pro audio apps have mongrel UIs, showing their lineage as they have been ported from one platform to another through the years. While there might be good business reasons for these examples, it remains that their UIs tend to suck and going this route should be avoided if in any way possible!
The overriding principle is still to follow the path of least surprise, and take account of your user's familiarity with the OS, and ratio of their time using your app to others on the OS.
是的，只是因为它使操作系统能够使用文本转语音等内置的任何辅助功能。 对于需要辅助功能的人来说，没有什么比拥有另一个破坏他们习惯的所有工具的用户界面更烦人的了。
Yes, if only because it enables the OS to use any accessability features that are built in like text-to-speech. There is nothing more annoying for someone who needs accessability features to have yet another UI that breaks all the tools they are used to.
我想说这取决于用户、应用程序和平台。 界面对于用户来说应该是直观的，只有适合这些用户的系统 UI 标准才与遵循的系统 UI 标准相同。 例如，过去我曾参与开发用于 Windows CE 手持设备上的乳制品和面包配送的手持系统。 这种情况下的用户通常不懂计算机，并且教育背景薄弱。 用户界面注重通过简单的语言实现易用性，并以现有的纸质表格系统为模型。 它没有尝试遵循 Windows 的外观和感觉，因为这并不合适。
目前，我为一个通常受过第三级教育并且非常精通计算机的用户组开发非常图形化的软件。 这里的期望是该软件将遵循并扩展 Windows 的外观和感觉。
软件应该尽可能简单直观，而如何实现这一点完全取决于上下文。
I'd say it depends on the users, the application and the platform. The interface should be intuitive to the users, which is only the same as following system UI standards if they are appropriate for those users. For example, in the past I have been involved in developing hand held systems for dairy and bread delivery on Windows CE hand helds. The users in this case typically were not computer literate, and had a weak educational backround. The user interface focussed on ease of use through simple language and was modelled on a pre-existing paper form system. It made no attempt to follow the Windows look and feel as this would not have been appropriate.
Currently, I develop very graphical software for a user group that is typically 3rd level educated and very computer literate. The expectation here is that the software will adhere to and extend the Windows look and feel.
Software should be easy and intuitive where possible, and how to achieve this is entirely context dependent.
我想回答另一个问题（不是真正的 Stackoverflow 协议，但我认为，在这种情况下，这是合理的）
问题是“是否值得破坏操作系统的外观和感觉？”
换句话说，
不要简单地“与众不同”
I'd like to reply with another question (Not really Stackoverflow protocol, but I think that, in this case, it's justified)
The question is 'Is it worth breaking the OS look and feel?'
In other words,
Don't simply do it 'To be different'
这取决于您定义系统外观的范围有多大...但一般来说，您应该保留它。
不要因与用户习惯的不同而感到惊讶。 这就是我们称他为用户的原因之一；-)
Firefox 和 Adobe 产品通常不这么称呼，因为它们针对的是多个平台，而这些平台都有自己的 L&F。 但 Visual Studio 保留了典型的 Windows L&F。 而且，只要您只针对 Windows 进行开发，您就应该这样做。
It depends on how wide you would define system look'n feel... But in general, you should keep it.
Do not surprise the user with differentiating from what he is used to. That's one of the reasons why we call him user ;-)
Firefox and Adobe products usually don't because they are targeting several plattforms which all have their own L&F. But Visual Studio keeps the typical Windows L&F. And, as long as you are developing only for Windows, so should you.
除了 Windows 上没有明确定义的外观这一事实之外，您还应该始终尝试遵循主机平台本机 L&F。 但请注意，外观与程序的行为方式和外观一样重要。 以反直觉方式运行的程序与拥有自己丑陋的小部件的程序一样令人讨厌。
Fraps 是一个很好的程序示例（恕我直言），它实际上非常有用，但违反了一些用户界面准则并且看起来非常丑陋。
Apart from the fact that there is no well-defined look-n-feel on Windows, you should always try to follow the host platform native L&F. Note however that look-n-feel is just as much about how a program behaves as how it looks. Programs which behave in a counter-intuitive way is just as annoying as programs sporting their own ugly widgets.
Fraps is a good example (IMHO) of a program which is actually very useful, but breaks several user interface guidelines and looks really ugly.
如果您正在针对 Apple 的 Mac OS X 或 Microsoft Windows 进行开发，则供应商会提供接口指南，应该遵循这些指南才能使任何应用程序成为“本机”。
请参阅是否有任何标准请遵循确定在何处放置菜单项？以获取更多信息。
If you're developing for Apple's Mac OS X or Microsoft Windows, the vendors supply interface guidelines which should be followed for any application to be "native".
See Are there any standards to follow in determining where to place menu items? for more information.
如果您使用 Mac（或为 Mac 开发），那么绝对可以！
Windows 也应该如此。
If you are on (or develop for) a Mac, then definitely YES!
And this should be true for Windows also.
一般来说，是的。 但偶尔有一些程序，尽管没有针对其运行的所有操作系统进行格式化，但仍然表现良好。 例如，emacs 的运行几乎与 OS X 或 Windows（甚至可能是 gnome/KDE）上的每个界面指南相反，而且它不会很快消失。
In general, yes. But there's the occassional program that does well despite being not formatted for all the OSes it runs on. For example, emacs runs pretty much contrary to every interface guideline on OS X or Windows (and probably even gnome/KDE) and it's not going away any time soon.
我强烈建议让您的应用程序看起来像原生的。
将应用程序移植到新平台的开发人员似乎常犯的一个错误是，新应用程序的外观和感觉应该与旧平台上的一样。
不，新应用程序的外观和感觉应该与用户在新平台上习惯的所有其他应用程序一样。
否则，您会遇到像 Windows 上的 iTunes 那样令人厌恶的情况。 相同的 UI 设计可能在一个平台上完全正确，但在另一个平台上却非常错误。
您会发现您的用户可能无法确定他们不喜欢您的应用程序的原因，但他们只是觉得它很难使用。
是的，存在有效的例外，但它们很少见（当然，它们往往是 Office 和 Firefox 等主要应用程序，而不是小应用程序）。 如果您不确定，必须在 StackOverflow 上询问，那么您的应用程序不是其中之一。
I strongly recommend making your application look native.
A common mistake that developers who are porting an application to a new platform seem to make is that the new application should look-and-feel like it does on the old platform.
No, the new application should look-and-feel like all the other application that the user is used to on the new platform.
Otherwise, you get abominations like iTunes on Windows. The same UI design may be exactly right on one platform and very wrong on the next.
You will find that your users may not be able to pin-point why they dislike your application, but they just feel it hard to use.
Yes, there are valid exceptions, but they are rare (and sure enough, they tend to be the major applications like Office and Firefox, rather than the little ones). If you are unsure enough to have to ask on StackOverflow, your application isn't one of them.