Google
 
显示标签为“How to”的博文。显示所有博文
显示标签为“How to”的博文。显示所有博文

2007年10月8日星期一

7种手势的“剪刀石头布”



石头扑火,击碎剪刀和海绵
火熔剪刀,烧纸又能烧海绵
剪刀穿透空气,碎纸,碎海绵
海绵湿纸,气孔吸气又吸水
纸扇空气,包裹石头,水上漂
气流灭火,风化石头,蒸发水
水滴穿石,锈蚀剪刀,浇灭火

这里有更多的玩法规则,终极玩法有25种手势,玩起来一定要晕了。

2007年9月12日星期三

The cranky user:网络工程曾经发生了什么?(上)

前言:翻译同时也学习学习什么是CSS, PHP……这样更能加深理解,对于网页设计有更多的了解。篇幅很长,故分成2部分。事实上,这篇文章中好多东西都是专业性很强的东西,累人的说~呵呵。


软件工程——网络开发者的最优方法 原文
等级:介绍性

Peter Seebach (crankyuser@seebs.plethora.net) 自由作家 2007年6月24日

你有曾想到过今天的网络开发者们能学一两样传统的电脑程序吗?The cranky user 谈论了软件工程的基础并询问网络上那些最有方法都跑到哪里去了。
我 将成为首个承认这次自己犯错的人。互联网有些错误,而我恐怕是我引起的。回顾网络首次成为重要事物来,我和几乎所有其他的电脑程序员都取笑那些声明自己可 以“在HTML中编程”的人。在那时我们不只是唯一的流行:许多交易在“开发”和“设计”间强加直接分开——现在仍然如此。

问题是,直接从开发者里面分出设计师已经导致出一个由完全不懂网络运作的标准和技术的人建设的网络。今天绝大部分网页超出HTML有限范围很好的扩展延 伸,他们中很多是由像Java或者C++(你知道,是用来控制构造、变量和素材资料的真正的代码)这样的基于大块安全的JavaScript、PHP、 HTML、CSS还有别忘了XML等“纯”程序设计语言组建的。

被教导不要把自己看作是程序员的设计师对理解怎样把他们的设计转译成代码负有少量责任——这意味着有更多的工作去执行指控。更糟的是,网络开发者们花费时 间弄懂了使设计看上去像Ajax一样运行却有胜于大宗买进Adobe Flex革新,他们不把他们自己看作是网络工程师。最终结果是一代一直在尝试不通过参考软件工程最优方法而架设日趋完善网站的网络设计师和开发者们:看上 去像必备条件的聚集,DRY原理 ,还有怎样重整逃出程序之“小岛惊魂”的方法。这个月,我将只讨论少数软件工程中看上去在充斥里消失的最佳方法(一般艰难学习在十年期限以上的)去构建一个勇敢全新的互联网。

当然你听过必备条件了吧?

必备条件的聚集是 软件工程的一个本质方面,他一贯在网络开发中被忽视。像“用户能通过手机浏览器接入这个站点吗?”或者“URL能非常直觉的为网站导航所用吗?”这类问题 极少以构建的方式被回答。取而代之的是决定在闲混中决定而用户们忍受着这些结果。比如,最近当一个我喜欢的在线漫画网被收购重新命名后它变得让我很难像前 几年做的那样,通过日期来导航漫画的存档,我很失望。

然而之前精疲力尽的几年一直在学习必备条件聚集理论和学习前面这么做的重要性的软件 开发者,今天似乎太经常而不能在几乎忽略透视图和用户需求的真空中工作。我并不是反对网站创建者仔细衡量过那个补丁的价值后觉得它是值得网站去更新的。我 很反对的是当观众的问题可以解决而且对最终用户毫无疑问是有价值的补丁却从未出现。

当你在新的网站或者新的特性上工作时,之前先询问需求 问题。谁是你的观众?怎样假设能够安全的让浏览器、操作系统还有硬件习惯的接入你的网站?怎样假设你所希望从用户那里得到的动力、视觉、听觉还有演说能 力?假设每个用户接入了e-mail程序这合理吗?也许不是,如果你还记得许多用户通过公共终端或者手机接入互联网的话。

带宽经常是被了解网络的开发者和设计师看作是理所当然的另一个问题,但是他仍然是许多用户的问题。多花些时间测量你的服务器在各个不同的浏览器和系统下生成一个网页所需要的时间,包括可接入的浏览器和公共图书馆系统网络。



不要自我重复


不要自我重复原理也以DRY闻名,它被看作是好的工程的基础。令人惊讶的是它很少在网络开发中被遵循。重点是不要复制材料、构成或者效果。实际上给出2个版本的导航条你将最终更新1个而不是2个,复制不可避免。不是仅仅这样做会导致用户混淆,它对你来说还意味着某处完全的更加有效。答案——作为祖父可能会说——不要重复你自己!


一个出现在浏览器战争时期的有关网络开发者忽视DRY的最惊人的例子是在网页为特殊浏览器一般优化过后。许多人对他们网页使用宽范围字体种类的显示标签、控制外观还有下至网页最佳细节感觉的构架材料不以为然。(在网页上每一个段落中小心使用渴望的字体做标签再普通不过!)当然,这些网站的改进会引发问题。当公司的logo重新设计后怎样,网页字体必须要为了更配合新logo而改变吗?花费数小时打开站点上的每一个文件,搜索替换字体标签,然后期望不要漏掉什么或者出错(就像改变正文中的“Times”字体为“Verdana”然后仅仅是字体标签)。当CSS(层叠式样式表)出现,它改变了一切。这些天的版面信息都汇总在一个单独的中心样式表中。更新一个CSS中的元素就对任何被指定的样式表起效。有时仍然有网络开发者在写样式表的时忘记执行DRY原理,结果导致复制的效果仍属于不必要的时间耗费。

想象一下,如果你将声称用Helvetica字体做样式表的标题,只以大小区别。喔,很容易写,不是吗?


列表1、重复的CSS




               

h1 { font-family: Helvetica, sans-serif; font-size 250% }

h2 { font-family: Helvetica, sans-serif; font-size 200% }

h3 { font-family: Helvetica, sans-serif; font-size 150% }

h4 { font-family: Helvetica, sans-serif; font-size 100% }



但是当你因为某些原因需要转换网页为一个新的网页时发生了什么?CSS列表1将不得不更新4次——为这样一点小小的代码块真不值,但是给出一个更复杂样式表时就令人不快了。我内心的程序员不禁想到一次性写一个更好的代码,下面是列表2。


列表2、不太重复的CSS


 

h1, h2, h3, h4 { font-family: Helvetica, sans-serif; }

h1 { font-size 250% }

h2 { font-size 200% }

h3 { font-size 150% }

h4 { font-size 100% }



现在,你也许知道为什么我这么做很值了。列表2里面的代码不是比列表1里面的更短吗?而且可能会说对非程序员来说不易读。如果样式表过去从未有过4行,我可能会同意。发生的趋势是样式表变长了。

最终一点点的CSS在列表2中可能扩展成几百行代码。谁会说有一天你不必完全改变Helvetica到Times——还有谁会说你不会搞砸,会改变大多数情况下的问题而不是全部。更糟的是你可能仅仅为了查找要做一个全球搜索和替换,3页CSS后,有人指定Helvetica不作为标题头字体,而且不想改变。

这里的问题是,互联网是一个大的场所,大多数网络开发发生在极其危险的速度下。不想软件工程师们有DRY这样的原理训练掌控他们的大脑超过10年之久,网络开发者们现在趋于更加快速的工作和按照节约时间效率区分优先次序。那节省你一会儿时间,尽管最后也可能不节省你的时间。如果你为一个有大量共享数据的项目在做多重样式表,节省你自己无尽的痛苦使用@输入的规则收集所有重复的元素为一个单一的样式表。你以后会感谢你自己的。


The cranky user:网络工程曾经发生了什么?(下)

重整出逃!

软件工程师们已经学到的艰难方法是某些代码是如此糟糕你要做的就是替换掉。替换代码会制止花费,可是有一个强烈的趋向是避免或者延迟替换。很难有热情去除一整个项目的内脏,即使你隔绝了将用一大批判例案件终结和调试完的问题。

重整是一个允许你改变未经真正的外在功能性改变就被完成而给出结果的方法,这是个巧妙的妥协,胜于给软件内调。你简单的重新设计就可以更容易的操作。因为每一步重整操作保留了软件功能性的一致,这容易测试,而系统也保留了功能。多次的重整还使得代码更简单、更清晰、更容易维护,还使它更容易增强和修正你早就想修正的bug。以我的经验看来,
重整通常比大改软件更快。在很多案例中重整也比强力试图做出的改变更加可靠。

重整最经常是将像Java或者C++应用于代码中,但是这不难看出它怎样应用于CSS、网页版式还有其他网路设计的外观中。能学到更多关于网站设计重整的资料。




测试驱动开发

测试驱动开发,或者TDD,不是一个十年以上的软件工程技术。事实上,测试和调试代码失败是众多电脑程序员一代代遗留下来的不利遗产中的一个。像他们的前辈一样,许多网站开发者今天趋于延迟测试知道最后时刻到来,直到批评潮涌而来才发现太晚而无法改变了。用户不得不接受有很多bug的软件,不管它是来自架上产品的打包中还是从互联网泛滥下来的。

TDD是一项灵活的开发方法,那就是说你能够像早期票选那样常用!当你在设计一个网页时,确信你的目标平台是什么样的还有是否你的网页会在上面运行的很好。收集的必要条件,建立一个网页的实体模型,找出他是否在那些平台上也运作。如果你决定了你的网站必须在Safari上也可见,从第一天起在Safari下测试它。(对一个商业项目来说,一台Mac
mini 的花费也是一个在你真的发现这些问题与safari共存代价中的微小的成本了。)

一个测试用户界面(包括网站界面)的通病是富有经验的用户不倾向于犯明显的错误。真正的用户才那么做,然而,精力充沛的面对这些错误是很重要的。在不像你一样紧密熟悉网站导航安排的人群中测试你的站点。那个失败的话,自己吗自己的网站。如果一个用户在你的检验过程里中途迷路是怎么回事?有些人会。如果一个用户试图在数字填充区域输入文字NO是怎么回事?如果一个用户在你的邮编代码框内输入城市名是怎么回事?

就像重整,TDD是代码应用中最普遍的,但是惯例也扩充网页设计。学习更多关于测试驱动开发的资料。





总结

软件设计是一个许多最佳的研究员都承认他们还在寻求和尝试中学习的活跃领域。在这个专栏里我曾讨论过得大多数最佳惯例都是数年的反复试验的结果,但是随着时间推移他们形成了一个软件工程的标准,那是比在编译器上的一群猴子的重击要高级一点,希望开发出下一代的UNIX®。

作为一个网站设计和开发人员,你会从那些在你之前就有的辛苦的得到的最佳惯例中获益。不要让说网站开发不是真正的软件开发的人挡住你的去路。基础的方法论仍然是常用到。

如果这里的最佳惯例你感兴趣,看资料部分获得更多相关知识。紧记大多数软件开发书籍和文章都假设熟悉一两种程序语言;考虑获得足够的熟悉去阅读案例。甚至如果你不想学习一项程序语言,你将发现获得一些有助于软件开发者更好的开发更大项目的工具和惯例是值得的。

行动项:对你的工作引以自豪,抓住每次你得到的改进机会。网页已经变成一个数百万人日常生活的主要功能构成;你,网络开发者,是处于一个使那部分人每个人活得更好的位置——所以加油干!

随机,我向你道别

在2001年3月13日,我在开发者园地上出版了The cranky user系列的第一个专栏。在这6年期间我已经写了75篇 cranky
user专栏——如果你把这篇也算进去就是76篇。对促进以用户为中心的设计和一次改变一个网站的改变网络世界发展我不遗余力,今天我收到一封来自一个在线经纪人业务的署名给”亲爱的可怜的笨蛋“的邮件。喔,这结果是好像我使用不以用户为中心的在线旅游网站好像在线出售机票一样。作为结果,我耗费了我和作为一个共同协作者的我的几小时时间去解决他们留给我的这些杂乱事。这导致我怀疑我的专栏也许不能被广泛看到或者被我所期望的那样受关注。

所以,这里有一个想法:为什么当过去的大约6年时间里我写的所有这些问题都已经被修正了的时候,你们这些网虫不通告我?当那一天到来时我将穷追至新的问题写出来。同时,你可能发现我在开发者园地一次次的写作,但是我正成为Cranky的日子结束了。

这非常之有趣。我想要感谢所有在专栏发表评论的各位,不管是肯定的还是否定的评论。

以下就不译了:P

资 料

Learn

  • The cranky user series (March 2001 through July 2007): Read all of Peter Seebach's columns in this series.

  • "When Web pages don't work" (Chris Paul, developerWorks, February 2005): Reveals some of the ways Web designers can unwittingly alienate potential users.

  • "Demystifying Extreme Programming: Test-driven programming" (Roy W. Miller, developerWorks, April 2003): A primer on TDD.

  • Manifesto for Agile Software Development: Agile software development (also known as extreme programming) is one of many attempts to reformulate views of what software development is like; it seems that it might be well-suited to the always-live, always-changing environment of Web development.

  • Refactoring Home Page: Refactoring is a technique for improving software. The same technique could be applied to many Web pages with excellent results.

  • "Javascript Refactoring For Safer Faster Better AJAX" (Pavel Simakov, Software Secret Weapons, May 2007): Offers a concrete example of how to refactor a Web page.

  • CSS Specification 2.1: Learn more about CSS.

  • Edward Tufte's home page: Edward Tufte's work on displaying information to make it more accessible to readers is of inestimable value to Web designers.

  • JND.org: The homepage of Don Norman, whose The Design of Everyday Things is yet another example of a rich and well-developed resource that most Web designers have never been encouraged to study.

  • Improve Your Java Code Quality: Andrew Glover's code quality forum is a developerWorks community resource for improving the quality of your Web applications.


Discuss

2007年5月24日星期四

创建自定义圆角和边框


CSS Design: Creating Custom Corners & Borders
by Søren Madsen
原文
我们都听过这样一句话:

图像 “http://www.alistapart.com/pix/quote_wh.gif” 因其本身有错无法显示。“用CSS设计的网站趋向于箱子般方方正正和有轮廓鲜明的硬边线。那些圆角都哪里去了?”
答案:圆角就在这里。在本文中,我们将要展示利用有效的逻辑标记语言促成自定义的边框和圆角能够充分流畅和灵活的适用于多变的内容。

◆标 记
在下面举例的标记语言中,XHTML语言已经通过分割把虚拟段落拉长了:
◆挂 接

如果我们想完全控制版面,我们必须确保有足够元素能够和我们的CSS对应。让我们称这些元素为“hooks(挂接)”。我们的标记仅仅需要再多几个。
首先,我们用div把整篇文章包括起来,然后把每个结构片段用适当的元素包括起来。


如果我们检查标记,我们会看到我们给了自己至少5个挂接,那是我们需要放置在我们文章中每四个角内自定义图片所要的全部。
№ 第1步 —初级标记

◆设 计

[Image shows a white rectangle with rounded corners against a solid background.]

首先让我们对基本版面参数作出决定。我们的平面设计师给了我们这个标记。

“我想要边框和圆角看起来像这样。”他说。他还告诉我们事实上要清楚所有的文章可能会有不同的长度和宽度,而且他还没有确定他想要的文章背景色是什么样的。事实上,他甚至不确定那些边框是他想要的。“你能够不设定死,或者使他易于改变吗?”他问道。


◆处 理

我们打算使挂接的数量越少越好,所以当我们为解决方案准备图片的时候必须额外注意,确保我们需要的图形适合于挂接元素而且已经出现在我们的文档里。

我们已经用div包含了整篇文章。那代替了左顶角、左边和顶边。标题(header)元素被默认阻止,我们将利用他们的特性:他们扩展他们到父元素的整个宽边。所以我们对右顶角用

元素。我们对文章左下角用div元素,包含在内的段落作为我们的右下角。

№第1.1步,怎样大略切分

注:很明显,你能用任何元素对图形挂钩。你的文档标记结构未必准确的匹配于我们提到的例子。我们所知道的是你可能仅仅只有一段你想要运用自定义边框和圆角的文字,那也很适用此方法。

按照更简单的规定,你最少需要4个结构元素。(根据元素的高度你可能需要5个。)如果必要,这些元素可以是非语言的div,每个都有自己独立的等级。只要记住实施div元素必须包含内容表明他的存在。同时记住如果你的内容有助于他的共同结构元素比如,标题、段落等等,你能够也应该使用那些元素来替代非语言的 div元素。


◆类 型

继续...我们打开元素边框然后设置用div包含了的整篇文章相关的宽度,看看是怎么运作的:

№第2步,基本元素特性

这里没有什么令人惊讶的东西。然而,我们很惊讶。注意出现在div class="ArticleBody"前后的空隙。现在忽视那个问题,我们 继续来写一个我们的类型表单:

№第3步---首次尝试

不错!事实上比我们预期的好。很明显我们需要给各个元素加上些料是整体版面看上去更好些,然后是修补那些恼人的空隙。这些空隙是我们插入的段落(阻止)元素的回车导致的。
我们可以完全避免使用段落元素从而绕过这些问题,此外的一个原因是美国图书馆协会的读者们所周知的,我们更乐于保持我们的标记整洁逻辑。这不是我们数据的错误而是我们的懒惰问题。

在我们上一段中,我们假定一个回车相当于1.5em,那个数值被定为我们的行高。因此我们首要尝试着给我们的文章主体和底部增加一个边缘最高值为1.5em。在绝大多数标准兼容的浏览器里这个运行的很好,除了地球上那些94%以外的其他浏览器使用者(请别点名)。
经过测试,考验,误差和反复调试我们发现我们至少设置边缘最高值为2em,以确保元素接触和空隙关闭:

№第4步---看起来我们终于快了!

◆向后兼容

如果你已经在Netscape4.x版本观看这个例子,你很可能注意到那个页面是空白的。我们没有发现如何在NS4.x里解决这个技术问题。所以我们将隐藏这类浏览器不能完全渲染的问题。NS4.x
不能理解含有媒体=“all”的标签类型,我们已经利用遵循的例子证实了。我们做了2个类型的标签,一个是我们想要所有浏览器都能渲染的类型,另一个是我们想要在NS4.x里面隐藏的类型。即使这样做让我们心痛,我们已经改变了我们从行高到像素的字体大小规范。你想要向后兼容,你做到了。

№第5步---在NS4.x中的功能衰减

◆真正的世界

“是的,伙计,但我们想看看真正的应用。”你说。我们期望那样而且假设了一个更高级的上下文例子的技术应用。
我们我们借用了Alex Robinson的已经彻底测试的版面布局来应用我们的类型,很高兴我们这样做了!
我们的首要尝试是释放windowsIE6中的一组灾难事件,触发程序缺陷影响我们元素级别中的z索引堆。整个元素消失了,空白表现的像孩子们继续拖延他们的就寝时间一样。这很混乱。
然后我们懂得了一个简单的位置:一个很好的相关位置
能够修正一切。进一步研究请看第6步里面的源代码

№第6步-我们在一个完全有标题、分栏和底部的版面布局尝试应用我们的技术

◆限 制

如果你已经注意到了,你可能发现这个例子只适用于围绕物、纯色背景。用这样的方法我们需要用右顶角的图形去覆盖左顶角的图形。如果我们让右顶角的图形透明,
它下面的左顶角的图形就显现了。底部也同样如此。这绝对是个限制。也许在本文第二部分的中我们会展示如何使他适用于渐变背景。
同时,这篇文章示范了一个非特殊的向后兼容的有效的标记方法,我们也真诚的希望这个能够激发更多后续的想法,也许一些甚至可以避免需要纯色背景的方法。