輕鬆在網頁上放銷售分店清單! Google 地圖應用工具 Quick Builder 體驗測試心得

之前看到一個科技新聞 Announcing Quick Builder, a new low-code tool for you to build location-based experiences、Google推出低程式碼工具Quick Builder，降低地理位置網頁應用建置障礙，簡單來說就是 Google Maps Platform 推出的一個工具，料理鼠王有 Anyone can cook 的理想，Google 則有 low-code development 的概念，號稱用戶可以將該工具生成的程式碼直接用於網頁應用程式中，或是作為範例參考並依照需求修改。

官網介紹頁在此 https://mapsplatform.google.com/resources/quick-builder/
實際操作的功能頁在此 https://console.cloud.google.com/google/maps-apis/build

首先可以看到現有 Google Cloud Console 的「Google地圖平台」裡面多了三個小東西，123站著穿

科技媒體的中文新聞是把原文的 you can get personalized, production-ready code 翻成「生成可直接用於產品的程式碼」
喔？真的嗎？
對於我這個常常幫人家更新銷售店家資料的工人，還有做個吸貓地圖來玩玩的人，對於這種工具是稍微有點感興趣，反正測試操作不用錢，來玩看看。

一、Locator Plus

官方介紹：吸引更多客戶上門，為貴商家建立及自訂定位器。
簡單白話就是有三種模式可選，各自會套上不同的 Google 地理服務相關 API，方便使用者建立一份地圖清單。
適合的線上應用 : 經銷商/商品銷售地點地圖、分店地圖、口罩地圖之類的東西。

第一步:選取設計
– 基本：在地圖中顯示圖釘。如果您只有一個服務據點，則建議使用這個選項。使用 Maps JavaScript API + Geocoding API
– 中等：提供自動完成功能，可協助使用者找出最近的據點。如果您有多個服務據點，則建議使用這個選項。使用 基本 + Distance Matrix API + Place Autocomplete
– 進階：提供詳細資料、路線和距離，協助使用者找出最理想的據點。如果您有多個服務據點，則建議使用這個選項。使用 中等 + Directions API + Place Details

第二步:新增地點

把要放在地圖上的地點都 key 上去之後，第三步驟可以：
– 將程式碼複製到剪貼簿
– 將程式碼匯出至 JSFiddle
– 將程式碼匯出至 Google Cloud Storage

看了一下產出的網頁程式碼，地點資訊是塞在 JS 陣列中

const CONFIGURATION = {
"locations": [
{"title":"xxx","address1":台灣xxx","coords":{"lat":24.xxx,"lng":121.xxx},"placeId":"xxx"},
{"title":"yyy","address1":"台灣yyy","coords":{"lat":24.xxx,"lng":121.xxx},"placeId":"xxx"}
],
};

使用 handlebars.js 來當 templating language，還有用 let 來宣告變數，雖然有用了 polyfill，但 IE11 仍然會報錯而無法正常顯示任何地點跟地圖，幸虧 2022/6 月就可以跟 IE11 說掰掰了。
第一步的設計模式選擇進階，最後產出的網頁還多了 view detail 可以點，點擊之後會透過 PlaceID 與相關 API 帶出地點的星星評分、營業時間…等資訊。

忽略老舊的瀏覽環境，在此步驟碰到的其他問題是:
1.輸入地點非常麻煩，必須要歷經輸入地址、點擊小地圖上的地點、點「確認據點」按鈕，至少三步驟才能新增完一個地點，而且之前輸入的不會留存，當然也沒辦法「匯入」，喜歡省錢花時間，要放的店家數又不多的可以玩玩。
2.沒辦法指定初始中心點，例如桃園、臺東、臺北各輸入一個地點，地圖預設是顯示全台灣。(要再自己改程式碼設參數)
3.中等/進階功能產出的網頁，左上角會多一個搜尋框，但在搜尋框輸入文字之後是用 Place Autocomplete API 找全球的地址或地標，跟剛剛清單上輸入老半天建的地點無關…
4.基本/中等功能幾乎只顯示地名和地址，卻佔掉螢幕左邊一大半來顯示資訊，(手機直立小螢幕時會顯示在螢幕下半部)，不管是只有1個地點跟30個地點，都用同一種顯示方式。
5.三種等級的範例都沒用到 JavaScript Map API 的 InfoWindow 資訊視窗、Custom Markers 自訂圖示功能。
6.想要使用 static map 之類比較便宜的地圖 api類型? 要顯示店家營業資訊但不要顯示星星數? 這個產生碼產生工具的功能非常簡潔，簡潔的意思就是對於比較進階的需求不會有視覺化的 UI 給你選，就是要自己看程式碼和文件自己改。
7.產生的左側功能列 UI 上面都是英文字，Enter your address or zip code 之類的，有特殊需求可能還要自己中文化。

應用場景跟實用度還不少限制，例如地點全部在室內(如百貨公司櫃點)、地點在 Google 地圖上找不到的，沒在 Google 店家登記的，地點在樓上的，想要在點擊店家之後增加線上預約/點餐之類的連結…..諸如此類的需求，想要直接使用 Google Quick builder 來解決? 理想跟現實可能還有點距離。

我更好奇的是有哪種營業狀況，可能有點規模，有N家分店要放在網站上，還執意要顯示地圖，但卻不想花錢請工程師或設計師設計瀏覽界面，這麼節省的情況，又要使用這種要先綁定信用卡，超量就要付錢的 Google Maps API 地圖?

那一樣用於在網頁中，同一地圖上同時顯示多筆地點資料，Quick Builder 這個功能跟很多美食、旅遊部落客或是公家機關愛用的「Google 我的地圖」(例如桃園確診足跡地圖(全國))有什麼差異呢? 做個一個簡易的比較表

就不展示 Quick Builder 實際產出的網頁了，不然下個月的 GCP 帳單不知道要多少錢呢。

二、地址選擇

官方介紹：讓表單填寫變得快速又簡單。協助客戶快速輸入地址，並盡量減少結帳或註冊的錯誤。
簡單來說就是產生一個可以輸入地址，然後會顯示地圖的表單。
適合的線上應用 : 到府維修的報修表單、地點回報表單之類的東西。

第一步:選擇是否要使用一堆地址都找不到的 Place Autocomplete API
第二步:設定地圖顯示方式

第三步:設定表單按鈕的CTA文字
第四步:產生程式碼

那個 Place Autocomplete API 在台灣使用真是難以控制，有一堆地址就是會跑不出來。
產生的網頁程式碼少了 meta charset 屬性，英文可能正常，中文顯示會亂碼，要自己手動補上。

如果有以下應用需求，那這個地址選擇功能肯定可以完美達成任務
1.表單需要輸入地址
2.而且這個地址重要到需要顯示地圖讓使用者確認，但右邊的地圖又無法直接讓使用者點擊選位置
3.能接受 Place Autocomplete 有很多地址沒辦法自動補完
4.能接受碰到有些地址路名(例如比較偏僻或巷弄複雜的地方、工業區之類的)可能無法正確顯示地圖

但一時之間還真的想不到誰能用到這個，凶宅網或噪音回報網嗎?
還是例如有些網拍賣家不申請 ezship API 或統一超商相關 API，就想在網頁表單上跑出超商電子地圖給人選? 那還不如申請 7-11 賣貨便、全家好賣家就好了。

三、探索鄰近地區

官方介紹：利用在地知識自訂地圖。協助使用者瞭解鄰近地區，讓他們探索餐廳、學校、公園等當地景點。
簡單來說就是可以定一個中心點+距離，然後勾選要顯示的周圍景點種類，也可以手動新增地點上去。
適合的線上應用:民宿/農場/遊樂設施想做網站時，可以用這個功能快速做出一頁周圍景點地圖，或是新生入學的時候，可以做個周圍用品採買的地圖給新生看

操作步驟大致如下:

第一步:選一個地點
第二步:勾選設施類型，也可以點新增或移除地點，自己手動新增

第三步:確認設計選項(選擇顯示的資訊，有以下三種可以選)
進階:客戶可以查看鄰近地區的熱門景點，包含評分、評論和下列各項資訊。
中等:客戶可以搜尋喜愛的商家，並查看其他詳細資料，例如營業時間、聯絡資訊和下列各項資訊。
基本:客戶可以在動態地圖中查看重要的當地景點，包含地址、相片、行車時間和路線等基本資訊。

第四步當然就是產生程式碼，出來的東西長這樣，系統說西門町附近的夜店有這些:

重新定義夜店

測試之後發現不滿意的地方
1.似乎會遺漏地點，例如勾選提款機、郵局銀行之類的，就是會少了幾台，或是地標明明存在，但近的沒列出來反而顯示遠的，不知道為什麼。
2.如上範例西門町附近的夜店，系統給了 30 間，而這些景點資料是寫死的，用像下面這種 placeID 的方式塞在最後步驟的網頁程式碼內，也就是說以後如果有新開的店，或是舊的收掉了，應該還要回到 Quick Builder 重新產生檔案。

"pois": [
{"placeId": "ChIJJ6OuLg-pQjQRDfq7CLUh-Ac"},
{"placeId": "ChIJW5j0tgipQjQR5uBGVxfLmRY"},
}

以前大學時打工當管宿舍的，每次新生入學時都有一堆家長跟學生問說附近哪裡有賣XXX的，於是有一年突發奇想，用平面設計軟體弄幾張A3大小的海報(報公帳)，把 Google Maps 截圖放大，然後把附近的超商、全聯、NOVA之類的大家常問的地點都標出來，那時候 iPhone 剛出來，只能用這種不數位的方式。
現在這時候網路跟隨身上網裝置更普及，應該有更方便的方法了吧?

結論

1.Quick builder 這個概念還不錯，用一些看似很簡單的選項與拼裝程式，有望讓更多使用者入門 Google 的 API 並產生花費，那除了 Teachable Machines 跟 Quick builder 這種會提供範例程式碼，Google 會不會也讓更多的 Cloud API 服務，直接無腦按一按就產生可用的程式? 也許有機會，但很渺茫。
就像以前有聽過別人問說為什麼 github 上的程式碼不能直接線上執行? 因為很多「程式」並不是能在網頁瀏覽器裡面執行的，或是沒有輸入，也無法輸出什麼視覺化的結果。或是有些 API 的用途無法單獨執行(例如 Cloud Vision API 可能還要包含一套檔案上傳程式)。還有 Google 的關閉部門惡名昭彰，不知道幾年後 Quick builder 是不是也像 Google+, Google Reader 一樣慘遭關閉。
2. low-code development 不是什麼新概念，歷史上一堆類似 code generator, app builder 之類的東西長江後浪推前浪，但是真的有解決需求? 還是浪費時間產生一堆不合需求、又很難維護修改的程式碼、製造更多問題? 只有使用者自己知道了。
也常常看到網路產品打著「不會寫程式也能XXX」的廣告詞，真是鬼扯，
例如上述的地址選擇表單功能，為什麼不能直接讓使用者同意授權，瀏覽器取得位置資訊之後，表單自動填入地址到XX號X樓? 因為得到的位置資訊不是一般人想的幾號幾樓。
搜尋框的 Place Autocomplete API 跑出不合預期的地址，探索鄰近地區勾 ATM，但沒出現超商裡的提款機怎麼辦? 這個沒辦法「叫工程師修一下」。
Quick builder 產出的網頁程式碼，在某些瀏覽器開起來一片空白，或中文出現亂碼，這個原因也不是 Google Maps API 的問題。
若完全不懂背後的技術或基本知識，當製作產出結果不符預期，要怎麼知道是 API 的限制，還是工具的問題，還是網頁技術的限制，還是瀏覽器的限制呢? 可能連需求和製作規格都開不出來啊。