O记实录

From：aw’s blog
老实说，我个人很不喜欢那种对着工程师叫嚣“我只要结果”的产品经理。除非你是公司的CEO或者CFO，否则我不认为你有理由回避过程的复杂性。最起码的要求是，相关产品在用户面前所呈现的业务信息量，产品经理应该100%地了解。举个简单例子：如果校内网的产品经理无法向用户解释“如何将一个好友添加为‘特别好友’”，那就太失职了，至少我认为是失职的。
在我自己控制的产品中，我一定是要了解所有业务细节的。由于项目繁忙，我也曾将手头已经拿到的项目转手外包给第三方开发团队，自己做起“产品经理”。作为产品经理去领导工程师，如果高高在上的提出一个粗略的要求就像等结果，99%会荒废掉这个项目。和工程师打交道，“尊重”两个字最重要。你能想象一个工程师是这样工作的么：

(虽然是老图了，感谢Fenng的及时分享)
具体实施起来，除了基本的劳动报酬尊重外，更需要尊重对方的，是明确的需求和时间表（Schedule）描述：一定要面对面对着屏幕将需求说清楚，细化到每一个按钮点击后的效果，并且制定好时间表，否则工程师提交回来的成品八成是一个“四不像”。
而作为工程师或者Vendor，我很难说服自己去会为一个不懂HTML的产品经理效劳。结合06年到现在许多项 目的经验来看，至少在我coding的时候，是希望能有一个规范的阶段需求说明的。产品经理毕竟不是PR、市场总监，没有必要把大把的时间和精力放在产品 之外的地方；产品经理也不是创意总监，不需要每天都有新点子冒出来，而程序逻辑更是严谨的算法实现，再flexible的架构也无法满足所有的业务需求， 简单点说，你不能今天让我开发一个Twitter明天就让这玩意像Facebook那样工作。即便是Prototype阶段的开发也做不到。当然，工程师对于尊重自己的产品经理，则应以“责任”为报答。
总之，“产品经理”这个title已经被滥用了：越来越多不适合做产品经理的人开始做起了产品经理。这是一种事倍功半的分工：他们对公司赋予产品的 期望一无所知，又不知如何与工程师们沟通、交代需求。往往一个很不错的点子胎死腹中。真正优秀、称职的产品经理，其工作强度绝不亚于研发工程师。如果一家 公司的工程师都忙得加班到凌晨转钟，而产品经理们还在家里睡大觉的话，八成这家公司离死亡不远了。只可惜我们的工程师没有“罢工意识”：“长痛”肯定比“短痛”更痛苦的。
———————————–
读后感：
“产品经理毕竟不是PR、市场总监，没有必要把大把的时间和精力放在产品 之外的地方；产品经理也不是创意总监，不需要每天都有新点子冒出来”——有的时候偏偏就都是，对产品经理而言似乎根本就没有产品之外的地方，PR、市场、创意如果有专业人士协助当然更好，即使如此产品经理依然需要兼顾尤其从全局的角度兼顾。
换位思考很重要，有一个不错的想法不难，自己设法实现也不是不可能，但是要依靠一个团队来共同打造最后完美实现就非常不易，这个过程中间大家都需要多站在他人的角色立场思考，嗯，面壁思过去也，有则改之无则加勉~

The Meaning Of Friendship
简译：
在线好友究竟是什么？
社会网络本身以及在上面耗费了大量时间的我们都在试图搞清楚在线交友究竟意味着什么。这种友谊带来的好处是你可以获得关于某个人的一连串信息，而为此付出的代价是必须费心费力来处理大堆信息以及让他人获取你的私密信息。
facebook应对这个问题的做法是只尝试把线下的真实好友搬到线上，不过最近情况似乎有所改变，参考他们新版tagline与旧版的差异
很明显你通过任何服务获得的好友越多，你需要为此付出的处理相关信息的心力也就越多。在真实的世界里如果你不想跟某人做朋友，不用理会他就是了，但是在网络中，交个朋友似乎简单得只需要点个按钮，而且如果你不这么做还会显得很无礼，于是你接受了。
社会化网络们想出了两种应对方法。myspace和facebook以及一些类似的网站允许你对好友进行分门别类，你可以跟不同类别的朋友分享不同的信息，如果你确实对某人没兴趣但是又不想得罪人你可以把他放到一个特定的组别里面去。
另 一种做法的代表者是twitter和friendfeed，任何人都可以关注(follow)另一个人并且获取他的最新动态，这样你就没有什么做出回报的压力。但是问题是面对那些关注你的人你仍有压力需要也对他们加以关注，一个解决办法是提供礼貌性关注的功能（friendfeed正打算这么做）
不过好友分组似乎也不是什么终极解决之道，管理各种站点中成百上千个人的关系变化还是很要命。在未来，类似的服务应该更智能的为你指出谁亲谁疏。或许也能界定出我和某个完全不认识却拥有共同好友者的关系。因此即时没有任何互动，facebook们理论上也应该知道究竟有多少个人信息应该被分享。
不过，到最后我们的文化正在和这些网络一样快速适应，facebook的mark说用户正越来越适应在线分享。有时(好吧，是常常)facebook试图越过雷池来代替我们觉得什么是可分享的什么不是。
译后语：
SNS已经被炒得有点乏味了，一个又一个的海外名星（用“名星”而不是”明星”是因为他们中大多数拥有的还只有名气而已）让C2C们继续头脑发热乐此不彼的进行着copy的步伐，不可否认，存在的即是合理的，更何况还广受欢迎，但我的疑问是：

网络是全球的，但文化不是，尤其是中国文化，即使全球化的浪潮再跃进多少步，中国人骨子里的一些东西仍然不会变
如果经济是一切的基础，我们离名星们所在的国度还有多远的距离？在到达之前会不会已经有了其他更适合的路
SNS究竟是创造的新的需求还是满足了本已存在却未被发掘的需求？人人都需要都渴望SNS吗？我常常想起蔡康永同学的一句话：我还有很多基本需要都没满足，为什么还有人拼命想要创造新的需求？

最近看的东西和想的东西都有点多了，也有点过了，还是应该静下心来想想我们的用户现在到底需要什么？为什么需要？

04年Lane Becker在adaptivepath上发布的一篇文章今天看来仍然别具意义，原来我怀疑过的那些问题早有人做了深刻的反思。文章的标题是《90%的可用性测试都是无效的》，跟《不要听用户的》一样有标题党之嫌，但是读完全文却觉得深有同感，大意如下：
90%的可用性测试都是无效的
目前风行的可用性测试源于软件开发中人机交互领域的背景，典型的做法是一名研究者、一名用户、一个任务清单有时甚至加上一个秒表，这样的方法与软件应用以任务为基础的特点是相吻合的，但是网站并非软件（little O注：虽然近期表现出软件化的趋势但仍与传统意义上的软件有很大区别）。网站是创意与规则、形势与功能、艺术与科学的结合体，好的网站设计在所有这些方面都做得很好，很难说网站的哪一部分应该是开始哪一部分又应该是结束。想要精确的测量一个具体任务的完成时间是愚蠢的做法。问题在于，为什么用户会停下来？他们在看什么？又在想什么？你的导航系统究竟是错在分类、用语还是位置？又或者是因为站内的不一致？糟糕的css标签？传统的可用性测试无法给出答案。
我们必须放弃用户测试是一个量化研究的想法，关注那些数字只会让研究者试图得到一些明显可疑的论断例如”设计A比设计B好5%”。相反，我们应该做定性的深入研究，去理解用户是如何以及为什么那样做，更重要的是，如何将这些发现应用到将来的工作中。
可用性测试是设计而不是QA(质量检测)。理想的可用性测试应作为设计过程的一部分尽早开始、及时优化以及反复验证，而不是作为与设计独立的一部分放在项目最结尾输出一大叠问题清单。
与设计团队融合还意味着节约费用与时间，从而把可用性测试从一次性的报告导向转变为可迭代的行为导向。已经有一些基础框架图或是原型了吗？那就马上拿给用户看吧。很明显，这也降低了改进的成本，一张草稿、一份框架图、一个原型和最后的成品，哪个改起来更费劲？
最后，这一方法也能帮助设计师的成长，设计师常常担心用户的反馈会限制他们的创意，但如果作为设计过程的一部分，通过洞察用户的实际需求，往往能够激发设计师的新灵感从而改善用户体验。
英文的原文在这里

上传（制作），也就是贡献内容，好像有一个数据是说视频分享网站只有不到20%的用户是上传者其余都是下载者，但是这20%用户的重要性不言而喻，没有他们的辛勤劳动网站就失去了存在的基础，那么一个分享者为什么愿意分享呢？首先是尝鲜，”未走过的路通常比较有趣”，有时候新鲜有趣就足以促使一个人产生行动，所以任何一个内容分享型网站都能找出一堆只尝试过一两次的用户，那些长期坚持下来的用户又是为了什么呢？不可否认，互联网的本质之一就是分享，所以很多互联网狂热分子骨子里就有一种”我为人人，人人为我”的利他主义精神，但这样的用户可遇不可求，更多的人能够从分享中获得一种被重视的成就感和价值感，排在TOP10和赢得他人的赞誉对他们来说很重要，当然如果还有一些其他收益会更有效，例如积分、称号、特权、特别推荐等等，但是要注意这些收益最好是与网站本身相关的，而不是直接获得100个大洋，否则分享就变成了赤裸裸的交换。
还有一种可能会促进分享，那就是内容贡献包含一些个性化的附加价值，即通过某种方式使得我共享的东西是独一无二的，上传一个人人都有的流行MTV和一个我制作的短片是完全不一样的，手机主题网站的diy功能恰好提供了一个类似的途径，即使没有很多人下载我仍然乐于使用这一工具创作出个性化的主题供我自己使用和欣赏，但是”自制主题”需要在易用性和功能性中取得微妙的平衡，对大多数缺乏经验的用户来说他们需要的是简单快速的实现目标，而对高级用户来说他们更注重功能强大、效果精美，放弃哪一类用户都是不明智的，我们需要初级用户烘托人气同时也需要高级用户来树立标杆，这时要千万小心不要因为摇摆不定最后演变成两边都不讨好的折衷版本，给出简易版和专业版会是更好的选择，在产品初期可以主推简易版，但是要记得让高级用户有所期待（”我们即将推出更强大的专业版”）。
互动就是扎堆聊天？
所有的内容分享型网站都意不在内容而是内容背后的人，希望藉由内容分享促进用户的互动从而形成独特的虚拟社区，和真实社会一样，有了人就有了社会关系，有了社会关系一切就有了可能。在中国谈到网络社区立刻就会反应到BBS，仿佛社区互动就是扎堆聊天，真的是这样吗？
从社会学的角度来说互动是指人以互相的或交换的方式对别人采取行动,或对别人的行动做出回应，社会互动不仅仅是个人与个人，也包括个人与群体、群体与群体之间通过信息的传播而发生的相互依赖性的社会交往活动。虚拟社区同样可以借鉴这一定义，扎堆聊天是互动，但不是互动的全部。
还是说回手机主题的网站，产品一直在抱怨评论数太少看起来很没有人气，这一点也不奇怪，评论已经是一种很直接很高层次的互动，对很多人来说偶然的接触不足以消除陌生人的隔阂而产生情感联系，是的，这个主题很不错，我看过了，还下载了，也许还留意到了作者叫什么名字，这样不是已经足够了吗？请注意，浏览、下载、观看作者资料都是下意识对他人采取的行动，代表了我的某种倾向与选择，只是不如评论那么主动和直接，但事实上某种形式的互动已经开始了，任何一个内容分享型网站每天必然有大量这样的互动，但是他们往往都石沉大海没有得到任何回应……浏览数和下载数每天都在增加，但那只是数字而已，数字背后那些人对我来说仍然是无意义的–即使你已经多次看过我的主题又或者和我一样下载了这些那些主题，就这样所有的人都像永不交叉的平行线擦肩而过，他们不是没有互动过，只是他们不知道在和谁互动又可以怎样去回应。
在虚拟的世界建立真实情感从来也不是一件容易的事，不是有东西我就想要下载、有内容我就想要分享、有人我就想要say hello。

下午做了一场手机主题网站的CE，用户虽然使用经验不多想法却不少，一个多小时下来忽然觉得对内容分享型网站有了些比较清晰的看法。
手机主题网站是一个典型的基于用户贡献的内容型网站，用户自己制作主题供自己及他人下载同时也下载他人制作的主题，对用户来说有三个主要任务：下载、上传（制作）、互动，和大部分内容分享型网站基本一致，但是要在这三个任务上都获得完美体验并不容易。
首先说下载，对”沉默的大多数”来说这是首要甚至是唯一的任务，下载只是一个行为，背后的动机是”获取我喜欢的主题”，很明显，发现感兴趣的内容是第一步，对有一定上网经验的普通用户来说无非三个途径：随意浏览、分类查看和有目的的搜索。
随意浏览是一个新用户最有可能采取的方式，因此首页的内容质量非常重要，很多内容分享型网站认为只要做个平台出来让用户自己折腾就行了，美其名曰”完全用户自主”，结果往往是少数人（推荐自己作品）的热情打败多数人（寻找喜爱作品）的热情，至少在现阶段的中国是这样的，按这种机制排上首页跻身TOP的作品常常惨不忍睹，完全让人没心情再往下看了。个人认为原因有二，首先这类网站通常是免费的，对原作者来说推荐和增加人气的成本几乎可以忽略不计；其次对于其他用户来说支持喜爱作品的收益同样很微弱。基于”人都是自私的”这一普遍意义上的基本判断导致少数人的作为和大多数人的不作为同时放大，自然而然的沉淀出优秀的作品基本成为不可能的任务，所以呢，有中国特色的市场经济还是需要适当的干预啊，坚决抵制自生自灭型做法，这是对广大用户的不负责任。
分类，是很传统也很有效的内容组织方式，但是把分类的自主权给了用户之后问题又出现了，用户是如此之懒，不仅有一堆”test、jhekjt、????”之类的文件名（不好意思我也经常这样做），还倾向于不假思索的随意选择一个分类（通常没有去修改默认的），结果当我们进入”自然风光”分类是看到的是满屏的大头照片。身为一个产品经理你可能快要抓狂了–”为什么他们就不能花一点点时间起个好名字选个好分类呢”，好吧，想一想那些公园绿地，到处都竖着”脚下留情”的牌子，而牌子的旁边就是路人开辟的小径，不过就是近了那么一点点，希望这有助于你认清人类的本质。要知道，我正在赶着发布我的新作品呢，名字？分类？关我什么事，别妨碍我！当然，如果有一天你告诉我这个有助于增加我的作品曝光量、下载量从而获得一些额外收益的话情况就不一样了，不信的话你可以去淘宝搜索一下”N73″，排在首位的名称是”全新诺基亚N73港行带1G卡(全国联保)◆天盛移动◆100%冲双皇冠”，你有什么感想？
关键字搜索是高级用户的挚爱，我就是喜欢”周杰伦”，我搜~~~，还记得我刚才提到的那些文件名么，如果搜索结果基于文件名那么很幸运你不会得到一堆”蔡依林、芙蓉姐姐”，同时也很不幸，搜索结果可能是个位数，因为还有很多”zhoujielun、jay、最爱杰伦、test、jhekjt、????”被不那么智能的站内搜索拒之门外。身为一名走过路过的用户你当然不会想到这些，你只会想”这个网站的内容也太少了吧，还是走吧”，然后头也不回地走了。tag标签或许是一个不错的选择，但你仍然需要教育用户这是什么，对用户有什么用，否则他们仍然不会买账。
除了以上三种途径之外，关联推荐和人际影响是对技术要求更高但体验也更好的途径，做好了以上三点充其量也只是很好用的工具，但是如果做好了这两点就能让用户产生”这是对我有所了解能够给我惊喜的独特产品”这样一种情感体验，对产品来说就无形中增加了用户转移的成本，即使竞争对手能够原原本本的照搬全部功能，个性化体验却是需要用户长时间与产品以及其他用户互动才能累积产生，绝非一朝一夕能够建立的。这就是为什么即使再有一个一模一样的QQ也不可能替代现有的QQ，因为用户行为数据和人际关系链是不可复制（或者说不可轻易复制）的，只要产品没有明显的短板，一旦产品与用户建立了情感联系，产品就会变得难以放弃，亚马逊和豆瓣就是这样的典范。

术语真是可怕的东西，我到今天还记得第一次看到blog、rss和atom时那种云里雾里的感觉，现在看mashup和Microcontent也颇有同感，今天上yahoo pipes转了一下似乎稍微有点头绪了，但是很遗憾暂时还没有办法用自己的语言表达出这点头绪来，暂且记录一点相关资料以做备忘。
关于什么是pipes？有两段描述比较有代表性：
1.“几天前，我已经从媒体报导中得知Yahoo!最近刚发表一项名为Yahoo! Pipes的视觉化开发工具，让使用者操纵撷取自网站的data feeds进行Mash up，以开发各式各样崭新的应用。
至于Yahoo! Pipes是什么神奇的新工具，且让我们听听任职于Yahoo!平台工程事业部的部落客Jeremy Zawodny来诠释：
Pipes is a hosted service that lets you remix feeds and create new data mashups in a visual programming environment. The name of the service pays tribute to Unix pipes, which let programmers do astonishingly clever things by making it easy to chain simple utilities together on the command [...]

关于树形菜单，网上流传有很多版本，大致看了一下，还是觉得自己DIY一个比较合用，要点：

CSS和JS代码尽量精简
html结构化
兼容IE与FF
较好的视觉扩展性，即可通过修改CSS来控制菜单外观

JS 1:
function showhide(obj){
obj.nextSibling.style.display=(obj.nextSibling.style.display==”block”)?”none”:”block”;
obj.style.backgroundImage=(obj.style.backgroundImage==”url(icon_hide.gif)”)?”url(icon_show.gif)”:”url(icon_hide.gif)”;
}
JS 2:
function shutopen(t1,t2){
document.getElementById(t1).style.display=(document.getElementById(t1).style.display==”block”)?”none”:”block”;
document.getElementById(t2).style.backgroundImage=(document.getElementById(t2).style.backgroundImage==”url(icon_hide.gif)”)?”url(icon_show.gif)”:”url(icon_hide.gif)”;
}
DEMO

在某blog看到一篇关于css的文章，觉得还挺有用的，大致译了一下，译文和原文如下，如果有译得不正确的地方或是对类似问题有其他更好地解决办法的，请不吝赐教！(请尊重他人劳动，转载须注明出处！)译文：
css 十大密技
1.css 字体简写规则
当使用css定义字体时你可能会这样做：
font-size: 1em;
line-height: 1.5em;
font-weight: bold;
font-style: italic;
font-variant: small-caps;
font-family: verdana,serif;
事实上你可以简写这些属性：
font: 1em/1.5em bold italic small-caps verdana,serif
现在好多了吧，不过有一点要注意：使用这一简写方式你至少要指定font-size和font-family属性，其他的属性（如font-weight, font-style,font-varient）如未指定将自动使用默认值。
2.同时使用两个class
通常我们只为属性指定一个class,但这并不等于你只能指定一个，实际上，你想指定多少就可以指定多少，例如：
<p class=”text side”>…</p>
通过同时使用两个class（使用空格而不是逗号分割）,这个段落将同时应用两个class中制定的规则。如果两者中有任何规则重叠，那么后一个将获得实际的优先应用。
3.css中边框（border)的默认值
当编写一条边框的规则时，你通常会指定颜色、宽度以及样式（任何顺序均可）。例如：border: 3px solid #000（3像素宽的黑色实线边框），其实这个例子中唯一需要指定的值只是样式。假如你指定样式为实线（solid),那么其余的值将使用默认值：默认的宽度为中等（相当于3到4像素）；默认的颜色为边框里的文字颜色。如果这正是你想要的效果，你完全可以不在css里指定。
4.!important会被IE忽略
在css中，通常最后指定的规则会获得优先权。然而对除了IE以外的浏览器来说，任何后面标有!important的语句将获得绝对的优先权，例如：
margin-top: 3.5em !important; margin-top: 2em
除IE以外所有浏览器中的顶部边界都是3.5em，而IE为2em，有时候这一点很有用，尤其在使用相对边界值时（就像这个例子），可以显示出IE与其他浏览器的细微差别。
（很多人可能还注意到了css的子选择器也是会被IE忽略的）
5.图片替换的技巧
使用标准的html而不是图片来显示文字通常更为明智，除了加快下载还可以获得更好的可用性。但是如果你决心使用访问者的机器中可能没有的字体时，你只能选择图片。
举例来说，你想在每一页的顶部使用”Buy widgets”的标题，但你同时又希望这是能被搜索引擎发现的，为了美观你使用了少见的字体那么你就得用图片来显示了：
<h1><img src=”widget-image.gif” mce_src=”widget-image.gif” alt=”Buy widgets” /></h1>
这样当然没错，但是有证据显示搜索引擎对真实文本的重视远超过alt文本（因为已经有太多网站使用alt文本充当关键字），因此，我们得用另一种方法：<h1><span>Buy widgets</span></h1> ，那你的漂亮字体怎么办呢？下面的css可以帮上忙：
h1
{
background: url(widget-image.gif) no-repeat;
}
h1 span
{
position: absolute;
left:-2000px;
}
现在你既用上了漂亮的图片又很好的隐藏了真实文本–借助css，文本被定位于屏幕左侧-2000像素处。
6.css盒模型hack的另一选择
css盒模型hack被用来解决IE6之前的浏览器显示问题，IE6.0之前的版本会把某元素的边框值和填充值包含在宽度之内（而不是加在宽度值上）。例如，你可能会使用以下css来指定某个容器的尺寸：
#box
{
width: 100px;
border: 5px;
padding: 20px;
}
然后在html中应用：<div id=”box”>…</div>
盒的总宽度在几乎所有浏览器中为150像素（100像素宽度+两条5像素的边框+两个20像素的填充），唯独在IE6之前版本的浏览器中仍然为100像素（边框值和填充值包含在宽度值中），盒模型的hack正是为了解决这一问题，但是也会带来麻烦。更简单的办法如下：
css:
#box
{
width: 150px;
}
#box div {
border: 5px;
padding: 20px;
}
html:
<div id=”box”><div>…</div></div>
这样一来在任何浏览器中盒的总宽度都将是150像素。
7.将块元素居中
假设你的网站使用了固定宽度的布局，所有的内容置于屏幕中央，可以使用以下的css：
#content
{
width: 700px;
margin: 0 auto;
}
你可以把html的body之内任何项目置于<div id=”content”></div>中，该项目将自动获得相等的左右边界值从而保证了居中显示。不过，这在IE6之前版本的浏览器中仍然有问题，将不会居中，因此必须修改如下：
body
{
text-align: center;
}
#content
{
text-align: left;
width: 700px;
margin: 0 auto;
}
对body的设定将导致主体内容居中，但是连所有的文字也居中了，这恐怕不是你想要的效果，为此#content [...]

传统办法，在标签内加属性 代码多，修改难 <a href=”link1.htm” mce_href=”link1.htm” onfocus=”this.blur()”>link1</a><a href=”link1.htm” mce_href=”link1.htm” onfocus=”this.close()”>link1</a><a href=”link1.htm” mce_href=”link1.htm” hidefocus=”true”>link1</a>
<a href=”link1.htm” mce_href=”link1.htm” hidefocus=”hidefocus”>link1</a>
<a href=”link1.htm” mce_href=”link1.htm” hidefocus>link1</a> 非标准
中级办法，全局控制
1.CSS实现 增加IE负担，不推荐使用
a{blr:expression(this.onFocus=this.close());}
a{blr:expression(this.onFocus=this.blur());}
2.HTC实现 IE支持，并有延迟，不推荐
把下面这段代码存为.htc为扩展名的文件
<public:attach event=”onfocus” onevent=”hscfsy()”/>
<script language=”javascript”>
function hscfsy(){
this.blur();
}
< /script>
样式调用
a {behavior:url(htc文件所在路径地址)}
高级办法，全局控制
1.遍历实现
window.onload=function()
{
for(var ii=0; ii<document.links.length; ii++)
document.links[ii].onfocus=function(){this.blur()}
}
2.将其封装为一个函数
function fHideFocus(tName){
aTag=document.getElementsByTagName(tName);
for(i=0;i<aTag.length;i++)aTag[i].hideFocus=true;
//for(i=0;i<aTag.length;i++)aTag[i].onfocus=function(){this.blur();};
}
当前是添加一个hidefocus的属性，注释掉的句子是添加onfucus=this.blur();
然后调用fHideFocus(”A”);即可把a的虚线框去掉
通过传递不同的参数 可以去掉更多的虚线框 比如”BUTTON”可以去掉button的
但要记住参数要用大写字母
应用技巧及疑问
A. map area内链接如何消除链接虚线？
这是一个观念上的错误，其实应该在所在map的图片上加以控制，而不是在area内，参考传统办法
B. 关于onFocus
<a href=”http://blog.csdn.net/alonesword/” mce_href=”http://blog.csdn.net/alonesword/” onFocus=”this.blur()”>
<Img src=”Example.jpg” mce_src=”Example.jpg” Border=0>
</a>
其中，onFocus是设置鼠标焦点事件的东西，这个可以用，也可以不用，不过为了让更多的浏览器识别的话，建议采用；Border=0 这个才是去除虚线框的关键所在（在网上看到有的人用onFocus=”this.blur（）”来消除虚线框，但在本地测试时，仅仅用这一句是不能消除的）