时间：2009.11.1 地点：柳浪闻莺大草坪
主办方几大恶心人的商业奇招:
第一招：(车匪路霸)门票限一次使用,一旦进入场地不能出入。
第二招：(强买强卖)场内食物价位奇高,与第一招组和使用就形成了这第二招。
第三招：(坑蒙拐骗）消费券购物且限当日消费，限当日使用的小字需要借助放大镜才找得到，三哥的就因此白白损失了60大洋。
暴强的安保措施：
1，为了保证观众和乐手的安全舞台前10米范围被钢管护栏保护。
2，最佳观赏区被钢管围成羊圈状，且限制圈内羊儿的数量，以确保它们做广播体操的不时之需。温顺的羊儿们非常理解主办方全民健身的娱乐宗旨，因此频频跨栏以示支持。 More »
转载自 TEDtoChina
Blaise Aguera y Arcas: Jaw-dropping Photosynth demo
首先，我要用最快的速度为大家演示一项新技术的基础研究成果。正好是一年前，微软收购了我们公司，而我们为微软带来了这项技术，它就是Seadragon。Seadragon是一个软件环境，你可以通过它在本地或者以远程的方式与浩瀚的可视化数据进行互动。 More »
为了更好的记录分享成果，碳酸组委会开始用视频记录碳酸饮料会的分享过程，同时ppt也插入了音频。
在项目开发团队中，团队成员之间的沟通过程中经常会出现各种各样的冲突和摩擦，仔细分析这些冲突的根源，你就会发现。大部分冲突的产生都有一个共同的特点即：引发冲突的事务的决策权不清晰，或受到了某种程度的干扰。
以下是几个引发冲突的案例：
【案例1】运营看到视觉设计师的方案，运营：“我觉得这个秒表的图形应该用圆形而不是方形”
运营的说法侵犯了视觉设计师的决策权，是对视觉设计师职业分工的一种否定和不信任。
【案例2】交互设计师发现一个需求时向产品经理建议加上某功能，产品经理：“这个功能我知道有用之前也考虑过，但担心交互上太复杂用户理解不了就没加。”
产品经理基于自己对交互复杂程度的猜测而放弃了某个产品功能，忽略了交互设计师的角色定位。
【案例3】交互设计师要用新窗口的方式代替弹出层方式，已经和产品经理达成一致了。 开发工程师：“我不接受！…”
只有项目管理者才有拒绝设计方案的权利，开发工程师利用自己在项目进度中的制约作用行使不属于他的决策权。
这些对话引发冲突的一个共同的根源在于：项目开发团队各个角色间的决策权是混乱的，一个角色可以跨越自身的职责范畴干扰其他角色的决策权，开发可以做出产品经理的决策否定设计方案，运营的意见左右视觉表现。这种决策关系的混乱最终反映到产品上就必然导致产品的混乱。
决策权受到侵犯存在以下两种情况:
显性侵犯
案例1中视觉设计师的决策权受到非视觉专业领域人士的直接干预，属于显性侵犯。这种侵犯肯定会遭到抵抗。面临这种情况时被侵犯者需要具备一定的职业技能和较强的沟通技巧，才能完全不受这些非专业意见的影响。 虽然只要具备了上述能力设计师就能保护自己不受侵犯，但做出专业决策要依赖于非专业技能这件事本身就是一个严重的问题，首先非专业技能的学习需要付出高昂的学习成本，另外即使具备了这种技能也会有很多时间浪费在无效沟通上，尤其是对新设计师而言他们很难保护自己的决策权不受侵犯。最终导致非专业意见跨越职责分工影响产品最终形态。
隐性侵犯
还有一种侵犯属于隐性的，比如案例2中：产品经理在产品功能规划阶段砍掉了一个用户需求量很大的功能，原因是他推断此功能交互方式太复杂用户难以理 解，这个过程是发生在产品经理头脑中的思维过程，是完全不可见的，产品经理根据自己对产品交互方式的理解作出“太复杂”的判断显然是不恰当的，对交互方式 复杂程度的判断应该属于交互设计师的决策范畴，但由于砍掉产品需求这个过程是隐性的很难被发现的。所以交互设计师甚至没机会察觉自己的决策权被侵犯，就已经失去了决策机会。
针对这种决策权混乱的情况，我们已经有一些基本的管理工具，比如流程管理就在一定程度上避免了混乱，他通过划分每个角色的职责范畴来规定各个角色在项目开发事务中分别拥有的决策权，但这种划分只能解决项目主干任务上的决策权界限问题。对与项目分支任务中的细微决策点和决策权的隐性侵犯问题却不能有效解决。
在分支任务中的决策权混乱和决策权的隐形侵犯问题有没有更好的解决方式呢？
制定更加详细的流程，规范项目开发的每个细节？繁复臃肿的流程会大大降低系统的执行效率这样做显然不可行。因此，就需要建立另外一种规则，它不具有流程的强制执行的特点，因此更加灵活变通不会影响效率，但同时它又需要具有一定的约束力。这就是为什么我们要引入伦理的概念。
伦理具有以下特点使它能够成为制止混乱的有效工具：
伦理在一定程度上起到了调节社会成员之间相互关系的规则的作用，类似于约定俗成的交通秩序，引申为人在社会上为人处世的规则。它试图从理论层面建构一种指导行为的法则体系，即“我们应该怎样处理此类处境”，“我们为什么/依据什么这样处理”。并且对其进行严格的评判。
伦理这种“约定俗成”和“指导法则”的感性特征使他可以影响我们处理事情的方式，但又不具有强制色彩。而且它通过公众评判产生约束力（例如古代贞节 牌坊的象征意义，就是对受封者守寡行为的约束），在项目团队中这种约束力来自项目成员对规则的普遍认同，对不遵守规则的成员进行评判。
为了解决决策权混乱的问题，我们需要项目成员彼此尊重对方的角色定位和职业分工。这也就形成了项目开发伦理的基础内容：尊重角色定位和职业分工，不同的角色对自己职责范畴内的事务拥有最终决策权，其它角色可以提出意见和建议但是角色本身掌握最终决策权。
这种伦理将会给我们带来什么样的好处呢？我将通过以下案例说明：
在某项目中，设计师对产品经理的产品方向提出质疑认为功能设计不合理，并通过用户调研手段发掘出了真正的用户需求。但产品最终并没有体现这些需求， 设计师是应该利用自己对项目进度的影响为了用户的利益 “坚持到底”，还是将产品的风险告知产品经理并且尊重产品经理的最终决策权“点到即止”。
坚持到底
好处：产品在我们的坚持下，虽然付出了一定的变更成本，但最终做出了有利于用户的改动。 我们得到了一个好产品。
坏处：一旦我们为了满足某些用户需求质疑产品经理在产品方向上的决策权，就会破坏尊重职业分工的伦理，在这种伦理被破坏的情况下每个项目成员的决策 就都有可能受到其他项目组成员的反复质疑。系统的整体执行效率必然大打折扣。产品经理在本项目中的失误没有暴露出来，因此系统无法识别自身的薄弱环节，因 此为下一个产品埋下了隐患。
点到即止
坏处：这个产品不能满足一部分用户需求。
好处：我们尊重产品经理的最终决策权（虽然不一定信服），在相互尊重的伦理中，系统高效运转项目顺利完成，尊重伦理保证了系统的执行效率。 由于产品对市场的把握不准确，产品经理团队内部做出了调整。我们形成了一个更有战斗力的项目开发团队。
从上面的例子可以看到，尊重伦理保证了项目开发团队本身的良性发展和进化。因此，单个产品的成败，和系统的整体强健高效相比显得微不足道。
相互尊重建立在职责分工明确的基础上，只有在职责分明的情况下才能识别哪个角色拥有优先决策权，流程工具保证了主干任务的明确分工。在分支任务中如果存在角色职责模糊的地带，就需要遵循能力尊重原则，设计师深入理解用户行为的能力使他对产品细节有相对优先决策权。产品经理对市场的把握能力，使他在产品方向上有相对优先决策权。
如果不能明确职责分工，设计师干扰产品策略，开发干预产品设计。不但会影响适当的人作出正确的决策，当产品出问题时，系统也无法识别出错环节，不利于系统的进化。
一方面：要求角色有能力证明自身决策的权威性和正确性
其实很多质疑者的质疑习惯源于以往的质疑成果的激励。质疑者大多在之前有过成功质疑的经验，并且认为自己的质疑使产品更加完善。这种成功质疑的对象 必然是那些没有能力证明自己决策的正确性和必然性的不成熟的角色。如果质疑者的每次质疑都被成功说服。那她的质疑习惯就会被尊重习惯和信任习惯所取代。
对与设计师来说，就是自己的每一个设计决策都要禁得起质疑。能在每一次受到质疑的时候给出充足的理由。在经过多次合作后，其他成员自然会建立起对你 的信任和尊重。质疑声会逐渐消失。最理想的情况是设计团队的大多数成员都具有这种能力，那整个部门都将收到足够的尊重，即使是部门中少数不成熟的成员（这里的不成熟是职业技能而非专业技能）也可以享受这种尊重成果并尽快成熟起来。
另一方面：依靠所有成员对尊重伦理的认同。
所有伦理的产生都源于，利他利己原则，利他是为了利己。就像红灯的时候让别人先走。是为了自己在绿灯的时候不会受阻一样。尊重伦理也是同样的原理， 通过案例教育使成员认识到尊重原则的重要性，尊重别人是为了让自己的决策更受尊重，当大家都对这个伦理产生一至认同的时候伦理建设就基本完成了。
虽然贞节牌坊制造了“和谐”的社会风气，但也束缚了广大妇女同志追求性福的脚步。严重的甚至有可能对“偷情”的小寡妇造成人身伤害，因此有必要的时候我们必须要推翻它，
伦理在保护角色决策权的同时，有可能会屏蔽一些合理意见。当产品的大方向不会受到影响的情况下，这种负面的影响在可接受的范围内。但是如果产品目标出现严重偏差，而且有可能会威胁到用户的核心体验时。是有必要突破伦理的。
何时突破伦理有一个模糊的界限：产品形态跟产品目标出现严重偏差时有必要突破尊重伦理。
至于什么程度算是严重并没有明确的标准，只能根据具体项目具体评估。
今天打开picassa相册，第一眼就看到一个上传对话框。忽然想起来这就是上次上传picassa相册没成功的那几张照片。我都忘记了，picassa还记得，感动啊！上传完成赶紧打开在线查看。靠还是不能访问！
可以上传说明google的服务器还没撤，网页无法访问说明google还没正确认识到自己的错误，依然菊门紧闭。
问题：通过Google Reader订阅了自己的Blog，格式丢失，段落和换行都没有了。
解决方案：由 Options » Reading 进入设置页面，将 Syndication Feeds 下的 For each article, show: 设定为：Full Text 后保存就可以了。修改了之后，没有立即生效，可能是WordPress有缓存的问题。
radio button直译是 收音机按钮.这种称呼来源于早期的汽车收音机用来选台的按钮,一组互斥的选台按钮中有一个被按下时,其它按钮就会弹起,被按下的按钮保持按下的状态.还有一种说法是”radial button”这种说法的根据是按钮的形状是圆的,但这种说法是错误的,按钮的名字应该基于它的行为而不是形状.
radio button的初始状态可以是空选,但一旦与此控件产生交互,除非借助其它控件,空选状态不能还原.但是苹果的用户界面指南里有明确的描述,radio button控件里必须有一条是处于选中状态。
radio button只适用于5个以内的选择项。选项超过五个应该用弹出窗，
radio button可以水平排列也可以垂直排列，这取决于你的整体布局。但一般情况下我们应该选择垂直排列，这样的排列方式有利于强调按钮间的互斥关系。如果你选择了水平排列方式，你需要量出最长选项的长度值。并把这个值应用到每个选项所需的空间中。
另外不管你采用的是垂直布局还是水平布局，都要保证标题和第一个选项的文字基线处于同一条水平线上。
我们设计师一直在考虑应该怎么与产品经理合作能更融洽的沟通，更深入的理解业务，更好的支持产品设计。不如来听听产品经理希望怎样与我们合作吧。
以下是宽哥（淘宝企业营销产品经理）对这个问题的看法：
产品经理需要提前一个季度，将下个季度的业务产品计划列表与ued团队进行沟通；
目的：让ued团队提前了解业务团队未来的发展，并且提前准备配合，
为业务发展提供资源保障
产品经理和业务团队收集整理商业需求，并制定业务规划；
产出业务需求文档，和ued团队进行沟通;
目的：让ued团队理解商业需求，了解产品背后的商业意义；
同时也可以提出自己的意见和想法，让产品经理和设计师在产品萌芽期就达成默契；
并且可以在产品萌芽期就可以构思产品雏形；
产品需求整理阶段，设计师可以帮助产品经理共同构思产品，
产品需求整理完成时，设计师需要开始进行交互设计；
目的：设计师支持产品经理进行产品设计可以让设计师更了解产品；设计出更满足产品需求的交互设计；
产品经理也会得到设计师的建议调整产品设计；
立项前，设计师完成交互设计，通过交互设计指导产品团队更好的理解产品设计
立项后，设计师分别产出产品视觉设计，这个时候产品轮廓可完全产出；
目的：设计师在立项阶段的参与起到了参与产品研发的工作；保障了产品的产出；
其中1，2阶段产品经理要全力推动，这是让双方早日达成默契的重要阶段；
去年过年回家，抽时间见了一下我的大学老师，现在任教于天津美院雕塑系的黄老师还是那么执拗和坚持。不像“艺术家”倒更像一个，老老实实种地的中国农民。我跟他聊起了互联网。
关于互联网他提了一下自己的感受。
无论网络先进到什么程度，都无法代替现场的感觉。无法代替在场的状态。曾经我们去一个石窟考察民间雕塑。去之前是在网络上搜集过相关资料的。也看过一些照片，觉得可去可不去的一个地方。当我们真的站到那里时都震惊了。从来没人提到过的惊人的美。我们险些错过……。
有时候我们通过别人提供的信息，误读了很多东西如果我们没有亲身经历。这种误读就是我们认识的世界。
“随着人们象征性活动的进展，物质现实似乎在成比例地缩小。人们没有直面周遭的事物，而是在不断 地和自己对话。他们把自己完全包裹在语言形式、艺术形象、神话象征或宗教仪式之中，以至于不借助人工媒介他们就无法看见或了解任何东西。”【卡西尔，《人 论》，纽约花园城： 双日出版社，铁锚丛书，1956，第43页。】
虽然作者把若干瞬间分门别类，但其实看下来完全没这个必要。叫瞬间之美也只是噱头而已，说白了就是一个有经验的设计师在面对一些非常普遍的交互问题时，是怎么想，怎么做的。他的思路和做法都对我们有很大启发，还是那句俗套的话，结果不重要，重要的是过程。每个交互设计师都可能遇到的问题，每个人都有自己的解决方法，不同的方法能导致不同的结果，作者很谦虚，很坦诚。看完之后你可能会觉得，就这样啊！这没什么，看起来很简单吗！？确实很简单，没有复杂的用户需求调研，没有严谨的数据支持，没有繁复的交互设计步骤。
很简单，你面前有一个很具体的问题，怎么解决？
那些策略层，结构层，表现层……的飘渺概念，或许能让外人觉得我们交互设计师是一个非常牛逼的行业，要具备认知心理学，行为科学的知识；要理解系统的局限性；商业目标和用户体验的微秒平衡。
其实在日常工作中那些高深的知识并不能直接帮助你，它们可能更适合做研究的时候用。认知心理学只需要遵循一般的设计原则就不会太跑偏，当然这也依靠相当丰富的设计经验。系统的局限性，只要理解瘟酒吧实现不了喂死他的效果就行。商业目标和用户体验的平衡，大部分情况下你只能决定某个推广信息的视觉效果是强一点还是弱一点。有时候甚至做到这一点都难。
当你踏踏实实的解决一些问题的时候，你主要依靠的还是经验，敏锐的洞察力，和科学有效的方法，其中只有第一项有一定的行业门槛，后两项都可以通过修炼习得。我们部门就有很多用户研究人员和前端开发对交互设计问题有很到位的理解。
作者的方法中对我启发最大的就是下面这两点：
1.将熟悉的问题陌生化：每次面对一个问题的时候，作者都会以一个完全陌生的角度去审视，即使注册表单这样最普遍的问题，也像第一次面对一样审视和质疑每一个细节，分析尝试更优的方案。
2.广泛吸取已有经验：在播放器设计的例子中，作者在开始动工之前，遍历了所有优秀的视频播放器的设计。进而得出自己的最佳方案。
印象最深刻的例子是，WordPress注册流程改进的例子，通过一次简单的视觉调整注册率提升了25%。这种活生生血淋淋的数据拿出去，就是设计价值的最佳佐证，可以让最龟毛的运营和pd失声。开始干吧兄弟们，你的价值一直都在，只不过看你有没有能力证明它的存在。你的网站的任何一个角落都能找到一堆可以改进的产品。找到最好的把烂的换下来。
但记住，决定这么做的时候，最好确认一下自己能拿到对比数据，有把握之后再制造机会跟你的“宿敌”吵一架。“老子一定能改好，改不好扣我一年工资……，”干完这一票你就有了话语权，加了工资那是不可能的。”没关系，起码我自己成长了，”通常我们这样安慰自己。（哈哈，YY一下）
在读关于分步任务的章节时，我发现作者的解决方案，跟我刚做的一个项目的解决方案如出一辙，靠，难道我也“大湿”了？其实细想这也并不完全是巧合，交互设计不像视觉，视觉方案如出一辙那肯定有猫腻。交互设计中只是一些解决问题的方法和思路，在相同的前提下解决问题的最佳方案只有一个，一些牛人（比如我和霍克曼，哈哈）的思路撞车是很正常的。
“我们预计每天会来五万人，结果却来了100万人。我饿了整整两天，因为我们不能走出去买东西。所以我只能吃玉米片度日。这些孩子都很不错。他们总是‘先 生’这个，‘先生’那个，‘谢谢’这个，‘谢谢’那个。没人可以抱怨这些孩子。这个音乐节太大了，对世界都是如此。这是前所未有过的。”
这是『Woodstock』纪录片开篇对当地居民的一段采访。而在音乐节举行的前几个月，住在那边的人们还把即将到来的年轻人视之为洪水猛兽，在他们看 来，围绕在这些嬉皮士身上的无非就是邋遢外表和大麻迷幻药，考虑到与之相随的交通堵塞和污水废物，这个只有几千人口的Bethel小镇立刻陷入了恐慌。可 这个为期三天、聚集50万人的音乐节除了两人因意外致死，没有发生任何的骚乱和暴动。而在Woodstock之前，最大型的音乐节也不过两三万人，它的举 办无疑是创纪录的，而其“和平、反战、平等、博爱”的主旨更是激荡了一代人的灵魂。
1969年对美国来说是不同寻常的一年。那年的7月20日，阿波罗号登上月球，标志着美国在抗苏联的冷战中取得了科技性胜利；相隔不到一个月时 间，Woodstock让世人见证了一次“爱与音乐”的盛大聚会，以原始的热情将理想凌驾于冷漠隔阂的现实。能让我们在胶片中身临其境Woodstock 的壮观景象，应该要感谢Michael Wadleigh和他的团队，在制作人纷纷回绝拍摄摇滚纪录片的情况下，这个当时以拍摄独立和地下电影闻名的年轻导演却不计报酬、欣然地接下了邀约，而日 后大名鼎鼎的导演马丁•西科赛斯也参与了影片的剪辑工作。最终，这部电影用去了长达120英里的胶片，留下了300小时的珍贵资料。1970年3月26 日，华纳公司将这部长度为184分钟的纪录片搬上了大荧幕，这部制作成本仅60万的影片单单在美国就创造了5000万美元的票房，并在1971年的奥斯卡 颁奖礼上赢得了最佳纪录片大奖。『Woodstock 3 Days Of Peace & Music 1969』至今依旧是电影纪录片翘楚之作。1994年8月，在Woodstock的25周年纪念之时，发行方又重新推出了长达228分钟的导演剪辑版本。 More »
© Alex Ren 2009 - All Rights Reserved
