October 31, 2006

原文链接:five ways to optimize your design
原文作者:Neil Patel

每天有成千上万的网站被创造出来,这些新网站不是基于浏览者的需要而是基于网站所有者的需要。浏览者被忽视,是大多数网站不成功的最大原因。这里将给出5种方法来优化您的设计。

1. 成为浏览者中的一员 把自己放在浏览者的地位。浏览者到您的网站来,他想要什么?您的网站的目标不仅仅需要满足您的需求,更重要的是需要满足浏览者的需求。要得出浏览者想要 的,有一种好的方法就是,对对您开发的产品和服务感兴趣的人做个调查,并调整您的设计以满足他们的需求和您自己的需求。这并不需要花多少钱,比如您可以问 问身边的朋友们。

2. 简约是最终的目标 假如您看了比较成功的网站,比如 Google、Flickr 和 Blogger,他们都是简约的。为什么要加上臃肿的内容呢?尤其是当只有80%的浏览者使用了20%的上述的内容。当加入每一个特征时,请考虑浏览者的需要!把它当做您的目标吧。

3. 内容为王 确保网站的内容以一种有效的方式排列。如果您仅仅将注意力集中于网站的视觉及其引起的感受,而忽视了内容,那么由浏览者转化为忠实的会员的比值,您认为会 很高吗?如果您想浏览者购买您的产品或服务,就需要一种简洁的、令人心悦诚服的内容和立体化的信息结构。同时最重要的是,内容要通俗易懂。

4. 细节是大的区别 网站的每一个方面的细节都需要仔细考虑。有一些元素,比如颜色、形状甚至梯度改变后,在整体上就有可能给浏览者很大的冲击。使用蓝色、绿色、青绿色和银白 色,能给人一种平静的氛围。在您的设计中,使用圆角比使用尖角更能给人一种柔和的、个性化的感受。通过适当的混合颜色、图形、图片,您可以创造出强烈的氛 围和感受,这将对浏览者产生深刻的映像。

5. 指导浏览者 您并不想要浏览者为了寻找一个产品而点遍您的网站。避免混乱,通过链接、导航菜单指导浏览者,是可行的。在页面上”告诉”浏览者,以便他们仅通过几次点击就可以买到产品和服务。通过降低浏览者点击的次数,可有效的降低浏览者的挫折感,提高从浏览者到会员的转化率。

这些优化您的设计的方法可能看起来很简单,但是大多数情况下,他们被忽视了。试着用用,他们所起的作用,通过优化您的设计就能节约很多广告费用,这些将震撼您!

penguin 投稿翻译 - 欢迎访问他的BLOG(qianjin@Health)

Tags: No Tags

October 29, 2006

这篇文章翻译至:http://www.webdesignfromscratch.com/current-style.cfm

它总结了一些当前网站设计风格的发展趋势。但是我得先提一句,它说的都是西方网站,未必适合我们中国网站的情况和中国网民的审美观。如果能给你一点点参考和借鉴的价值,就足够了。

————–Enjoy!————–

我很高兴看到2006年的网站设计比以往任何时候都要好。这并不仅仅是因为现在有更多的网站,因而可以找到更多长得不错的。事实上还是有很多长得抱歉的。我想是因为有越来越多的网页设计师比以往更懂得该如何做设计。

下面的这些例子显示了现代图形设计技术的精彩。它们看起都很漂亮、干净而且容易使用。

最热门的

我并不是说下面这些就是最好的,但它们是典型:


» The Alternative Energy Store


» Gr0w collective


» Forecast Advisor


» emaginacion.com.ar


» iconbuffet.com


» Save Longstone Edge


» iomega.com


» linkedin.com


» mozilla.org


» Rapid Mortgages


» plaxo.com


» Prolotize

共同的特点

以上这些网站都有下面的特征:

  • 布局简单
  • 中心定位
  • 3D效果
  • 柔和,自然的背景色
  • 颜色鲜亮(要谨慎使用)
  • 可爱的图标(也要谨慎使用)
  • 有许多留白
  • 大字体

我们一个一个来说。

布局简单

和几年前相比,设计师们似乎正在寻找更加简单的单栏或双栏布局。总的感觉就是设计师们普遍认同简单的页面表现更好。阅读这类页面只需要从上看到下即可,你的眼睛不用在页面上转来转去拼命寻找想要的东西。同时在浏览过程中它也提供更加平和、稳定的浏览体验。

中心定位

从上面的这些网站还可以发现第二个特点,它们的内容都分布在中轴线附近。

大概两年前,你可以找到很多“流动布局”和“左对齐并固定宽度”的布局,现在内容开始在出现在屏幕的中央。

左对齐的布局方式已经不如以前常见了,流动布局(全屏)也没有这么流行了。

尽可能在“一屏”以内显示更多的信息似乎是一直以来的至理名言(也就是尽可能不要滚屏)。而流动布局可以达到这一点。然而,现在我们似乎不太介意滚屏了,而且我们更乐意发挥由滚屏带来的优势,比如更多的留白和行高。

有节制地使用3D效果

上面所有的网站都使用了一些很细致的斜面、给分隔条的边缘来个轻微的倒角、给背景一点点空间感、或者使用一些很“跳”的带着浮雕和阴影的图标。倒影和渐变非常普遍,阴影也还在使用,不过非常小心。

到处都是带着闪光图案的商标:

柔和,自然的背景色

上面这些网站都有一个朴素的背景,最流行的就是白色和灰调渐变。这样的背景提供了一个又酷又柔和又中立的环境,让那些抢眼的颜色可以引导用户的目光。

颜色鲜亮(要谨慎使用)

柔和、时髦的背景色为添加吸引眼球的特性提供了极好的基础,而强色调高对比度非常适合页面上的其他重要元素。

Iomega比其他几个网站用了更重的颜色,它的推广区域使用了浓烈的暗红色。然而这并没有淹没页面上的其它部分,因为它采用了一致的色调和简单的形状。

可爱的图标(也要谨慎使用)

有一个“规则”:不要在同一个页面上使用太多好看的元素(这样会影响用户的注意力)。(译者注:所谓适可而止)

抢眼的颜色、3D效果、漂亮的图标和按钮可以给页面增加一些闪光点,给人一种高品质的感受。但是,如果用滥了,就会产生一种叠加效应,使页面变得混乱,用户变得迷惑。

有许多留白

今天的网页设计风格非常之清新,仿佛刚刚经历了深呼吸一般

有时候我甚至想把一些非常拥挤的网页粘到气球上,然后一直吹气直到页面上所有东西之前都有足够的空隙。

我们的眼睛需要被注视物的周围有一定的空间,这样才能看清楚它是个什么玩意儿。

一般来说,留白越多越好。我极少看到一个页面,然后会想:“唉,他们一定要再加点内容上去才行!”。

当然,留“白”不一定是的,但它必须留出一定的空间。

很高兴地看到现在有很多设计都使用了合适大小留白,页面上的元素之间有足够的空隙。同时为了屏幕阅读也设定了额外的行间距。

看看这些让人舒服的留白吧!

大字体

我并不是说你网站上的所有文字都要大得让人吃惊。事实上,在某些情境下,小字体也不错。

真正优秀的设计应该是这样:

让重要的文字比一般的文字更大

就像我们在上面提到的设计方法一样,它只有在一定的模式下使用才能起作用。如果所有的文字都很大,那就没有一个是大的了。

用大字体让你的访客迅速地了解这个页面是关于什么的,什么是重要的,并且指出接下来他们可以在哪里找到想要的东西。

感谢承志的投稿,来自淘宝UI团队的辛勤翻译,欢迎订阅他们的blog;同时欢迎在豆瓣为我们留言:doubanclaim7dfc2b8d5079066b

Tags: No Tags

原文: User Interface Design - Taking the Good with the Bad

成功的婚姻之关键在于折衷。当事情沿着你不希望的方向发展,在最后,形成的争论却可以为你带来极大的好处。这条定理同样适用于用户界面设计。毕竟,如果婚姻不是形式和仪式又是什么呢?

设计用户界面的过程从根本上就是折衷的训练。这个训练并非指设计者和项目负责人之间的折衷(可用性从来没被办公室政治利用过),而是指设计方案的倒退和前进之间的折衷。每一个有关用户界面的决定,从一像素的精确定位到整个网站的信息架构都需要深思熟虑。对每一个设计方案给用户带来的好处与花费两者之间的仔细权衡才是本质。人们常常忽略有时是很小的代价,但每一个用户界面设计都要付出的代价。经过考虑的折衷原则其实贯穿了所有的用户界面设计,但在设计最佳的用户界面时,具有讽刺的是,它还要求你避免设计折衷的界面。

你不能吃了蛋糕还想拥有它

在创作用户界面的时候,你必须处理两个主要且冲突的局限:在仅有的一个显示器上传达海量的信息;用户在一定时间内接受海量的信息。在一个显示器上显示太多的内容,用户不得不从混沌中“艰难跋涉”了;显示太少的信息,用户为了找到他们的目标,又不得不靠猜测了。好的设计应该在程序和用户之间找到平衡点,既有效利用屏幕,又能考虑用户理解信息的能力。

你的舞台(显示器)是有局限的——毕竟有x像素的宽和y像素的高。这意味着资源很重要,你利用的每个象素都可看作是有价格的。当你试图去创建一个用户界面的时候,保持信息密度的平衡是项挑战。每个设计方案都要经过深思,因为在屏幕上每增加一块内容就加大了信息密度,这对用户有限的精力和认知过程是个挑战,使得用户更难弄明白了。

好的设计代替不好的

无论何时,花费只要能带来好处,采取折衷原则也是可以的。理论上,你可以最大化好处和最小化坏处,但本质问题是,所带来的好处能否超过其花费?不仅仅是超过,在所有可选的设计方案中,它能否带来最大利润?果真如此,它才是最佳方案。

花费/好处的折衷考虑穿越了用户界面开发的所有层次,从导航设计到字体大小。越是重要的设计方案,越是体现出用户界面巨大而潜在的影响。小的设计方案看起来似乎无关紧要,但积少成多,也会对用户界面产生潜在影响。无论大小,每一个设计方案都应该在可用性评估和考虑网络用户界面好处之后再决定。

一些对比的设计方案

设计 好处 花费
减少信息构架的层次 找到信息时减少了点击 更混乱
深层信息架构 清晰,减少混乱 找信息时点击多
小字体 一屏上显示更多信息 某些用户太难阅读了
大字体 阅读起来容易 每屏信息少了
下拉框 在有限空间里容下了更多选项 隐藏了选项
单选框 同一时间看到更多选项 需要更多空间,易混淆
图标 一旦记住就容易辨认了;视觉愉悦 M要学习识别
文字链接 总是易懂的 一旦不理解,可能必须阅读更多的资料
缩写 节约空间 需要学习和识别
非缩写 易懂 需要额外空间
键盘快捷键 数据高速输入 需要学习
鼠标指向和点击 直觉的 交互增加了额外的时间,需要更多的经验

疯狂背后的模式

事实上,你无法刻意评估每项设计方案的优劣。此过程就像天性一样,你可以凭直觉判断哪里该用下拉菜单还是单选按钮,或者此设计是不是比另一个略胜一筹。但直觉是建立在相关经验和努力之上的。设计的折衷评估仍旧可能发生,它在潜意识中形成了。这种潜意识行为可能让你没意识到为什么选择了此项,而非另一项方案。但如果你拆开了这个过程,其核心就是基于可用性原则的判断。

在设计过程中描述这个潜在法则可能并非必须,它很自然就发生了,但是你必须清楚,并在逻辑上意识到你的设计。如果你和别人一起工作,他们的建议可能降低了可用性,你意识到自己的决定是如何产生的就很重要了。通过将用户界面设计中潜意识的行为化作语言,你可以为坚持自己的决定增加了砝码。但如果你让每个人都对界面设计提出一种意见(就像恐怖的会议讨论),界面可能会像过去那样难看了。

好 – 坏 = 网络可用性

你是否注意到你可以立刻指出各种界面设计的不足?这是因为在界面设计时的折衷原则使然。甚至最好的设计解决方案都可能有些倒退,一些成员可能会尝试改变设计。但任何设计都有不足之处,每一个无不如此。这样的不足还不至于损害设计。一个设计比另一个设计更好的地方在于无时无刻不照顾到网络可用性。所以,好-坏=网络可用性。最后测量的标准就是网络的可用性价值。

批评开始满天飞了。字体太小了、图标含义不清、缩写词意不明。也许最初只是脸红一下,然后就红到耳根了,仿佛这些批评都是对的一样。事实上,这类宣言单独来看都是正确的,但它太过正确,也应该被挑战。来决定它值不值,就要既考虑花费,又要考虑好处了。后台设计者能立刻识别一个特殊设计的花费,但是他们看不到好处。你需要客观的评估每个建议对可用性的影响,从而决定哪个是最可取的。

除了要懂得界面设计中的折衷性,你也应该鼓励那种有缺陷的设计建议。为了有效评估那些作用于界面设计的花费和好处,你需要涉猎多种领域:从认知学到人因学到图形设计。只有对人们如何与应用程序交互建立了巨大的知识储备,你才能更有效地评估用户界面设计。这不仅仅是个非对即错的事情,因为花费总是与带来的好处相关。

举例来说,你的页面字体可能小了,对一些老年人相当难以阅读。这就是花费。但这在一屏上提供了更多的信息,也意味着更少的滚动,减少滚动可以降低物理操作和认知输入。现在假设统计出你的用户年龄90%在21至30岁之间,因此比较其他解决方案,这时字体更小一些会更好,网络的可用性也更高。

所选的方案并非完美,但它提供了更好的可用性。你也可以提出异议,用好的替代坏的设计,但对于你特定的应用,选择这种方案无非是最明智的。你必须在完整的程序使用中加以衡量,才能选出最合适的方案。

懂得在界面设计中无所不在的折衷原则,并应该灌输给整个项目组,甚至每个普通员工都要知晓。对用户界面的争论应该被鼓励。在每一个设计方案中通过理解、评估和解释折衷原则,你可以设计可用性更高和更有说服力的界面。

对成功的评估

当评估一个设计是否更好时,又需要一个用户界面准则去评估,以下是几个用户界面质量的元素:

  • 容易学习并容易记住
  • 使用的有效性
  • 出错率,可伸缩性和可恢复性
  • 个人满意度

以应用程序的最后使用效果评定,每一个因素都可能是重要的。举例来说,使用的有效性也许对高端的用户程序有用,而对小册子市场就不一定那么有效了。虽然这种转变可能会提高个人满意度。但每一个设计决定都应该接受上面四个因素的考验。

广泛折衷原则

折衷也不应该以屏幕设计为终点。在用户界面设计中占据了很大分量的包括:网络信息统计(比如什么浏览器、平台、显示效果尺寸等)、瘦/胖/富客户端体系、开发时间和花费的资源等。在评估折衷时,可用性占据了极大的分量,但真实使用环境中的一些问题也日趋重要。比如说,如果一个设计方案比另一个好得多,是否值得用1万美元开发它?这部分功能的提升值得吗?反过来想,节约的这些钱是否削弱了可用性?这类讨论是如此现实,需要被谨慎评估。

只要认识到用户界面设计是建立在折衷上的,会帮助我们清楚地认识到为什么如此设计。这样做会减少优秀界面设计出轨的风险,尤其对那些只看到事物一个方面的人有用。通过清晰地列出花费、好处和相互交流设计的意义,你可以更好地说明别人、得到更多的支持。总之,如果我们能依照折衷的原则,我们就能正确地看待好处和坏处。只是希望别带给我们丑陋的事物。(完)

感谢qinghou投稿,隆重推荐Taobao UI团队的blog,他们的blog既记录了taobao的点滴,又着眼于用户体验的方向

Tags: No Tags

最近对Web前端有很多想法,刚好看到这篇文章,跟我想法不谋而合,所以翻译出来与大家分享。许久没翻译了,里面多少还是有些我没能完全理解,意译过来,如果错误,请务必指出和修改,谢谢。

原文The Time is Now for Front-End Architects, 来自:Garrett Dimon,感谢作者的许可。

去年,我在YTS发表了前端架构师的想法,之后花更多时间来思考,现在更坚信这是一个不可或缺的角色。

当后端技术伴随.Net, Rails和Java之类的框架发展得越来越抽象和强大,前端技术的潜在发展也日益复杂。在束缚前端技术潜在好处的差劲实现之前, Web需要更多的前端架构师。

多亏了诸如跨浏览器支持的先进技术的发展,用户体验、更多有意义的主题比如无障碍都拨云见日,这个世界再也不仅仅就HTML和CSS如此简单,因此,绝大部分的团队都需要一个真正理解和实践涉及到前端的一切的人。

角色

这并不是一个扼要和简单的清单,对于下面的主题/技术,前端架构师也不能仅仅满足于了解一下里里外外而已,而是需要足够的深入研究,并有自己出色的见解。

  • XHTML
  • CSS(1, 2, 3)
  • 跨浏览器和跨平台
  • DOM脚本编程
  • AJAX
  • Flash
  • 渐进增强和适度降级
  • 无障碍
  • 可用性
  • 信息架构
  • 界面设计
  • 视觉设计
  • 表现层逻辑(ASPX, Rails视图等)
  • 商业规则和逻辑

作为一个前端架构师,必须拥有这些领域的绝对执行力。例如,前端架构师能够决定某个特性是使用AJAX还是传统的页面刷新。哪个更便于使用?对无障碍的影响如何?改用Flash有意义吗?

拨乱反正

表现,结构,行为和商业逻辑的混杂,导致不必要的复杂,导致难以维护的怪胎解决方案。就如后端需要正确地划分为数据层,商业逻辑,表现逻辑等,前端开发复杂到是时候调整其架构了。

编写良好结构或者说避免使用表格布局是远远不够的。这是第一步,前端架构的哆咧咪而已。现在是时候关注DOM脚本编程,AJAX, 无障碍等,该升级了。

非编程不可

我主张前端架构师必须懂得真正的编程知识,而这正是很多自封为前端架构师的人所缺乏的。我的意思不是能够剪切粘贴改进代码就行了,而是能够跟老练的工程师商讨如何能够最好地结合前端。

这就是说,前端架构师需要真正理解结构遭遇商业逻辑的问题。如果工程师说某些东西使用ASP.Net DataGrid是不可能实现的,前端架构师必须能够解释如何与为何要使用DataList或Repeater取代,解释为何DataGrid在该情景下是个错误的选择……

这只是个例子,问题还在于仅知道客户端编程也是不够的。能够使用与工程师相同的术语,能够讨论(前后端)关键集成的最佳解决方案,这是绝对必须的。

断线的风筝

我们今天正处在一个不妙的处境中,原因在于几乎没有人能够为前后端的沟壑搭桥。一般工程师不会有兴趣或实践标记,CSS, 或DOM脚本编程,大部分客户端开发者也没有与后端技术协作的经验。几周入门PHP不会成为程序员,几周入门XHTML也不会成为真正的客户端开发者。

罪魁祸首

我首先想到的十足例子是,ASP.Net完全漠视Web标准,同样地,web氛围(我们指表格和占位gif)让Web标准郁闷。企业项目的大多数框架输出的标记,即使使用1999年的标准来衡量,都是糟糕无比的。

如此巨大和“专业”的产品怎么能才够不忽视,按理说是整个项目最简单的方面?只有静态代码。理由是,基于技术的立场衡量产品,结构,CSS和其他客户端技术都是“事后诸葛亮”。表现逻辑,结构和行为混杂,压根无助于无障碍,Web标准,或者前端技术干净的分离。抬起你的头来,就在2006,这些都成受欢迎的惯例了。

总结

如果这个世界上姿态最鲜明的产品和项目都如此低劣的方式来处理事情,其他的还有什么好说?毫无疑问,我们需要前端架构师,而且就在昨天。

归结于归结,我们有一堆相互关联的技术,很少人能够埋头钻研它们之间的关系,这很不幸。正确做事的真正价值在于容易的维护和长期的适应性。虽然在关键时刻,有些方式更容易选择其他的方法和拼凑起另外的东西。对某些人来说,这可能是可接受的做事方式。但是,对我们大部分人来说,这是拙劣的抉择,也非常不专业。

我交给你去想了。我假设你把车交给技工修理,修好了时候,瞧瞧引擎罩内大量的输送管,我不知道你对技工作何感想?

感谢realazy的投稿,欢迎访问他的blog

Tags: No Tags

February 11, 2006

原文地址:http://24ways.org/advent/transitional-vs-strict-markup

作者:Roger Johansson

推广Web Standards的人经常说XHTMLHTML更加严格,当然从某种意义上说是这样的,比如它要求所有的标签关闭并且所有的属性都用引号。但其实XHTML 1.0还分两种(加上Frameset DOCTYPE的话算三种,本文不讨论),Transitional(过渡型)和Strict(严格)DOCTYPEs。并且HTML 4.01也有同样的文档声明。

从字面上就可以看出来意思:Transitional DOCTYPEs只是为了实现从旧时代到新时代的过渡,而且Strict DOCTYPEs是默认的文档声明, 对构造HTML 4.01XHTML 1.0都适用。

使用Transitional DOCTYPE一般是由于代码中含有过多陈旧的写法,并且一下子很难完全转换到Strict DOCTYPE来。但是Strict DOCTYPE才应该是你的目标。它鼓励甚至有时是强迫你把结构与表现区分开来,把表现层的代码都写在CSS里。HTML 4 Document Type Definition: -

本HTML 4.01 Strict DTD不包括表现层属性和标签,W3C将逐渐淘汰这些属性和标签,您完全可以使用样式表来实现。您应该使用Strict DTD,如需获得表现层属性和标签的支持,请使用Transitional DTD。

Strict DOCTYPE还有一个好处,即可以让浏览器使用它们最严格、(一定程度上)最符合标准的模式来渲染页面。

Tommy Olsson在Web Standards Group的Ten questions for Tommy Olsson一文中很好的阐述了使用Strict的好处:

我觉得,使用Strict DTD,无论是HTML 4.01 Strict还是XHTML 1.0 Strict,远比讨论是用HTML还是XHTML重要的多。它代表了未来互联网的质量。它将结构和表现分开,使得维护一个站点非常容易。

对于刚开始接触web standards和正确的、语义化的结构的人,认清Transitional和Strict DOCTYPEs的区别非常重要。更多详细列表请参考:XHTML: Differences between Strict & TransitionalComparison of Strict and Transitional XHTMLXHTML1.0 Element Attributes by DTD

对于准备向Strict进发的人来说,两者的有些区别很可能会使开发者犯错误,接下来我将会谈到。

Strict DOCTYPEs下不支持的标签

  • center
  • font
  • iframe
  • srike
  • u

Strict DOCTYPEs下不支持的属性

  • align (表格相关的支持:col, colgroup, tbody, td, tfoot, th, thead, and tr)
  • language
  • background
  • bgcolor
  • border (table支持)
  • height (imgobject支持)
  • hspace
  • name (在HTML 4.01 Strict中支持,XHTML 1.0 Strict中的formimg不支持)
  • noshade
  • nowrap
  • target
  • text, link, vlink, 和alink
  • vspace
  • width (img, object, table, col, 和 colgroup都支持)

内容模型的区别

元素类型的内容模型描述了什么样的元素类型实例可以被包含。这一点上,两种文档声明的最大区别在于blockquote, body, 和form元素仅能够包含块级元素,如:

  • 文本和图像不允许直接包含在body中,必须被p或者div等块级元素包含
  • input元素不能直接是form元素的下一层
  • blockquote元素内的文本,必须被p或者div等块级元素包含

将所有的表现都交给CSS,恪守Strict标准

在向Strict DOCTYPEs过渡的过程中,了解每个元素是做什么的比知道每个元素长啥样有效的多。

首先考虑结构和语义,然后再担心表现。

翻译:JunChen

Tags: No Tags