Web 应用程序中具有多列的表
哪种方式是表示具有多列且列中可能有长文本的表中的数据的最佳方式？困境是，如果我使用表格，表格宽度很长并且表格溢出到div之外。有哪些选项，我可以列出数据，这些帖子在业务应用程序的 stackoverflow 中列出的方式吗？它将如何影响可用性？
Which is the best way to represent data from a table with many columns and possible long text in the columns? The dilemma is , if I use tables, the table width is very long and the table overflows outside the div. What options are there, can I list the data, the way this posts are listed in stackoverflow in a business application? How will it affect usability?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一般来说，对于每条记录占据一行的非常宽的表来说，不存在根本的可用性问题，只要：
您提供水平滚动，以便用户可以到达所有字段。
您将记录标识符修复为行标题，使其不会滚动到视图之外，以便用户始终可以识别他们正在查看的记录。
字段相对较短，因此可以同时看到许多字段；当然，您不希望某个字段比典型的窗口屏幕宽，这样用户就可以来回滚动每条记录来读取该字段。
用户成功使用非常宽的电子表格的事实表明，宽表不一定是问题。
然而，像 SO 这样的每条记录多行布局可能最适合 SO 所用于的任务类型：用户扫描记录中的特定字段值（问题标题）以查找潜在感兴趣的记录。一旦用户找到可能感兴趣的记录，她或他就可以在没有任何额外输入的情况下读取其他字段（例如答案数、投票数）来决定是否值得深入了解更多信息。与每条记录单行的宽表相比，这意味着需要更多的滚动来扫描相同数量的记录，但需要更少的滚动或单击来查看给定记录中的内容。因此，在以下情况下，用户的工作量将会减少：
某些字段非常长（例如，跨越整个窗口）。
用户可能会扫描的字段很少。
那些用于扫描的字段以图形方式突出以方便扫描（例如，使用大、粗体和/或彩色字体）。
当用户可能扫描大量字段中的任何一个时，每条记录多行布局不太好。您可以使一到三个字段比其他字段更显着，但如果您尝试使每个字段显着，那么它们都不显着。
与每条记录单行的宽表相比，用户可以水平滚动到感兴趣的任何字段并向下浏览表。没有必要让任何特定领域比其他领域更加突出。
当用户在给定字段上的两个或多个记录之间工作时，每条记录单行表也更好，例如，比较字段上的记录或将一个字段值复制到另一个字段值。一次可以看到给定字段值的更多记录，从而减少滚动。当值直接位于彼此之上时，比被其他字段垂直分隔时，比较值也更容易。
In general, there are no fundamental usability problems with a very wide table with each record occupying a single line as long as:
You provide horizontal scrolling so the user can get to all the fields.
You fix the record identifiers as row headers that they do not scroll out of view so the users can always identify the record they’re looking at.
Fields are relatively short so that many are in view at once; certainly you don’t want one field being wider than the typical window screen so the user as to scroll back and forth for each record to read that field.
The fact that users successfully use very wide spreadsheets shows that wide tables are not necessary a problem.
However a multi-line-per-record layout like SO is perhaps best for the kind of task that SO is used for: the user scanning records for a particular field value (the question title) to find a record of potential interest. Once the user finds a potentially interesting record, she or he can then without any additional input read the other fields (e.g., number of answers, number of votes) to decide if it’s worth drilling down for more information. Compared to a wide single-line-per-record table, this means more scrolling to scan the same number of records, but less scrolling or clicking to see what’s in a given record. There will thus be less work for the user when:
Some fields are very long (e.g., spanning the whole window).
There are few fields the user is likely to scan on.
Those fields for scanning are made graphically salient to facilitate scanning (e.g., with big, bold, and/or colorful font).
A multi-line-per-record layout is not so good when the user may be scanning on any of a large number of fields. You can make one to three fields more salient than the rest, but if you try to make every field salient then none of them are salient.
In contrast with a wide single-line-per-record table, the user can scroll horizontally to whatever field is of interest and scan down the table. There is no need to make any particular fields more salient than the others.
A single-line-per-record table is also better when the user is working between two or more records on a given field, for example, comparing the records on a field or copying one field value to another. More records for a given field value are visible at a time, reducing scrolling. It’s also easier to compare values when they are directly on top of each other rather than when separated vertically by other fields.