標簽歸檔: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。壓縮的相當完美,不僅把代碼間的空格換行給去除掉了,而且對變量名,北部方法名都進行的簡化,無意中實現了混淆腳本的作用?,F在我們僅僅做到了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這種上下基線不同的情況。所以當中英文混排對齊時,就會出現明顯的高度差異,使排版不均??梢姺糯髨D。

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

可以解決文字排列不對齊的情況,但宋體英文字是襯線字體(Times New Roman即是英文中的襯線字),字型緊湊,細節較多,排列在一起很醒目,但在連續成文時,容易造成辨識困繞,看錯行的情況。關于襯線字體的優缺點,請見這篇文章。相比之下,表示英文還是使用無襯線字體更美觀大方。

解決方法一 “餃子”童鞋的 發現。

英文采用tahoma字體–宋體,arial及 tahoma字體比較–arial與tahoma的無襯線體比較精致

當中英文混排時,使用tahoma字體的情形

中英混排,純中文組合的行高都一致了,但a在hover狀態下下劃線與中文粘聯在一起。

缺陷:使用tahoma字體時,在ie6及ie6以下版本,會導致所有中文字體鏈接的下劃線會出現與字體粘連現象。淘寶使用的也是這一解決方案。相信大型項目,不同的人來共同完成一個頁面的模塊時,在統一的規范下,使字體更規范,減少錯位,而采用帶有下劃線會出現與字體粘連的tahoma字體,是值得的

以下是攜同大米童鞋 發現的

英文采用arial字體,中文使用宋體??稍?lt;a>標簽內注明 line-height:1.231,可解決行高不等以及字體與下劃線粘連問題。(不知道大范圍中英文混排適不適用,有待后續校驗。)

總結:感謝大米,感謝餃子,感謝YUI,感謝淘寶!