不要使用@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網頁設計公司

搜尋引擎最佳化行銷

　搜尋引擎最佳化行銷

為什麼進行搜尋引擎行銷最佳化行銷?

　　搜尋引擎目前是成本最低，最有效的網路推廣手段，超過85%的網民通過搜尋引擎尋找信息，制定一個良好的搜尋引擎策略甚至比好的搜尋引擎優化技術更加重要。沒有一個好的策略，搜尋引擎優化進行的再好效果也會大打折扣，所以一個好的搜尋引擎策略是企業進行搜尋引擎行銷的重要基礎。

什麼是搜尋引擎行銷？

　　搜尋引擎行銷就是通過幫助您分析整個網站的主題，營運模式以及網站內容為您量身訂做符合你網站情況的一套關鍵 字。包括核心關鍵字，地域關鍵字，客戶搜尋習慣關鍵字以及圍繞核心關鍵字的相關長尾關鍵字。

　　優化一整套關鍵字，在搜尋引擎上取得較好的表現，讓用戶從各個方面，各個角度都能夠找到網站。讓網站整體排名已經整體流量得到提升。

搜尋引擎行銷策略服務內容包括什麼？

　　 搜尋引擎行銷策略服務項目包括：企業網站搜尋引擎行銷關鍵字策略分析、搜尋引擎優化實施顧問、搜尋引擎廣告策略與管理、搜尋引擎行銷效果監測與評估等項目


　　　　　　搜尋引擎行銷的重要性

為什麼我們這麼大的網站，在搜尋引擎上卻找不到?

為什麼我們網站這麼便宜的產品，在搜尋引擎上也找不到?

為什麼我們公司這麼漂亮的網站，在搜尋引擎上還是找不到?

其實搜尋引擎檢索網站和網站的大小、漂亮美醜、產品的價格完全沒有關係。您需要的是一套有效的搜尋引擎行銷方法。

推廣臺灣多年來專研於企業網站的規劃和建製以及搜尋引擎的發展，我們認為企業網站在搜尋引擎上的能見度（search engine visibility）要比網頁設計得驚世駭俗或炫麗奪目來得重要許多，因為再好再美的網站，若沒有辦法讓人順利找到，頂多也只能關起門來自己欣賞。搜尋引擎行銷即是爭取網站在搜尋引擎上重要關鍵字的排名，也是推廣臺灣所專職專業的服務項目之一。

對於搜尋引擎行銷，我們不僅秉持著專業領先的觀念，並且累積了許多豐富的知識與寶貴的經驗。我們的做法並不是以保證名列前茅等誇大的宣傳來贏取客戶，而是以務實的態度和專業的能力來獲得信任。

目前網路上有許多不同的行銷方法，各種方法都有其優劣利弊與適用性，當然搜尋引擎行銷也不例外。與幾個主要的網路行銷方式比較上，我們可以由下表瞭解一些搜尋引擎行銷的差異和適用方向。

我們專業的搜尋引擎行銷服務包括:

* 網站架構體檢
* 分析及定義重要關鍵字
* 網頁結構檢視與修正
* 網頁文案編輯與調整
* 連結聲望（link popularity）規劃與執行
* 網站登錄規劃與執行
* 關鍵字標購策略規劃與執行
* 搜尋引擎監控報表

文章來自 Baystars Design網頁設計公司

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. 如果標籤之間都是相互平等的，可以考慮對標籤欄進行操作，如加入左右移動按鈕，允許使用者拖動/滑動等。

原文：http://uxday.com/archives/76

文章來自BAYSTARS DESIGN網頁設計公司

設計良好的網頁四大原則

英文原文：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網頁設計公司

當網頁設計師遇上前端開發

作為網頁設計師，在和前端開發人員溝通時你是否常常會聽到這樣的聲音：

—— “大姐，給點專業精神好不好，這個表格是自我調整的，你這樣設計頁面不好擴展啊…”
——“用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網頁設計公司

iFotbol用麥當勞的賣法來賣美國人不喜歡的東西

做獨立網站的人似乎愈來愈少了！大家做iPhone，想辦法搶上iPhone熱門排行榜；大家做Facebook插件，想辦法透過動態資訊和互相訊息傳播出去；大家做Twitter周邊，想辦法讓好多twitter會員都猛貼連到網站的超連結給所有朋友看到……相較之下，現在要做一個獨立網站，自行推廣、自行拉會員、還要擔心獲利，真是愈來愈「不流行」了。

不過，獨立網站還是可以提供最多可能，可大可小、可寬可窄，可加入自己想要的任何功能，最重要的是，可在全世界通行無阻──問題是，如同美國的麥當勞是最風行全球的速食店、美國的可口可樂是最風行全球的飲料，現在網路上成功的全球網站，也幾乎都還是美國網站，MSN的使用者佈及全球，Google、Yahoo!在許多國家排行前三名，Facebook、Twitter各國都有忠實使用者，而Amazon、Monster都有40%以上營收來自海外……在2009年，我們看到這樣的狀況，還有什麼東西可玩？

上周傳出有一個關於「足球」的網站開站，叫「iFotbol.com」，iFotbol這個網站沒什麼太了不起的創新，它基本上就是一個關於「足球」的網站。聽起來有點老套，儘管它號稱是目前網路上最有創意、最廣納百川的足球網站，創辦人是一群人，包括記者、電視台、網路工作者，不過當我看到後，卻有一種說不出來的「實際感」。實際感就是，這個網站顯然並沒有什麼創新的地方，它只是做出目前美國網站都在做的事情（各種社群與轉寄的功能)，一塊一塊兜起來成了iFotbol，兜成了以後，才看到沒想到美國這麼多創業家卻很少做過這類型的網站──目前iFotbol已經收集了350個來自全球各地職業足球球隊的歷史資料與最新feed，包含了高達1萬名球員的現在與歷史資料，以及一共60個國家級與世界級的比賽的目前各隊排名，包括「Premier League」、「World Cup」等。iFotbol列出全球所有的隊伍的比賽結果，以及最新的新聞、照片、影片…也給所有的隊伍、所有的比賽、所有的隊員，都有一個個別的頁面，列出所有最新的比賽資料。這些資料，只是這個網站的第一層，接下來才是重點，iFotbol顯然先用所有資料來吸引所有人加入，加入後，設置自己的個人首頁。網友可以自設個人的首頁，也可以加入討論區。接下來還有有趣的足球球迷會喜歡的小小遊戲，預測誰會贏，就有機會得到Wii這類的獎品。另外他們還有一個不可思議的3D照片呈現功能，用類似iPhone看照片的方法來把照片一張一張秀給使用者看。至於收費的部份它也頗有創意，已經設立一個機制來吸引各國的在地的廣告商，來放廣告到他們那個國家裡面的球隊和球員的iFotbol頁面，iFotbol說所有的收益將會回到這些廣告主而不是網站本身。
這些看下來，iFotbol還好而已，顯然是美國人做的，雖是美國人，但iFotbol所指的「football」是在腳上踢的圓圓的那種球，和一般美國人愛打的橄欖形的「美式足球」不同，我們可以想像，這位熱愛圓形足球的美國創業家一定「懷才不遇」，美國人不喜歡足球，他必須尋求美國以外其他地方的網友。iFotbol的口號正是：「football everyday, football everywhere」。

全球愛好足球的人很多吧，大家看的電視台都不一樣，更是需要一個社群網站把大家都找來加入會員！全球身上帶有「足球癮」的人為數頗多，散布在各個國家，針對這些人來做社群網站，交換最新情報，分享彼此的熱情……。 他們也善用社群的傳播，包括Facebook、Myspace、LinkedIn、Twitter等等。雖然這個網站是個獨立網站，但它利用Facebook、Twitter這些全球可能有的社群，來傳播出去。

歷史告訴我們一些事情，美國這邊的網路創業家與可以支持創業家的使用人口都比其他地方多很多，在美國並沒有明顯比較「不熱門」的題材如觀星星啦、塔羅牌啦……如果現在沒有一個成功的全球的網站，那以後也不會有。但有些網站是美國這邊明顯比較「不熱門」的，這些題材倒會是適合在「美國以外」的全世界試試看，而且是搭著美國人已經搭建的這些Google、Facebook、Twitter網絡來灑出去。

除了足球外，還有哪些在美國境外的全世界各國紅的？這些通常是比較沒有一個像樣的獨立網站的。甚至譬如有些亞洲電子廠賣不進美國，所以在歐洲等地賣得較好，這些公司可以考慮一下，如何利用麥當勞的店面來賣包子。

文章來自mr6
文章提供BAYSTARS DESIGN網頁設計公司

談中國電子商務（四）轉單模式造就輕公司

轉單模式的美妙之處在於他的輕巧。

◎電子商務＝電子＋商務 電子商務是網際網路產業中一個十分複雜的領域。

正如其名，電子商務等於「電子」加上「商務」，過往有很多大學剛畢業沒多久就創業做網站獲得成功的年輕人，但他們的創業領域卻很少在電子商務。因為這些年輕人懂得「電子」，卻還不懂得「商務」。

正因為這樣兩極的特性，過往也使我們看見大量的傳統產業想要進入電子商務領域的時候遭逢失敗，傳統產業在「商務」的經驗累積上十分可觀，但卻不懂「電子」。

最終只有能夠完美的融合這兩種領域的人，才可能造就成功的電子商務網站。 然而，電子商務卻不僅只是把貨品拿到網上賣而已。由於網際網路擅長處理資訊流，因此資訊流的變革也引發了不少有別於傳統的新模式誕生。

這裡的模式不是指B2C 或者C2C之類的名詞，而是更加細膩的運作方法，例如：轉單模式，專櫃模式等。 這些模式，大部分在台灣或者美國都不新鮮，已經運作相當長的時間。然而，對於08年以來電子商務才剛要高速起飛的中國大陸來說，卻有很多模式並未被探索過。某些模式在其他國家或地區被證明行不通的，或許在中國反而是有機會的，這是誰也不知道的。

◎轉單模式與輕公司

首先要提到的是轉單模式。正如其名，網上商城接受消費者的訂單，訂單再由商城轉給商品的真正供應商，再由供應商出貨給消費者。這種轉單模式可謂實現了「輕公司」的架構：商城本身沒有庫存。所有的操作都在資訊流上，商城的主要責任是把訂單流程管理做好。 由於商城首先接受了消費者的支付（信用卡或網銀或支付寶等），錢會先進到商城的口袋。

當供應商出貨的時候是一毛錢都沒拿到的，而商城每個月跟供應商結清款項。這種模式下，供貨商必須負擔庫存壓力以及資金壓力，因為貨物出門錢卻還沒收到。 這種模式與淘寶不同的地方在於，在淘寶，消費者認為交易的對象是供貨商而不是淘寶。而轉單模式下，消費者認為交易的對象是商城而不是供貨商，消費者是認知商城本身的品牌而消費，因此供貨商對他們來說是不存在的。

由於此種認知差異，導致轉單模式的網上商城必須要負起售前售後客戶服務與退換貨的責任，更由於收了錢，必須承擔開發票的責任。這在先前還導致一個很妙的結果：商城透過物流送發票給消費者，而供應商則送貨品給消費者，兩者分開導致很難同一個時間送到。 ◎轉單模式的問題 早年轉單模式的網上商城是讓供應商自己找物流送貨，這導致了不好的消費體驗。

例如早在97年，當時台灣網路書店就是採取轉單模式經營：消費者網上下單買了七本書分屬於五間出版社，訂單就轉成五筆給出版社，最後消費者會分五次從五個地方拿到這七本書。 轉單模式在銷售上也不靈活，以前消費者甚至無法在一個訂單裡包含不同供應商的商品，商城很難做跨供應商之間的綑綁銷售，因為這牽涉各方不同利益。此外，中國大陸的網上交易大部分仍透過貨到付款支付。供應商如果是使用自己的物流，會導致網上商城無法控制金流。 要建立統一物流體系從眾多供應商處取貨送到眾多消費者手中，這種多對多的物流架構在中國廣大的幅員下顯得十分吃力。

或許在小城市範圍內，轉單模式的統一物流可能不是問題，但全國範圍可能較難實現。誰能解決這個問題，轉單模式在中國就存在發展的可能。 網上商城只要自建倉庫，轉單模式的問題就幾乎解決。不管什麼品類的商品都往倉庫裡塞，要怎麼做綑綁銷售都行，消費者一個訂單裡的五件不同類別商品，連同發票保證都在一個盒子裡收到。然而，自建倉儲的網上商城本身就沒有什麼可說的，他很傳統。 轉單模式的美妙之處在於他的輕巧，使用網際網路將資訊流以及金流控制住的方法使其不用背負庫存壓力。在這個年頭誰都認為輕公司很美妙，這個模式還是值得研究與深度挖掘的。說不定因為中國大陸特殊的環境下會誕生出想不到的新模式。

（文：黃紹麟)

文章提供BAYSTARS DESIGN網頁設計公司