模式面板中的滚动条
我正在开发一个 Web 应用程序，其中有一个模式面板/对话框弹出窗口来收集用户数据。面板中的表单变得很大，我们建议将表单拆分为多个选项卡，但我们的客户建议在模式面板中添加滚动条。
模式面板中的滚动条是否存在可用性问题？我认为这是一个不好的做法，但我想听听其他意见。
谢谢，
格伦
更新： 我将更详细地解释该场景。我们有一个搜索页面，可以在其中保存搜索结果项（复制到系统的另一个区域）。附加信息可以与此项目一起保存（例如附加注释、分配给其他存储桶 - 我无法详细说明）。当用户想要保存搜索结果项时，他们可以检查一个或多个项目并单击保存按钮 - 这时我们的模式面板会弹出。
最初，用户被带到一个单独的页面，并且他们关注一系列页面。我们的客户认为这很耗时，因此我们更改了页面以使用模式面板。
我不能 100% 确定使用模态面板是最好的设计，但这就是我们现在所拥有的。我欢迎任何其他想法。
I'm working on a web application where we have a modal panel/dialog popup to collect user data. The form within the panel has grown large and we've suggested splitting the form across multiple tabs, but our client has suggested adding scrollbars within the modal panel.
Are there usability issues with scrollbars within a modal panel? I believe it's a bad practice but I'd like other opinions.
Thanks,
Glen
Update:
I'll explain the scenario in more detail. We have a search page where search result items can be saved (copied into a another area of the system). Additional information can be saved with this items (e.g. additional comments, assignment to other buckets - I can't get into any more detail than that). When a user wants to save a search result item, they can check one or more items and click a save button - that's when our modal panel popups.
Originally, the users were taken to a separate page and they followed a series of pages. Our clients felt this was time consuming, so we changed the page to use a modal panel.
I'm not 100% sure using a modal panel is the best design, but that's what we have now. I welcome any other ideas.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
好吧，我想问一下，如果你有一个这么长的模态表单，难道不应该将其制作成自己的页面吗？
我的意思是，模态对话的全部目的是告诉用户他需要知道的事情（这些信息通常被忽视并且很烦人），或者在继续之前从用户那里获取一些必要的信息。
您说您的表单是用于收集用户输入的。如果用户在继续操作之前必须输入某些内容（例如结帐流程的一部分或类似的内容），那么我想说最好将整个页面专用于该流程。
如果它更像是“在继续您正在做的事情之前先登录”之类的事情，那么我认为它作为自己的页面更有意义，可以将您带回到您所在的页面填写完表格后，在输入之前。这就是 Stack Overflow 人工验证页面的工作原理。
如果它是像“向我们提供有关该网站的反馈”之类的烦人内容，那么它根本不应该是模态的，而应该是一个很容易被忽略的（我敢说吗？）弹出窗口。
模态对话确实应该尽可能简短。如果简洁是不可能的，并且对话确实必须是模态的，那么我认为创建一个必须先填充才能访问下一个页面的页面流会更有意义。就像结帐一样：您需要在添加运输信息之前将产品添加到购物车，并且需要运输信息才能确定运输成本。那种事。
但是，如果不知道模态对话的确切性质，我无法准确地告诉您哪种方式最好。
编辑：啊哈！您的客户觉得这很耗时，是吗？在这种情况下，您应该进行非常快速且肮脏的实时可用性测试，看看哪种方法实际上更好。从大厅下面抓一些人，向其中一些人展示模式化的方式（通过滚动），向其他人展示旧的（非模式化的）方式，看看他们会说什么。
（理想情况下，您正在录制会话和屏幕，并且确保不让您自己的个人喜好暴露出来。只需要求他们在您观看时使用系统，看看他们执行任务的情况如何。使用录音来计时方法来查看一种方法是否真的比另一种方法更快。）
您不应该做出违反规范的可用性决定（在这种情况下，规范是“大型表单值得拥有自己的页面”）而不确保它实际上非正常方式更有用。当谈到可用性时，规范通常是规范，因为它是可用的（但并不总是如此，这就是为什么你必须测试）。如果客户反击，你至少会有证据表明他们正在反对确凿的经验证据，证明他们想要的东西是愚蠢的。
但最终买单的还是客户。如果你不能让他们明白道理，那么你就必须充分利用他们告诉你的内容。如果表单必须处于模式对话框中，那么您至少可以尝试将非必要字段隐藏在折叠下（如果有非必要字段），以便大多数用户永远不必滚动。
确保无论用户滚动到哪里，提交表单的按钮（或您需要对表单执行的任何操作）都是可见的。一个非常糟糕的主意是将所有必填字段放在顶部，然后强迫用户向下滚动以点击提交按钮。这太粗鲁了。
Well, I gotta ask, if you have a modal form that's so long, shouldn't it be made into its own page?
I mean, the whole point of modal dialogues is to tell the user something he needs to know (which are usually disregarded and are annoying) or to get some information from the user that is necessary before proceeding.
You say your form is for gathering user input. If it's something the user must enter before proceeding (as in a part of a checkout flow or something like that), then I would say it's probably best to dedicate an entire page to the flow.
If it's something that's more of a "log in here before proceeding with what you're doing" kind of thing, again, I think it would make more sense for it to be its own page that brings you back to the page you were on before you entered it once you're done filling out the form. That's how the Stack Overflow human-verification page works.
If it's something annoying like "give us your feedback about the site", then it shouldn't be modal at all but rather an easily-dismissed (dare I say it?) pop-up window.
Modal dialogues really should be kept as brief as possible. If brevity is impossible, and the dialogue really must be modal, then I think it would make more sense to create a flow of pages that must be filled in before the next one can be accessed. Like a checkout: you need to add products to a cart before adding shipping information, and you need shipping information before you can determine the cost of the shipment. That kind of thing.
But without knowing the exact nature of your modal dialogue I can't tell you exactly which way would be best.
EDIT: Aha! Your clients felt this was time consuming, eh? This is the type of situation where you should do a very quick and dirty live usability test to see which way is actually better. Grab some people from down the hall, show some of them the modal way (with scrolling) of doing it and show others the old (non-modal) way of doing it and see what they have to say.
(Ideally you are recording the session and the screen, and you make sure to not let your own personal preferences show through. Just ask them to use the system while you watch to see how well they perform the task. Use the recording to time both methods to see if one way really is faster than the other.)
You shouldn't ever make a usability decision that goes against the norm (the norm in this case being "large forms merit their own pages") without making sure that it actually is more usable the abnormal way. When it comes to usability, the norm is usually the norm because it's usable (but not always, which is why you must test). If the client fights back, you'll at least have evidence that they're going against hard empirical evidence that what they want is silly.
Ultimately, though, the clients are the ones paying the bills. If you can't get them to see reason then you'll have to make the most of what they tell you. If the form must be in a modal dialogue, then you can at least try to hide non-essential fields under the fold (if there are non-essential fields) so that the majority of users will never have to scroll.
Make sure the buttons to submit the form (or whatever it is that you need to do with the form) are visible no matter where the user has scrolled. A really bad idea would be to put all the required fields at the top and then force the user to scroll down anyway to hit the submit button. That's just rude.
在这里放置一个模式窗口似乎是有意义的——我假设您将其作为页面上的一个层进行操作。但听起来它变得越来越拥挤，而您正在寻找管理不断增加的 UI 元素数组的方法。
要回答您关于滚动条的最初问题，不，它们不是禁止的。然而，正如另一个回应所断言的那样，你永远不应该在滚动区域内设计操作 UI 元素。
听起来一些好的用户研究在这里可能会有用。哪些项目对用户来说很重要。哪些项目是必需的，哪些是可选的？可以对它们进行分类吗？
有些人建议，当 UI 项目的数量超出对话框时，选项卡对于分类很有用。但在这种情况下，我认为这将是一个坏主意。这不是对话框的设置类别，而是更多的确认/选择/输入对话框，用户将在其中保存输入和选择的内容。对于选项卡，用户很可能会错过选项卡并错过输入信息。如果需要“后退”选项卡上的某些内容而用户没有去那里，那么您的错误体验会非常糟糕。
滚动的优点之一是对于使用鼠标的用户来说很容易。他们可以选择单击滚动条或（对于许多人来说）滚动滚轮。
您可能没有考虑到的一件事是在对话框中创建可以折叠和展开的部分，特别是如果用户可以输入或选择的某些内容是可选的。默认情况下，具有必需元素的部分将展开，而具有可选元素的部分将默认折叠。如果某个部分的扩展添加了滚动条，则用户界面中的这种添加对用户来说是显而易见的。
当然，您可能必须弄清楚这一切对于只有键盘的人、有残疾的人以及可能在移动设备上访问此内容的人来说是如何工作的。
It seems to make sense to put a modal window here--I assume you're doing it as a layer on the page. But what it sounds like is that it's getting crowded, and you're looking at ways to manage the ever-increasing array of UI elements.
To answer your initial question about scrollbars, no, they are not verboten. However, as another responded asserted, you should never design action UI elements within the scrolling area.
It sounds as if some good user research could be useful here. What items are important to users. Which items are required and which are optional? Can they be categorized?
Some people suggest that tabs are useful for categorization when the number of UI items overflows a dialog box. In this case, though, I think this would be a bad idea. This isn't a setting category of dialog box, but more of a confirmation/selection/entry dialog where users will save whatever is entered and chosen. There's a good chance with tabs that users would miss the tabs and miss entering information. And if something on a "back" tab is required and a user doesn't go there, then you have a really poor error experience.
One of the things about scrolling is that it is easy for users with mice. they have the option of either clicking on the scrollbar or (for many) rolling a scroll wheel.
One thing you may not have considered, especially if some things that users can enter or choose are optional, is to create sections within the dialog box that can be collapsed and expanded. Sections with required elements would be expanded by default and sections with optional elements would be collapsed by default. If expansion of a section adds a scrollbar, that addition to the UI is obvious to users.
Of course, you may have to figure out how all this would work for people who have only keyboards, who have disabilities, and who might be accessing this on a mobile device.
我不认为选项卡式面板从根本上比滚动面板更好或更差。每个人在不同情况下都有优势。然而，在您的情况下更重要的是：如果您需要选项卡或滚动，那么您的面板可能太复杂而无法模式化。在模态面板中输入的信息越多，用户就越有可能需要去其他地方才能获得答案，并且如果用户决定出于任何原因必须去其他地方，那么您浪费的工作就越多。
解决方案是将尽可能多的信息移出面板并移至父页面/窗口上。让用户直接在搜索结果页面上输入“附加信息”，让他们探索结果以帮助他们做出信息决定。由于附加信息显然消耗了大量空间，因此使其控件可显示和可隐藏，但始终在隐藏和显示之间保留用户输入。我认为可以使用选项卡或滚动来保持较小的占用空间。有关单个搜索结果的附加信息应放在该搜索结果旁边的控件中，而不是放在单独的面板中。
模式“保存”面板应该只包含一些有助于保存的控件，例如文件名和位置，也许还包括文件类型。如果所有信息都有助于保存，则使保存面板成为无模式。谁说你不能？
将所有保存信息放在另一个页面上并不比模态面板好多少，因为这也是有效的模态面板，从某种意义上说，用户无法在不丢失输入的情况下转到其他地方。即使您采取措施在用户转到另一个页面时保留用户对该页面的输入，大多数网络滥用用户也会认为他们可能会丢失他们的输入，因此他们不会尝试。
I don’t think a tabbed panel is fundamentally better or worse than a scrolling panel. Each has advantages in different situations. However more important in your case is this: If you need tabs or scrolling then your panel is probably too complex to be modal. The more information input in a modal panel, the more likely a user will need to go somewhere else to get an answer, and the more work you throw away if the user decides they must go somewhere else for any reason.
The solution is to move as much information as you can out of the panel and onto the parent page/window. Let users enter the “additional information” right onto the search results page, allowing them to explore the results to help them decide on the information. Since the additional information apparently consumes a lot of space, make its controls show-able and hide-able, but always preserve user inputs between hides and shows. I think it’s okay to either tabs or scrolling to keep the footprint small. Additional information about a single search result should go in controls next to that search result, rather than in a separate panel.
The modal Save panel should only include a few controls that are instrumental to saving, such as the filename and location, and maybe the file type. If all the information is instrumental to saving, then make the save panel modeless. Who says you can’t?
Putting all the save information on another page is not much better than a modal panel, since that is also effectively modal, in the sense that the users can’t go somewhere else without losing their input. Even if you take steps to preserve users’ inputs to the page if they go to another page, most web-abused users will think they might lose their input, so they won’t try.