🌌我倾向于在 Web 设计中尽可能在最优分辨率前后都给予浏览器宽度一定的自由度. 往﷽大去是为了在能改善体验的前提下充分利用大屏幕的用户的屏幕空间, 往小去是考虑到有时候用户并不是把浏览器窗口最大化, 或者不能占满整个屏幕.

举个 use𝄹 case, 我工作的时候经常会两个窗口 side-by-side, 一个窗口是 Google Docs, 另外一个窗口呈现参考资料. 如果是在咖啡馆里面干活那就只有笔记本一个屏幕, 每个窗口 700px 宽, 很多时候我就要不断地拖水平滚动条, 非常悲剧.

如果浏览器的窗口特别大或者特别小呢? 我觉得可以不为这些极端情况做优化, 但底线是不要让人🍸觉得出错了, 也算是给网站界面预留退路的一种吧. 一般来说, 我会给界面指定个最大宽度值和最小宽度值, 这样宽度的变化不至于失控. 像 iGoogle 在小屏幕下乱成这样, 不应该:

这些肯定都不是主流用户面对的场景, 可设计师不就是应该追求完美么. 这里有另外一个因素是自适应宽度页面的设计和开发工作量都要比固定宽ꦇ度大, 许多人大概还要考虑一下这个额外投🐬入值不值的问题, 例如我就把自己 blog 的宽度给写死了, 反正没啥人上来看…

Google 的大部分产品界面都是自适应浏览器宽度的, 产品不同, 具体做法也会有不同. 对于 applicat꧃ion 性质的产品, 界面框架一般都是自适应的, 但为了保证里面文本的可读性, 往往会对文本内容区域限制一个最大宽度, 像 Google Reader 这样:

新版 Google News 加拿大预测网-在线预测整个固定宽度居中, 除了上面统一的导航条 (我🎐是觉得可以做得更有弹性一🍷点):

𒀰Google Images Se✃arch 的结果页面没有什么文本可读性的问题, 所以他们采取的解决方案是每行显示图片的数目随界面宽度变化而变化, 内容区域总能填得满满的:

Picasa Web Album🤡 的图片浏览界面右栏是固定的宽度, 而左栏显示图片的区域是变化的. 值得一提的是它还会根据窗口大小的不同, 请求不同大小的照片大图, 而不是把照片拿回来再缩放. 可以随便点上面一个大图去看看.

而我最近做的一个项目的要求是希望从大概 200px 到大概 1000px 都要呈现良好, 鉴于这是一个🦂导航性质的列表页面, 最后采取了大致如下的布局方式:

这些都是现在的解决方案, 再超前一点呢? 不大恰当地类比, 大屏幕和小屏幕的关系就如同报纸和书本一样, 媒介的面积大了, 其实还有很💝多潜力可挖. 两个例子, 用户现在可以在 Google Books Search 的读书界面中设置成两页并排放, 如果这个是自动做的呢? 而 CSS3 中也引入了文本分栏, 可以像报纸那样把文本分栏显示 (参照 persistent.info 的实现效果). 不是说分栏这样的解决方案一定好 (搞不好要用户来回拖垂直滚动条就更麻烦了), 但我们确实还可以开阔一下思路, 想想如何能优化宽屏幕下的显示效果.

实际上设计和用户行为也是相互影响的过程, 手头的一份💫数据显示, 目前来说屏幕越大, 用户进行 “最大化” 浏览器窗口的操作越少, 这也说明用户觉得宽屏幕下网页显示效果不佳. 但如果越来越多的网站提升了宽屏幕下的体验, 说不定也会有越来越多的用户也会选择在宽屏下 “最大化” 窗口呢.

参考阅读:

• Fenng: UCDChina 的设计是否土鳖?
• 白鸦: 网页用多宽才合适?
• 西贝乔: 拿数据说话
• 千鸟: 宽屏不是用来阅读的

原文：//blog.wangjunyu.net/1076