当数据以列表/表格或图形格式（后者包括地图、图表和大多数所见即所得应用程序）布局时，针对多种窗口大小进行设计（如果不是开发）非常容易。显示表格或图形的窗格应随着窗口大小的调整而调整。通常，您可以根据需要添加水平和垂直滚动条，以允许用户在当前的任何窗格大小内平移数据。通过调整窗口大小来调整窗格大小通常意味着所有数据都可以通过滚动条访问。将数据分解为页面的效果并不好（例如，像 Google 搜索结果的分解方式）。
Apps should automatically adjust to a variety of window sizes as well as screen sizes. You shouldn’t assume that users will always want to run your app at full screen size. Even if all your users have humungous screens, they may want to show multiple windows side by side in some cases.
Designing (if not developing) for multiple window sizes is pretty easy when the data are laid out in a list/tabular or graphic format (the latter including maps, diagrams, and most WYSIWYG apps). The pane that shows the table or graphic should resize as the window resizes. Generally, you include horizontal and vertical scrollbars as necessary to allow the user to pan around the data within whatever pane size there is at the moment. Resizing the pane with window resizes generally implies all data is accessible by scrollbars. It doesn’t work well to break up the data into pages (e.g., like the way Google search results are split up).
It’s perfectly acceptable to have horizontal scrolling for a table (unlike for a web page dominated by prose) as long as the first column(s) that identifies the rows remains in view when the user scrolls horizontally. Likewise the column headers should remain in view when the user scrolls vertically. For graphics, changing window size generally should not change the level of zoom. Instead, show more data when zooming out and less when zooming in, while providing a separate zoom feature.
For data laid out as a form, with fields and labels for a single record running down the pane, there really isn’t a good way of handling multiple window sizes, and you have to choose a window size to design for. For usability, you should design so that at standard text size all fields are visible without scrolling when the window is sized to the lowest screen resolution you’re likely to come across. Use tabs or other similar controls to fit all the required fields in that space. Generally, this implies a designed-for size of 1024x768, assuming your users may use your app on a laptop. It may be acceptable to have a form layout that requires some vertical scrolling at smaller resolutions (as is common on web apps), but users should never have to scroll horizontally for typical cases. Thus, in your case you may want to design for 1024x1050 if most of your users use desktops and only occasionally use laptops. Test that users realize they have to scroll when using a low resolution before proceeding with this. If you expect users to use the window regularly while viewing other windows (e.g., it’s more like a properties dialog), that may set additional limits on the window size.
With a form layout, the size of the text or the spaces between the fields should not change when the window is resized (although allowing the user to explicitly increase text size is a good idea). Resizing larger than the designed-for size should simply add blank margins to the right and bottom. In other words, there really isn’t much point in resizing larger for form layout. That’s okay. At least some of your users will make good use of unused screen space for something else (e.g., another window or app). Real power users with big screens may open two instances of the same window side by side and have each instance show a different tab so they can monitor as much as possible at once.
Resizing smaller than the designed-for size for a form layout should cause scrollbars to appear and provide access to fields that are no longer in view. The latter situation should be an edge case if you’ve chosen the lowest screen resolution you’re likely to come across.
In general, you design for the lowest screen resolution that you expect to encounter.
You're correct in that there are a multitude of reasonable screen resolutions.
You have the option of designing your user interface for multiple screen resolutions, and having your application choose the appropriate layout depending on the actual screen resolution.
发布评论
评论（2）
应用程序应自动调整以适应各种窗口尺寸和屏幕尺寸。您不应该假设用户总是希望以全屏尺寸运行您的应用程序。即使所有用户都有巨大的屏幕，在某些情况下他们也可能希望并排显示多个窗口。
当数据以列表/表格或图形格式（后者包括地图、图表和大多数所见即所得应用程序）布局时，针对多种窗口大小进行设计（如果不是开发）非常容易。显示表格或图形的窗格应随着窗口大小的调整而调整。通常，您可以根据需要添加水平和垂直滚动条，以允许用户在当前的任何窗格大小内平移数据。通过调整窗口大小来调整窗格大小通常意味着所有数据都可以通过滚动条访问。将数据分解为页面的效果并不好（例如，像 Google 搜索结果的分解方式）。
只要用户水平滚动时标识行的第一列保持在视图中，表格的水平滚动（与以散文为主的网页不同）是完全可以接受的。同样，当用户垂直滚动时，列标题应保持在视图中。对于图形，更改窗口大小通常不应更改缩放级别。相反，缩小时显示更多数据，放大时显示更少数据，同时提供单独的缩放功能。
对于以表单形式布局的数据，以及在窗格中运行的单个记录的字段和标签，确实没有处理多个窗口大小的好方法，并且您必须选择要设计的窗口大小。为了可用性，您应该进行设计，以便在标准文本大小下，当窗口大小调整为您可能遇到的最低屏幕分辨率时，所有字段都可见，无需滚动。使用选项卡或其他类似控件来填充该空间中的所有必填字段。一般来说，这意味着设计尺寸为 1024x768，假设您的用户可能在笔记本电脑上使用您的应用程序。表单布局需要在较小分辨率下进行一些垂直滚动（这在网络应用程序中很常见），可能是可以接受的，但在典型情况下，用户永远不必水平滚动。因此，在您的情况下，如果您的大多数用户使用台式机并且只是偶尔使用笔记本电脑，您可能需要针对 1024x1050 进行设计。测试用户是否意识到在使用低分辨率时必须滚动，然后再继续执行此操作。如果您希望用户在查看其他窗口时定期使用该窗口（例如，它更像是属性对话框），则可能会对窗口大小设置额外的限制。
对于表单布局，当调整窗口大小时，文本的大小或字段之间的空格不应改变（尽管允许用户显式增加文本大小是一个好主意）。调整大小大于设计尺寸时，只需在右侧和底部添加空白边距即可。换句话说，为表单布局调整更大的大小实际上没有多大意义。没关系。至少您的一些用户会充分利用未使用的屏幕空间来进行其他操作（例如，另一个窗口或应用程序）。拥有大屏幕的真正高级用户可以并排打开同一窗口的两个实例，并让每个实例显示不同的选项卡，以便他们可以同时监控尽可能多的内容。
将大小调整为小于表单布局的设计大小应该会导致出现滚动条并提供对不再显示的字段的访问。如果您选择了可能遇到的最低屏幕分辨率，则后一种情况应该是一种边缘情况。
Apps should automatically adjust to a variety of window sizes as well as screen sizes. You shouldn’t assume that users will always want to run your app at full screen size. Even if all your users have humungous screens, they may want to show multiple windows side by side in some cases.
Designing (if not developing) for multiple window sizes is pretty easy when the data are laid out in a list/tabular or graphic format (the latter including maps, diagrams, and most WYSIWYG apps). The pane that shows the table or graphic should resize as the window resizes. Generally, you include horizontal and vertical scrollbars as necessary to allow the user to pan around the data within whatever pane size there is at the moment. Resizing the pane with window resizes generally implies all data is accessible by scrollbars. It doesn’t work well to break up the data into pages (e.g., like the way Google search results are split up).
It’s perfectly acceptable to have horizontal scrolling for a table (unlike for a web page dominated by prose) as long as the first column(s) that identifies the rows remains in view when the user scrolls horizontally. Likewise the column headers should remain in view when the user scrolls vertically. For graphics, changing window size generally should not change the level of zoom. Instead, show more data when zooming out and less when zooming in, while providing a separate zoom feature.
For data laid out as a form, with fields and labels for a single record running down the pane, there really isn’t a good way of handling multiple window sizes, and you have to choose a window size to design for. For usability, you should design so that at standard text size all fields are visible without scrolling when the window is sized to the lowest screen resolution you’re likely to come across. Use tabs or other similar controls to fit all the required fields in that space. Generally, this implies a designed-for size of 1024x768, assuming your users may use your app on a laptop. It may be acceptable to have a form layout that requires some vertical scrolling at smaller resolutions (as is common on web apps), but users should never have to scroll horizontally for typical cases. Thus, in your case you may want to design for 1024x1050 if most of your users use desktops and only occasionally use laptops. Test that users realize they have to scroll when using a low resolution before proceeding with this. If you expect users to use the window regularly while viewing other windows (e.g., it’s more like a properties dialog), that may set additional limits on the window size.
With a form layout, the size of the text or the spaces between the fields should not change when the window is resized (although allowing the user to explicitly increase text size is a good idea). Resizing larger than the designed-for size should simply add blank margins to the right and bottom. In other words, there really isn’t much point in resizing larger for form layout. That’s okay. At least some of your users will make good use of unused screen space for something else (e.g., another window or app). Real power users with big screens may open two instances of the same window side by side and have each instance show a different tab so they can monitor as much as possible at once.
Resizing smaller than the designed-for size for a form layout should cause scrollbars to appear and provide access to fields that are no longer in view. The latter situation should be an edge case if you’ve chosen the lowest screen resolution you’re likely to come across.
一般来说，您会针对预期遇到的最低屏幕分辨率进行设计。
您是对的，有多种合理的屏幕分辨率。
您可以选择针对多种屏幕分辨率设计用户界面，并让您的应用程序根据实际屏幕分辨率选择适当的布局。
In general, you design for the lowest screen resolution that you expect to encounter.
You're correct in that there are a multitude of reasonable screen resolutions.
You have the option of designing your user interface for multiple screen resolutions, and having your application choose the appropriate layout depending on the actual screen resolution.