• 介绍
• 必需属性
  • width
  • height
  • classid[OBJECT only]
  • codebase[OBJECT only]
  • movie[OBJECT only]
  • src[EMBED only]
  • pluginspage[EMBED only]
• 可选属性
  • id
  • name
  • play
  • loop
  • menu
  • quality
  • scale
  • align
  • salign
  • wmode
  • bgcolor
  • base
  • allowFullScreen
  • fullScreenAspectRatio
  • flashvars
• 参考

一、介绍

OBJECT标签是用于windows IE3.0及以后浏览器或者其它支持Activex控件的浏览器。

“classid”和“codebase”属性必须要精确地按上例所示的写法写，它们告诉浏览器自动下载flash player的地址。如果你没有安装过flash player，浏览器会跳出一个提示框访问是否要自动安装flash player。当然，如果你不想让那些没有安装flash player的用户自动下载播放器，或许你可以省略掉这些代码。

EMBED标签是用于Netscape Navigator2.0及以后的浏览器或其它支持Netscape插件的浏览器。“pluginspage”属性告诉浏览器下载flash player的地址，如果还没有安装flash player的话，用户安装完后需要重启浏览器才能正常使用。

为了确保大多数浏览器能正常显示flash，你需要把EMBED标签嵌套放在OBJECT标签内，就如上面代码例子一样。支持Activex控件的浏览器将会忽略OBJECT标签内的EMBED标签。Netscape和使用插件的IE浏览器将只读取EMBED标签而不会识别OBJECT标签。也就是说，如果你省略了EMBED标签，那firefox就不能识别你的flash了。

二、必需属性

三、可选属性

allowFullScreen

四、参考

http://kb2.adobe.com/cps/127/tn_12701.html

我们在追求一些成功的时候，往往忘掉了最底层的思考。因为我们只是追求一些当前项目和代码级的满足。我们好多时间，因为底层不牢固，说话没有说服力，做的东西的逻辑性也很差，思考的范围没有什么理论界定，我们会慢慢的感到累。我们在做什么？只是个轮廓上的大概，或许可以这样说，只是为了满足最表象上的要求。

底层的东西是什么？做一个程序员，代码级底层的思考、算法的规则、逻辑的思考方式、以及语言的基本的特性、还有一些代码的基本规范等等。说实话，没有这些，我们在做一些项目时，仍然写出一段代码来让这个项目满足运行。但是，你对这个东西真正的理解也未必达到心里上的满足。可能写过这几行代码马上就会忘掉。因为这些东西最底层的东西，你并不了解。你只是以你的方式来实现，但其真正实现的来源与机制，你并不清楚。

或许有人说，这些并不需要去研究懂得，只需要了解，会运用就行。可是在真正的运用代码时，用一种语言思想去探索另一种语言时，如果基本的不清楚，会发现另一种语言学习的时候很吃力，有时候回过头来，会发现哪种语言都陌生了。原因很简单，你并没有真正懂得学习，并没有学习和注意一些底层的东西。衍生一下到其它方面。我们在做任何的事的时候，我们有木有在追求表象的满足而忘掉其内在的底层逻辑机制；我们有木有为了讲一个道理而转了几个弯去讲述；我们有木有为了实现某一个符号类的东西而纠结用什么方式来表现。有，而且很多。

说到这，其实我们缺专钻劲。生活中形形色色的东西实在是太多了。我们常常迷恋一个东西时，又迷恋另一个东西，常常在表面层次上游来游去，而不去探究真实有意思的东西。可能这些人对其并不喜欢，只是一种谋生的手段而已，也有可能并没有注意，还有可能本身就是如此，自以为是的认为用自己浅浅的了解就行。

我们每个人都会缺少很多各个方面的底层的东西。所以我们每个人都得一直学习（这一点，得向海豚童鞋学习），去了解一些真相，当然从职业的角度来讲，当然要先了解本职工作上的东西。所以，不能太迷恋什么新东西，把握好专职上最底层的东西，去研究下语言规范及特性，还有相关的设计模式等这些思想上的东西，觉得这些东西，对我这样的前端开发者来说，会很有帮助的。

圈子、学习。今天和三思聊了很多（这小子竟然进了无线事业部当PM了），其实移动互联网已经明显成为未来将要爆发的一个东西。移动产品、与移动相关的一些产品，将会在未来是一个非常流行的东西，尤其在智能机相当普遍的情况下。而这个大潮下，自己当然不能成为井底之蛙，因为确切的说，这是一个革命的时代，你不努力，不顺应，会挂的很快很快。一直都说“快鱼吃慢鱼”，而手机这个东西，确实是一个新的竞争平台。朋友还说，如果没有HTML5、没有android、没有iphone，之前的前端开发早已到了瓶颈，幸好有了它们，前端才会有新的爆发。当然一定要顺应这些东西，才会有自身价值。

俺是比较偏JS的前端开发。但这半年来似乎像是个打杂。用户体验、数据分析、交互设计都会沾一些，做一些。朋友说，你这半年来前端似乎停止了，没有学习。今天仔细想了想，的确浪费或荒废了很多前端要学的东西，一直是自己一个人在瞎折腾，本想去冲洗一些事儿，却发现到头只是冲刷。想静思，想安静的思考下未来的路。因为：方向不能再太乱，得有自己的主方向。

有些原则性的东西，改不了，放不下。俺会坚持自己的想法，可是未来俺不会试着让自己受伤，让自己太累。为了俺爱的人，和爱俺的人，俺要努力充实自己，学习，奋斗，去变成一个有力的种子，然后开花，然后结果。有些东西，如果俺没有认识，俺不会玩这个东西，既然来，俺会创造一个奇迹来。

再次谈下产品。这次不谈细节，不谈逻辑，不在文案上较劲。俺只想的是任何东西的出生都会遵守些规则，而不是东西是随手拍桌子得到的东西，更不是跟风似的改来改去。它有原则，有自己的一套成长标准。标准是什么？是让我们做东西有头绪，兼容很多需求，有理念，有概念，逻辑上才会靠谱。

不说了，时间是一把无情的杀猪刀，砍来砍去总会变的，最主要跟着自己内心的想法走，实现自己心中的梦想，把所有的不开心统统抛走，和爱的人，欢喜的人，投缘的人一起，这就是快乐。

最后，感谢亲，感谢亲常提醒俺要淡定，虽然可能还要蛋疼一段时间，但俺想，静思过后，一切都会烟消云散。

前几天和三思闲聊一些关于页面的看法。俺说“页面是一个拥有灵魂的履历，是一个有内涵的男人”。的确，在俺的意识中，页面就是一个拥有灵魂的生命体。

关于页面。接触很久的东西了。弱弱地觉得现在的互联网已经过了设计的时代，现在玩的是数据，玩的是信息结构，外观控已是过去式了。在页面上良好的展示信息，然后再加个NB的交互，才是王道，这样的页面的UE才会好。因为一切元素都有原则。俺是极不喜欢在页面堆积其它相关不大的数据，不喜欢逻辑差的文案，不喜欢权重分不清的功能布局，不喜欢没有概念的上下关系，总之不喜欢没有灵魂的页面。

关于产品。在俺的意识中，产品就是商品，而商品的生产总需要一些需求（小学社会课程^^）。因而大部产品,需求是第一，这个明确之后，产品才会有概念，才会有性格。另外，极不喜欢凭空而想的产品，喜欢用数据来说话，喜欢用原则性的思考来辩解，喜欢强有力的概念性和专业性的逻辑解释。因为觉得只有这样，所做的产品才不会只是后知后觉一张虚无缥缈的履历。

关于产品上线。话说任何一个产品的上线都无法满足所有用户的需求，尤其新的产品上线，觉得如果做不到功能百分百的齐全，耦合性，逻辑性没有完善。俺觉得可以先上一分部体验好的，逻辑与文案方面经过不少的内测且九层以上完善的，之后实际运行中坚持用户相关数据和分析用户的反馈信息，进行相关产品的调整与增加、觉得产品的需求目的明确后，其实之后所做的工作在某种意义上都称为优化。产品永远在优化。

俺认为，团队更需要灵魂，需要一个指引方向的人。对，需要一个独裁，专业上，能力上，认识上，学习上，性格上，这些都是团队成长的必须，如果这些没有基础，没有概念，就别谈团队的扩大，更别谈团队的专业化。或许很多团队是否成功，一开始就已经注定了。

以上所述只是一个小前端的角度。因为在写页面时，发现挺多需要注意的东西，没有好的概念，就没有性格；没有好的架构，就谈不上体验；没有产品的权重灵魂，那就是坑运营，没有…..

议题：“我应聘的工作”

定义：个人用户在招工信息、出国劳务、招生培训、就业团等栏目相关信息的应聘记录，或用程序的角度可以这样讲：是用户在相关信息页面触发“报名”按钮后产生的数据记录。

核心用户：个人会员

使用情景：在前台信息报名后，在此查看相关信息。

使用目标：获得相关信息的反馈

俺的相关定义理解：

它就是一个记录集，是滴，一个关于用户的应聘记录集合。用操作方式的局限来讲，它只是一个只能查看的数据记录集，它不能修改，即使删除（从DB里删除），我觉得都不应该。

由于只是记录的原因，用户关心的字段肯定会有时间、状态、标题。当然还有其它因用户需要而产生的字段。但这几个是必须的，而且优先级都较高。

关于它不能删除的原因有如下：

前台信息页面报名后，如果删除，在机构和前台信息（显示中的信息）的页面，他仍是报名的状态，这会造成用户删除后无法报名，当然按照现在的设计，如果机构不删除面试信息，似乎他只能报一次名。

虚构情景三个：

情景A：一个人用户A向机构B的一条招工信息报名后，在B的“已收到的报名”产生一条记录，但是用户A很调皮，在自己的应聘记录中把这条记录删除了，然后又搜索去”报名”，他不知道已经报名过了，蛋疼的看着无法点击，第一感觉会是愤怒，不，应该还是蛋疼。

情景B：一个人用户A向机构B的一条招工信息报名后，在B的“已收到的报名”产生一条记录，但是某时间后，这条招工信息过期或手动移除到“未显示中的信息”去，然后机构B又重新发布这条信息(内容不变)，然后用户A搜索时又去”报名”，你说能报名吗？

情景C：一个人用户A向机构B的一条招工信息报名后，在B的“已收到的报名”产生一条记录，但是某时间后，这条招工信息过期或手动移除到“未显示中的信息”去，然后机构B又重新发布这条信息(内容不变)，用户A同时也在自己的应聘记录中把这条记录删除了，然后又搜索去”报名”，你说能报名吗？

以上情景只是抽离出的几个故事，还有其它可能结果，但俺主要讲大家的蛋疼的。是想让大家明白一个句话：应聘的工作和已收到的报名都是一个只能查看的记录”。当然这句话，是我们必须知道，但我们的用户不必知道。

解决办法：

1. 删除时，同时删除B和C的投递信息
2. ID-ID对应每条应聘数据，所有记录绝不从DB里删除，且在用户二次报名时，提示曾经应聘该信息的时间和提示是否更新报名记录（更新机构端的报名记录）。

我喜欢第二种，因为这些信息就是记录或叫做用户的行为日志，而这些日志是不能删掉的。

这是俺的理解。我理解的不勉强，可能表达的太勉强了。

看现有界面

注：其实这是一个灰常灰学简陋的，而且现在在前台信息页面触发的“报名”后，“招生培训”和“就业团”的在这里没有记录。

未来的概念性建议

• 关键词：记录、只查看
• 记录是让查看的，一般信息的管理操作在这里不合适。
• 每条记录都必须突出“状态”、“标题”，“时间”。尤其时间，必须滴。
• 统一信息“报名”接口。
• 与报名相关的联系方式，也应该突出下。

Q&A几个问题

Q:“删除”这个功能到底该不该有？

A:有吧。把记录移除到其它地方，然后在用户二次报名时，重新全局匹配计算。不该有。这样也行滴。让用户从时间纵观个人的记录史。

Q：能不能在机构端加一个“拒绝”功能？

A：理论上加一个比较好。因为“拒绝”可以看做是直接删除的一种变种。这样的信息在机构端，报名被分类到“拒绝类”中（只能被删除），在用户端会给予相关提示。

Q：个人用户会关心报名是否被机构“查看”吗？

A：心理学上来讲，会有这样的心态。而且会关心有哪些机构查看过我的简历，包括查看的次数。

Q：这样一来，简简单单的“报名”是不是复杂化了？

A：其实本来就是复杂的，但我们要在用户面前展现一个简单的。不要”以任务为心中”去做，而是“以用户为中心”去实现。

ps:这只是上，因为俺觉得应该还会有下文。

本文的标题叫“第二季”，是相对前几天写的一篇《信息管理的纠与结》，当然根据需求，它还会出现第三、四季。好吧，俺承认俺很BT，又在折磨可怜的#信息管理#。以下是俺的角度的理解，如果大家觉得有意思的话，可以听听。回到正题~~。

第二季关键词：清晰、明确、简洁； 

分三类：

•  显示中的信息
•  未显示的信息
•  审核中的信息

显示中的信息

定义：能完全展示（出现）在所有用户面前的信息。

如下图：

A区：分三类（显示中、未显示、审核中）；

B区：两种功能（刷新：刷新信息；移除：将信息移到“未显示中的信息”中）

分析：与之前的版本对比：把原有功能“停止”去掉；把原来的“删除”的功能换成“移除”。个人觉得，原版本的“删除”功能放在这里，本身就不太合适，用户不小心的删除会直接造DB里的删除，用句俗话说“太直接了吧~”，所以试着和“停止”功能“合体变身”，功能效果只是把信息移到“未显示的信息”中去。

未显示的信息

定义：与“显示中的信息”相反，可包括自动过期，手动移除、审核未通过的信息。

如下图：

A区：只有一个功能“删除”，当然这个删除肯定是从DB里delete了；

B区：这个应该是这个页面的主要部分（用户在这个页面更关心的是“未显示的信息”的原因）；

C区：两个功能“修改”和“删除”。“修改”，用户在看原因会进行相关修改，据现在分析会有以下三种动作

1. 原因是自动过期的，点击“修改”后会更改“有效期”，然后再提交；
2. 原因是信息内容有不对的，点击“修改”后更正相关错误，然后再提交；
3. 原因是手动移除的，点击“修改”和“显示中的信息”的修改一样，然后再提交；

审核中的信息

定义：用户提交后待审核的信息

如下图：

分析：很干净，只有一个状态，为什么呢？其实这个分类只是提醒用户这条信息“正在审核中”，只有这个功能。

以上是第二季的基本草图和基本思想。总体而言，信息更清晰，功能更明确，结构更简洁。用户在信息字段、功能模式上都会容易理解。

Q&A几个问题

Q：是否应该在右侧主体中加入标签分类？

A：个人觉得，如果在主体加入标签分类，左侧导航的分类就成了一个“鸡肋”。并且在信息逻辑上，我也不推荐使用两个同时存在。要不只用标签，要不只留左导航。

Q：“审核中的信息”文案的角度是谁？

A：其实我喜欢“待审核”这个词。因为站在用户的角度，这条信息就是等待审核的嘛。且“审核中”，好像是这条信息一直在审核但没给出结果的意思。

Q：右侧主体的右上角放什么为好？

A：之前讨论过，原则是为了遵守“页面上元素的一致性”，不过，无论是“帮助信息”还是其它功能，在用户面前只是一个具有“提示性”的链接，关于这个链接的动作是否触发，要看这个链接上提示的语言是什么？所以，这个位置，个人觉得功能类和帮助类信息都可以存在，只不功能类信息的优先级要大于帮助类信息。

话说今天快下班，团队开始讨论两个问题，大都是上周已经提过，但没有给最终方案的。弱弱地说，这样效率很慢。似乎大家都喜欢感性地想问题，而不是用理性的态度和方式去解决这个问题。

在说之前，我们先在脑海里酝酿下几个意识，如下：

第一、  这个产品的核心用户是谁？

第二、  他们在什么情况下使用这个产品？

第三、  我们对这个产品的目标是什么？

现结构如下：

其缺点有如下：

• 流程上：用户需要登录 –>我是机构首页->管理信息->（然后进行相关的刷新、删除、修改等操作）相关用户使用率极高的页面嵌套级过深、机构用户主产品左侧导航不突出；
• 文案上：“已发布上网”文案不太恰当；

分析：

1.  此功能的核心用户是招人的企业、学校等相关机构，而这些机构的招工会在多个网站发布信息，简化流程减少用户的学习负担至关重要。
2.  网站中正常显示的信息和审核未通过的信息，用户操作过多，原因是前者是常常要去刷新使前排名靠前，后者是查看未通过的原因，然后进行相关修改和重新发布。
3. 在现有的整个产品结构中，这个管理信息的优化级很高。

关于团队中一些人的建议方案如下：

第一种：

整个信息管理分为两类：

• 已发布上网的：包含审核中和已发布的信息；
• 未发布上网的：其余归类为未发布上网的信息；

理由如下：

1. 只把信息输出的结果展示给用户，不给用户展示太多状态概念；
2. 审核标准的提升，机构入驻标准的严格，对于审核信息可以先显示后审核；

分析：其实这个分类比较极端，站在用户的角度想法很好，让用户从信息组织上感到简单。但是的确很极端，比如在功能组织上没有考虑细致。如其所述，已发布上网的（这个文案在上面提过，不太准确）包括审核中和已发布信息，众所周知，用户对“已发布的信息”使用最多的功能是“刷新”，当然这个在“已发布的信息”中还有“停止”功能。可这两个功能对“审核中”的信息，理论上是不能有相关操作的。

另外，“审核中”的信息是“不稳定信息”，即1：它的结果状态有可能是“审核未通过”，这样信息会从在“已发布上网的”信息转向“未发布上网的”信息中，对发布者会有影响（难道，亲！不恼火吗？不都发布了，吃了一顿饭，回来，竟然审核木通过~~~）；其2：站在访问此信息用户的角度，如果正在关心或可能收藏此信息，当突然审核未通过而访问不到此信息时，体验也不好。

第二种：

整个信息管理分四类（和之前风格一致）：

•  已发布上网的：已发布上网的
•  审核中的信息：审核中的信息
•  已停止的信息：客户停止的和过期的
•  审核未通过的：审核未通过的

分析:

不得否认，此种分类上线，不会像第一种一样出那么麻烦，因为这种分类和之前没有什么改变。我不能说它不好，毕竟它是经过用户使用过的（虽然不知道用户使用的感觉）。

第三种：

其它第三种是第二种的一次探索性简化，如下：

• 显示中的信息
•  停止中的信息
•  审核中的信息

分析：这里的分“显示中”，“停止中”，“审核中”三类的原则是当前信息站在用户角度是什么状态（和DB里的形态不一样滴，User眼里只有前台显示，前台未显示的，正在审核的）。把正在审核和未审核通过的放在一起，是根据之前的调研数据，这两类信息数目不大（一般超不过两位数，就算超过，30分钟内，客服部也会审核掉），所以把这个正在审核的数据放在这个像程序语言中的栈内存里一样，这些数据的活动性大（插入和离开的波动大），受用户关心的程度可能紧次于“显示中的信息”，所以这些审核未通过和正在审核的放在一样，另外把审核未通过的加上原因，便于用户对“正在审核”和修改的优化。我是这么想的。

————————————————纠结的分隔线——————————————————

审核中的信息的形态推测：

    1)     90%的情况下都只会存在“未审核”一种状态；

   2)     以上这种情况的发生机率也很低，大概在10%左右，大部用户还是会修改让其它通过的；

   3)     之前和大家分享过一次数据调研，里面100个用户中，未审核通过+正在审核只有38条，平均到个人只有0.38条，且数据中最高未审核信息为9条，正在审核一般在1-3条。这说明“审核中”的信息如果按10条一页分的话，会保持在2页以内；

以上是只是个人角度的分析，可以理性视野不太宽阔，如有建议，敬请指教，共同学习。

关于此产品上线方案，推荐使用第三种（第二种可当替补），根据User使用后获得的反馈和调研相关数据，来进一步获取用户行为和习惯来进行相关调整。

今天开会还提了一个小问题：

Q:冯说“从数据访问的角度上讲，显示在左侧导航，层级为全局的，访问每一类信息，都需要计算数量，增加数据库开销。”。

A:是会增加DB的开销，但要明白，站在用户的角度想问题，技术类、硬件类等都要降级且这个也可以从实现方式上解决；还有弱弱地说，这次这个功能单页面访问下传输只有不到1KB，而且在以后的版本中为了增强体验，更会可能增加，所以，如果现在这个是问题的话，那网站别开了^^。

呼呼~，淡疼的又来唠叨这个东西。最近一次在项目，累呀，尤其今天在写老杨的那种“步骤提示”时，更让我久久的蛋疼。好吧。睡觉，补血，补蓝。世界上有两种人，一种是控，另一种是想成为控的人。明天继续奋斗。安！外面似乎又下雨了~~

记得有一次和周，李闲聊。说起信息架构（IA）的事，当时用“图书馆”和“超市”来诠释这个东西。之前我还不太理解IA，不过听他们大致的描述后，豁然开朗，很多不太了解的事儿，有了镇定的看法。后知后觉也发现用户体验（UE）也和这事有致命的关系。

先说说“图书馆”。最让我想起的是大学时的那间老图书，因为年久的原因，没有电子查阅，只有几个不太高的木柜子，柜子上面有很多小抽屉，抽屉外面写着各种书籍的分类，抽屉里面是一张张书的名片纸用铁丝串在一起并固定在其中。查阅的时候，会打开喜欢的分类，然后一个一个名片翻阅着去寻找自己喜欢的书。然后再给管理员报书的编号，然后管理员去书架上帮你找。

另外一个是“超市”。这个大家更为熟悉。超市的商品很多（可以阅读：

http://wenku.baidu.com/view/a98d68630b1c59eef8c7b4a4.html）。超市里会根据在分类在超市的角落放置。但是怎么放置，应该有一定的原则和标准。

假设你眼前是一个空空的超市。你怎么合理的放置你所要卖的商品。当前首先要确定你的超市的面积、超市的地段、交通是否便利、超市附近主要消费群体，还有是否有其它超市，其它超市与自己的竟然水平怎样，其它超市的优缺点怎样，他们有哪些商品且什么商品卖最好。确定好之后，再来确定你的商品种类和商品摆放位置。再根据超市内部环境的情况，分析下人流密集的地方有哪些…。要确定的因素很多。为什么这么大动干戈的去放置商品？为什么？一切都了客户。合理的摆放结构会让客户感动满足、合理的摆放方式会让客户觉得超市有档次。这样超市的用户体验就会比较好，回头率当然也很高。当然，你也可以把超市的商品随便放置，反正是商品，有需求的人肯定会来嘛。

整理下以上一段废话如下：

开超市前的准备：

1. 确定超市的面积
2. 确定超市的地段以及交通情况
3. 调查超市附近的主要消费群体
4. 调查超市附近的其它竞争产业

…

摆放的原则：

1. 根据商品和主要消费群体的目录检索习惯摆放大部分商品；
2. 根据某些商品的使用情况，放置用户常注意到的位置；
3. 根据季节、节日等情况，改变超市内人流较大区商品摆放；
4. 使用合理的索引标识来引导客户；

…

回到网站的IA上。

现的后台大部内容放置在：http://my.chinalao.com/里

文件结构树如下：

如上图所示：页面级的文件都放置在Chinalao.My.web的根目录下，没有相关的产品目录，二级文件夹只有一些页面的附属文件（Css、Image、Js等）。这样的结果在前台非常明显。如下图：

地址栏中的是：

后台页面中所有的页面的地址都是http://my.chinalao.com/+页面名称。

缺点：

• 没有详细的产品分类
• 没有页面上下层关系的逻辑性
• 没有后续开放的可扩展性
• 页面维护难

或许你会认为用户没有像超市的用户一样，会真正的去关心目录索引，会用索引去看产品，如果你认为用户的动作只是在网站的页面上点来点去，如果你认为最忠实的用户也只是产品的使用者而不是拥有者，请点击右上角带叉那个东东。因为以下的东西，你会觉得更无聊。

先来个大家熟悉的界面，如下图：

左边这个，又叫“资源管理器”，电脑里的所有资源都可以在这个树里找到它的结点。

如下图是这个文件夹的表现路径，一般我们会见到这样的

（D:\Users\Stri\AppData\Local）

清晰的路径，让用户一目了然，清楚所在的位置、所在的文件夹功能等。

还有一个就是我们在使用电脑过程中都会不知不觉的在桌面上放很多文件（很多时候都是刚开始觉得没什么，不过慢慢的堆积多了，却发现成了一种累赘），我们很烦这样，因为我们想找一些文件时，要寻找半天，常常因此抓狂，而且这样电脑也会卡的，心情有时候也会卡掉，还有时候也会一不小心把重要文件丢进垃圾桶，这样后果会更严重。原因是什么，是我们平时没有结构化（梳理）习惯，每天都会做的东西却不去思考怎样让其变的简单，有理念和有价值。(因为我们常常思考去解决问题，而不是研究问题，为什么这样做？)

比如我的工作原因，某些工具的使用率很高。我会用某类软件放置在桌面不同的位置。如下图：

记得有一句话很经典“不论是简单或复杂、合理或不合逻辑，最成功的产品设计都是那些和学习生活连接最深的东西”。我很喜欢这句话。我们无需去思考和研究复杂的产品模式，无需去崇拜哪位成功人才的名言伦理，更无需因别人叽叽喳喳的意见而去改版。我们做的不需要很多，因为我们只是换了一种表现方式给用户展现，细节和习惯还是用户的。

到这里，我们可以回到这篇文章的标题上。关于“URL目录索引”，看了以上我的看法之后，你会怎么做？没有后续…，因为还要忙着做项目（囧！淡疼的产品，你为谁而生？）。

transform{transform-function}

{transform-function}:有scale(缩放)、rotate(旋转)、skew(倾斜)、translate(移动)等方法。每个方法都有两个参数，分别是当时2D空间的X和Y坐标。

transform-origin{和background-position的属性值一样}是指变形的基准点。

transition{property duration timing-function}

{transition-property}:要进行动画的属性；
{transition-duration}:要进行动画的时间（单位:s（秒））
{transition-timing-function}:要进行的动画效果；有linear(均速)、ease-in(慢到快)、ease-out(快到慢)、ease(慢快慢)

animation{name duration timing-function}

{name}:#关键帧#的名称；
{duration}:要进行动画的时间(单位:s)
{timing-function}:要进行的动画效果；有linear(均速)、ease-in(慢到快)、ease-out(快到慢)、ease(慢快慢)

关键帧:@keyframes name
其格式如下:

1
2
3
4
5
6
7
8
9
10

@-webkit-keyframes facebook{
   0%{ 
     }
 
   50%{
     }
 
   100%{
      }
}

facebook是此关键帧的name(详看Demo1)

以下Demo演示环境：Chrome 8+

Demo 1:

Demo 2

运行下面代码看2009年到2099年发生“五个星期五，五个星期六，五个星期日”的月份