本部落格已搬家
點此前往新部落格

新主機測試中...

你知道你的網站可能在 InAppBrowser/webview 無法使用嗎?

你知道你的購物網站,可能在 Facebook App 裡面無法結帳嗎?

最近遇到一個案例,購物網站上線後,廠商說許多消費者回報「購物車無法刪除商品」,選擇取貨的超商分店後「無法跳回原本的結帳頁面」。工程師用了幾十年 的 JavaScript confirm() 跟 window.open() 語法,到底會有什麼問題?

一開始以為是資訊界的「顧客整人」理論(註一)。但是深入了解後,終於重現發生問題的情況: 網站主要導流來源是 Facebook 粉絲專頁,只要使用者使用 iOS Facebook app 內的瀏覽器開啟網站,一些 JS 功能就會失效,但如果將連結使用一般的 Safari 瀏覽器開啟,則是一切正常。這種 APP 內的瀏覽器有個專有名詞,叫做 InAppBrowser,或是對 App 開發人員,叫做 "UIWebView"。

註一: 服務業有所謂「顧客至上」理論,不需要任何邏輯,花錢的就是大爺,客人就是神。資訊界則相傳有「顧客整人」理論,程式不會有問題,一定是使用者不會用,或是軟硬體太舊或太新,造成相容性問題。

再找了一些瀏覽器功能支援度的線上測試工具,用這年頭最新的 iOS 9 實機測試,Safari 跟 InAppBrowser 的確會跑出不一樣的分數,證據確鑿! 明明在同一台裝置上,都可以看網頁,但卻是不一樣的東西。

除了那些細部的測試,另外之後也初步條列出幾個常用,但是會在 InAppBrowser 發生問題的語法:

- alert() :無法出現對話提醒視窗,所以「請填寫某欄位」之類的提示通通看不到,假如姓名欄位必填,有個使用者沒填姓名,但是他點送出的時候,網頁也無法提示「請填寫姓名」,使用者只會看到點了送出,怎麼網頁都沒反應?

- confirm() :對話確認視窗無法出現
if(confirm) 的行為通通無法繼續操作。「是否確定刪除購物車內的商品?」之類的確認視窗通通看不到,也無法操作,這是使用者體驗的一大忌,因故完全無法操作,但使用者又無法得知發生了什麼事。

- window.open 或 window.opener:與電腦上完全不同的顯示行為。
會有兩種情況產生,一種是點擊後毫無動作,如果選超商分店之類的 emap 是用 window.open 來做,那使用者是無法選擇超商的。target="_blank"倒是可以用的,沒問題。
另一種是會覆蓋原本的頁面,而不會在新視窗開啟。如果沒有特別作紀錄,將導致使用者剛剛輸入的內容被清除掉,又得重新輸入。

- window.close 或 self.close :失效。
承上,因為頁面已經被覆蓋掉了,所以一些指定視窗跳回的也失效了。程式可以接收到傳回的資料值,但使用者只會看到精美的空白畫面,無法關閉分頁。有些 App 按返回,會直接跳回 App 的文章,而不是網頁的上一頁,不管是卡在空白畫面或是無法回上一頁,等於結帳流程完全被中斷。

但是裡面有內建瀏覽器,而預設不會直接呼叫 Safari 開啟網頁的 App ,不只有 Facebook 呀!
又測試了一些比較常見的 App,檢測以上項目,只要有一項無法操作,就打叉。

  • Facebook (X)
  • Line (O)
  • Plurk (X)
  • Pinterest (O)
  • Pocket (X)
  • QQ (O)
  • Twitter (X)
  • Wechat (O)
  • Whatsapp (O)
  • 新浪微博 (O)

除了上述的社群軟體或閱讀軟體,其實還有掃描 QR code 的軟體要測,但是太多了,先忽略。以上是 iOS 中發生的問題,至於 Android 呢? Android 4.x 跟 Android 5.01 大致上沒發現這問題。

這份問題 App 清單不一定是準確的,因為症狀通常不會同時出現,還有可能某 App 今天沒事,但更新後就有問題了。或是本來有問題,但某天 App 更新後就正常了。還有明明 App 已經修復此問題,使用者卻從來都不知道要更新 App,繼續使用有問題的版本。

解決方案
現在是科學的時代,先把網站的 GA 報表叫出來看看影響層面究竟有多大? 是否真的有需要解決? 但數據表示用行動裝置的比用桌機的還多,iOS user 更是 Android user 的兩倍,所以目標客戶群主要還是拿 iOS 裝置的使用者,這問題是不能不找出解法了。

網站已經上線好幾週了,這種裝置不支援的問題算 bug 嗎? 網頁公司是否要無償去修正?
那 Flash 在手機上面不能看也算 bug 嗎?
XX 銀行的 WebATM 只能在 IE 上使用,不能在 Chrome上面執行,算 bug 嗎?
廠商把責任推給網頁公司,網頁公司把責任推給 Mark Zuckerberg,Mark Zuckerberg 把責任推給 Steve Jobs,所以先準備買機票去美國抗議,使用者的問題最後還是沒解決,事情不是這樣幹的。

這時候要拿出將太的壽司的經典台詞之一:

改程式、跟開設測試機都是要花錢的,先來考察別人都怎麼解決的:

1.網站公告法
用 Google 找了一下,這種「請消費者用預設瀏覽器開啟網站」的說明文還真不少,
隨便舉幾個來瞧瞧:

案例四 - 批踢踢網路創業板 - 緊急分享 fb app更新影響訂單成立

正常的購物行為,不管是明確型還是閒逛型購物,會先去看公告才開始消費的使用者比例其實是不高。如果叫廠商的 FB 小編每次發文時都要加「請消費者用預設瀏覽器開啟網站」,或是「請消費者自己更改 APP 開啟網頁的預設值(這個設定iOS 沒有,只有 Android 的 Facebook app 才有。)」,都是不夠理想的作法,應該只有花不起錢,或是時間有限的廠商才會做這種事。

2.自動提示法
訪客每天嘩啦啦的進來,問題持續存在。如果抱著老公務員心態,遵照一般流程,先寫報價單、等客戶確認簽回、開設測試主機、調整程式、內部測試、客戶驗收,更新正式機,客服人員都崩潰了,應急處置就先來做個提示,判斷如果用 iOS 的 FB APP 開網頁,則會跑出一個「請選擇在 Safari 開啟」的提示。

首先發現從 FB App 進站,會帶來源網址(document.referrer),依不同裝置與不同 App 版本,至少會有 http://m.facebook.com, http://m.facebook.com/, https://m.facebook.com, https://m.facebook.com/, http://lm.facebook.com, https://lm.facebook.com/, https://lm.facebook.com, http://lm.facebook.com/ 這八種,所以我們可以用上述 document.referrer 再搭配 iDevice 的 UserAgent 判斷式,來顯示「請選擇在 Safari 開啟」的提示訊息。

但是後來讀取 iOS FB InAppBrowser 的 UA 字串,發現裡面通常有 FBIOS 的字,所以可以簡寫成
if (navigator.userAgent.match(/FBIOS/i)) {
// show something...
}

以上是針對 FB app 的,那其他的哩? 一樣可以用實機去測 UA,用 UA 裡的字串來做判斷。
只是以後每流行一個新的 app ,就要去查一次 UA,再加一些判斷式嗎? 得找找有沒有治本的方法。

3.更改程式法
台灣是 FB 生態系,網站最基本的需求在 FB 上面要完美,不能分享時顯示一些亂七八糟的摘要,還有購物網站要可以完成購物流程。中國大陸地區則是 WeChat 生態系,H5 頁面最基本的標準是要在 WeChat 裡面可以跑,網路上一樣有許多前人分享血淚史。

去考察一些連小學生都知道的國內外知名購物網站,或是所謂行動開店服務的網站,是怎麼處理上述問題的。赫然發現,瑞凡,已經沒有人在用 alert(), confirm(), 或 window.open() 了!

alert(), confirm() 的歷史悠久,保證絕不出錯,比較不會有詢問視窗還沒按確認,但是程式卻在背後偷跑的情況,也不怕有人關閉視窗,或是繞過去。但是卻有可能有使用者去勾到「防止此網頁產生其他對話方塊」,這樣網站不管執行任何動作,都不會再跳出確認與詢問視窗,造成非常多的問題。每一種瀏覽器的解除法也不一樣,大大增加了客服人員的處理時間。

另一個問題是在每一種瀏覽器、每一種裝置,對話視窗都長得不一樣,如對話視窗的位置,IE 跟 Firefox 在中間,Chrome for PC 在上方,還有按鈕文字也不同,有的「確定」顯示在右邊,有的「確定」在左邊,在 iOS 上面則顯示「好」,帶來完全不一致的使用者體驗。

window.open() 的好用之處在於可以保留原本的視窗,程式不需要先額外記錄使用者原本輸入的東西後再把視窗轉走。但常見問題則是被瀏覽器的攔截廣告彈跳視窗功能擋住,使用者要發現瀏覽器網址列或是某處多了一些紅叉叉或提示訊息,再去按允許,讓網頁重新整理一次,才能看到應該要顯示的視窗。或是開發人員設定了 windows.open 的尺寸,但是在行動裝置上卻不聽話,造成異常大的空白區域。

所以一般大型購物網站是如何排除這些問題呢?

  • alert: 使用另外的 Modal, Dialog, Message 相關元件,如淘寶,91APP。
  • confirm: 使用自製的 Modal, Dialog 元件,或是直接執行動作,但是有個復原按鈕可以按,如 Yahoo 拍賣。
  • window.open/self.close: 選擇超商的視窗時,先把使用者當下輸入的資料記錄起來,然後整頁轉過去,選完之後再整頁轉回來,並把使用者先前輸入的資料塞回去,完全不彈跳額外的小視窗。如 Yahoo 商城。

結論:
資訊業一日千里,一套程式就想用一輩子是不行的,有些程式只能解決古代的問題,無法解決現代的問題。只會吹噓古時候的成功案例,但是無法滿足現代的客戶,是一點用處都沒有的,必須要常常更新才能更上時代。

但是管理階層或業務常會有「這套程式給某大客戶都用得好好的,幹嘛要更新?」「用起來好像沒啥差別呀,重構後的跟舊的差在哪?」 的想法,只能說很容易換了位子就會換了腦袋。

以前高中老師說過,看到一個現象就解釋一個說法,這不叫科學。
但是後來發現常常在做不科學的事,見人說人話,見鬼說鬼話,科學是假的,達成自己的目的才是真的。


這篇文章有幫助到您嗎? 歡迎 😀打賞贊助


Comments 轉載文章請留言說一聲

comments powered by Disqus