【问题标题】:is it worth keeping the OS look and feel?是否值得保持操作系统的外观和感觉?
【发布时间】:2023-03-31 22:10:02
【问题描述】:

是否值得尝试将您的 GUI 保持在系统外观内?

无论如何,每个主要程序都有自己的... (visual studio、iexplorer、firefox、symantec 实用程序、adobe ...)

或者只是框架和对话框应该留在系统外观和感觉范围内?

更新:

一个简单的例子,如果你想在你的标签中添加一个关闭按钮,通常你会根据你当前的桌面主题来做。但是如果用户有不同的主题,你的关闭按钮就不合适了,它就不再适合系统的外观了。

我玩过 uxtheme api,但你无能为力,而且我看到的一些主题是不完整的集合。

因此,为了解决这个问题,我认为最好的方法是像 Visual Studio/firefox/chrome 一样使用您的主题来滚动您自己的选项卡控件...

【问题讨论】:

    标签: user-interface usability


    【解决方案1】:

    我认为,除非您的程序成为用户生活中非常重要的一部分,否则您应该努力尽量减少“惊喜”并最大限度地提高可识别性(这甚至是一个词吗?)。

    因此,如果您要制作可供 1.000 人每天使用 10 分钟的东西,请使用系统外观和机制。

    另一方面,如果您正在制作 100 个人每天使用 6 小时的东西,我会开始探索我可以在 UI 改进和快捷方式中塞进什么东西,以使这 6 小时更容易处理。

    但请注意,UI 修复不能以牺牲性能为代价。当有人认为在 .Net 中简单地覆盖 OnPaint 事件就足够时,这几乎总是如此。

    在不知不觉中,您再次拦截了 NC_PAINT 和 NC_BACKGROUNDERASE 以及所有这些小技巧,以使其与内置控件一样快。

    【讨论】:

    • 我想到的一个例子是自定义关闭标签按钮,默认情况下标签没有关闭按钮,所以如果你想添加一个与用户拥有的主题一致的按钮,它是有点难。
    【解决方案2】:

    我倾向于同意这里的其他人——尤其是 Soraz 和 Smaci。

    不过,我要补充一点。如果您确实觉得 OS L&F 过于受限,并且您有充分的理由超越它,我会努力遵循“起搏和领先”的原则(我在此从 NLP 上下文中借用)。

    我们的想法是,您仍然希望尽可能多地利用您的目标受众对主机操作系统的熟悉程度(这方面的例外情况很少见,正如 Smaci 已经介绍的那样)。因此,您尽可能多地使用“标准”控件和行为(这是“步调”) - 但在必要时以仍尽可能“适合”的方式扩展它(领先)。

    您已经提到了这一原则在工作中的一些很好的例子——Visual Studio,甚至在某种程度上是 Office(Office 是“特殊的”,因为新的 UI 样式在这里切入了他们的牙齿,通常会在未来的操作系统版本中找到它们的方式——或事实上的标准)。

    我提出这一点是为了对比那些“按自己的方式做”的应用类型——通常是因为它们是从另一个平台移植过来的,或者是在 GUI 和核心中被编写成跨平台的. Java 应用程序通常属于这一类,但它们并不是唯一的。它不像以前那么糟糕,但即使在今天,大多数专业音频应用程序都有混合 UI,显示了它们的血统,因为它们多年来一直从一个平台移植到另一个平台。虽然这些示例可能有很好的商业原因,但它们的 UI 往往很糟糕,应该尽可能避免走这条路!

    最重要的原则仍然是遵循最少意外的路径,并考虑您的用户对操作系统的熟悉程度,以及他们在操作系统上使用您的应用的时间与其他人的比例。

    【讨论】:

      【解决方案3】:

      是的,如果只是因为它使操作系统能够使用任何内置的可访问性功能,例如文本转语音。对于需要可访问性功能的人来说,没有什么比这更烦人的了。

      【讨论】:

        【解决方案4】:

        我想说这取决于用户、应用程序和平台。界面对用户来说应该是直观的,只有在适合这些用户的情况下,才与遵循系统 UI 标准相同。例如,在过去,我曾参与开发用于在 Windows CE 手持设备上交付乳制品和面包的手持系统。在这种情况下,用户通常不具备计算机知识,并且教育背景薄弱。用户界面通过简单的语言专注于易用性,并以预先存在的纸质表单系统为模型。它没有尝试遵循 Windows 的外观和感觉,因为这不合适。

        目前,我为一个通常受过第三级教育且精通计算机的用户群体开发了非常图形化的软件。这里的期望是该软件将坚持并扩展 Windows 的外观和感觉。

        软件应尽可能简单直观,如何实现这一点完全取决于上下文。

        【讨论】:

          【解决方案5】:

          我想回答另一个问题(不是真正的 Stackoverflow 协议,但我认为,在这种情况下,这是合理的)

          问题是“是否值得打破操作系统的外观和感觉?” 换句话说,

          1. 您有这样做的理由吗? (为了以某种在正常 L&F 中不可能的方式呈现数据)
          2. 您这样做有什么收获? (提高可用性?)
          3. 这样做会失去什么? (直觉和熟悉度?)

          不要简单地“与众不同”

          【讨论】:

          • (1) 进行我自己的控制,否则会过多地破解默认值,(2) 这样我就不会被默认值的约束所困。 (3) 与主题的集成将被破坏(某些部分将没有等效的主题,或者实现了一半的主题)
          • (1) 这仍然可以在保持外观和感觉的同时完成。想象一下操作系统提供商决定实施相同控制的情况 - 他们将维护 L&F (2) 自定义内容的充分理由 (3) 不自定义内容的充分理由。
          【解决方案6】:

          这取决于您对系统外观的定义范围...但总的来说,您应该保留它。

          不要因为区别于他的习惯而让用户感到惊讶。这就是我们称他为 user 的原因之一 ;-)

          Firefox 和 Adob​​e 产品通常不这样做,因为它们针对的是几个平台,这些平台都有自己的 L&F。但是 Visual Studio 保留了典型的 Windows L&F。而且,只要您只针对 Windows 进行开发,您也应该这样做。

          【讨论】:

            【解决方案7】:

            除了在 Windows 上没有明确定义的外观之外,您应该始终尝试遵循主机平台原生 L&F。但是请注意,外观与外观一样重要的是程序行为。以违反直觉的方式运行的程序与拥有自己丑陋小部件的程序一样令人讨厌。

            Fraps 是一个很好的示例(恕我直言),该程序实际上非常有用,但违反了一些用户界面准则并且看起来非常丑陋。

            【讨论】:

              【解决方案8】:

              如果您正在为 Apple 的 Mac OS X 或 Microsoft Windows 进行开发,供应商会提供接口指南,应遵循任何“原生”应用程序。

              更多信息请参见Are there any standards to follow in determining where to place menu items?

              【讨论】:

                【解决方案9】:

                如果您使用(或开发)Mac,那么绝对是的!

                Windows 也应该如此。

                【讨论】:

                  【解决方案10】:

                  一般来说,是的。但是,尽管没有针对它运行的所有操作系统进行格式化,但偶尔有一些程序运行良好。例如,emacs 的运行方式与 OS X 或 Windows(甚至可能是 gnome/KDE)上的每个界面指南都大相径庭,而且它不会很快消失。

                  【讨论】:

                    【解决方案11】:

                    强烈建议让您的应用程序看起来是原生的。

                    将应用程序移植到新平台的开发人员似乎犯的一个常见错误是,新应用程序的外观和感觉应该与旧平台上的一样。

                    不,新应用程序的外观和感觉应该与用户在新平台上习惯的所有其他应用程序一样。

                    否则,您会在 Windows 上遇到 iTunes 之类的可憎之物。相同的 UI 设计可能在一个平台上完全正确,而在下一个平台上则大错特错。

                    您会发现您的用户可能无法确定他们不喜欢您的应用程序的原因,但他们只是觉得很难使用。

                    是的,有有效的例外,但它们很少见(果然,它们往往是 Office 和 Firefox 等主要应用程序,而不是小应用程序)。如果您不确定是否必须在 StackOverflow 上提问,那么您的应用程序不是其中之一。

                    【讨论】:

                      猜你喜欢
                      • 1970-01-01
                      • 1970-01-01
                      • 2012-09-30
                      • 2012-02-06
                      • 1970-01-01
                      • 1970-01-01
                      • 2011-02-03
                      • 2013-02-09
                      • 2015-07-07
                      相关资源
                      最近更新 更多