釋放網頁版的新功能

網路是令人驚豔的平台,不論是使用何種裝置,都能觸及全世界的使用者。這類產品易於使用及共用,不必安裝任何程式但最重要的是,這是一個開放生態系統,任何人都可以使用或建構。

目前有些應用程式無法在開放網路上建構及提供。這就是所謂的「應用程式差距」。網路上潛力無窮的 原生可能和原生的不足我們想填補缺口。我們認為網頁應用程式應該具備原生應用程式的強大功能,

如何設計及導入這些新功能?

功能流程圖。

我們開發了這套流程,是為了設計及開發新的網路平台功能,讓使用者能夠在現有的標準程序中,快速設計及開發符合開發人員需求的新網路平台功能,最重要的是。這與我們開發其他所有網路平台功能的方式並無不同,而是著重開發人員的意見回饋。

開發人員的意見回饋十分重要,有助於我們確保提供的功能正確無誤,但如果整個流程的後期有所調整,就很難改變課程走向。因此,我們提早開始徵求意見回饋。如果及早收到可做為行動依據的技術和用途意見回饋,就能輕鬆修正或停止開發作業,而不會因缺乏周全或實作不當的功能而造成問題。在 WICG 開發的功能並非無法變更,且您的輸入內容將大幅影響其演進方式。

值得注意的是,許多想法絕對不會超過說明或來源試用階段。這個程序的目標是寄送適當的功能。這表示我們需要快速學習並反覆改進。拒絕提供功能 因為無法解決開發人員的需求為了實現這個學習目標,我們採用了下列程序 (不過由於意見回饋,使用者經常會重新排列步驟中的某些步驟):

找出開發人員的需求

第一步是找出並瞭解開發人員的需求。開發人員希望達成哪些目標?誰會使用?他們今天的做法如何? 這項新功能還可以解決哪些問題或困擾。一般而言,這些功能會由開發人員提出功能要求,通常是透過 error.chromium.org 提供的錯誤回報。

建立說明

確定新功能的需求後,請建立說明 (基本上是用於說明問題的設計文件),以及一些說明 API 運作方式的程式碼範例。此說明是一份持續運作的設計文件,只要新功能不斷演進,就會經歷大量疊代作業。

取得意見回饋並反覆改進說明內容

當說明具備合理的清晰程度後,就可以發布說明、徵求意見回饋,並反覆改進設計。您可以藉此機會確認新功能符合開發人員的需求,並以預期的方式運作。這是收集公開支援並驗證實際需要這項功能的機會。

將設計移至規格並反覆測試

一旦說明狀態處於良好狀態,設計工作就會轉成正式規格,與開發人員和其他瀏覽器廠商合作,以疊代及改善設計。

等到設計開始穩定後,我們通常會使用來源試用來實驗實作結果。來源試用可讓您邀請實際使用者試用新功能,並對實作方式提供意見。這些實際回饋有助於塑造及驗證設計,確保我們在納入標準前,能夠得到正確的結果。

寄送

最後,來源試用完成後,規格就已確認完成,其他所有啟動步驟也都已完成,就可以將版本運送到穩定版了。

考量使用者安全性、隱私和信任

其中部分功能一開始可能令人感到驚慌,在原生實作方面更是如此。不過,網路的本質比原生使用者來得安全,開啟網頁時也不應令人害怕。

在預設情況下,不應授予任何存取權,但這類模型依賴的是讓使用者能完全掌控且易於撤銷的權限模型。但必須清楚瞭解這些 API 的使用時機和使用方式。我們在「控管強大 Web Platform 功能存取權」一節中概述了幾個思維流程。