根據MIC調查，先進國家寬頻網路環境健全，加上服務業者積極推展影視加值應用吸引用戶，故預估2012年起至2014年網路視訊流量將超過有50%的成長空間。除了寬頻網路串流的爆發外，台灣數位電視也積極的部署，有線寬頻產業協會理事長簡仁德表示，台灣有線電視頭端數位化比例已經超過90%，整體數位化普及率僅約在7%上下，初步估計頭端數位化投資總額超過50-60億元。因此聯網電視設備接收到經數位化處理後傳輸的數位電視訊號影音畫面將更清晰，且具備電子節目表單與隱藏式字幕等功能，可接收寬頻網路、IPTV、MOD、手機、STB、OTT Box等設備組成的應用平台，如：Google TV和Samsung Smart TV(Android)、Apple TV、Panasonic公布的新Viera Connect與Intel之BOXEE等平台，這樣提供雙向互動傳輸機制的設計，就是把電視訊號的控制權交給用戶，促進了信息合理的流動，預期刺激更多用戶行為，讓整個聯網電視平台應用體驗更多元。

對Smart TV或OTT Box聯網裝置業者而言，選用何種平台作為開發的基準，無非是看中聯網電視平台上App能帶入豐富的內容資源。根據MIC2011年的統計，全球App軟體商業市場規模仍持續的成長，且預計至2013年將超過有200億美元的收入。此外，SPB TV也是一個聯網電視的解決方案，也在3.0平台提供有手機版的TV app商店。因此widgets便是為了提供各種內容製造者或軟體設計師，甚至系統整合商一個方便共通架構，參考圖一的軟體整合示意圖，widgets是小型互動多媒體應用，其可用於桌上型電腦、行動電話與電視機、STB等設備。widget的類型相當的多，典型的例子有日曆、天氣、遊戲、便利貼、新聞等，不管是鑲入網頁的設計方式，或使用於單機版的應用，皆使用相同的方式製作widgets。從2006年開始W3C持續的更新相關的widgets家族規格，目前規範性規格有7組，包含widgets標準化的配置格式與封裝格式(簡稱P&C)、定義儲存偏好與存取widget封裝內metadata的APIs規範(簡稱TWI)、定義widget封裝進行數位簽章時，使用到之自訂XML簽章語法與處理規格(簡稱DigSig)、當版本控制設計允許更新時，透過HTTP保持widget為最新版(Widget Updates over HTTP)、widget可透過URI認證資源要求/存取網頁資料(簡稱WARP)、定義使用於widgets內的URI策略或使用於其他無法連網的網頁技術(Widgets 1.0: URI Scheme)以及定義媒體功能CSS媒體詢問相關的展現文件內容模式的規格(簡稱VMMF)。

《圖一 概述聯網電視設備之整體架構 (資料來源：資策會繪製)》

Widget引擎組成介紹

目前已經有些領先市場的widget引擎(User Agent)參與W3C Widget的封裝與配置測試一致性的吻合度，如：Owrandroid(Opera Widgets Runtime for Android)、Wookie(Apache)、Aplix、Opera、BorqsWRT1.0與Obigo，其中Opera 11.10 Beta和Apache Wookie 0.9與W3C widget的一致性最高，可使用JQuery javascript函式庫撈進(mash up)所有公布於W3C網站上的測試案例，比對設計客製化的widget引擎與W3C widget標準的吻合度最高。圖二顯示一個widget引擎(User Agent)可分為五個基本組成技術，包含封裝發佈與佈署、metedata配置、腳本存取連結、使用者介面和權限以及展現與行為邏輯，其中打星號的部分封裝格式與數位簽章、媒體類型、配置文件以及Widget的APIs在W3C的widget家族成員之規範性的規格內，都已經定義運作的方式，因此對開發者而言，widget引擎幾乎就是仿造瀏覽器的行為，因此widget引擎也能繪製(render)網頁，同時藉由ECMAScript的轉譯可與其他瀏覽器元件併入運作，widget為了給最終用戶(end-user)帶來單一互動應用感受，提供顯示和/或更新本地數據或網頁數據，因此包裝法允許單一下載和安裝到用戶機(user's machine)、行動電話(mobile phone)、或上網設備(Internet-enabled device)。封裝widget的優點就是可以在用戶間共享widget包，而不需仰賴HTTP。

《圖二 單機版的W3C widgets引擎整體架構 (資料來源：W3C)》

封裝widget包注意事項

所謂的widget包(參考圖三)，就一個封裝了所有該widget的相關資源，包含metadata描述文件(CSS, DOM等等)、配置文件、HTML/XML頁面、圖片和其他文件整體包裹成的壓縮包，其封裝格式可採用ZIP壓縮的Deflate編碼或未壓縮僅封裝的ZIP檔案兩種封裝法，為了widget跨平台的互通性，這個ZIP檔內相關檔名的設計有些需要注意的事項，如同：須注意最長的關聯檔名長度建議是低於250字元，且為了避免檔名字元組在ZIP打包後，跨不同作業系統執行時產生不一致的狀況，建議採用Unicode編碼的檔名設計法(如：UTF-8編碼)，還有此widget包內部的資料夾或個別檔名在命名時，應避免使用到ZIP禁止字元，以及於檔案或資料夾名稱的最後一個字元也需要避免用到 “.” U+002E FULL STOP和空白字元，因為有些檔案系統在解壓縮widget包時，會主動移除這些字元。

《圖三 典型的widget包內檔案分布狀況 (資料來源：W3C)》

Widget配置文件

每個widget包中包含一個metadata描述的XML配置文件，其檔名為config.xml，檔頭必須標明使用xml的版本與採用的編碼方式()，使用UTF-8的編碼格式可防止亂碼的產生，且在此組態文件檔案內，包含widget成員的宣告，以及widget的名稱、描述、版權、作者等等內容，同時指定起始檔(X)HTML/XML檔案名稱，預設起始檔名為index.htm、index.html、índex.svg、index.xhtml與index.xht五種，也可使用content成員宣告加入客製的起始檔，若要使用數位簽章也可放置於config.xml內，此配置文件有11個成員，以widget成員作為根成員因此其包含相當多的子成員，name成員描述widget名稱，description成員敘述用途，author成員標明此widget的作者資訊，license成員涵蓋此widget配送的所有平台，icon成員是使用圖像的方式呈現這個widget，content成員便是指名widget起始檔案的服務為輔助程序機制(bootstrapping mechanism)，feature成員則是指要求進階可用的功能如同API(例如：與camera鏡頭的連結、或使用LBS地理位置的API、或widget引擎內部自訂的API等)，preference成員為宣告widget運行時可用的名稱數值對(name-value pair)(例如：preference名稱為api-key其對應數值則為該key使用到的f6d3a312f9d742機器碼，還可指定存取屬性)，以及param成員為宣告給某feature成員的子成員，還有span成員就是通用文本容器，為了國際化的目的而使用。以上所描述配置文件內使用到的11個成員與config.xml內文本節點(text node)間的親子屬性關係，且包含w3C網站上相關細部的屬性定義，可參考圖四與圖五成員間父子狀態圖。

《圖五 widget、icon、content、preference與feature成員與param成員間的關聯性 (資料來源：資策會繪製)》