Questions tagged «usability»

3
用户界面文本中的“我的东西”与“您的东西”
在引用用户资料时,应使用My或Your,例如: 我的购物车 我的帐号| 我的收藏 要么 您的购物车 您的帐号| 您的心愿单 我发现这篇文章主张您使用。它说flikr这样做。它还说MySpace和MyYahoo是错误的。 我今天还注意到,亚马逊使用术语Your。但是,我听说他们是测试变体并找到最佳变体的大师,因此您在他们的站点上看到的可能是最佳变体,或者仅仅是他们当前正在测试的东西。 我个人喜欢我看起来更好的方式,但这仅是我的意见。 你怎么看?什么会对客户产生更好的影响?真的重要吗?

4
如果该错误已存在5年以上,那么它是否具有功能?[关闭]
已关闭。这个问题是基于观点的。它当前不接受答案。 想改善这个问题吗?更新问题,以便通过编辑此帖子以事实和引用的形式回答。 4年前关闭。 请允许我添加详细信息:我在许多编码员,测试人员,质量检查分析师,产品负责人等机构工作,以下是令我感到困扰的事情: 十多年来,我们已经能够销售糟糕的(尽管功能很强大)软件。它具有许多功能,产品具有竞争力,但是那里存在一些严重的错误,以及成千上万的“剪纸”,这是客户需要习惯的小烦恼。 看某些事情让我很痛苦,因为我坚信,如果计算机无助于让我们的生活变得更轻松,那么我们就不应该使用它们。我对我的同事充满信心-他们很聪明,有能力,并且在专注于这样做时可以改善事情。 但是,很难将漏洞提交到某些旧功能,而又不会发现它们已关闭或被遗忘。一个典型的答案是:“它在无数个世纪中一直如此”。同样,当质量检查进行回归分析时,他们倾向于寻找与看起来不正确的差异不大的差异。因此,可以将一个旧问题的解决方案写为一个错误,因为“甚至在我之前就已经这样了”。 我心中的年轻程序员认为:重写这个怪异的东西!作为有机会接近客户的人,我想对此方法产生疑问。 我也对您的意见/经验感兴趣。请尝试考虑风险,收益成本和其他非技术因素。

8
验证码值得降低可用性吗?
什么时候使用验证码有用?什么时候是不必要的障碍?验证码只是懒惰/没有经验的程序员的快速解决方案,还是真的防止垃圾邮件和僵尸程序的最佳方法?

3
是否已对任何编程语言的语法进行了可用性测试?
想要改善这篇文章吗?提供此问题的详细答案,包括引文和为什么您的答案正确的解释。答案不够详细的答案可能会被编辑或删除。 在发布给公众之前,任何编程语言的语法都经过可用性测试吗?如果是,执行了哪些测试,结果是什么,以及测试结果对语言的设计产生了什么影响?


3
您如何克服大屏幕房地产设计的挑战?[关闭]
已关闭。这个问题需要更加集中。它当前不接受答案。 想改善这个问题吗?更新问题,使其仅通过编辑此帖子来关注一个问题。 4年前关闭。 这个问题比较主观,但是我希望有一些新的看法。我习惯于为特定的屏幕尺寸(通常为1024x768)进行设计,以至于发现该尺寸不是问题。将尺寸扩展为1280x1024并不能为您带来足够的屏幕空间,无法为您带来显着的变化,但会给我更多的呼吸空间。基本上,我只是扩大了“网格大小”,并且略微缩小屏幕的相同基本设计仍然有效。 但是,在最近的几个项目中,我的客户都使用1080p(1920x1080)屏幕,他们希望解决方案能够尽可能多地使用该屏幕。1920像素的宽度几乎是我习惯使用的宽度的两倍,宽屏使我的一些旧设计方法无法正常使用。我遇到的问题是,面对如此多的空间,我遇到了一些重大问题。 我应该使用几列?宽格式适用于以2:1:1拆分的3列拆分(即,内容列大于其他两个列)。但是,如果我选择三列,那么该多余的列怎么办? 如何有效利用屏幕空间?试图将所有内容同时显示在屏幕上是一种诱惑,但是太多的信息实际上使应用程序更难使用。空格对于帮助理解复杂的信息很重要,但是太多的空格会使相关的概念显得过于分离。 我通常使用具有复杂数据的Web应用程序,而可视化和表示形式是理解原始数据的关键。当您的用户还具有大屏幕(至少24英寸)时,某些信息不在视线范围内,您需要将指针移动很长一段距离。如何确保所需的所有内容都停留在视觉热点内? 当宽度受限制时,像博客之类的简单网站实际上会做得更好,这会导致大量的房地产浪费。我有点想知道是否将文本框和文本预览并排放置对于这种类型的屏幕的管理员侧来说是否会有很大的好处?(1:1两列拆分)。 对于您的答案,我知道设计中的几乎所有内容都是“取决于”的。我正在寻找的是: 您使用的一般原则 您的设计方法是如何改变的 我发现我必须重新训练自己如何使用这种不同的格式。迄今为止,我一直努力解决的每个分辨率难题都约为25%:640至800(增加25%),800至1024(增加28%)和1024至1280(增加25%)。但是,从1280到1920的跃迁在空间上增加了50%,相当于从640跃升到1024。这是没有常用的中等大小来帮助逐步学习课程的。
10 design  gui  usability 

7
如何说服用户不要使用草图UI?
我最近使用Sketchflow设计了一个新系统的原型,现在一些主要的利益相关者正在努力在最终产品中绘制草图外观。更糟糕的是,查看原型的人被要求通过相当领先的调查问题提供有关草绘外观的反馈,其中80%的回答是肯定的。 它用于主要是内部客户端的企业应用程序,但也打算由某些外部客户端使用。 我认为这是个坏主意的主要原因是: 它看起来不光滑或专业 以草绘样式为实际应用程序蒙皮涉及大量工作 草绘的样式无法有效利用屏幕空间 我一直在尝试找出可能的吸引力,而我唯一能想到的就是人们被它的简单性所吸引-尤其是当与现有系统相比时,它将被取代。 谁能指出我为什么使用草图外观是一个坏主意的证据?理想情况是基于UI研究的东西。我担心除非我能指出一些具体的东西,否则我的声音不会被听到。 [编辑] 我可能应该补充一点,使应用程序外观困难的因素还在于,它打算作为一个或多个Silverlight Web部件在Sharepoint站点中交付。在两种技术之间获得一致的草图外观可能非常困难。 [编辑] 万一有人不确定Sketchflow原型的外观(以及相关人员的要求),他们实质上是在要求生产应用程序具有铅笔素描线框的外观和感觉。
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.