从根本上说,Flash Catalyst是一个专业的交互设计工具,它的前身是Thermo(听到这个名字大家可能会有一些印象,这是Flash Catalyst正式推出之前的开发代号,在之前Adobe的很多非常酷的视频中介绍过如何使用这个工具快速制作同样非常酷的应用)。
这里我们对Flash Catalyst的功能做一个简单的概述。刚才我们也说到,Flash Catalyst是一个全新的专业的交互设计工具,就是说,这是一个非常适用于UI设计人员以及交互设计人员的工具,你可以用它快速完成一个界面原型,或者说是包含交互行为的界面原型。
通常完成交互行为的构建需要编写大量的代码,这也是UI设计人员以及交互设计人员在完成设计工作时非常头疼的事情,而这些工作通常情况下也会移交给开发人员来完成,这中间会有交流的成本在里面,而且增加了开发人员的负担。
而Flash Catalyst则可以让设计人员在不写代码的情况下,创建应用程序的界面以及交互内容。我们可以看到,它提供了完全可视化的编辑界面,让我们构建界面,绑定行为。它能根据你的设计方案快速创建出非常酷的UI界面。
然后你就可以把包含交互的原型移交给Flex开发人员,完成后续的逻辑代码编写工作。Flash Catalyst可以和Flex很好的协同工作,稍后我们会详细介绍。
导入功能是Flash Catalyst中非常重要的功能,虽然Flash Catalyst本身也具备绘图的功能,但实际上你可以使用更专业的绘图工具(比如Photoshop,Illustrator)来绘制界面,然后把这些工具制作的包含图层的素材文件(注意是源文件,比如PSD,AI文件),导入到Flash Catalyst中,完成界面加工以及交互操作。
阅读原文
Posted in Flex&ActionScript.
Spark 是Flex4中新增的皮肤与组件类。与Flex3的mx.skins.halo相比,新增了30多个组件和原始类型,并完全支持原有的Halo架构(截至目前的Beta版本)。
Spark架构同样还包含一个更灵活的布局模型。这个新布局机制可以在运行时进行设置,并且可以完整支持2D旋转,缩放以及使用Flash Player 10所支持的3D功能。新的布局机制还支持包括List,以及一个普通容器使用Repeater组件时的虚拟化。他同样支持任何容器组件和List的平滑滚动。
参考文章:
Deepa Subramaniam: An Introduction to the Gumbo Component Architecture
Adobe Flex4 Reference
Posted in Flex&ActionScript.
文字历来是人机交互中信息传递的重要手段。虽然在交互界面图形化的趋势下,图标的识别效率和可学习性都胜过文字,但文字这一最基础的信息传递方式依旧承担着沟通的重任。
国内的 Web 服务商在日益重视用户体验与可用性的时候,往往都忽略了文字信息的正确性、科学性和有效性。我们经常可以看到设计精美构思巧妙的交互页面上充斥了晦涩的专业术语,或者是大段罗嗦的文字却无基本的分段,再有甚者乱用“的地得”或通篇提示信息都跟随着让人心惊的感叹号等等。这些错误也许不足以影响用户完成他们的任务,但其不良的影响却是潜在的。如果你有心去观察国内一个服务类的网站,也许你可以罗列出上百条文字方面的错误信息。这并不需要你必须是中文系本科毕业,你只需在高考前接受过语文老师的突击训练即可发现绝大部分的问题。
改正了基本的语法错误之后网站并不能高枕无忧。文字信息还体现着服务商的企业形象,这一点都不夸张。我们花一点点时间去浏览一些跨国公司的中文网站,留意一下IBM中国的错误提示页面或离站跳转页面,留意一下微软软件产品的宣传用词,就可以发现严谨的措辞体现着服务商认真踏实的服务态度。( 至少让用户感觉如此
)
完成了严谨的措辞之后,文字信息的优化并没有大功告成。你的语法正确了,你的措辞严谨了,但你还没有从用户的角度出发,让语气和语态符合用户现有的需求,或引导用户的需求。阅读一段人性化的提示信息就好比聆听嗓音甜美,字正腔圆的声讯台小姐的应答,可以让你身心愉悦;阅读一段富有激情的宣传语就好比喝下一盅暖酒,可以让你热血沸腾当下决心。
这样一来,用户在交互过程中的体验舒适性无形中就有了提升,这样一来,用户满意度随之提升,网站美誉度随之提升,用户忠诚度随之提升,单用户消费额随之提升,网站收入随之提升……
有感于支付宝的 UI Team 开始招聘专职的文案人员改善网站上的文字( 详看麦兜的交互设计)。
Posted in Usability.
自从可用性(Accessibility)这一概念被引入国内以来,一直没有看到国内对Web的可用性有一个完整的标准,很多时候都是从零碎的细节对可用性有一个隐约的勾勒。其实W3C早在 1999 年 5 月 5 日作为推荐标准首次发布了WCAG1.0。 2006 年 4 月 27 日,W3C公布了该标准的 2.0 版本草案 几乎所有可访问性标准和法律都源自WCAG 1.0。WCAG 包含 14 条准则。每一条准则又包含一个或多个进一步阐明该准则的检查点。每个检查点都按 1 到 3 的优先级进行分级。为使这些准则的实施变得更加容易,W3C 已经发布了一组文档,其中包含有关如何遵守这些准则的技术(请参看篇末链接中的 3 和 4 )。 同Web标准一样,W3C提供了WCAG的验证。我们可以要求不同程度地遵守 WCAG 准则。如果要求 Web 站点满足所有优先级 1 的检查点,则在站点上可以显示具有 Conformance Level A 的标识语和 LOGO 。当 Web 站点满足所有优先级 1 和 2 检查点时,该 Web 站点可以显示 Conformance Level Double-A 标识语和 LOGO。最后,满足所有检查点的 Web 站点可以显示 Conformance Level Triple-A 标识语和 LOGO。 关于WCAG的一些链接:
- Web Content Accessibility Guidelines 1.0
- Web Content Accessibility Guidelines 2.0
- Understanding WCAG 2.0
- Techniques for WCAG 2.0
- W3C WCAG 1.0 Conformance Logos
Posted in Usability.
在网上看到的与网站相关的一些定律。其实很多时候,不是我们不知道,只是我们没想到。只缘身在此山中阿。
- 250定律
拉德认为:每一位顾客身后,大体有250名亲朋好友。如果您赢得了一位顾客的好感,就意味着赢得了250个人的好感;反之,如果你得罪了一名顾客,也就意味着得罪了250 名顾客。 在你的网站访客中,一个访客可能可以带来一群访客,任何网站都有起步和发展的过程,这个过程中此定律尤其重要。
- 达维多定律
达维多认为,一个企业要想在市场上总是占据主导地位,那么就要做到第一个开发出新产品,又第一个淘汰自己的老产品。 国内网站跟风太严重,比如前段时间的格子网,乞讨网,博客网,一个成功了,大家一拥而上。但实际效果是,第一个出名的往往最成功,所以在网站的定位上,要动自己的脑筋,不是去捡人家剩下的客户。同理,买人家出售的数据来建站效果是很糟糕的。
- 木桶定律
水桶定律是指,一只水桶能装多少水,完全取决于它最短的那块木板。这就是说任何一个组织都可能面临的一个共同问题,即构成组织的各个部分往往决定了整个组织的水平。 注意审视自己的网站,是速度最糟糕?美工最糟糕?宣传最糟糕?你首先要做的,不是改进你最强的,而应该是你最薄弱的。
- 马太效应
《新约》中有这样一个故事,一个国王远行前,交给三个仆人每人一锭银子,吩咐他们:“你们去做生意,等我回来时,再来见我。”国王回来时,第一个仆人说: “主人,你交给我们的一锭银子,我已赚了10锭。”于是国王奖励他10座城邑。第二个仆人报告说:“主人,你给我的一锭银子,我已赚了5锭。” 于是国王例奖励了他5座城邑。第三个仆人报告说:“主人,你给我的一锭银子,我一直包在手巾里存着,我怕丢失,一直没有拿出来。”于是国王命令将第三个仆人的一锭银子也赏给第一个仆人,并且说:“凡是少的,就连他所有的也要夺过来。凡是多的,还要给他,叫他多多益善。”这就是马太效应。 在同类网站中,马太效应是很明显的。一个出名的社区,比一个新建的社区,更容易吸引到新客户。启示是,如果你无法把网站做大,那么你要做专。作专之后再做大就更容易。
- 手表定理
手表定理是指一个人有一只表时,可以知道现在是几点钟,而当他同时拥有两只表时却无法确定。
一个网站,你只需要关注你特定的用户群需求。不要在意不相干人的看法。
- 不值得定律
不值得定律:不值得做的事情,就不值得做好 不要过度seo,如果你不是想只做垃圾站。不要把时间浪费在美化再美化页面,优化再优化程序,在你网站能盈利后,这些事情可以交给技术人员完成。
- 彼得原理
劳伦斯.彼得认为:在各种组织中,由于习惯于对在某个等级上称职的人员进行晋升提拔,因而雇员总是趋向于晋升到其不称职的地位。
不要轻易改变自己网站的定位。如博客网想变门户,盛大想做娱乐,大家拭目以待吧。
- 零和游戏原理
当你看到两位对弈者时,你就可以说他们正在玩“零和游戏”。因为在大多数情况下, 总会有一个赢,一个输,如果我们把获胜计算为得1分,而输棋为-1分,那么,这两人得分之和就是:1+(-1)=0 不要把目光一直盯在你的竞争网站上,不要花太多时间抢它的访客。我们把这些时间用来寻找互补的合作网站,挖掘新访客。
- 华盛顿合作规律
华盛顿合作规律说的是: 一个人敷衍了事,两个人互相推诿, 三个人则永无成事之日。 如果你看准一个方向,你自己干,缺人手就招。不要轻易找同伴一起搞网站,否则你会发现,日子似乎越过越快了,事情越做越慢了。
- 邦尼人力定律
一个人一分钟可以挖一个洞,六十个人一秒种却挖不了一个洞。合作是一个问题,如何合作也是一个问题。
你需要有计划。
- 牛蛙效应
把一只牛蛙放在开水锅里,牛蛙会很快跳出来;但当你把它放在冷水里,它不会跳出来,然后慢慢加热,起初牛蛙出于懒惰,不会有什么动作,当水温高到它无法忍受的时候,想出来,但已经没有了力气。 如果你是soho,注意关注你的财务。不要等到没钱了再想怎么挣,你会发现那时候挣钱更难。
- 蘑菇管理
蘑菇管理是许多组织对待初出茅庐者的一种管理方法,初学者被置于阴暗的角落(不受重视的部门,或打杂跑腿的工作),浇上一头大粪(无端的批评、指责、代人受过),任其自生自灭(得不到必要的指导和提携)。
做网站毕竟要遭遇这样的阶段,搜索引擎不理你,友情链接找不到,访客不上门。这是磨练。
- 奥卡姆剃刀定律
如无必要,勿增实体。
把网站做得简单,再简单,简单到非常实用,而不是花俏。google的首页为什么比雅虎好?
- 巴莱多定律(Paredo 也叫二八定律)
你所完成的工作里80%的成果,来自于你20%的付出;而80%的付出,只换来20%的成果。
随时衡量你所做的工作,哪些是最有效果的。
- 马蝇效应
林肯少年时和他的兄弟在肯塔基老家的一个农场里犁玉米地,林肯吆马,他兄弟扶犁,而那匹马很懒,慢慢腾腾,走走停停。可是有一段时间马走得飞快。 林肯感到奇怪,到了地头,他发现有一只很大的马蝇叮在马身上,他就把马蝇打落了。看到马蝇被打落了,他兄弟就抱怨说:”哎呀,你为什么要打掉它,正是那家伙使马跑起来的嘛!” 在你心满意足的时候,去寻找你的马蝇。没有firefox,不会有ie7,firefox就是微软的马蝇之一。马蝇不可怕,怕的是会一口吃掉你的东西,像 ie当初对网景干的那样。
- 最高气温效应
每天最热总是下午2 时左右,我们总认为这个时候太阳最厉害,其实这时的太阳早已偏西,不再是供给最大热量的时候了。此时气温之所以最高,不过是源于此前的热量积累。
你今天的网站流量,是你一个星期或更长时间前所做的事带来的。
- 超限效应(溢出效应)
刺激过多、过强和作用时间过久而引起心理极不耐烦或反抗的心理现象,称之为“超限效应”。 别到别人论坛里发太多广告。别在自己网站上放太多广告。别在自己的论坛里太多地太明显地诱导话题。
- 懒蚂蚁效应
生物学家研究发现,成群的蚂蚁中,大部分蚂蚁很勤劳,寻找、搬运食物争先恐后,少数蚂蚁却东张西望不干活。当食物来源断绝或蚁窝被破坏时,那些勤快的蚂蚁一筹莫展。“懒蚂蚁”则“挺身而出”,带领众伙伴向它早已侦察到的新的食物源转移。 不要把注意力仅仅放在一个网站上,即使这个网站现在为你带来一切。你要给自己一些时间寻找新的可行的方向,以备万一。
- 长尾理论
ChrisAnderson认为,只要存储和流通的渠道足够大,需求不旺或销量不佳的产品共同占据的市场份额就可以和那些数量不多的热卖品所占据的市场份额相匹敌甚至更大。 对于搜索引擎,未必你需要一个热门词排在第一位,如果有一千个冷门词排在第一位,效果不但一样,还会更稳定更长远。
- 破窗理论
栋建筑上的一块玻璃,又没有及时修好,别人就可能受到某些暗示性的纵容,去打碎更多的玻璃。 管理论坛时,如果你发现第一个垃圾贴,赶紧删掉他吧。想想:落伍现在为什么那么多××贴?现在控制比最初控制难多了。
- “羊群效应”,又称复制原则(Copy Strategy)
一个羊群(集体)是一个很散乱的组织,平时大家在一起盲目地左冲右撞。如果一头羊发现了一片肥沃的绿草地,并在那里吃到了新鲜的青草,后来的羊群就会一哄而上,争抢那里的青草,全然不顾旁边虎视眈眈的狼,或者看不到其它地方还有更好的青草。
不要轻易跟风,保持自己思考的能力。
- 墨菲定律
如果坏事情有可能发生,不管这种可能性多么小,它总会发生,并引起最大可能的损失。
除非垃圾站,否则不要作弊,对搜索引擎不要,对广告也不要。
- 光环效应
人们对人的某种品质或特点有清晰的知觉,印象比较深刻、突出, 这种强烈的知觉, 就像月晕形式的光环一样,向周围弥漫、扩散,掩盖了对这个人的其他品质或特点的认识。
不要轻易崇拜一个人或者公司、一个概念、一种做法。
- 蝴蝶效应
一只亚马逊河流域热带雨林中的蝴蝶,偶尔扇动几下翅膀,两周后,可能在美国德克萨斯州引起一场龙卷风。
不管你做什么,网站或者其他,你都应该关注新闻。机遇或者灾难可能就在那。
- 阿尔巴德定理
一个企业经营成功与否,全靠对顾客的要求了解到什么程度。 我赞同别人的点评:看到了别人的需要,你就成功了一半;满足了别人的需求,你就成功了全部。
尤其是做网站。
- 史密斯原则
如果你不能战胜他们,你就加入到他们之中去。
不要试图做孤胆英雄。如果潮流挡不住,至少,你要去思考为什么。
Posted in Misc.
在AJAX的应用中,往往需要通过URL地址传递一些参数。一般情况下我们常见的是形如 index.html?name=3&size=14 这样的通过location.search对象传递。而为了解决AJAX交互过程中无法使用浏览器的前进后退按钮的问题,也常用形如index.html#name=3&size=14这样的通过location.hash对象传递。我们需要对此进行处理,获取传递的参数名和参数值。
下面这段代码扩展了location对象,增加了2个属性和2个方法。
Properties
| params |
对象,存放 location.search 中的参数名和参数值。形如 params[ name ] = value |
| hashes |
对象,存放 location.hash 中的参数名和参数值。形如 params[ name ] = value |
Mehtods
| getParams |
解析 location.search 中的参数 |
| getHashes |
解析 location.hash 中的参数 |
location.params = {};
location.hashes = {};
location.params.toString = function()
{
var _ostParams = "";
for ( i in location.params )
{
_ostParams += i + " : " + location.params[i] + "<b" + "r >\n";
}
return _ostParams;
}
location.hashes.toString = function()
{
var _ostHashes = "";
for ( i in location.hashes )
{
_ostHashes += i + " : " + location.hashes[i] + "<b" + "r >\n";
}
return _ostHashes;
}
location.getParams = function( _aParamString )
{
var _queryString = aParamString || location.search.substr( 1 , location.search.length );
var _result = null;
if ( _queryString != null && _queryString != "" )
{
var _queries = _queryString.split("&");
for ( var i = 0 ; i < _queries.length ; i++ )
{
var _query = _queries[i].split("=");
_result[ _query[0] ] = unescape( _query.slice(1).join("=") );
}
}
if( arguments.length > 0 )
{
return _result;
}
else
{
location.params = _result;
return true;
}
}
location.getHashes = function( _aHashString )
{
var _hashestring = _aHashString || location.hash.substr( 1 , location.hash.length );
var _result = null;
if ( _hashestring != null && _hashestring != "" )
{
var _hashes = _hashestring.split("&");
for ( var i = 0 ; i < _hashes.length ; i++ )
{
var _hash = _hashes[i].split("=");
result[ _hash[0] ] = unescape( _hash.slice(1).join("=") );
}
}
if( arguments.length > 0 )
{
return _result;
}
else
{
location.hashes= _result;
return true;
}
}
Posted in JavaScript.
对于Location这个JS内建的对象,似乎很多人都仅仅是应用href和search这两个属性。其实Location对象内建有多个属性和方法,都可以直接调用。
Properties
| Properties |
Description |
JS |
IE |
NS |
OP |
FF |
KQ |
SF |
| hash |
锚点,即#及其后面的锚点 |
1.0 |
3.0 |
2.0 |
7.1 |
1.0 |
3.3 |
1.2 |
| host |
主机名称+端口号 |
1.0 |
3.0 |
2.0 |
5.12 |
1.0 |
3.3 |
1.2 |
| hostname |
主机名称 |
1.0 |
3.0 |
2.0 |
5.12 |
1.0 |
3.3 |
1.2 |
| href |
url完整地址 |
1.0 |
3.0 |
2.0 |
7.1 |
1.0 |
3.3 |
1.2 |
| pathname |
路径 |
1.0 |
3.0 |
2.0 |
7.1 |
1.0 |
3.3 |
1.2 |
| port |
端口 |
1.0 |
3.0 |
2.0 |
7.1 |
1.0 |
3.3 |
1.2 |
| protocol |
协议 |
1.0 |
3.0 |
2.0 |
7.1 |
1.0 |
3.3 |
1.2 |
| search |
搜索条件,即?及其后的参数字串 |
1.0 |
3.0 |
2.0 |
7.1 |
1.0 |
3.3 |
1.2 |
Methods
| Methods |
Description |
JS |
IE |
NS |
OP |
FF |
KQ |
SF |
| replace() |
更改当前页面url |
1.1 |
4.0 |
3.0 |
5.12 |
1.0 |
3.3 |
1.2 |
| reload() |
从缓存中重新加载页面内容 |
1.1 |
4.0 |
3.0 |
5.12 |
1.0 |
3.3 |
1.2 |
范例
我们可以看一个范例:
http://blog.imkink.com:80/jssample/location.html?id=3#sample
这个URL地址中,我们可以列出Locaiton对应的各个属性:
Location Properties
| Properties |
Value |
| protocol |
http: |
| host |
blog.imkink.com:80 |
| hostname |
blog.imkink.com |
| href |
http://blog.imkink.com:80/jssample/location.html?id=3#sample |
| pathname |
/jssample/location.html |
| port |
80 |
| search |
?id=3 |
| hash |
#sample |
说明
协议
关于协议,下表列出了主要的一些协议,请注意File协议要多带一个/号。
Protocol types
| Protocol |
URL type |
Example |
| javascript: |
JavaScript code |
javascript:history.go(-1) |
| view-source: |
Navigator source viewer |
view-source:wysiwyg://0/file:/c|/temp/genhtml.html |
| about: |
Navigator info |
about:cache |
| http: |
World Wide Web |
http://home.netscape.com/ |
| file:/ |
File |
file:///javascript/methods.html |
| ftp: |
FTP |
ftp://ftp.mine.com/home/mine |
| mailto: |
MailTo |
mailto:info@netscape.com |
| news: |
Usenet |
news://news.scruznet.com/comp.lang.javascript |
| gopher: |
Gopher |
gopher.myhost.com |
两个方法的说明
replace()方法在效果上与直接将新URL地址赋值给location.href属性基本一致,但是使用replace()方法后,我们无法通过浏览器的“返回”按钮来回到上一页。
reload()方法和浏览器的“刷新”功能也有所区别,reload()方法仅仅是重新加载本地的缓存,而不会向服务器重新发出请求,这点还没有严格的测试过,不过应该在包含有表单的页面中特别注意。
Posted in JavaScript.