Web 和桌面应用程序之间构建 UI 的差异[关闭]答案

【问题标题】：Differences in building UI between Web and Desktop Applications [closed]Web 和桌面应用程序之间构建 UI 的差异[关闭]
【发布时间】：2010-09-25 12:49:00
【问题描述】：

Web 应用程序的 UI 与桌面应用程序的 UI 构造不同。我很想知道在以下领域中两种风格的应用程序在构建 UI 方面的主要区别是什么：

1.使用的技术

2.使用的技术

3.使用的控件

4.换屏行为

【问题讨论】：

有趣的在这里阅读：Web Apps vs. MS Windows Apps.

标签： web-applications user-interface desktop-application

【解决方案1】：

在网页设计中您不能忽视的一个重要因素是后退按钮。成千上万的人试图禁用或绕过它。不要试图绕过后退按钮！而是让后退按钮成为您设计的一部分。

【讨论】：

【解决方案2】：

很多人忽略的一个很大的设计差异是窗户本身的结构。

桌面应用程序倾向于为最小的高度和宽度分辨率（通常为 800*600）而构建，并尽可能努力地将所有相关信息放入小于该大小的大小，因为滚动条通常非常非表格/列表数据的不良做法。在需要更多空间的情况下，信息通常会拆分到新窗口或子窗口窗格/选项卡中。
另一方面，Web 应用程序具有基本上无限的垂直高度，因为大多数人习惯于在其 Web 浏览器中滚动。滚动条不再是坏事；事实上，在 anywhere 可以使用主要滚动条的地方通常被认为是不好的形式（当然也有少数例外）。信息通常在一个“窗口”中描绘，因为将其拆分需要单独的页面加载和重新加载相同的数据（样式、菜单等）。是的，有一个缓存，但它不如不加载单个页）。更多的负载总是更慢，并导致不连续的感觉。有时它们是不可避免的，但您几乎不应该将您的应用限制为仅浏览器窗口的可见大小。
人们使用网络浏览器的很多目的是阅读。新闻、博客、youtube 上的 cmets 等。当你制作一个网络应用程序时，它应该反映这种习惯，因为如果他们在网页和你的应用程序之间切换，你会通过完全不同的布局来刺激人们的大脑（你知道有些会）。看起来您只是在模仿大玩家，但一致性比看起来要重要得多。
文本的列不应该超宽，因为越宽的行越难跳到下一行继续阅读。坚持类似于书本的东西；它们经过世纪的完善。这就是为什么很多网页都是固定宽度的，并且喜欢列而不是行的部分原因。
空白是重要的。它有助于分离信息，并使其更易于处理。想象一下，在没有任何空格、换行符或项目符号的情况下阅读此回复。

我最讨厌的是执行频繁操作的文本链接。除非您实际上是在“链接”到一个单独的页面，否则不要让它看起来像一个链接。使其成为控件、图像或某物。链接用于移动网站，按钮做事情。大多数人在想做某事时会主动忽略带下划线的蓝色文本，因为他们习惯了“提交表单”按钮或类似的东西。链接也非常小，并且相对难以单击以进行重复操作，并且对我来说臭在广泛使用时设计/编码不完整。

我见过的许多网络应用程序通常都失败了，它们尝试在浏览器窗口中复制桌面应用程序......这是将圆钉安装到方孔中。可以这样做，但它们不是一回事，几乎在任何情况下都不应该被这样对待。
部分例外是网络应用程序复制了桌面应用程序（即 Google 文档）的功能。然后，在大多数情况下，布局仍然应该更多地反映网页而不是应用程序，但控件应该模仿桌面应用程序以帮助人们过渡。

大多数人使用桌面上的程序来做一些事情。大多数人使用浏览器查看某些东西（阅读、观看等）。当然，有交叉，但想想大多数人的日常习惯，并记住其他人会使用你设计的东西；不只是你（和你的克隆人）在那里。

而且，虽然它是重复其他的，但返回按钮是关键。如果你打破它，用户就会想打破你。覆盖右键菜单或行为通常也是一个坏主意，而且大多会惹恼用户（有些人会积极阻止 javascript 这样做，因为它会让他们非常恼火（包括我自己））。

【讨论】：

【解决方案3】：

唯一最大的区别是 IMO，在 Web 应用程序中，您对鼠标行为的影响非常有限，而且您所拥有的内容与已建立的桌面行为背道而驰。例如：

在桌面应用程序中，几乎普遍地单击鼠标右键会弹出上下文菜单。在 web 应用中也是如此，但它是浏览器的上下文菜单，您不能（也不应该）更改它。
在桌面应用程序中，单击选择某事，双击执行某事；在 web 应用中，单击已经“执行”了一个链接，而双击不存在。

【讨论】：

可以覆盖浏览器的右键。 Google Docs 做得很好，但允许 Shift + Right Click 拉出浏览器的菜单。这使得压倒一切可以接受。但是，据我所知，Google Docs 是唯一提供访问浏览器上下文菜单方式的网站

【解决方案4】：

桌面应用程序倾向于使用“在此事件上执行此代码块”模式编写。 Web 应用程序更多的是块模式“服务器格式化整个页面，用户填写表单并按下按钮，服务器处理整个表单，服务器格式化另一个整个页面”模式。

AJAX 稍微搅浑水，因为浏览器可以在后台请求一些数据，并刷新页面的某些部分。然而，基本原则仍然存在。

让桌面 GUI 更容易响应特定的鼠标移动和点击等。另一方面，对于 Web 应用程序，与服务器的唯一通信是“获取”和“发布”请求，因此用户界面更加笨拙。

基于 Web 的应用程序更加便携，您在客户端上需要的唯一软件就是兼容的浏览器。这些系统管理优势是人们忍受略逊一筹的 GUI 的原因。

【讨论】：

虽然答案来自 2008 年，但桌面的最大缺点是正如您所提到的 - “桌面应用程序倾向于使用“在此事件上执行此代码块”来编写。这会导致业务逻辑最终在客户端。

【解决方案5】：

主要区别在于 Visual 在桌面上构建速度非常快，无需使用不同的浏览器进行测试。我总是发现构建桌面的魅力，因为软件的 Visual 部分只是绑定在你的控制器（包含你的模型），你就在路上！

另一个区别是加载速度。您不必为显示传输 Javascript 或 CSS...您不必压缩或其他东西，因为它始终在桌面上的源代码中可用。

另一件事是您可以使用计算机的 RAM 来做一些困难的事情，这往往会减少在服务端拥有多台计算机的需要，因为您可以使用所有这些计算机来“农场”大进程（如果需要)。

另一方面，部署更难（你有 ClickOnce 和可以帮助你的自动工具），但它从来没有像 web 那样透明。因此，您必须更有计划地进行发布，因为您无法进行“热修复”。

【讨论】：

您可能不必使用不同的浏览器进行测试，但您仍然可以使用许多操作系统来测试桌面应用程序。 XP、Vista、32 位、64 位以及所有使用不同的语言。
测试不同的浏览器再简单不过了。在 Windows 上，您可以测试 IE、Firefox 和 Chrome，并且您已经涵盖了大多数浏览器。 Chrome 使用与 Safari 相同的引擎（Webkit）。
根据经验，我告诉你，对浏览器进行测试要痛苦得多……你的 Web 应用程序仍然需要在所有操作系统中进行测试……而 32 位到 64 位是 99% 的唯一设置在编译中改变..没什么大不了的。

【解决方案6】：

在 Web 浏览器中跨框架通信很困难。例如，让一个 iframe 使用 javascript 影响另一个 iframe。主要是因为加载时间可能不同，所以帧 A 可能需要在定时器循环上等待帧 B 加载。
在 Web UI 中，消息传递确实需要考虑请求/响应周期。很难做到“如果数据库中的记录发生更改，则在用户屏幕上弹出一条消息”。此外，如果按下按钮必须刷新 5 个不同的 iframe，您最终可能会收到 5 个对服务器的单独请求。在桌面用户界面中不必担心这一点。

【讨论】：

【解决方案7】：

我发现最不同的一件事是数据绑定。这个概念还是一样的，但是对于网络应用程序，你总是担心是否重新绑定所述控件以根据其他一些事件单击来刷新数据。桌面应用程序的好处在于，这不是一个问题，因为单击其他事件或转到其他选项卡不会使控件中的数据无效。

【讨论】：