很謝謝各位的支持,
讓這趟連續30天的教學旅程能告一段落。
在參考官方文件整理內容的過程中,
讓我學習到,開發Action的前置步驟原來遠比自己實作的流程複雜許多。
希望在這幾天的文章後,你也可以學到開發Action的標準流程並加以實踐!
最後,你可以參考Google官方在Google I/O的教學!
很謝謝各位的支持,
讓這趟連續30天的教學旅程能告一段落。
在參考官方文件整理內容的過程中,
讓我學習到,開發Action的前置步驟原來遠比自己實作的流程複雜許多。
希望在這幾天的文章後,你也可以學到開發Action的標準流程並加以實踐!
最後,你可以參考Google官方在Google I/O的教學!
到這裡,你已經建立一個具備完整對話體驗的Action
也已經藉由GCP建構符合使用情境的架構了
接下來,你可以嘗試精進你的Action
在正式上線後,你可能會發現當初所設計的對話流/對白不符實際使用情形。
在這個情形下你可以透過以下的方式進行修正:
這項操作需要在DialogFlow上進行,
依據你所修正的對話流來更正Intent。
更正完成後,
你需要前往Actions On Google Console提交新的版本來更新Actions上的對話流
根據欲修正之對白的所在位置,我們需要進行不同的操作
現在,你有個支援中文語系的Action了!
當你的對話流設計能充分應對你的受眾後,你可以試著擴展Action的適用範圍!
來自不同地區的使用者不僅可以擴展你的Action的曝光度,也能得修正更細微的對話流問題!
在鐵人賽的最後一天,將會分享自己在向各位介紹對話流設計流程中得到的收穫,
以及我如何運用這些技巧改進現有的Action。
基於昨日文章的說明,
我們已經建立了一個資料庫協助我們暫存資料資料
但缺乏驅動負責拉取與上傳資料的Function之機制,
在本日的文章,會簡單講述你可以如何借助GCP的服務來完成這個需求
這是一項Google的資訊傳遞服務,
我們可以透過它,向負責抓取資料並上傳資料到資料庫的Cloud Function傳遞資訊並為我們工作!
這是一項Google推出的全代管的企業級 Cron 工作排程器。
我們可以透過它替我們的Function執行進行排程,
藉由這項操作,Function將會在我們指定的時間點被喚醒並執行我們事先撰寫好的程式碼!
從最上方的架構圖中,我們可以略知一二。
為了達成自動定時觸發Function的效果,我們需要:
詳細教學可以參閱下方的官方文件:
使用來自環保署提供之OPEN API獲取空氣品質資訊,
並篩選所需資料備份到Firebase RealTime Database
以索引空氣品質資訊為主要功能的Action
現在,Cloud Function會依據你設定的時間進行資料拉取及上傳至資料庫的動作了
到這裡,GCP的架構設計到此告一段落!
接下來將會提供一點建議,
進而精進及擴大你的Action之使用者範圍!
從昨天所提及的架構,讓你在爬蟲獲取資料的情境下使Cloud Function能各司所職。
並使維護專案的難度下降。
今天的文章會簡單帶各位了解RealTime Database可以如何被運用到你的專案上。
而 Cloud Function 傳遞資料的流程會發生什麼變化
基於昨天的基礎架構,現在我們的Cloud Functions依舊執行類似的任務,
但在兩者資料傳遞間多了一個資料庫來協助暫存資料。
因此兩個Cloud Functions現在推送或拉取資料的對象變成我們的資料庫。
它是一種NoSQL型態的資料庫,使用鍵與值來儲存與索引資料。
透過它我們可以輕易地建立可以即時同步數據的小型資料庫!
在我們的專案中,他可以協助我們解決以下情境的問題:
現在你已經建立起一組 Cloud Function 以及介於兩者間的資料庫了
看似很美好,但Cloud Function本身是事件驅動(event driven)的服務。
無法自行協助我們進行資料拉取以及上傳的動作,這導致你的Action去資料庫會拉不到所需的資料。
因此,在明日的文章中將會簡述如何透過GCP服務的幫助解決這個燙手山芋!
接下來這幾天,將會帶領各位以GCP的架構的視角。
向各位闡述我們先前進行的DialogFLow Fulliment操作實際上的架構圖是什麼
而你可以在這個基礎上進行怎樣的設計來建構更好的流程。
在數天前的實作教學中:
我們藉由內建在DialogFlow的Inline Editor,
在Cloud Function上建立DialogFlow Fullfiment。
從GCP的架構來看,我們可以得到下方這張圖:
從這張示意圖,我們可以理解Google助理與我們的Action是如何互動的,
當使用者透過Google助理與我們的Action互動後,
Google助理會辨識用戶輸入的語音,並將辨識後得到的文字轉傳給DialogFlow。
執行自然語言處理的DialogFlow會尋找對應的Intent,並設法給予相對應的回應。
如果指定的Intent被設定以Fullfiment來處理回應,則DialogFlow會將擷取到的參數送往Fullfiment。
並由Fullfiment的程式碼進行邏輯盼判斷來產生回應。
上述的說明也可以透過這張圖來表示:
假定你所使用的資料是Open API。
那麼,你可以透過處理DialogFLow Fullfiment的Cloud Function直接拉取資料。
從GCP的角度,現在你的專案架構會變成以下形式:
介接《萌典》的 OPEN API 所建構的Action
在今天的文章中,向不知從何開始建立一個Action的新手。
提供幾個可以嘗試發揮的方向,從而建立相對應的對話流!
若你對於要進行什麼類型的專案沒有頭緒,可以往其他語系的Action尋找可能的靈感。
像是開放第三方平台已有一段時間的英語或日文語系:
例如下列這個Action即仿造美國區的同類型Action而來!
這是一個建立在Google助理之上的框架,它允許開發人員為對話式Actions增添視覺、身臨其境的體驗。
這類視覺體驗是一種交互式網絡應用,Google助理在對話中會將視覺體驗作為回應向用戶發送。
與Google助理預設的回應方式不同,Interactive Canvas網絡應用呈現為全螢幕的網路介面。
詳細資料可以參考:Interactive Canvas | Conversational Actions | Google Developers
若你有興趣的資料沒有提供API,可以試著藉由爬蟲獲取資訊
現在,你有個資料來源以及假想的對話流!
在明日開始的一系列文章中,將會簡述如何透過GCP幫助我們建構這類型的架構!
現在你的Action已經具備完善的對話流,能針對各式裝置進行支援。
測試者們回報的用戶體驗均十分良好,是時候讓你的Action接觸真實用戶了!
範例Action:詞語接龍
在填寫Action頁面內容時,主要需要注意的項目有以下幾個:
它定義用戶如何藉由顯式調用來呼叫你的Action。
此名稱亦會被展示在Assistant目錄當中。
控制用戶是否可以根據他們使用的裝置調用你的Action。
如果用戶嘗試在不支援的裝置上調用Action,
他們會收到一條錯誤消息,告訴他們他們的設備不受支援。
在支援的裝置上開啟 | 於不支援的裝置上開啟 |
---|---|
簡單來說,Google官方的審核小組在收到你的Action部屬申請後,
會檢視你是否違反任何《Google助理的開發者政策》,以下列出幾點主要的項目:
基本上,在檢視你的Action沒有發生問題後。
你會收到一封電子郵件,通知你的Action已經被核准部署到Production Channel!
一旦部屬完成,你的Action將能夠被使用者找到且能與之互動。
根據你的開發階段,你在部署時可以發布到不同的渠道:
現在,你已經充分了解到建立一個Action背後會經歷的開發流程!
如果你是個不曾開發過一個Action新手又該從何開始呢?
在明日的文章中將會給予一些方向供你參考!
現在,你有個能針對不同裝置進行適當對白的Action了。
但要評量一個Action是否成功,用戶的回頭率是一個很重要的因素。
因此,我們今天將會簡單介紹一些官方提供的小工具。
妥善運用它們,你就能讓使用者與Action之間的距離更進一步!
如果你的Action提供每日變化的有用資訊或能幫助用戶完成日常任務的小技巧,
可以在Action中啟用每日更新訂閱來協助用戶更快獲取資訊。
例如:每天向用戶發送今日的歷史事件或即時的空氣品質資訊。
目前這項功能只適用於en-US語系的Action
取而代之地,你可以在Action中加入導引用戶進行加入日常安排的對話
讓您的Action成為用戶日常活動的一部分是讓他們保持參與的好方法。
提供日常安排訂閱功能,以便用戶可以將您的Action添加到他們的助理的日常安排中。
例如,創建一個出色的Action來提供創造性的早餐創意,並讓用戶將你的Action添加到他們的「早安」日常安排中。
使用 Actions API 向用戶的手機或智慧音箱等裝置發送Google助理通知,例如提醒或事件的最新動態。
發送有用的通知能讓你的Action成為用戶數位生活的一部分!
當有關你的Action的消息開始傳播時,新用戶和回訪用戶應該要能夠快速地與Action互動。
生成一個Action鏈接,能將用戶從他們的瀏覽器直接發送請求到他們的Google助理裝置上並直接與Action互動。
看起來我們的Action已經一切就緒了!
是時候提交你的Action給官方進行審查,讓世人來使用你的Action了!
在明日的文章,將會快速帶領各位了解這個審查機制是如何被進行的,
而你又該如何撰寫Action頁面的說明與使用範例來避免可能的違規情形。
從手機到智慧音箱,在不同裝置上要考量到的情形皆有差異。
這篇文章中將先介紹Google助理可回應的裝置有哪些
而你應該如何依據不同的裝置修改回應方式來增進對話體驗
裝置 | 說明 |
---|---|
對於智慧音箱或耳機上的對話,語音回應會承載整個對話並傳達核心資訊。 | |
對於車內顯示器或智慧螢幕上的對話,用戶可能無法時常使用屏幕進行互動。因此,語音提示必須承載大部分對話並傳達核心資訊。屏幕可用於視覺元件補充詳細資訊並提供繼續或轉換對話的建議。 | |
電視、筆記本電腦、手機或手錶上的對話同樣適用於語音輸入/輸出和基於屏幕的互動模式。用戶可以選擇以口頭或視覺互動的方式繼續對話。因此,所有用於回應的元件可以協同來承載每一輪對話並傳達核心資訊。 |
從針對語音回應(智慧音箱)所設計的對話流開始,逐步拓展你的設計到不同的裝置上。
使你的設計能很好地適應不同的情形並給予最佳體驗。
從示例對話框中的原始語音提示開始。為減少認知負荷,在此官方範例中在口頭上提供的選項只有隨機挑出的六個選項。
大多數情況下,您可以簡單地在智慧螢幕等設備上重複使用相同的語音提示,因為傳達對話核心的需求保持不變。 在對話的這一點上,沒有任何內容適合在卡片或輪播等視覺組件中使用,因此不包含任何內容。但最基本的要求是一定要加建議卡片。來提供用戶任何可能的選項並以便用戶可以快速點擊它們來進行響應。
由於原本必須包含在語音對白中的內容能以視覺化形式展現了。因此,在這裡重新使用了視覺組件是OK的。 文本對白理論上是語音提示的精簡版本,讓用戶可以快速掃描內容獲取資訊。若口頭或文本對白中有對用戶提出任何問題,在建議卡片的內容中應包含可能的選項供用戶使用。 因此,在這裡可以重複使用您剛剛創建的建議卡片。
現在,你應該有了一個能妥善處理各種意外情形。
且能妥善引導使用者滿足他們主要需求的對話流了。
在今天的文章中,我們要拓展對話流應用的視野。
這篇文章中將先粗略介紹可使用的回應元件有哪些,
善加利用它們你將能增進使用者體驗。
根據呈現方式,可以將Action能使用的反應粗略分類為兩種
會話元件由語音回應、文字回應和建議卡片中的內容組合而成。
其中,每個對話回合都應該包含會話組件(回應和建議卡片)。
組成要件 | 詳細說明 |
---|---|
語音回應 | 你的 Action 通過 TTS 或預先錄製的音訊檔案向用戶傳達的內容 |
文字回應 | 您的 Action 通過屏幕上的文本對白顯現給用戶的內容 |
建議卡片 | 提供用戶繼續或轉移對話的建議對白 |
視覺化元件由卡片、旋轉木馬選單和其他視覺化元素所組成。
如果您要呈現詳細信息或需要陳列或比較需要進行比較的選項可以使用它們,但並非每次對話都需要被使用到。
|組成要件|詳細說明|
|–|–|
|基本卡片|以文字形式向用戶傳達的內容,需要時可以增加一按鈕供用戶前往網站查看詳細內容|
||Browsing carousel|當這些項目是來自網絡的內容時,為允許用戶選擇許多項目之一進行了優化。|
|旋轉木馬選單|允許用戶選擇許多項目中的一個,當這些項目能輕易透過圖片來區分時可以使用。|
|清單|當這些項目可以輕易透過其標題區分時,允許用戶選擇眾多項目中的一個。|
|Media response|用於播放和控制音訊檔案(如音樂或有聲書等)|
|表格卡片|以用戶能輕於快速瀏覽的格式展示靜態數據|
我們將了解到,
這些如何屬性不同的元件,在各式型態的裝置上能夠如何被運用。
從昨天的文章中,我們能知道長尾問題在分析用戶體驗是十分重要的。
在今天,我們將會從現正運行的Action的角度。
了解長尾問題能如何完善對話流並增加使用者體驗!
關於這些分析的詳細內容,可以參考Google官方撰寫的說明。
以下是結合我自己的開發經驗並以長尾問題的角度來分類對話流。
在這個Action中,主要目的是滿足使用者進行1A2B遊戲的需求。
因此在最初上線時,僅包含最基本的遊戲機制。
毫無疑問地,這就是最重要且最多人會接觸到的對話流。
在正式上線一段時間後,
我發現對於某些使用者來說,他們可能從未聽過1A2B這款經典遊戲,
更不可能知道這款遊戲的機制是甚麼。
這個情形下,直接開始遊戲會讓他們陷入混亂無法進入狀況。
因此在後續的更新上,為這些曾未接觸過這種遊戲的用戶提供「教學模式」。
讓他們有機會可以先理解遊戲的基本機制與玩法後,再進入遊戲。
在座標上這是相對次要的對話流,但是部分使用者可能必經的對話流。
使用者在充分了解規則後,能帶動他們後續再回來進行遊戲的可能性。
由於這款遊戲是由數字為輸入為主的遊戲,
因此應對這些罕見的情形相當簡單:
提示這是不被接受的輸入並給予一些可能的選項即可。
到這裡,
你應該已經擁有一個能應對多數使用者需求,
且可以妥善針對不同意外情況進行應對的對話流範本了。
接下來,我們要進一步依據對話發生的裝置。
對Action的回應進行修改並完善它,讓整體的使用者體驗更上一層樓!
到現在為止,您的設計應該涵蓋大多數用戶將遵循的對話流。
現在是時候關注對話流的長尾問題了。
想想您的對話中可能出現的所有問題,以及用戶可能採取的所有意料之外的對話。
這些對話路徑是用戶透過您的Action滿足需求所採用的最重要和最常見的路徑。
您應該將大部分精力放在這裡使其成為出色的用戶體驗的關鍵!
這些出現頻率不太高的對話流。僅需花少部分時間來建構。
這些出現機率相對較低且不在Action主要功能上的對話。
可以考慮像「對不起,我不知道如何提供幫助」這樣的通用提示來滿足需求。
我們將從長尾問題的角度檢視一款運行中的Action,
看它如何滿足不同用戶的可能的需求以達到更好的使用體驗。
透過GCP上的Cloud Function這項SaaS (Software as a Service) 服務,
我們能輕鬆快速地建構DialogFlow Fulfillment來達成我們今日的需求。
你也能參見官方撰寫於Qwiklabs的實作範例。
Google Assistant: Build an Application with Dialogflow and Cloud Functions
如果各位尚未進行任何設定,可以先完成下列文章的教學再接續下方的步驟
[Day12] 於DialogFlow中實踐對話流設計
首先,前往「Fulfillment」分頁。
開啟Inline Editor的功能,我們將透過他於GCP上建立雲端函式。
並以此撰寫程式來客製化回應。
開啟該功能後,系統會提示需要啟用GCP的付費功能。
請點擊「OPEN CLOUD CONSOLE」繼續操作。
跟著系統的導引建立帳單帳戶,並將其綁訂到這個專案上
現在,你已經成功開啟我們所需要的雲端編輯器啦!
依照我們先前所提及的架構。
來客製化我們先前要設計的對話。
1 | 'use strict'; |
1 | { |
在Fulfillment之中,我們能擷取來自Dialogflow的資料進行判斷並據此回覆。
在我們的範例中,擷取的資料是「用戶輸入的顏色」這個Intent所擷取的參數(Entities)「color」。
而上述的「index.js」所做的事是判斷參數「color」的數值來給予回應。
前往「用戶輸入的顏色」這個Intent的設定頁面。
至頁面最底部的「Fulfillment」,
開啟「Enable webhook call for this intent」
請參照以下教學的詳細步驟
[Day13] 前往Actions On Google平台試用
現在,你可以前往 Actions on Google Developer Console進行測試了,
看看你的Action是否有照著Fulfillment設定的邏輯進行回應!
在這裡所使用的Fulfillment是在DialogFlow上透過Google Cloud Function所建構的。
你也能夠在Google Cloud Platform或Firebase上進行編輯。
詳情請參考下列的網址:
我們將會從語音使用者介面設計的角度,
探討與對話流設計息息相關的**長尾問題 (long tail problem)**。
並了解如何應用它使Action能專注在主要的目的上並增進使用體驗。
從昨天的文章中,我們獲得了數種進行綠野仙蹤實驗的方法
在今日的文章,假定我們已經獲取用戶的反饋。並將要加以改進。
到目前為止,我們所實踐的對話流如下圖所示:
假定我們在昨日進行用戶測試的反饋中,
得知他們對於輸入理想回應(即表達自己所喜歡的顏色)後的到的回應感覺太過單一。
因此我們挑出幾個在測試過程中出現頻率最高的顏色(如:綠色、紅色、藍色)進行回應的客製化。
而其他顏色的回應則保持原先設定。
修改後的對話流可以以下方這張圖所示:
在Dialogflow上,我們能做的對話流設計被侷限在單純的回應。
無法進行更進一步的互動,像是:
因此,我們將需要額外接入Fulfillment。
能使回應之設計更具多樣性,達到更貼近一般生活上的對話互動。
在明天的文章中,
將透過實際操作闡述我們如何藉由Fulfillment在DialogFlow實踐修正後的對話流。
在昨天的文章中,快速而簡潔地向各位介紹語音對話設計中「測試與迭代」的相關名詞
在今天的文章中我們將簡單介紹一下你可以如何實踐「綠野仙蹤實驗」來精進你的對話流
不管你使用什麼方式進行實驗,一定要做到以下幾點:
標題 | 詳細說明 |
---|---|
說出來 | 由於您的目標是更新您的對話流以獲得最適合真實用戶的設計,因此您的 WOZ 實驗應盡可能接近現實情境。在紙面上看起來不錯的東西在實際對話中不一定聽起來或感覺自然,因此請務必確保用戶能聽到您的提示並說出他們的回應。 |
記錄您的對話 | 向你的「用戶」獲取錄製對話的許可,以便您可以重複收聽它們以記下對話過程中任何可能出現問題或瑕疵。 |
徵求反饋 | 請用戶用他們自己的話描述他們的體驗。它是如何達到或未能達到他們的期望的?有什麼讓他們吃驚的嗎?他們滿意嗎?請記住,重點在於他們的反應。 |
您可以採用 3 種不同的方法來測試您的語音應用程序:
您所需要的只是您撰寫的對話流。
接下來,只需找到不熟悉您項目的人(例如:家人、朋友、同事)並讓他們與您進行角色扮演對話——
您將朗讀角色的台詞並觀察他們作為用戶的反應。
如果不幸地用戶「脫稿演出」,請隨意即興創作您的角色會說的話。
為了獲得最真實的體驗,請使用 Actions on Google Developer Console 上的 TTS 模擬器輸入角色的對話來模擬角色的真實對白。
並下載音訊檔案以準備好按所需播放。
在標準版本的實驗中,將需要四件事來達成:
一旦開始構建 Action,您應該經常使用 Actions on Google Developer Console 上的 Actions Simulator 對其進行測試。
如此一來你便能邀請您的朋友、家人或同事直接來測試一下!
我們在幾天前的文章中,已經完成建構Action的流程。
因此,
你可以直接實行上述「標準可用性實驗」的流程,
讓您的朋友、家人或同事也來測試一下!
有了一個初始的對話流是個很好的開始,
接下來我們將試圖讓它變得更好。
在明日的文章中我們將會改造初始的對話流,並闡述如何將之實踐在DialogFlow之中!
現在,基於我們現有的初始對話流與打造完成的語音應用程式。
來試著讓它變得更好!
現在我們進入設計對話流中,「測試和迭代」階段
用戶研究在設計過程中的任何時候都會有所幫助。
沒有什麼可以替代從實際用戶那裡獲得反饋,以找出哪些有效,哪些無效。你越早這樣做越好。
當你沉浸在設計中時,發現問題是很困難的——需要一個局外人的意見。
好消息是,在編寫一行代碼之前,您可以快速而輕鬆地洞察您的設計是否適合用戶。
找一個不熟悉你的項目的人來嘗試你的對話可以獲取反饋以查看您的對話是否有效 。
在設計過程中獲得反饋能找出可能的問題,並有機會儘早自我修正。
在編寫一行代碼之前,對您的對話體驗進行可用性測試很重要。
我們建議進行快速而簡陋的綠野仙踪 (WOZ) 實驗,以幫助您確定自己是否走在正確的道路上。
綠野仙踪 (WOZ) 實驗得名於電影《綠野仙踪》;
它是一種實驗心理學實驗方法,測試人員模擬計算機應用程序來與用戶進行通訊交互,這個時候用戶會覺得自己在與真正的機器對話而表現出最真實的行為反饋。
簡而言之,這是一種無需實際開發軟件即可測試原型的方法。
WOZ 原型設計用於評估設計的功能、
滿足用戶目標的能力以及整體改善用戶體驗 (UX)**。
WOZ 實驗旨在看起來和感覺像真實的體驗,但不是軟件,而是一個人模擬角色(“嚮導”)在實際應用程式中的行為。
參與者可能知道也可能不知道他們正在與幕後的「巫師**」互動。
[例如] 亞馬遜基於該方法做語音交互驗證實驗
利用Amazon Echo將幕後的測試人員實時輸入的話轉化為機器語音,並通過機器語音與用戶進行測試交流,此時用戶會認為自己正在與真正的機器對話。透過這個方法能得到最真實的行為反饋。
WOZ 原型設計的最大優勢之一是您無需構建即可測試您的設計。
WOZ 實驗是語音測試原型的最小可行產品(MVP)。它們相對容易運行且幾乎不需要額外的努力。
原型可能非常簡單,或者它可能是一個能夠執行一些但不是所有任務的一個對話模型。
當然,你的原始模型越逼真,你的反饋就會越好。但要明智地選擇:您可以為此分配多少時間?執著於將原始模型真實化是值得嗎?
運行 WOZ 實驗可以讓您了解人們將如何參與您的設計。
您可能會發現用戶所做的事情與您的預期非常不同(如下方這張圖),為此需要您更改設計以更好地滿足他們的需求和期望。
基本底線:專注於設計的可用性(而非用戶的意見)並根據用戶行為進行迭代,並在時間允許的情況下再次測試。
我們將介紹幾種綠野仙踪實驗的實踐方法
接續昨日的DialogFlow對話流設計後,
現在你已經擁有了一個能執行的語音應用程式!
接下來,我們將前往Actions On Google平台體驗在實際裝置上的互動效果!
現在,我們已經有了一個能實際運行的語音應用程式。
但還尚需更多調整才能真正問世。
接下來將進入語音介面設計中,「測試與迭代」的流程!
在這個範例裡,我們假設一個要蒐集使用者偏好顏色的資料集。
並透過語音助理來協助我們進行資料蒐集。
為此我們需要先假想使用者與之互動時可能的對話流,並加以進行改進。
你可以透過上傳我預先做好的angent.zip 到你的DialogFlow專案,
搭配這篇文章服用能更快理解以下內容的操作!
專案頁面
首先,點擊進入Default Welcome Intent,並更改系統預設的回應
刪除多餘的回應,最後只留下一個回應,並將其更改為:
「歡迎,你喜歡的顏色是什麼?」
3. 接著向下滾動頁面,我們要進一步設計這個Intent所給予的回應。
4. 在上述操作完成後,點擊「Save」來儲存剛剛的設定。
在昨日我們已經完成Actions On Google的專案設定
接下來,我們將接續設定Dialogflow!
您可能想知道Google助理如何解析用戶輸入的語義(如語音)。
這是通過自然語言理解(NLU)來完成的,它使Google的軟體能夠識別語音中的單詞。
對於開發者自己的Action來說,
Dialogflow簡化了理解用戶輸入,從輸入中提取關鍵詞和短語以用來回應請求的意圖。
開發者可以在Dialogflow定義這一切的運作方式。
接續昨日的對話流設計,
現在我們要進入實作的部分讓各位能更了解設計流程。
首先從設定 Actions On Google 專案開始!
它被用來專載你的Action,
無論是建構對話式Action或智慧家庭的介接都需要經過這一步驟。
若你未完成上述設定,可能會在後續的開發中碰到錯誤。
請確認你已經完成這些設定後再繼續操作喲!
點擊這個連結進入Actions On Google 控制台
點擊[New Project]按鈕
在跳出選單中輸入以下資訊:
進入初始化選單,在這裡請選擇「Custom」
進入進階選單,在這裡請選擇位在選單最下方的「build your Action with Dialogflow」
恭喜你,大功告成啦!
請待明天,繼續進行下一個DialogFlow專案的設定吧!
基於昨天所闡述的簡易對話流,我們今天來快速實作一個看看!
為求各位能迅速上手,我們將打造一個蒐集用戶顏色偏好的簡易語音應用程式。
經過我們這幾天所闡述的語音用戶介面設計,我們可以依據上述需求設計出一個初始的對話流。
對話角色 | 用戶輸入 / 系統提示 |
---|---|
用戶 | Ok Google, 與我的測試應用程式說話 |
Google助理 | 沒問題,接下來交由「我的測試應用程式」來協助你<earcon> |
APP | 歡迎,你喜歡的顏色是什麼? |
用戶 | 可以再說一次嗎? |
APP | 不好意思,請問你喜歡的顏色是甚麼? |
用戶 | 我想應該是綠色吧! |
APP | 真巧,我也喜歡綠色 |
Google助理 | <earcon> |
整體來說,
我們將要實作的對話流可以用下方的圖片表示:
接續前天所闡述的,我們有了假定使用者與一個賦予系統扮演的角色。
現在是時候讓它「動」起來了!
跟著下方的表格練習寫出一個初始的對話流吧!
步驟 | 內容 |
---|---|
第1步 | 專注在一位假定使用者以及特定的使用案例 |
第2步 | 找一位同伴並扮演對話的角色,其中一人扮演使用者;另一人則扮演Action的角色。(或者你也可以自行扮演兩種角色)在對話過程中將其錄製下來。 |
第3步 | 轉錄對話成文字。這是簡易對話流的初步樣貌。 |
第4步 | 瀏覽每個對話框,說出用戶的台詞,並在文本到語音 (TTS) 中播放系統角色要呈現的每個台詞。如果 TTS 聽起來不好,請試著重寫它或使用語音合成標記語言 (SSML) 來更改其性能。 |
第5步 | 以不同的假想使用者與使用情境,重複步驟1到4 |
開始編寫對話的最簡單方法是將您自己的專業知識作為第一個對話流的主題。
如此一來,你通常可以輕易判斷某件事聽起來是對還是錯,
即使他們無法以基本語言原則闡明為什麼聽起來會這樣;
因此,角色扮演對話是創建初始草稿和往後迭代後續草稿的最簡單方法。
在Google助理平台上
呼叫Google助理調用Action的方式,
依據用戶是否明白指出調用的Action而分為兩種調用方式:
使用者清楚地向Google助理表達欲使用的Action為何者
一般情況下,若使用者未向Action指定想進行的操作為何。
Google會將使用者導入開發者預定的預設歡迎畫面(Default Welcome Intent)
用戶也可以選擇在調用同時添加一個調用短語,
這方式得以將使用者直接帶到他們所請求的意圖。
其語言架構如下所示:
調用短語描述了Action的特定功能。
用戶調用Action時,可能會包含一個可以深度鏈接到特定功能之一的調用短語。
舉例來說,如果使用者想玩1A2B。
可能會直接向Google助理詢問。
而Google助理就會自Actions On Google平台尋找最類似的Action推薦使用者。
不過這項功能在中文版尚未啟用,只能在draft(草案)模式下試用。
在我們了解到與設計對話流息息相關的隱式調用與顯式調用後,
我們將繼續昨日設計對話流的旅程!
自前兩天範例中,我們看到受眾目標與假想使用者之重要性。
現在,我們能設身處地的以使用者的角度來設計對話。
為了避免對話不自然的尷尬情形發生,因此蒐集對話經驗就是個很重要的環節!
收集對話體驗不僅僅是定義Action的主要功能,而是一個必經的道路。
從這過程中,可以更了解用戶的需求和達成該需求所需的技術能力。
從明確的、經過充分研究的需求開始,是避免在設計途中發生重大更正的最佳方法。
現在你對於對話的角色有個相當清晰的概念(你的Action與你的使用者),以及他們所談論的主題。
那麼現在該是撰寫對話的時候了!
簡易對話流是在Google助理平台上創建出色 Actions 的關鍵:
這會讓你快速且稍微貼近真實地感受到你正在設計一個帶有「聲音」和隨之而來的互動應用。
它們傳達用戶實際體驗的流程,沒有任何程式符號、複雜的對話流程圖、或語音識別問題等技術干擾。
通過編寫簡易對話流,您可以非正式地試驗和評估不同的設計策略,例如:
我們將先了解上頭所提及的隱式調用、顯式調用在Google助理平台所指的各是甚麼。
再繼續前往我們設計對話流程的旅程。
接續我們在昨天所闡述的設計流程,
接著來看看這些設計流程是如何在實際運作的Action上被實踐的。
各位可以參考這個正在運行中的Action,
它的主要目的是協助使用者獲取所在地的AQI指數。
空汙查詢精靈 | Google 助理
主標題 | 說明 |
---|---|
誰是這位使用者? | Anna,25 歲,是一名上班族。由於自身有過敏史,對於空氣品質的相關資訊相當注意。 |
他們的目的是什麼? | 希望能快速獲取所在地的空氣品質資訊,而且能以簡單明瞭的方式得知目前的AQI指數以及相關的作為。 |
用戶的使用情境是什麼? | Anna 正準備出門上班。剛開始她的一天,正準備離開所居住的地方並前往公司。 想要再確認是否需要留意空氣品質相關的資訊。 |
描述對話過程中的每個關鍵時刻。 | Anna 首先獲取全台灣整體的空氣品質報告。接著依據自己所在的地區選擇查詢區域。之後,他得到所在區域的整體測站之AQI指數資訊。並獲取相對應的指引。Action提醒她:此時是一個空氣品質相對較差的時段並需要留意相關資訊,因此她出門前戴上口罩以作為防備。 |
如果想參考官方提供的範例,可以參閱以下的連結的說明
首先,在開始一個好的設計之前,
如同廣告投放一般,
我們需要找出目標受眾來設計出更符合他們的對話流程。
有以下幾點是我們需要留意的:
雖然針對最常使用的用戶進行優化很重要,但不要以犧牲其他用戶的體驗為代價。
精心設計的產品具有包容性和普遍性。
為不同人群設計意味著利用包容性設計或通用設計策略。
通常,您被迫為一個人群做出的調整最終會惠及所有人。
- 誰將是你的使用者?
假想使用者是一個特定的個別用戶且具備清晰的描述,
請試著想像:
你預期哪種類型的使用者將會使用你的Action,並寫下一些可能的用戶特質來代表他們。
這些用戶特質將會協助你避免建構出一個只完成你個人目標的Action。
- 使用者希望達到的目標是什麼?
- 他們會使用怎樣的詞彙來代表這個目標?
用戶在給定情境中透過你的Action完成目標的途徑。
- 描述對話流程中的每個相關時刻
關鍵用戶流程是那些 經常發生 或 對用戶至關重要 的對話流程。
旨在幫助用戶從頭到尾完成其中一個流程。
專注於這些將幫助您構建能夠覆蓋大量和或專門受眾的行動。
我們將會來看看一個實際運作中的Action,
看它是如何依照我們今日所提及的設計指引建構Action!
對話設計的核心是對話的流程及其底層邏輯。
因此,在將界面重新設計為對話式時,需要從下往上開始。
適用於圖形界面的邏輯幾乎永遠不會適用於對話界面。
設計對話流程前,需要考慮到所有可能的情形。
並給予適當的回應
避免單純把圖形化介面轉用在語音對話介面上,使人們能以習以為常的方式進行互動
建立一個人物形象
在正式開發前,選擇要代表這個語音應用的角色。
需建立在它所要面對的主要使用群眾與他們的所需。
用戶與之互動時,透過連續性的對話讓使用者對之建立一個一致性的形象
也就是該品牌與使用者之間的品牌大使!
傳遞形象的要點:
跳出固有的邏輯思維
跳脫思維,將設計的對話想像成劇本或是日常對話中的片段。
或是在紙上雜記的一個靈感,這些都有助你設計出一個優異的對話流程!
謹記:在對話中沒有「錯誤」存在
當你的Action在對話中無法了解使用者的意圖時,對使用者說「我不清楚你想說什麼」將使你的對話陷入厭惡與沮喪。
遇到這類情形時,與其要他們從中選擇。你要做的是引導他們做出正確的回應。
例如:
假設你想要使用者在A或B選項之中擇一,
你不應該在他們沒有回答出相應的對話時回應「無法瞭解意思」。
反而應該直白的問「**我這裡有A跟B兩個選項,你想選哪一個?**」
希望各位在看完這篇文章後,能對「語音介面設計」有更深一層的了解!
那麼接下來,進入設計語音應用程式「由下而上」的實作流程!
在進入正式的開發流程前,
先來簡單快速地了解語音對話介面的一些關鍵詞。
依據對話量多寡,可以粗略分為以下兩種對話的分類。
傳統上的對話都是單輪對話,而近日因機器學習的發展使多輪對話漸成主流。
示例對話:爲VUI挑選最常見的使用場景,爲這些場景寫一系列最優路徑的示例對話以及異常情況的示例對話。
VUI主要通過語音來反饋結果,確認訊息對於對話體驗非常重要,要做到這一點需要使用置信度閾值。
使用三級置信度時,系統將一定的閾值內以明確的形式確認訊息,若是訊息置信度小於45%,則系統會通過顯性確認訊息。若是訊息置信度大於80%,則系統將以隱性置信度來確認。
因環境噪聲或用戶聲音的輕重,導致系統出錯。
出錯的情況有:
大家好,我是Hank。
目前就讀於台科大資工所的研究生。
很高興有機會向大家分享我在開發Google Assistant語音應用程式的相關經驗。
那麼首先,
我先簡單介紹一下Google Assistant語音應用程式究竟是什麼?
它是一個介接於Google助理的一個基於語音設計界面的新型態應用程式。
使用者在向Google助理表明想使用某個特定的Action(動作)後,
Google會在Actions On Google平台上搜尋是否有對應名稱的Action。
接著使用者會被Google助理導引至Action的使用介面。
從此刻開始,Google助理的角色轉變為協助進行語音辨識與傳遞資訊的角色。
辨識使用者輸入的意圖與給予對應回應的工作則轉由開發者所設計的Action所執行。
is a fully distributed, software-defined managed service for all your traffic.
You can dynamically increase the size of a subnet in a custom network by expanding the range of IP addresses allocated to it. Doing that doesn’t affect already configured VMs.
a fully distributed, software-defined managed service for all your traffic.
VPC Peering : establish a peering relationship between two VPCs so that they can exchange traffic
Shared VPC : full power of IAM to control who and what in one project can interact with a VPC in another
Peering traffic (traffic flowing between peered networks)
Different applications and workloads required different storage database solutions
最短保留期限 | 存取頻率 | |
---|---|---|
Multi-regional | 無 | 高,於regional之間 |
Regional | 無 | 高,於regional之內 |
Nearline | 30天 | 約 1 次/月 |
Coldline | 90天 | 約 1 次/年 |
Cloud SQL | Cloud Spanner | |
---|---|---|
scale to higher database sizes | √ | |
presents SQL interface to clients | √ | |
offers transactional consistency at global scale | √ |
in classficatio of relational database
Cloud Datastore | Cloud Bigtable | |
---|---|---|
NoSQL | √ | √ |
scalable | √ | √ |
free daily quota | √ | |
SQL-like queries | √ |
Cloud Storage | Bigtable | Datastore | Cloud SQL | |
---|---|---|---|---|
儲存類型 | Object (BLOB) Store | NoSQL | Wide column NoSQL | Document |
資料儲存區域 | Multi-Regional | Regional | Multi-Regional | Regional |
Cloud Endpoints
Apigee Edge
[1]GCP 儲存空間(一): Cloud Storage/ Datastore / Bigtable / SQL 介紹與比較
藉由 Colab
大幅簡化Python初學者在設定環境以及安裝相關編譯器的時間。
藉由實作書本上的範例程式碼來學習撰寫Python。
書本採用Jerry老師推薦的
DATA SCIENCE FROM SCRATCH中文版:用PYTHON學資料科學
作者: Joel Grus
譯者: 藍子軒
出版社:歐萊禮
出版日期:2016-10-30
語言:繁體中文
時間:2021/3/2 ~ 2021/6/22
藉由 Colab
大幅簡化Python初學者在設定環境以及安裝相關編譯器的時間。
藉由實作書本上的範例程式碼來學習撰寫Python。
書本採用Jerry老師推薦的
《精通 Python:運用簡單的套件進行現代運算》(第二版)
Introducing Python, 2nd Edition
作者: Bill Lubanovic
譯者: 賴屹民
出版社:歐萊禮
出版日期:2020/06/02
語言:繁體中文
時間:11/10 ~ 1/5
如果希望參與線上讀書會,歡迎點擊Meetup的報名頁面