键/值属性框用户友好吗？
假设我有一个应用程序，它的 GUI 设置屏幕非常糟糕。 我可以容纳我需要的 90% 的属性，让用户使用看起来像这样的盒子之一进行设置
▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪ ▪height ▪ 1.3in ▪ ▪width ▪ 3.0in ▪ ▪top ▪ 3.2in ▪ ▪left ▪ 2.3in ▪ ▪caption ▪ 'awesome'▪ ▪order ▪ 3rd ▪ ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
但是，这些盒子真的很好用吗？还是我只是假设它们是因为作为一名程序员，我一直在使用它们我的IDE？
Say I've got an app with a laughably awful GUI setup screen. I could fit 90% of the properties I need to let the user set up with one of those boxes that look like
▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪ ▪height ▪ 1.3in ▪ ▪width ▪ 3.0in ▪ ▪top ▪ 3.2in ▪ ▪left ▪ 2.3in ▪ ▪caption ▪ 'awesome'▪ ▪order ▪ 3rd ▪ ▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪▪
But, are these really good and usable or do I just assume they are because as a programmer I use them all the time in my IDE?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
使其更加用户友好的一个关键项目是类别。 正如 Oddthinking 在他的回复中指出的那样，四到五个项目就差不多了。
尽管如此，只要你非常简洁和仔细地对它们进行分组，你就可以逃脱更多的惩罚。 例如，高度和宽度可以而且应该分组在一起，因为每当用户指定其中一个时，他们就会用来指定另一个。
如果您的类别布局非常好并且其中只有四到五个项目，那么您的设置屏幕可以包含更多选项而不会显得混乱，因为标题告诉他们在尝试之前需要什么样的信息部分。
A critical item that makes it much more user friendly is categories. As Oddthinkingnoted in his response, four or five items is about right.
Although, you can get away with more as long as you group them very concisely and carefully. For instance, height and width can and should be grouped together, because whenever users specify one they are used to specify the other.
If your categories are very well laid out and have only four to five items in them, then your setup screen can contain a lot more options without seeming confusing, because the titles tell them what kind of information they need at their disposal before they attempt that section.
这实际上取决于正在创建的应用程序的类型以及访问它的用户的类型。
如果他们是技术类型，并且对应用程序进行了一些分析，我可以看到这非常适合。 如果应用程序更多地以操作或工作流程为导向，我不确定这是否适合。
同样，这一切都取决于什么将为最终用户提供最大的生产力。
That really is going to depend on the type of application being created and the type of users accessing it.
If they are technical types and there is some analysis going on with the application, I can see that fitting in quite nicely. If the application is a little more action or workflow oriented, I'm not sure how well this would fit in.
Again, it all depends on what is going to give the end user the most productivity.
理想情况下，您将拥有良好的默认值，因此用户不需要更改任何内容......但如果这是不可避免的，并且您对此很聪明，我认为这是可以做到的。
一些提示：
您可能无法使用默认控件来做到这一点.. 。所以写你自己的。 这需要一些时间，但恕我直言，这是值得的。
Ideally, you'll have good defaults, so the user won't need to change anything... But if that's unavoidable, and you're smart about it, I think it could be done.
A few tips:
You probably can't do this with a default control... So write your own. It will take some time, but IMHO it's worth it.
这里的属性数量是一个相关因素。
我的直觉是四五个可能是可以原谅的。 七可能会推动它。
我的经验是，到了几十上百的时候就不行了。 人们不再能够简单地阅读所有条目来找到他们想要的功能，而无需在经验丰富的用户之间传递秘密秘诀。
The number of properties here is a relevant factor.
My gut feel is that four or five may be forgivable. Seven may be pushing it.
My experience is that when it gets to dozens or hundreds, it becomes unworkable. People can no longer simply read all the entries to find the feature they want, without secret recipes that get passed around from experienced user to experienced user.
作为主要用户，我有时将这些与带有配置屏幕的应用程序一起使用，但是在使用一定数量（通常大约 5 或 6 个）之后，我开始感觉该程序制作得很差。
As mainly a user, I use these sometimes with applications with configuration screens, but after a certain number of them (usually around 5 or 6), I start to get the feeling that the program is poorly made.
你骑什么类型的自行车？ 一速巡洋舰？ 简单的！ 一台有 6 个档位的老式 10 速旧车还能用吗？ 基本可以用。 21 速需要高于平均水平的技能，然后大多数人都会使用其中的一个子集。 80 速？ 嗯。
What kind of bicycle do you ride? One-speed Cruiser? Easy! An old 10-speed clunker with 6 gears that work? Basically usable. 21-speeds take greater than average skill, and then most folks use a subset. 80-speeds? Hmmm.
它当然有用。
对于简单的概念来说就足够了。 我发现我经常试图让用户输入他不理解的东西。 有时，这是我不理解的数据。
然后我觉得很好地理解你的数据到底代表什么是非常重要的，然后不要要求一个数字表，而是找到一种方法来通知你的用户他在输入的同时他正在输入什么。
例如，在您给出的非常简单的示例中（假装它很复杂），您实际上可以在屏幕上显示盒子的图片以及数据。 当您输入数据时，该框可能会稍微移动或明显调整自身大小。
然后，您可以通过允许他们拖动框的边缘并通过拖动更新字段来进一步实现这一点。
虽然这个例子太简单，无法保证这种努力，但我已经取得了很多成功——例如设置一个电路，其中必须在 DS1 或 T1 中的 DS0 组中包含 DS0。 OC-3 中的 T1 束位于光纤环路上的 3 个通道之一上。
实际上比这复杂得多，10 名工程师在弄清楚我的要求后花了 2 天的时间才正确记录。 有一次，我们有 4 个充满排列的白板，然后我们将它们重构为一张（非常拥挤的）纸。
一旦我理解了这一点，我就为它制作了一个很棒的用户界面。
此外，那篇论文本身也成为了一份营销文件——他们以前从未描述过他们的盒子实际上是做什么的（而这正是他们的营销经理在查看论文时所说的）。
因此，简短的要点是：对于任何不明显的事情，请尝试充分分析和理解您向客户提供/请求的数据背后的业务问题。 当你理解它时，弄清楚到底是什么导致了突破，并将其转化为 GUI。
it's certainly usable.
For simple concepts it is adequate. I find that I'm often trying to get a user to input something he doesn't understand. At times, it's been data I don't understand.
Then I feel it's REALLY IMPORTANT to get a good understanding of exactly what your data represents, and then rather than ask for a table of numbers, find a way to inform your user of what he's entering at the same time as he's entering it.
For instance, in the very simple example you give (pretend it's complicated), you could actually display a picture of a box on the screen as well as the data. As you input the data, the box may shift a little or visibly resize itself.
You could then further this by allowing them to drag the edges of the box and have the drag update the fields.
Although this is too simple an example to warrant that kind of effort, I've had a lot of success--for instance setting up a circuit where you must contain a DS0 in a group of DS0s inside a DS1 or T1 which is in a bundle of T1s in an OC-3 which is on one of 3 channels on a fiber loop.
It was actually much more complicated than that and took 10 engineers 2 days to document correctly once they figured out what I was asking. At one point we had 4 white boards full of permutations, then we refactored them down to a single (very crowded) piece of paper.
Once I could understand that, I made a GREAT UI for it.
Also that paper became a marketing document itself--they had never described what their box actually does before (and that's exactly what their marketing manager said when he looked at the paper).
So the shorter take-away version: For anything that isn't obvious, try to fully analyze and comprehend the business problem behind the data you are presenting to/requesting from the customer. When you grok it, figure out exactly what caused the break-through and turn it into a GUI.
通过对细节的相当多的关注，您可以使其可用。 但是，如果您有许多嵌套对象，它很快就会变得笨拙。 我会看看您当前 GUI 的重新设计。 截图怎么样？
With a fair amount of attention to detail, you could make it usable. However if you have many nested objects it'll soon get unwieldy. I'd look at a re-design of your current GUI. How about a screenshot?