标签归档:ued

IE Developer Toolbar Beta 3 – Now Available

在微软的博客上复制过来的,如果做IE的项目开发,不可不看,原文地址:http://blogs.msdn.com/ie/archive/2007/01/09/ie-developer-toolbar-beta-3-now-available.aspx,因为时间关系,就不翻译了,做网页设计的可以看看

We’re happy to announce the availability of a new beta of the IE Developer Toolbar. Along with all the features available previously this release contains some new features to improve the usability and help web designers troubleshoot issues on their pages.
User Interface Update. You’ll notice some changes to the user interface. There is now a single button on the IE command bar that allows the user to quickly toggle on and off the bottom panel which then gives easy access to all the features. After discussions with a number of web developers we decided that having the menus only available in the bottom panel made sense for most scenarios, so the toolbar at the top has been removed to avoid duplication of commands and the loss of screen real estate that entails. We’ve also slightly reorganized the menus for the panel to make it easier to find functionality.

There is now quick access to the most commonly used features through toolbar buttons at the left for “Select Element by Click”, “Refresh”, “Clear Browser Cache” and “View Element Source” (a new feature we’ll get to shortly. “Select Element by Click” is possibly the most commonly used function allowing you to hover over the page and select an element and this was previously under a menu.

Style Tracer. A useful new feature is the style tracer which allows you to locate exactly where and in which style sheet a rule is set that is effecting a particular element. In the screenshot below you can see that we have selected an element and the current style of the element shows that the font size is 11px.

One of the challenges when troubleshooting web pages is finding exactly where in the style hierarchy that font size has been set. With this version of the IE Developer toolbar we can now right click on the current style being displayed and select “Trace Style” which will then bring up the window in the screenshot below with the source of the style sheet and highlighting the rule that is in this case specifying that TD elements have a font size of 11px.

You’ll also find an option off the View menu for “CSS Selector Matches”. This will result in a window appearing that reports on all the CSS rules defined along with how many times they have effect on the page. This can be useful if you wish to optimize your style sheets so that only the rules that are needed are actually defined.

View Source. Another new feature is the ability to view the source of the original page, currently rendered version of the page or the selected element from the View menu. You can also choose to view the source of the selected element combined with the styles that currently are affecting it. In the screenshot below you can see that the source for the element we highlighted previously has been combined with the style rules that affect it so that you can save the source and recreate just that portion of the page.

You’ll see that the source in these windows is colored for the syntax. In the installation directory for the toolbar at \Program Files\Microsoft\Internet Explorer Developer Toolbar you’ll find a vs_styles.css files where you can edit the values for the colors if you wish to adjust them.

We appreciate feedback on this latest beta both here and on the wiki on channel 9. One issue we are aware of is that it is necessary to logoff and then logon on Windows Vista for the toolbar to become functional, we expect to address that in a future update.

There’s lots more we hope to provide for the developer toolbar in future versions and all your ideas are welcome.

Thanks
Dave Massy
Senior Program Manager

Edit: January 12, 2007
We’ve just refreshed the download of the toolbar to address the issue some people were seeing where the Style Tracer was not working. If you have an earlier version installed, please uninstall and download the latest version. We really appreciate your feedback so far. Thanks – Dave

Published Tuesday, January 09, 2007 5:02 PM by ieblog
Filed under: General IE Information

界面设计测试规范

目前流行的界面风格有三种方式:多窗体、单窗体以及资源管理器风格,无论那种风格,以下规则是应该被重视的。

1.易用性

按钮名称应该易懂,用词准确,屏弃没楞两可的字眼,要与同一界面上的其他按钮易于区分,能望文知意最好。理想的情况是用户不用查阅帮助就能知道该界面的功能并进行相关的正确操作。

易用性细则:

  1. 完成相同或相近功能的按钮用Frame框起来,常用按钮要支持快捷方式。
  2. 完成同一功能或任务的元素放在集中位置,减少鼠标移动的距离。
  3. 按功能将界面划分局域块,用Frame框括起来,并要有功能说明或标题。
  4. 界面要支持键盘自动浏览按钮功能,即按Tab键的自动切换功能。
  5. 界面上首先应输入的和重要信息的控件在Tab顺序中应当靠前,位置也应放在窗口上较醒目的位置。
  6. 同一界面上的控件数最好不要超过劳过度10个,多于10个时可以考虑使用分页界面显示。
  7. 分页界面要支持在页面间的快捷切换,常用组合快捷键Ctrl+Tab
  8. 默认按钮要支持Enter及选操作,即按Enter后自动执行默认按钮对应操作。
  9. 可写控件检测到非法输入后应给出说明并能自动获得焦点。
  10. Tab键的顺序与控件排列顺序要一直,目前流行总体从上到下,同时行间从左到右的方式。
  11. 复选框和选项框按选择几率的高底而先后排列。
  12. 复选框和选项框要有默认选项,并支持Tab选择。
  13. 选项数相同时多用选项框而不用下拉列表框。
  14. 界面空间较小时使用下拉框而不用选项框。
  15. 选项数叫少时使用选项框,相反使用下拉列表框。
  16. 专业性强的软件要使用相关的专业术语,通用性界面则提倡使用通用性词眼。

2.规范性

通常界面设计都按Windows界面的规范来设计,即包含”菜单条、工具栏、工具厢、状态栏、滚动条、右键快捷菜单”的标准格式,可以说:界面遵循规范化的程度越高,则易用性相应的就越好。小型软件一般不提供工具厢。

规范性细则:

  1. 常用菜单要有命令快捷方式。
  2. 完成相同或相近功能的菜单用横线隔开放在同一位置。
  3. 菜单前的图标能直观的代表要完成的操作。
  4. 菜单深度一般要求最多控制在三层以内。
  5. 工具栏要求可以根据用户的要求自己选择定制。
  6. 相同或相近功能的工具栏放在一起。
  7. 工具栏中的每一个按钮要有及时提示信息。
  8. 一条工具栏的长度最长不能超出屏幕宽度。
  9. 工具栏的图标能直观的代表要完成的操作。
  10. 系统常用的工具栏设置默认放置位置。
  11. 工具栏太多时可以考虑使用工具厢。
  12. 工具箱要具有可增减性,由用户自己根据需求定制。
  13. 工具箱的默认总宽度不要超过屏幕宽度的1/5。
  14. 状态条要能显示用户切实需要的信息,常用的有:
    目前的操作、系统状态、用户位置、用户信息、提示信息、错误信息等,如果某一操作需要的时间较长,还应该显示进度条和进程提示。
  15. 滚动条的长度要根据显示信息的长度或宽度能及时变换,以利于用户了解显示信息的位置和百分比。
  16. 状态条的高度以放置五好字为宜,滚动条的宽度比状态条的略窄。
  17. 菜单和工具条要有清楚的界限;菜单要求凸出显示,这样在移走工具条时仍有立体感。
  18. 菜单和状态条中通常使用5号字体。工具条一般比菜单要宽,但不要宽的太多,否则看起来很不协调。
  19. 右键快捷菜单采用与菜单相同的准则。

3.帮助设施

系统应该提供详尽而可靠的帮助文档,在用户使用产生迷惑时可以自己寻求解决方法。

帮助设施细则:

  1. 帮助文档中的性能介绍与说明要与系统性能配套一致。(我们的系统帮助文档都是系统的祖先时期的说明,让人困惑)。
  2. 打包新系统时,对作了修改的地方在帮助文档中要做相应的修改。
  3. 操作时要提供及时调用系统帮助的功能。常用F1。
  4. 在界面上调用帮助时应该能够及时定位到与该操作相对的帮助位置。也就是说帮助要有即时针对性。
  5. 最好提供目前流行的联机帮助格式或HTML帮助格式。
  6. 用户可以用关键词在帮助索引中搜索所要的帮助,当然也应该提供帮助主题词。
  7. 如果没有提供书面的帮助文档的话,最好有打印帮助的功能。
  8. 在帮助中应该提供我们的技术支持方式,一旦用户难以自己解决可以方便的寻求新的帮助方式。

4.合理性

屏幕对角线相交的位置是用户直视的地方,正上方四分之一处为易吸引用户注意力的位置,在放置窗体时要注意利用这两个位置。

合理性细则:

  1. 父窗体或主窗体的中心位置应该在对角线焦点附近。
  2. 子窗体位置应该在主窗体的左上角或正中。
  3. 多个子窗体弹出时应该依次向右下方偏移,以显示窗体出标题为宜。
  4. 重要的命令按钮与使用较频繁的按钮要放在界面上注目的位置。
  5. 错误使用容易引起界面退出或关闭的按钮不应该放在易点位置。横排开头或最后与竖排最后为易点位置。
  6. 与正在进行的操作无关的按钮应该加以屏蔽(Windows中用灰色显示,没法使用该按钮)。
  7. 对可能造成数据无法恢复的操作必须提供确认信息,给用户放弃选择的机会。
  8. 非法的输入或操作应有足够的提示说明。
  9. 对运行过程中出现问题而引起错误的地方要有提示,让用户明白错误出处,避免形成无限期的等待。
  10. 提示、警告、或错误说明应该清楚、明了、恰当。

用YSlow分析我们页面

这篇是来自aliued的文章,以前应试没有成功,但是还有很多不服,现在看到这篇文章,发现自己确实差太多了~

YSlow是yahoo美国开发的一个页面评分插件,非常的棒,从中我们可以看出我们页面上的很多不足,并且可以知道我们改怎么却改进和优化。

仔细研究了下YSlow跌评分规则。

主要有12条:

1. Make fewer HTTP requests 尽可能少的http请求。。我们有141个请求(其中15个JS请求,3个CSS请求,47个CSS background images请求),多的可怕。思考了下,为什么把这个三种请求过多列为对页面加载的重要不利因素呢,而过多的IMG请求并没有列为不利因素呢?

发现原来这些请求都是可以避免的。

15个JS和3个CSS完全可以通过特殊的办法进行合并(这个技术部已经帮我们解决了,实在是太感谢了,嘿嘿。),这样合并以后,一般情况下页面上只会出现一个JS和一个CSS(对JS的封装得有一定的要求)。

但是47个CSS background images请求改怎么解决呢?为什么页面上的纯IMG请求时合理的,而CSS background images请求过多就是不利因素了呢。这个我想了很久,总算明白,原来是这样的:

一般页面上的ICON,栏目背景啊,图片按钮啊,我们都会用图片CSS背景来实现,而一般这个图片CSS背景用到的图片都是比较小的,所以完全可以把这些图片合并成一个相对比较大的图片,这样页面上只会出现一个CSS background images请求,最多也就2-3个。后来仔细看了下雅虎美国的页面,他们的确也是这样做的,虽然这样做需要花一定的时间来有规则的合并这些ICON,栏目背景,图片按钮,以方便CSS调用,但是这样做绝对是合算的,而且是有必要的,YSlow也是极力推荐的。

2.Use a CDN 这项我们的评分是F级,最低。说实在的,我刚开始什么是CDN都不知道。后来查了GOODLE才知道。CDN的全称是Content Delivery Network,即内容分发网络。其目的是通过在现有的Internet中增加一层新的网络架构,将网站的内容发布到最接近用户的网络”边缘”,使用户可以就近取得所需的内容,解决Internet网络拥挤的状况,提高用户访问网站的响应速度。从技术上全面解决由于网络带宽小、用户访问量大、网点分布不均等原因所造成的用户访问网站响应速度慢的问题。

看来上述的解释后,基本上明白了CDN是怎么回事,后来咨询了下中文站点SA,得知我们网站目前的确还没有做CDN的优化,但是据说我们有更加先进的技术来解决类似的问题(具体什么技术那就保密了),但是毕竟CDN也是个相当不错的技术,所以在我们先进技术的基础上在做CDN优化,肯定比现在更好,嘿嘿。据说SA明年会做几个点的CND。

3. Add an Expires header置过期的HTTP Header.设置Expires Header可以将脚本, 样式表, 图片, Flash等缓存在浏览器的Cache中.

其实我们网站也做了这个优化,至少图片在这个上做过优化,但是没有做完全。我们的CSS和JS都还没有做过优化,倒是外部引入的一个广告JS做了,呵呵。其实设置过期的HTTP Header 更应该做在脚本, 样式表, Flash上.不过据说这个SA也是没有做的,但是有一定的风险,因为JS和CSS是有一定的逻辑,如果服务器端和客户端都存在缓存的话,万一出了什么问题,对我们以后查找问题的所在和增加难度,不过我想两者中是可以权衡和并存的。

4. Gzip components 对我们的页面内容进行Gzip格式的压缩,Gzip格式是一种很普遍的压缩技术,几乎所有的浏览器都有解压Gzip格式的能力,而且它可以压缩的比例非常大,一般压缩率为85%,就是说服务器端100K的页面可以压缩到25K左右的Gzip格式的数据发给客户端,客户端收到Gzip格式的数据后自动解压缩后显示页面。

这点我们网站基本上是100%做到了,但是我们这项的评分并没有达到想象中的A级,原因是出在我们的外部链接,比如我们首页,有外部的广告投放JS,这个JS说拥有的网站是没有做过GZIP优化,连累了我们网站,所以我们也只有B,或者C级。

5. Put CSS at the top 把CSS外部链接放到页面的顶部。

其实这个原则我们一般都遵守的,如果把CSS外部链接作为逻辑的一部分出现在页面头部以下,我个人觉得这个本身就是个错误。还好,我们的页面基本上都做到了,可是有些页面比如LIST页面,还是出现了和逻辑挂钩的CSS链接,原因是为了解决一些本来就不合理的产品逻辑。所以,我们WEB前端工程师有义务杜绝这些不合理的产品逻辑破坏我们的页面结果及页面加载速度,不能为了实现而实现。

6. Put JS at the bottom 把Javascript脚本尽量放到页面底部加载。

一开始为以为Javascript脚本尽量放到页面底部加载,是指所有的JS脚本都要放到底部,后来才发现,并不完全是这样,这里所指的脚本是指那些在加载过程中要执行的脚本,所以一般的处理办法还是页面头部引入JS链接,页面底部执行JS脚本程序。为什么要这么做呢?呵呵,其实很简单,为了实现最大的下载并行,页面加载初期做的事,最好只有下载,HTML的下载,CSS的下载,JS的下载,等下载完成后再去实现页面渲染,JS脚本运行。这个方面我们还需要努力,很多页面我们在加载过程中运行了一部分脚本,或许是为了实现一些功能,没有办法,不过或许有更好的办法来替代呢。。。

7. Avoid CSS expressions 避免CSS表达式

其实在CSS中运行表达式和页面加载中运行大量的JS脚本差不多,或许还更慢,而且还不兼容,虽然可以使我们在页面逻辑简单不少,但是我们完全可以抛弃之。这个点,我们的页面基本上都做到了。不过说实话,CSS表达式,嘿嘿,我以前还不知道有这么回事。惭愧。哈哈。

9. Reduce DNS lookups 尽可能少的DNS查找。

这项我们做的不是很好。D级,有9个域名,一般不要超过4个。不过这个主要是服务器架构上的问题,我们也无能为力,现在单单首页的广告域名就有好几个,好耶的广告域名,雅虎的广告域名,淘宝店广告域名,打点的域名。如果去掉这些,我们其实还是够用的,一个主域名,一个图片的,一个STYLE的,最多加上IFREAM的刚好4个。

10. Minify JS 对Javascript 代码进行压缩。

这点我很早以前就对此关注了,也找到了一个不错的压缩工具,yuicompressor,雅虎美国开发的JAVA压缩包yuicompressor.jar。压缩的相当完美,不仅把代码间的空格换行给去除掉了,而且对变量名,北部方法名都进行的简化,无意中实现了混淆脚本的作用。现在我们仅仅做到了JS合并,并没有对齐进行压缩,如果我用yuicompressor手工的去压缩,虽然实现了JS压缩,但是给我们自己的维护量增加了一倍,因为我们需要维护2套JS脚本,一套是压缩前的(调试用的),一套是压缩后(发布到网上的),而且要保证2套代码一致。所以最完美的做法是在发布的时候实现JS脚本合并,并对其用yuicompressor进行压缩,然后发布到晚上,把关键点移到发布的时候,这样我们只需要关心一套JS脚本(发布前的版本)。而且我觉得这个方案完全是行动通的。

11. Avoid redirects 避免重定向(跳转)

怎么理解这点呢?

我们经常遇到的一种做法,注册成功后,旺旺会有一个页面提示“你已经注册成功,3秒后将自动跳转到XX页面”。我就觉得很奇怪,你为什么不直接跳转到该去的页面?还有一种,我们大家非常熟悉,一般我们页面的链接都写成:http://china.alibaba.com或者http://china.alibaba.com/,有人会问,有区别吗?我明确的告诉大家,有!服务器如果接收到的URL是http://china.alibaba.com,它会自动重新定向到http://china.alibaba.com/,虽然最后都打开了阿里巴巴中文站的首页,但是前者比后者多走了一步,重定向,显然多多少少浪费了一定的时间。所以以后我们加URL链接的时候,别忘了把最后的“/”给加上去。

12. Remove duplicate scripts  去除重复的脚本

这个其实没有什么好说的,大家都应该毫无条件的去遵守,但是越是明显,越是简单的事,我们往往会做不好,当然,很多理由的,项目时间太紧张了等等,导致代码很乱,很多重复的地方。其实谁都知道重负不好,不过还好,我们的页面重复的脚本代码不多(至少一个页面里面,呵呵)。不过,我到是希望,我们不仅要做到一个页面脚本不重复,而且要做到N个页面,脚本要重用。

13.Configure ETags  这个好像是服务器端配置的问题,我不太懂,也就不乱说了,怕把大家给误导了。

总共13个,但是看了YAHOO的官方说明,好像还有一个AJAX CACHE(AJAX 缓存)。我倒是觉得这个很重要,随着我们AJAX应用的广泛,AJAX 缓存这个概念一定要时刻在我们脑子中,AJAX是个好东西,但是重复的数据,无休止的向后台申请,绝对是个错误(不仅是速度上还是对服务器压力上来说),所以我们就要对我们已经申请到的数据进行缓存,当第2次用到的时候,就直接从缓存中取,不要在去访问我们宝贵的服务器资源了。其实这个思想不仅仅适合AJAX,在所有有数据复用的应用中都应该考虑到。

YSLOW就分析到这里完毕了,或许有些地方分析的不是很正确,或许有人分析的比我更早,更好,但是这些的确是我从工作中去积累,发现的,并很多都实际应用到工作中去了,顺便说下,嘿嘿,LIST页面进行优化后,在0.92版本的YSLOW评分将达到76分,甚至80分,相当于0.8版本的90分以上。不过评分毕竟是评分,关键还是速度。

网页中英文混排行高不等问题

在口碑UED上看到解决方案:

基本上快被这个问题搞疯了,症状如下

症状描述:在ie下(6或7,8没有试过)当出现中英文混排,都采用默认字体时,并使用 li 列表做float时,会出现如上图的症状,文字排列上下不对齐的情况。影响了布局的美观性,造成上图情况的原因是中英文的文字基线不同,arial字体的下边缘要比宋体(同为12号)低一个象素,上边缘比宋体矮两个象素,而且英文还有i,y这种上下基线不同的情况。所以当中英文混排对齐时,就会出现明显的高度差异,使排版不均。可见放大图。

采用中英文字均使用宋体的方案

可以解决文字排列不对齐的情况,但宋体英文字是衬线字体(Times New Roman即是英文中的衬线字),字型紧凑,细节较多,排列在一起很醒目,但在连续成文时,容易造成辨识困绕,看错行的情况。关于衬线字体的优缺点,请见这篇文章。相比之下,表示英文还是使用无衬线字体更美观大方。

解决方法一 “饺子”童鞋的 发现。

英文采用tahoma字体–宋体,arial及 tahoma字体比较–arial与tahoma的无衬线体比较精致

当中英文混排时,使用tahoma字体的情形

中英混排,纯中文组合的行高都一致了,但a在hover状态下下划线与中文粘联在一起。

缺陷:使用tahoma字体时,在ie6及ie6以下版本,会导致所有中文字体链接的下划线会出现与字体粘连现象。淘宝使用的也是这一解决方案。相信大型项目,不同的人来共同完成一个页面的模块时,在统一的规范下,使字体更规范,减少错位,而采用带有下划线会出现与字体粘连的tahoma字体,是值得的

以下是携同大米童鞋 发现的

英文采用arial字体,中文使用宋体。可在<a>标签内注明 line-height:1.231,可解决行高不等以及字体与下划线粘连问题。(不知道大范围中英文混排适不适用,有待后续校验。)

总结:感谢大米,感谢饺子,感谢YUI,感谢淘宝!