问题标签 [usability]

谁能告诉我一些最重要的可用性、可访问性和 SEO 指南，在开发一个好的 Web2.0 网站时必须考虑这些？

在注册用户部分的大多数网站上，他们希望您输入密码 2 次。这是为什么？为什么不只输入一个输入密码？为什么一定要“确认”呢。

你知道

这件事一直在我脑海里...

希望有人能回答这个问题。

谢谢

我想知道是否可以在网页的搜索框附近没有提交按钮（例如，确定、执行或搜索）。

我知道按回车键要快得多，并且它会执行搜索。

但是，对于普通的非技术精通用户还是仅适用于技术社区，这是公认的惯例吗？

例如，stackoverflow 的搜索框没有提交按钮，但我认为没有人在抱怨（我当然不会）。

另一方面，有人建议以谷歌为例：如果按钮被删除，人们会注意到吗？

我刚开始阅读Steve Krug的Don't Make Me Think，他提到每个搜索框都应该有一些东西告诉我我可以点击它来启动搜索。

你的意见？

我们有时需要通知用户有关警告或问题的信息。但很多时候，特别是如果这是一个常见问题，用户只会忽略警告并继续。很多时候用户甚至不会记得看到警告，但我们检查他们的日志并看到显示了几个。那么，当你试图告诉他们一些重要的事情时，你如何让用户注意呢？

这不像强迫用户在允许他们保存之前解决所有问题那么简单。由于各种原因（通常是因为无法立即解决或根本无法解决的问题），他们经常需要保存我们的业务规则并不严格允许的数据。

我们有一个更好的警告/错误处理系统，我认为这将有很大帮助，但我想看看其他人做了什么。

<title>标签 的多种用途使问题复杂化……</p>

• 作为浏览器窗口或搜索结果标题，它似乎没什么区别——所有东西都有足够的空间，显示顺序与标题无关。

• 对于选项卡和任务栏/停靠标题，空间更为宝贵。将页面名称放在首位可以更容易区分同一站点上的多个页面，但如果页面名称是通用的（“搜索结果”、“CSS 简介”），则区分站点可能比区分站点更重要页。

• 在书签标题中，首先使用站点名称既可以使它们更容易找到，也可以通过简单的排序将它们分组，但是用户可以根据自己的喜好轻松更改标题（并且经常这样做），使提供的“默认”标题不太重要。

还应考虑哪些其他因素？是否有普遍接受的“最佳实践”？

当前被认为是 UI 设计中用于显示当前上下文中不可用的操作的最佳实践。

例如，A 页面显示可以拥有许多关联合同的客户。如果有有效合同，我不希望允许用户删除客户。从可用性和 UI 的角度来看，什么被认为是最适合用户体验的。

1. 始终显示删除选项，但在用户选择它时警告用户该选项不可用，因为有活动合同。
2. 显示删除选项，但将其变灰。
3. 根本不显示删除选项

始终显示选项具有一致性的好处，并且相关操作始终在同一个地方等，但相反，向他们展示他们不能做的事情的意义何在。

将选项灰显仍然具有一致性，但不允许他们选择他们无法执行的操作。

完全不显示选项缺乏一致性，但可能不会那么混乱。

在昨天之前，我什至不会问这个问题，而是直接选择选项 2（灰色）但是看到用户多次尝试点击灰色的图像并最终问我为什么他们不能点击按钮我不再确定最好的选择是什么。

有可用性和 UI 测试经验的人觉得什么是最好的选择？

我开发了一个在抵押贷款公司内部使用的 Web 应用程序。我们一直遇到人们在与客户交谈时填写表格然后在点击保存之前点击离开屏幕的问题，从而丢失他们的数据（他们可以只点击返回，当然，但他们从未想过这一点）。

我们用户的第一个“解决方案”是要求我们在每次更改字段后自动保存数据。即使忽略明显的可扩展性问题，在我看来，这与地球上几乎所有其他 Web 应用程序的惯例完全背道而驰，其中您在提交表单时保存（总 Ajax 应用程序，如 GMail 不算，因为他们是一个完整的“另一种野兽”。我错了吗？或者（再次，忽略可扩展性）您认为这是一种合理的方法吗？

继续前进，我们的实际解决方案是弹出旧的“您确定要离开此页面浏览吗？” 当用户离开脏表单时的对话框。现在我们收到了有关对话结构方式的投诉。大多数应用程序都会说“您要保存更改吗”，因此点击“是”或“确定”是一个很好、安全的选择。但是对于导航离开对话框，点击 OK 是不安全的、不保存的选项。我们的用户当然不会阅读对话框，他们只是点击 OK，然后砰的一声，他们丢失了他们的更改。

我对更改此对话框犹豫不决，因为 (a) 该对话框是标准的，由浏览器生成，(b) 我什至不知道如何更改该对话框，以及 (c) 它已经存在数月了，人们（包括已经弄清楚的非白痴）将不得不重新学习他们的行为。

你认为这里最好的路线是什么？

现在开始查看我去年的项目，因此我正在编写规范要求文档。现在，碰巧这个项目需要高度的“可用性”——我不知道这是否是正确的英文单词，但我的意思是它应该很容易从用户 PoV 中使用。现在 - 在我目前从事的所有项目中，可用性并不是一个真正重要的因素，所以我可以写一些乱七八糟的东西来解决它。虽然我总是问我们的老师他们会如何指定可用性的要求，但还没有人给我一个我觉得足够好的答案。

我们的老师一直鼓吹对项目的任何要求都应该是“可测试的”，但是您如何测试您的用户界面的可访问性？

假设我有一个实时应用程序正在运行。在这里说“一个条目应该在初始调用后不到 100 毫秒内被删除”并不难。但是要说“用户界面应该是 86% 直观”要困难得多。

我想这是一个难以破解的难题，但我肯定不会是世界上第一个想到这一点的人，更不用说遇到问题了。

我想为我的用户提供一个“高级”搜索引擎。我基本上有很多搜索条件可供选择：

• 有些非常简单/常见，将大量使用（即时间段、项目 ID）
• 有些不太主流
• 还有一些不会用很多，但我还是想提供

总的来说，我有大约 30 多个标准可供选择

结果是我在网格中显示的数据集。

我在互联网上寻找灵感，甚至谷歌似乎也没有一个很好的高级搜索解决方案。

我过去设计过这种工具，但我对结果并不满意，尽管用户最终能够非常有效地使用它。

• 你认为搜索面板应该一直可见（即显示在我的结果网格顶部）还是以单独的形式提供（这让我可以为所有控件使用更多位置）

• 您认为最好显示所有搜索条件，还是让用户在想要查看/使用更多条件时单击“高级”？

• 您将如何组织标准？按使用频率，或者按区域（即与用户、位置、时间等相关的标准）

• 我应该把“搜索”按钮放在哪里？在更常见的搜索控件旁边，还是在底部，或两者兼而有之？

更一般地说，您是否有关于如何设计一个漂亮的搜索 UI 的提示要分享？在这种“高级”搜索引擎中，您通常会错过哪些功能？

有时会发生一个特征似乎属于多个地方的情况。

简单的例子，假设我有以下菜单：

• 文件
• 挂单
• 接受的订单
• 工具
• 帮助

我有一个搜索功能，相同的搜索窗口适用于待处理和已接受的订单（它只是一个你可以更改的“订单状态”组合）

这个搜索功能属于哪里？

• 工具菜单似乎是一个不错的选择，但我担心用户可能希望搜索接受的订单在接受的订单菜单中，这是有道理的

• 在我看来，在待处理订单和已接受订单中复制菜单条目似乎是错误的。

你会怎么办？（假设我们不能将两个订单菜单合并为一个菜单）