根據 ValleyWag 內線消息指出，一位自稱為蘋果員工的朋友表示，蘋果目前正在認真地跟 Twitter 討論關於收購方面的話題，而且此次收購的價碼，將會上看七億美金（比起先前 Twitter 婉拒 FaceBook 的價碼還要高上一檔），而如果雙方談得來的話，甚至可能會在六月就正式對外公佈。至於這件消息的真實性，現在當然還是霧裡看花的狀態，不過回頭想想，蘋果真的有吃下 Twitter 的必要嗎？雖然七億對於蘋果傳言中的 300 億現金來說，不過是個位數，但是目前連 Twitter 自己對於要怎樣利用其廣大的社群來獲利，似乎都還在摸索階段，蘋果總不能真的這樣亂花錢吧？到時候要是投資人反撲就不妙囉！不知道各位讀者怎樣看待這則消息呢？
[出自 TechRadar UK]
文章來自engadget
文章提供BAYSTARS DESIGN網頁設計公司
2009年5月7日 星期四
鄉民正式在 iPhone / iPod touch 上插旗！Nally Touch 推出！
Nally 降臨 iPhone / iPod touch 了！眾鄉民手上如果握有 iPhone / iPod touch，又想要時時刻刻上 B，那 Nally Touch 應該是唯一點五的選擇了吧！（先前的 TouchTerm...默）
Nally Touch 除了可以順利上 BBS 之外，連線的速度聽說也不差，同時對中文的支援可以說是完全不跳針（因為是台灣人開發的！）；至於 Po 文、推文等操作，目前看來也沒有啥大問題，同時也可以透過旁邊的小放大鏡放大文字（不支援雙指縮放），另外輸入也支援注音輸入，可以說是相當便利。
下載這東東需要花上 4.99 美元，有沒有這個價值，就看各位朋友對於 BBS 的依賴程度囉！
[文章出自 PTT]
文章提供 BAYSTARS DESIGN網頁設計公司
2009年5月6日 星期三
不要使用@import
在網頁設計的@import 對於網站的性能有某些負面的影響，然後在 Web 2.0 Expo 的演講上深入探討了這個問題，並創建了一些測試頁面和HTTP瀑布狀圖表，這些在下面將會用到。對於這個問題的底線是：如果你想樣式表並行載入，以使頁面更快，請使用LINK 替代@import。LINK vs. @import大家都知道，有兩種方法可以在你的頁面中導入樣式文件。你可以使用LINK標籤：
程序代碼
或者使用@import 方法：
程序代碼
更喜歡使用LINK，因為它比較簡單——而如果使用@import的話，你必須時刻記得要將@import放到樣式代碼的最前面，否則它將會不起作用。而且事實證明，避免使用@import 同樣對網站性能有益。@import @import將探究LINK和@import兩種方式的不同。在這些例子中，有兩個樣式表：a.css和b.css。每個樣式表都配置為需要花費兩秒鐘來下載，這樣就比較容易的看出來它們對網站性能的影響。第一個例子使用@import 導入兩個樣式文件。這個例子，我們稱之為@import @import，HTML代碼可以寫成這個樣子：
程序代碼
如果你一直這種方式使用@import，那麼就沒有什麼性能問題，儘管這可能會因為競態條件而可能引起JavaScript錯誤。兩個樣式文件將同時並行下載，就像在圖一中顯示的那樣(第一個小的請求是HTML該文件) 。問題出現在當@import嵌套入其它樣式中或者和LINK聯合使用的時候。圖一、一直使用@import 是可以的LINK @import這個LINK @import的例子使用LINK加載a.css，使用@import導入b.css：
程序代碼
在IE中(在6, 7, 和8中測試過)，這會導致樣式表文件逐個加載，正如圖二所示。並行下載資源是加速頁面的一個關鍵。就像圖示的那樣，這種方法在IE中會導致頁面需要更多的時間才能加載完成。圖二、在IE中link混合@import 會破壞並行下載 LINK嵌套@import在這個LINK 嵌套@import 例子中，a.css 通過LINK插入到頁面中，然後a.css 通過@import規則來引入b.css：HTML代碼：
程序代碼
在a.css中：
程序代碼
@import url('b.css');這種方式同樣阻止並行加載代碼，但是這次是對於所有的瀏覽器。其實這個應該不會讓我們感到奇怪吧，簡單的想一下就能理解了。瀏覽器必須下載a.css先，並分析它，這個時候，瀏覽器發現了@import 規則，然後才會開始加載b.css。圖三、在在一個通過LINK加載的的樣式文件中使用@import將會在所有的瀏覽器裡面打破並行下載。LINK 阻斷 @import上面的例子做一個細微的變化，IE中會引起驚人的結果：使用LINK導入a.css 和一個新的樣式文件proxy.css。proxy.css沒有添加額外的樣式，它只是用來通過@import 規則導入b.css。HTML代碼如下：
程序代碼
proxy.css的代碼：
程序代碼
@import url('b.css'); 這個例子在IE中運行的結果，LINK 阻斷@import，在圖四中顯示。第一個請求是HTML文檔。第二個請求是a.css (花了兩秒鐘)，第三個(很小) 的請求是proxy.css。第四個請求是b.css (也花費了兩秒鐘)。令人震驚的是，在下載a.css完成之前，IE不會開始下載b.css。但是在其它所有的瀏覽器中，這種情況不會發生，結果頁面顯示的也比較快。如下圖五所示。圖四、IE中，LINK 阻斷使用@import嵌入的其它樣式文件。圖五、在非IE瀏覽器中，LINK不會阻斷@import 嵌入樣式表。多個@imports這個使用多個@imports的例子展示在IE中使用@import會引起資源被按照一個不同於預期的順序下載。這個例子有6個樣式表(每個將花兩秒鐘的下載時間)以及後面跟著一個js腳本文件(需要四苗種下載)。
程序代碼
看一下圖六，最長的條條是耗時四秒鐘的腳本。儘管它在代碼裡面被列在最後，但是在IE中，它被首先下載。如果腳本中包含的代碼以來從樣式表文件中應用的樣式(比如getElementsByClassName)， 那麼就將可能會發生意外的結果，因為腳本先於樣式被加載，儘管開發人員將其置於代碼的最後面。圖六、@import在IE中引發資源文件的下載順序被打亂LINK LINK使用LINK來引入樣式更簡單和安全： 使用LINK 可確保樣式在所有瀏覽器裡面都能被並行下載。這個LINK LINK的例子演示了這一點，就像在圖七中顯示的那樣。使用LINK 同樣能保證資源按照開發人員制定的順序下載。圖七、使用LINK確保在所有的瀏覽器裡面都能並行下載這些問題都需要考慮到IE。它非常不好的地方是，資源文件可能會在個別地方結束下載，所有瀏覽器在下載樣式文件的時候應該執行一些前瞻以導入所有的@import規則並立即下載它們（通過@import導入的樣式）。知道所有的瀏覽器都變成這種方式，我都會推薦避免使用@import並一直使用LINK 來插入樣式。更多測試根據讀者的反饋，原作者增加了兩項測試：使用@imports的LINK 和多個LINKs，每個例子都插入4個樣式文件到HTML文件中。使用@imports的LINK 使用LINK 加載proxy.css，然後proxy.css 使用@import 加載4個樣式文件。多個LINKs的例子，在HTML文件中有4個LINK 標籤來引入4個樣式文件(這正是我推薦的方法)。這兩個HTTP 瀑布圖如圖八和圖九所示：圖八、使用@imports的LINK圖九、多個LINK看一下使用 @imports的LINK 的演示 ， 第一個問題是在proxy.css加載完成之前這四個樣式文件不會開始下載，這在所有的瀏覽器裡面一樣。另一方面，多個LINK的顏色立即同時下載這些樣式文件。第二個問題是IE改變下載順序。我在頁面的代碼的最底部添加了一個10秒的腳本（圖中最長的條條）。在所有的非IE瀏覽器中，@import樣式文件(proxy.css文件中引入) 首先下載，然後才是腳本文件，嚴格的按照指定的順序。然而，在IE中，腳本卻先於@import 樣式被插入，正如例子使用@imports的LINK 在圖八中顯示的那樣。這會導致樣式文件花費更多的時間來下載，因為，在IE6和IE7中，它們還要等到長腳本用光僅有的兩個可用連接中的一個。然而在樣式文件沒有下載完之前，IE不會在頁面中渲染任何內容，以這種方式來使用@import會引起頁面保持空白長達12秒鐘。使用LINK 替代@import 可以保持加載順序，正如圖九中顯示的 多個LINK 那樣。這樣的話，頁面渲染只需要四秒鐘。頁面資源的加載時間被誇張的用來簡單的查看發生了什麼事情。但是對於那些使用窄帶或網速比較慢的用戶來說，特別是那些新興的市場，這些響應時間可能有些遠離實際。在一個樣式文件中使用@import會為頁面總體加載時間增加更多一個返程（也就是增加頁面的總體加載時間）在IE中使用@import 將會引起文件的下載順序被改變。這更會引起樣式文件花費更長的時間來下載，這會阻礙頁面的渲染，讓人感到頁面比較慢。
文章來自WOWBOX
文章提供BAYSTARS DESIGN網頁設計公司
程序代碼
或者使用@import 方法：
程序代碼
更喜歡使用LINK，因為它比較簡單——而如果使用@import的話，你必須時刻記得要將@import放到樣式代碼的最前面，否則它將會不起作用。而且事實證明，避免使用@import 同樣對網站性能有益。@import @import將探究LINK和@import兩種方式的不同。在這些例子中，有兩個樣式表：a.css和b.css。每個樣式表都配置為需要花費兩秒鐘來下載，這樣就比較容易的看出來它們對網站性能的影響。第一個例子使用@import 導入兩個樣式文件。這個例子，我們稱之為@import @import，HTML代碼可以寫成這個樣子：
程序代碼
如果你一直這種方式使用@import，那麼就沒有什麼性能問題，儘管這可能會因為競態條件而可能引起JavaScript錯誤。兩個樣式文件將同時並行下載，就像在圖一中顯示的那樣(第一個小的請求是HTML該文件) 。問題出現在當@import嵌套入其它樣式中或者和LINK聯合使用的時候。圖一、一直使用@import 是可以的LINK @import這個LINK @import的例子使用LINK加載a.css，使用@import導入b.css：
程序代碼
在IE中(在6, 7, 和8中測試過)，這會導致樣式表文件逐個加載，正如圖二所示。並行下載資源是加速頁面的一個關鍵。就像圖示的那樣，這種方法在IE中會導致頁面需要更多的時間才能加載完成。圖二、在IE中link混合@import 會破壞並行下載 LINK嵌套@import在這個LINK 嵌套@import 例子中，a.css 通過LINK插入到頁面中，然後a.css 通過@import規則來引入b.css：HTML代碼：
程序代碼
在a.css中：
程序代碼
@import url('b.css');這種方式同樣阻止並行加載代碼，但是這次是對於所有的瀏覽器。其實這個應該不會讓我們感到奇怪吧，簡單的想一下就能理解了。瀏覽器必須下載a.css先，並分析它，這個時候，瀏覽器發現了@import 規則，然後才會開始加載b.css。圖三、在在一個通過LINK加載的的樣式文件中使用@import將會在所有的瀏覽器裡面打破並行下載。LINK 阻斷 @import上面的例子做一個細微的變化，IE中會引起驚人的結果：使用LINK導入a.css 和一個新的樣式文件proxy.css。proxy.css沒有添加額外的樣式，它只是用來通過@import 規則導入b.css。HTML代碼如下：
程序代碼
proxy.css的代碼：
程序代碼
@import url('b.css'); 這個例子在IE中運行的結果，LINK 阻斷@import，在圖四中顯示。第一個請求是HTML文檔。第二個請求是a.css (花了兩秒鐘)，第三個(很小) 的請求是proxy.css。第四個請求是b.css (也花費了兩秒鐘)。令人震驚的是，在下載a.css完成之前，IE不會開始下載b.css。但是在其它所有的瀏覽器中，這種情況不會發生，結果頁面顯示的也比較快。如下圖五所示。圖四、IE中，LINK 阻斷使用@import嵌入的其它樣式文件。圖五、在非IE瀏覽器中，LINK不會阻斷@import 嵌入樣式表。多個@imports這個使用多個@imports的例子展示在IE中使用@import會引起資源被按照一個不同於預期的順序下載。這個例子有6個樣式表(每個將花兩秒鐘的下載時間)以及後面跟著一個js腳本文件(需要四苗種下載)。
程序代碼
看一下圖六，最長的條條是耗時四秒鐘的腳本。儘管它在代碼裡面被列在最後，但是在IE中，它被首先下載。如果腳本中包含的代碼以來從樣式表文件中應用的樣式(比如getElementsByClassName)， 那麼就將可能會發生意外的結果，因為腳本先於樣式被加載，儘管開發人員將其置於代碼的最後面。圖六、@import在IE中引發資源文件的下載順序被打亂LINK LINK使用LINK來引入樣式更簡單和安全： 使用LINK 可確保樣式在所有瀏覽器裡面都能被並行下載。這個LINK LINK的例子演示了這一點，就像在圖七中顯示的那樣。使用LINK 同樣能保證資源按照開發人員制定的順序下載。圖七、使用LINK確保在所有的瀏覽器裡面都能並行下載這些問題都需要考慮到IE。它非常不好的地方是，資源文件可能會在個別地方結束下載，所有瀏覽器在下載樣式文件的時候應該執行一些前瞻以導入所有的@import規則並立即下載它們（通過@import導入的樣式）。知道所有的瀏覽器都變成這種方式，我都會推薦避免使用@import並一直使用LINK 來插入樣式。更多測試根據讀者的反饋，原作者增加了兩項測試：使用@imports的LINK 和多個LINKs，每個例子都插入4個樣式文件到HTML文件中。使用@imports的LINK 使用LINK 加載proxy.css，然後proxy.css 使用@import 加載4個樣式文件。多個LINKs的例子，在HTML文件中有4個LINK 標籤來引入4個樣式文件(這正是我推薦的方法)。這兩個HTTP 瀑布圖如圖八和圖九所示：圖八、使用@imports的LINK圖九、多個LINK看一下使用 @imports的LINK 的演示 ， 第一個問題是在proxy.css加載完成之前這四個樣式文件不會開始下載，這在所有的瀏覽器裡面一樣。另一方面，多個LINK的顏色立即同時下載這些樣式文件。第二個問題是IE改變下載順序。我在頁面的代碼的最底部添加了一個10秒的腳本（圖中最長的條條）。在所有的非IE瀏覽器中，@import樣式文件(proxy.css文件中引入) 首先下載，然後才是腳本文件，嚴格的按照指定的順序。然而，在IE中，腳本卻先於@import 樣式被插入，正如例子使用@imports的LINK 在圖八中顯示的那樣。這會導致樣式文件花費更多的時間來下載，因為，在IE6和IE7中，它們還要等到長腳本用光僅有的兩個可用連接中的一個。然而在樣式文件沒有下載完之前，IE不會在頁面中渲染任何內容，以這種方式來使用@import會引起頁面保持空白長達12秒鐘。使用LINK 替代@import 可以保持加載順序，正如圖九中顯示的 多個LINK 那樣。這樣的話，頁面渲染只需要四秒鐘。頁面資源的加載時間被誇張的用來簡單的查看發生了什麼事情。但是對於那些使用窄帶或網速比較慢的用戶來說，特別是那些新興的市場，這些響應時間可能有些遠離實際。在一個樣式文件中使用@import會為頁面總體加載時間增加更多一個返程（也就是增加頁面的總體加載時間）在IE中使用@import 將會引起文件的下載順序被改變。這更會引起樣式文件花費更長的時間來下載，這會阻礙頁面的渲染，讓人感到頁面比較慢。
文章來自WOWBOX
文章提供BAYSTARS DESIGN網頁設計公司
2009年5月5日 星期二
搜尋引擎最佳化行銷
搜尋引擎最佳化行銷
為什麼進行搜尋引擎行銷最佳化行銷?
搜尋引擎目前是成本最低，最有效的網路推廣手段，超過85%的網民通過搜尋引擎尋找信息，制定一個良好的搜尋引擎策略甚至比好的搜尋引擎優化技術更加重要。沒有一個好的策略，搜尋引擎優化進行的再好效果也會大打折扣，所以一個好的搜尋引擎策略是企業進行搜尋引擎行銷的重要基礎。
什麼是搜尋引擎行銷？
搜尋引擎行銷就是通過幫助您分析整個網站的主題，營運模式以及網站內容為您量身訂做符合你網站情況的一套關鍵 字。包括核心關鍵字，地域關鍵字，客戶搜尋習慣關鍵字以及圍繞核心關鍵字的相關長尾關鍵字。
優化一整套關鍵字，在搜尋引擎上取得較好的表現，讓用戶從各個方面，各個角度都能夠找到網站。讓網站整體排名已經整體流量得到提升。
搜尋引擎行銷策略服務內容包括什麼？
搜尋引擎行銷策略服務項目包括：企業網站搜尋引擎行銷關鍵字策略分析、搜尋引擎優化實施顧問、搜尋引擎廣告策略與管理、搜尋引擎行銷效果監測與評估等項目
搜尋引擎行銷的重要性
為什麼我們這麼大的網站，在搜尋引擎上卻找不到?
為什麼進行搜尋引擎行銷最佳化行銷?
搜尋引擎目前是成本最低，最有效的網路推廣手段，超過85%的網民通過搜尋引擎尋找信息，制定一個良好的搜尋引擎策略甚至比好的搜尋引擎優化技術更加重要。沒有一個好的策略，搜尋引擎優化進行的再好效果也會大打折扣，所以一個好的搜尋引擎策略是企業進行搜尋引擎行銷的重要基礎。
什麼是搜尋引擎行銷？
搜尋引擎行銷就是通過幫助您分析整個網站的主題，營運模式以及網站內容為您量身訂做符合你網站情況的一套關鍵 字。包括核心關鍵字，地域關鍵字，客戶搜尋習慣關鍵字以及圍繞核心關鍵字的相關長尾關鍵字。
優化一整套關鍵字，在搜尋引擎上取得較好的表現，讓用戶從各個方面，各個角度都能夠找到網站。讓網站整體排名已經整體流量得到提升。
搜尋引擎行銷策略服務內容包括什麼？
搜尋引擎行銷策略服務項目包括：企業網站搜尋引擎行銷關鍵字策略分析、搜尋引擎優化實施顧問、搜尋引擎廣告策略與管理、搜尋引擎行銷效果監測與評估等項目
搜尋引擎行銷的重要性
為什麼我們這麼大的網站，在搜尋引擎上卻找不到?
為什麼我們網站這麼便宜的產品，在搜尋引擎上也找不到?
為什麼我們公司這麼漂亮的網站，在搜尋引擎上還是找不到?
其實搜尋引擎檢索網站和網站的大小、漂亮美醜、產品的價格完全沒有關係。您需要的是一套有效的搜尋引擎行銷方法。
推廣臺灣多年來專研於企業網站的規劃和建製以及搜尋引擎的發展，我們認為企業網站在搜尋引擎上的能見度（search engine visibility）要比網頁設計得驚世駭俗或炫麗奪目來得重要許多，因為再好再美的網站，若沒有辦法讓人順利找到，頂多也只能關起門來自己欣賞。搜尋引擎行銷即是爭取網站在搜尋引擎上重要關鍵字的排名，也是推廣臺灣所專職專業的服務項目之一。
對於搜尋引擎行銷，我們不僅秉持著專業領先的觀念，並且累積了許多豐富的知識與寶貴的經驗。我們的做法並不是以保證名列前茅等誇大的宣傳來贏取客戶，而是以務實的態度和專業的能力來獲得信任。
目前網路上有許多不同的行銷方法，各種方法都有其優劣利弊與適用性，當然搜尋引擎行銷也不例外。與幾個主要的網路行銷方式比較上，我們可以由下表瞭解一些搜尋引擎行銷的差異和適用方向。
我們專業的搜尋引擎行銷服務包括:
* 網站架構體檢
* 分析及定義重要關鍵字
* 網頁結構檢視與修正
* 網頁文案編輯與調整
* 連結聲望（link popularity）規劃與執行
* 網站登錄規劃與執行
* 關鍵字標購策略規劃與執行
* 搜尋引擎監控報表
tab(標籤)在使用時的禁忌
總結者：戴雨森 yusendai.com
我們小組討論的話題是tab（標籤）在使用時的禁忌。
在討論的開始，大家很快產生了六個感興趣的話題：
如何處理海量的tab？
在流覽器中關掉tab之後應該發生的行為？
不同tab下內容的相互關係
多層tab的使用
Tab和SEO的關係
使用多個tab工作時快速回到注意力的焦點
由於時間有限，我們討論的話題最終集中在一個點上：如何處理海量的tab？經過大家的熱烈討論，現在將一些想法以及對應的示例總結如下，還請各路英雄好漢指正。
首先回顧一下Tab的歷史。這裡的tab，是一類交互元素的統稱，既包括在web設計中的導航，也包括在流覽器等桌面軟體中的使用。被稱為tab的交互元素一般有如下兩個特性：
同時具有動作和狀態兩個含義。tab之所以流行，一個原因就是因為它既方便操作，同時又能夠讓用戶清楚地知道自己目前在哪個位置（tab）
從資訊架構的角度來看，tab之間的內容一般是不交叉的。並且tab之間的關係應該是平等的，沒有相互隸屬的關係。
所以從廣義來講，絕大多數導航功能表其實都可以歸結為tab。
在網頁設計中tab的使用一般認為是Amazon開了先河。相信大家很多人都讀過LukeW的經典回顧文章：The History of Amazon’s Tab Navigation（中文版請猛擊這裡）。從這篇文章中我們可以看到，Amazon的導航從最初只有兩個tab：Book和Music，演化到2000年最多的時候有兩排tab。很顯然，當tab數量增多的時候，tab這種對話模式遇到了一些困難。
另一個例子是Word 2003中的設置對話方塊。如下圖所示，當標籤太多而顯示空間有限的時候，微軟不得不同樣把標籤排成兩排。這樣做的一個大問題是，上排的標籤在選中的時候，如何表示選中狀態和當前內容頁的關係？
微軟的做法是飽受詬病的。在上圖中當用戶點擊上排標籤時，上排自動和下排對調從而保持標籤和內容頁的緊貼關係。然而這個做法使得標籤的位置非常不一致，相信很多人都有著同樣的迷茫經歷。
在其他一些軟體中，如firefox 3（如下圖），點擊上排標籤時，僅僅將標籤顯示變為選中狀態，這樣的好處是保持了標籤位置的一致性，然而卻失去了一些位置上的指示功能。
那麼如果多排標籤不是個好主意，如何處理很多的標籤呢？
一個顯然的思路是把標籤從慣用的水準排列換到豎直排列。一般這樣的排列是在視圖的左側，可能是以圖示或者文字的形式。
不過這種做法存在一些問題。首先，如果標籤的名字很長，將會佔據很多寶貴的左側空間，而這一空間正好是螢幕上使用者注意焦點，兵家必爭之地。有的網站的做法是將文字垂直擺放，這樣的做法，特別對於英文網站來說，可讀性簡直就是災難。如果放在右側，有可能和捲軸相互干涉，並且用戶也不容易注意到。其次，當標籤不多的時候（考慮標籤數目可變的情況），標籤下方放什麼內容也是比較頭疼的。
（左）一個設計網站的縱向標籤排列，可讀性很差。（右）雅虎易搜裡面採用的右側垂直標籤導航
另一個思路是，如果標籤之間存在著某種結構，那麼可以把標籤分組。然後增加一個導航級別。微軟的onenote在這方面做到了登峰造極的程度，將資訊分為Notebook, section, page三個層次，每個層次都用標籤導航來表示，結果就是在頁面的上方，左側和右側都佈滿了標籤……微軟功力不俗，用格式塔（左側的分割）、色彩標記（section的彩色和page的白色）等手法把三層標籤導航都處理得很好。
另一種分組的方式是直接呈現在標籤上。考慮windows工作列的默認分組方法，將同一個程式的不同視窗歸為一組。或者是IE8中，將來源於同一父網站的標籤用相同的顏色歸為一組。
如果標籤之間不存在重要程度的區別，也不存在顯然的結構呢？比如流覽器的標籤？不同的流覽器有不同的做法。firefox和IE的預設做法是只顯示一行標籤，設定標籤的最短長度，然後在兩端加入向左/向右的箭頭，同時還在標籤欄左側或者右側加入顯示全部標籤按鈕。Safari 4只在最右側加入一個”…”的”顯示全部標籤”按鈕。而Chrome做的比較奇怪，沒有最短標籤長度這一設置，也不管三七二十一將所有標籤都顯示在一行裡面
總結流覽器的做法，可以看出還是以對標籤欄的橫向操作為主。舉個手持設備的例子。facebook的iPhone App中，對於不同的feed是將其顯示在一個”window”中，手指滑動可以拖動feed條在window下移動（語言很難描述清楚，看圖）。另一個對標籤條橫向操作例子是蘋果的 Mac頁面 ，在這裡蘋果使用了交互設計模式中的”注釋捲軸”模式，將捲軸加上了標籤的功能，這同時也是標籤分組的使用。
總結以上討論：
1. 在靜態頁面設計中，儘量避免使用多排水平標籤的佈置。可以使用垂直標籤代替。
2. 如果標籤之間存在結構，可以將標籤分組。分組可以以下拉式功能表，顏色分組等多種方式進行。
3. 如果標籤重要性或相關性存在區別，可以顯示最重要的標籤，然後加入”更多”（全部）按鈕。
4. 如果標籤之間都是相互平等的，可以考慮對標籤欄進行操作，如加入左右移動按鈕，允許使用者拖動/滑動等。
2009年5月4日 星期一
設計良好的網頁四大原則
英文原文：http://www.myinkblog.com/2009/03/21/4-principles-of-good-design-for-websites/
我最喜歡的設計書籍之一就是《Robin Williams Design Workshop》.它深入實際的設計理論，並且包含許多極棒的設計實例。其中一個值得關注的地方就是4項主要的設計原則，它們已經在設計中為我所用。這4項原則就是：反差, 重複, 排列, 和分類。
本文將討論這4項與網頁設計相關的原則。只要在腦海中牢牢記住了這4項原則，你就一定可以設計出更加整潔漂亮的網頁。
1.反差效果
好的反差效果設計可以給用戶一個極好的第一印象。如果用戶的眼睛沒有焦點，注意力就會在處處是相同尺寸的元素和排版介面中迷失。設計師需要設計出很明顯的突出視覺元素來引導使用者的體驗。你可以通過選擇圖片、顏色和字體等來形成良好的反差效果。
圖片反差
當需要在很多小元素後面展示一個大尺寸的插圖時，這種方法很有效。嗯，我的意思就是，比如：
The Invoice Machine
這個網頁利用一張大圖片來吸引使用者的注意。而同時網頁很自然的單色又讓很少的藍色應用有了更好的效果。
Instabox
當你眼睛看到這個頁面的時候，首先你會注意到什麼？最有可能的就是盒子上面的那個星星了。跟 The Invoice Machine 一樣，它們都是通過用一張大圖片和很少的顏色來製造一個視覺焦點。
文章來自BAYSTARS DESIGN網頁設計公司
我最喜歡的設計書籍之一就是《Robin Williams Design Workshop》.它深入實際的設計理論，並且包含許多極棒的設計實例。其中一個值得關注的地方就是4項主要的設計原則，它們已經在設計中為我所用。這4項原則就是：反差, 重複, 排列, 和分類。
本文將討論這4項與網頁設計相關的原則。只要在腦海中牢牢記住了這4項原則，你就一定可以設計出更加整潔漂亮的網頁。
1.反差效果
好的反差效果設計可以給用戶一個極好的第一印象。如果用戶的眼睛沒有焦點，注意力就會在處處是相同尺寸的元素和排版介面中迷失。設計師需要設計出很明顯的突出視覺元素來引導使用者的體驗。你可以通過選擇圖片、顏色和字體等來形成良好的反差效果。
圖片反差
當需要在很多小元素後面展示一個大尺寸的插圖時，這種方法很有效。嗯，我的意思就是，比如：
The Invoice Machine
這個網頁利用一張大圖片來吸引使用者的注意。而同時網頁很自然的單色又讓很少的藍色應用有了更好的效果。
Instabox
當你眼睛看到這個頁面的時候，首先你會注意到什麼？最有可能的就是盒子上面的那個星星了。跟 The Invoice Machine 一樣，它們都是通過用一張大圖片和很少的顏色來製造一個視覺焦點。
文章來自BAYSTARS DESIGN網頁設計公司
當網頁設計師遇上前端開發
作為網頁設計師，在和前端開發人員溝通時你是否常常會聽到這樣的聲音：
—— “大姐，給點專業精神好不好，這個表格是自我調整的，你這樣設計頁面不好擴展啊…”
——“用ajax不是不行，不過你要事前給我說嘛，你不說我怎麼知道呢，你說了我就知道了嘛…”
面對這些回答，除了欲哭無淚，你有沒有想過是什麼原因導致出現這樣溝通偏差，有沒有解決的辦法呢？設計師需要瞭解哪些知識才能和前端開發人員來更好的合作呢？ 首先得從這兩者之間都有哪些不同說起。
我認為最主要原因在於設計師和前端開發在部門中不同的職責劃分。
通常情況下，產品設計師的產出物多是線框圖（wireframe),視覺設計稿（mockup）等，前端負責編寫HTML,CSS等代碼（demo），有時還會根據需要編寫程式碼（如 JSP/ASP/PHP/Rails),光看這些分工，就知道不同的角色對產品的理解和著重點是截然不同的。按照正常的專案流程，設計團隊通常需要先設計出介面mockup或demo（HTML/CSS),接著開發人員才開始正式編寫代碼。
然而多數情況下為了保證專案進度，需要開發人員和設計師在專案前期就介入進來，不同的是，開發人員多是審核通過項目計畫書（PRD）和原型評審，她們更關注於技術可實現性；而設計師更傾向理解產品經理的專案需求以及通過什麼樣方式來解決需求從而達到提升使用者體驗的目的，她們更關注創意的可行性。
更令人糾結的是前端開發對“介面元素”和“交互動作”的理解和設計師有很大不同。統一的介面元素對網站的前端架構也會很有好處，他們更關注代碼的再使用性。 一方面是CSS：前端開發要實現設計師（或者自己引以為自豪）的介面設計，如果新頁面的設計和原先頁面中相同功能元素的設計有出入，哪怕是一點出入，都有可能帶來很多重複的工作，將CSS文件變得越來越臃腫。
另一方面是JavaScript：對於很多應用型網站，會有很多需要JavaScript的頁面交互元素。這些交互元素的視覺或者行為設計與之前的有出入，也會讓前端工程師為了既保證代碼的健壯性來方便後端工程師的開發，又為了實現一些設計上的差別而對現有代碼修修補補忙得不可開交，最可怕的是最終淹沒于bug的海洋…而交互設計師的側重點並不在程式的編碼實現，而注重於使用者如何最好地與系統交交互操作，在設計中重點需要考慮的是介面元素的易用性：比如他們會考慮到並非每個使用者都是電腦的熟練使用者，面對隱藏的層和特殊設計的功能表可能會抓瞎，使用者不見得能明白按兩下左鍵能自動滾屏或者怎樣能讓自動滾屏停下來，直接看最下面的結果？
總之，設計師（完美主義者更甚）會不斷完善產品，來滿足更好的用戶體驗。那麼設計師怎樣來解決這些問題呢？我覺得最重要的就是“溝通”，這是最根本的解決辦法。在原型設計前期就要針對自己想法的詢問前端開發在技術上的可行性，在介面設計過程中會有很多精確到圖元級的標準，同樣要和他們溝通瞭解代碼的實現方式，不然很有可能做無用功。在提交介面設計之後，交互設計師也要主動出擊，不定時的去關注demo的實現效果（mockup和demo多多少少存在不一致，在後期需要跟進；另外涉及到複雜的對話模式前端很可能會忘記或者搞混，也需要不斷的去核查）。
另外建立標準的文檔管理和設計規範也很重要，好在我們開始建立設計規範和標準(淘斯基和TPL 模式庫）的文檔管理方法（SVN)，包括：
• 制定檔命名標準
• 設定檔統一路徑
• 保存原始創作檔（例如PSD、Fla原始檔案）
• 最終完成檔（經過產品經理認可的檔）
• 視覺模式庫和與其對應的代碼模式庫
當然，前端都很忙的，經常去“騷擾”他們會被鄙視的。跟他們溝通也需要技巧和一些基礎認識，我總結了以下幾點需要謹記：
1. 網站的頁面是動態的。 photoshop呈現的是靜態的東西，而網站頁面是動態的展現內容、佈局和交互。設計師過多關注用戶體驗層面，很難對所有的細節做到面面俱到。而前端（包括開發）需要照顧到所有的功能點涉及到的頁面，因此在前期要考慮的儘量周全，別讓別人幫我們收拾爛攤子。
2. 關注新技術。網頁設計缺少技術支援永遠只是藝術。設計師必須經常關注新的技術和對話模式，這樣才能在設計的時候提供多種解決方案，才能權衡利弊找到最優化的方案。
3. 介面元素的標準化和統一。前端關注代碼的再使用性，設計師關注新創意。因此在設計前期就要考慮哪些元素和對話模式既可以滿足用戶體驗又能夠被重複使用，以此來提高效率。
4. 團隊合作很重要。設計師很容易沉浸在自己的小世界裡不能自拔，這是我們經常犯的通病。“溝通”是團隊合作的關鍵，一切皆在溝通。
5. 相信自己。前端通常出於不同的原因對一些對話模式可行性做出判斷，比如代碼複雜程度，技術可實現性等等。
好的設計師需要有一些超前意識和冒險精神，當他們受 新技術的激發，認為它能夠大大提升用戶體驗的時候，就需要把它當作挑戰來實現。在對技術的深入瞭解後去說服前端一起努力實現。 好了，這些血和淚的經驗是我工作一段時間慢慢總結的，如果你有更多的方法，希望能一起分享。
文章來自BAYSTARS DESIGN網頁設計公司
—— “大姐，給點專業精神好不好，這個表格是自我調整的，你這樣設計頁面不好擴展啊…”
——“用ajax不是不行，不過你要事前給我說嘛，你不說我怎麼知道呢，你說了我就知道了嘛…”
面對這些回答，除了欲哭無淚，你有沒有想過是什麼原因導致出現這樣溝通偏差，有沒有解決的辦法呢？設計師需要瞭解哪些知識才能和前端開發人員來更好的合作呢？ 首先得從這兩者之間都有哪些不同說起。
我認為最主要原因在於設計師和前端開發在部門中不同的職責劃分。
通常情況下，產品設計師的產出物多是線框圖（wireframe),視覺設計稿（mockup）等，前端負責編寫HTML,CSS等代碼（demo），有時還會根據需要編寫程式碼（如 JSP/ASP/PHP/Rails),光看這些分工，就知道不同的角色對產品的理解和著重點是截然不同的。按照正常的專案流程，設計團隊通常需要先設計出介面mockup或demo（HTML/CSS),接著開發人員才開始正式編寫代碼。
然而多數情況下為了保證專案進度，需要開發人員和設計師在專案前期就介入進來，不同的是，開發人員多是審核通過項目計畫書（PRD）和原型評審，她們更關注於技術可實現性；而設計師更傾向理解產品經理的專案需求以及通過什麼樣方式來解決需求從而達到提升使用者體驗的目的，她們更關注創意的可行性。
更令人糾結的是前端開發對“介面元素”和“交互動作”的理解和設計師有很大不同。統一的介面元素對網站的前端架構也會很有好處，他們更關注代碼的再使用性。 一方面是CSS：前端開發要實現設計師（或者自己引以為自豪）的介面設計，如果新頁面的設計和原先頁面中相同功能元素的設計有出入，哪怕是一點出入，都有可能帶來很多重複的工作，將CSS文件變得越來越臃腫。
另一方面是JavaScript：對於很多應用型網站，會有很多需要JavaScript的頁面交互元素。這些交互元素的視覺或者行為設計與之前的有出入，也會讓前端工程師為了既保證代碼的健壯性來方便後端工程師的開發，又為了實現一些設計上的差別而對現有代碼修修補補忙得不可開交，最可怕的是最終淹沒于bug的海洋…而交互設計師的側重點並不在程式的編碼實現，而注重於使用者如何最好地與系統交交互操作，在設計中重點需要考慮的是介面元素的易用性：比如他們會考慮到並非每個使用者都是電腦的熟練使用者，面對隱藏的層和特殊設計的功能表可能會抓瞎，使用者不見得能明白按兩下左鍵能自動滾屏或者怎樣能讓自動滾屏停下來，直接看最下面的結果？
總之，設計師（完美主義者更甚）會不斷完善產品，來滿足更好的用戶體驗。那麼設計師怎樣來解決這些問題呢？我覺得最重要的就是“溝通”，這是最根本的解決辦法。在原型設計前期就要針對自己想法的詢問前端開發在技術上的可行性，在介面設計過程中會有很多精確到圖元級的標準，同樣要和他們溝通瞭解代碼的實現方式，不然很有可能做無用功。在提交介面設計之後，交互設計師也要主動出擊，不定時的去關注demo的實現效果（mockup和demo多多少少存在不一致，在後期需要跟進；另外涉及到複雜的對話模式前端很可能會忘記或者搞混，也需要不斷的去核查）。
另外建立標準的文檔管理和設計規範也很重要，好在我們開始建立設計規範和標準(淘斯基和TPL 模式庫）的文檔管理方法（SVN)，包括：
• 制定檔命名標準
• 設定檔統一路徑
• 保存原始創作檔（例如PSD、Fla原始檔案）
• 最終完成檔（經過產品經理認可的檔）
• 視覺模式庫和與其對應的代碼模式庫
當然，前端都很忙的，經常去“騷擾”他們會被鄙視的。跟他們溝通也需要技巧和一些基礎認識，我總結了以下幾點需要謹記：
1. 網站的頁面是動態的。 photoshop呈現的是靜態的東西，而網站頁面是動態的展現內容、佈局和交互。設計師過多關注用戶體驗層面，很難對所有的細節做到面面俱到。而前端（包括開發）需要照顧到所有的功能點涉及到的頁面，因此在前期要考慮的儘量周全，別讓別人幫我們收拾爛攤子。
2. 關注新技術。網頁設計缺少技術支援永遠只是藝術。設計師必須經常關注新的技術和對話模式，這樣才能在設計的時候提供多種解決方案，才能權衡利弊找到最優化的方案。
3. 介面元素的標準化和統一。前端關注代碼的再使用性，設計師關注新創意。因此在設計前期就要考慮哪些元素和對話模式既可以滿足用戶體驗又能夠被重複使用，以此來提高效率。
4. 團隊合作很重要。設計師很容易沉浸在自己的小世界裡不能自拔，這是我們經常犯的通病。“溝通”是團隊合作的關鍵，一切皆在溝通。
5. 相信自己。前端通常出於不同的原因對一些對話模式可行性做出判斷，比如代碼複雜程度，技術可實現性等等。
好的設計師需要有一些超前意識和冒險精神，當他們受 新技術的激發，認為它能夠大大提升用戶體驗的時候，就需要把它當作挑戰來實現。在對技術的深入瞭解後去說服前端一起努力實現。 好了，這些血和淚的經驗是我工作一段時間慢慢總結的，如果你有更多的方法，希望能一起分享。
文章來自BAYSTARS DESIGN網頁設計公司
訂閱：
文章 (Atom)
