Audi Home of Quattro 技術回顧

https://www.audiquattro.hk/

這是一個在維港海上的車展
展示最新的 S3 Sportback, RS6 Avant 和讓用戶可以分享他們最喜愛的駕駛路線

在桌面和手持裝置上,有活力的頁面設計和動畫過場都能將品牌的形象展現
在互動性的地圖上帶出享受的體驗,不論在船上或網站上

基本架構: PHP codeigniter, jQuery mobile,

Mobile site

這次沒有使用 responsive design 而使用一個獨立的手機版網頁 (https://www.audiquattro.hk/?device=mobile 直接在桌面看手機版)
然後在每一個頁面根據裝置跳轉
使用Mobile detect做裝置檢測
並使瀏覽器跳轉到正確的 URL

Google map 樣式客製

我們使用了自定義樣式的地圖
Google map 本身有提供一個強大的樣式功能 (https://developers.google.com/maps/documentation/javascript/styling?csw=1)
可修改道路,海面,公園等的顏色
令我們可以將地圖完美配合到網站的色調

Google map 路徑API

這個網站中一個互動的功能是用戶可以建立並分享他們覺得有趣和有挑戰的行車路線
我們使用自定的錨點和 Google directions API (https://developers.google.com/maps/documentation/directions/)
令用戶可以點擊兩個地點而劃出行車路線

也對應手機版本
我們使用手機上的 html5 geolocation API 令用戶可以使用用戶現在的位置設計路線

這一次我們深入地客製google maps 和使用它的數個週邊 API
是一個全新的挑戰
而且得出的效果也非常好,也體驗到 Google map API 的強大
我們可以在上面建立順暢的過場動畫,錨點,markers,overlays等等
就像是一個客製的地圖一樣

Video playing

每一個知名的車手都有4段視頻,車手們之間使用 slideshow 的形式表現
我們使用的是 html5 video plugin http://www.videojs.com/ 播放伺服器上的 mp4, ogg
所以 html 上會有12段視頻
但我們發覺 browser 是有一個 video 的緩存限制
令 video 的 buffer ready event, onload event 不會啟動
(我們只會在 4段 video 都 buffer 完成的時候才會播放)
但這個情況只會在一個頁面放多於 10 個 video 的時候出現
而我們又找不到 browser 相關的技術文件
所以我們只好在 slideshow event 後 insert/remove video tags 來處理「一個頁面不多於 10 個視頻」的限制

Hennessy Artistry 2013 技術回顧

Hennessy Artistry 2013

這是一個送門票的活動,游戲旳玩法如下:

  1. 用戶甲參加游戲
  2. 在三十分鐘之內邀請另外兩個朋友 like 和參加游戲
  3. 他們一共會得到三張門票

一個看似簡單但其實複雜的流程,果難在於:

  • 一天之內只可以有十組人得到門票
  • 20 日的活動其間, 一個人只可以拿到一張門票
  • 三十分鐘的時限一過,用戶便會失去位置,其他人便可以「搶」這三個位置
  • 邀請方和被邀請方的顯示方式,文字都不一樣

最後的一點令我們底估了這個案子的難度和所需的時間。我們沒有預估到測試邀請方和被邀請方的互動是會如此困難。除此之外,還有幾個技術性的問題可以談談:

DNS 問題

我們發覺頁面的載入時間非常長,大約需要5秒的時間,不論是轉換語言,或者是 AJAX 請求都一樣。我們明白這個 tab 有比較多和 facebook 的互動,用戶的資料, signed request,access token,extended access token 等,所以有一些載入的時間是正常的,但5秒真的是太長了。所以我們立即做了一些基本的伺服器優化。一個 Redhat 的伺服器,簡單的 APC, mysqltuner.pl 之後,快了 5ms ,太好了。

這個應用也有很多查詢,有多少空位置,多少個可以參加的朋友,那個朋友已經參加了等等,所以增加了 innodb 緩存,table cache 加大等等⋯⋯無用

然後發覺開發的環境只需要大約一秒便可以返回頁面,就將問題指向網路問題了。但直存最伺服器上的圖片不發覺有問題,速度很快, ping facebook.com: 200ms 看來也是正常的範圍 graph.facebook.com? 200ms. 等一下,本機的 ping 是: 2.8ms !?!?

直接修改 /etc/hosts:
31.13.68.49 graph.facebook.com www.facebook.com

BLOOM! 返回時間由 5s 變成 1s.

Facebook notification api

https://developers.facebook.com/docs/games/notifications/ 看來是簡單到不行。POST 到一個指定的路徑,帶上用戶的 access token,返回 JSON 結果,簡單又容易。你需要產生一個 app access token,放在代碼內,一直重複使用便可。

發佈到用戶的的牆上,使用 extended access token

傳統上, Facebook 提供一個 share dialog: https://developers.facebook.com/docs/reference/dialogs/feed/. 可以照顧到一大部份的要求,但:
縮圖只有一個小方格 75x75
需要用戶的動作才可
所以 facebook 有一個新的權限 “publish_actions” ,可以使用 api 發佈到用戶的牆上, API ref: https://developers.facebook.com/docs/reference/api/post/ 例子: https://developers.facebook.com/docs/php/howto/postwithgraphapi/

提一下,這裡使用的是用戶自已的 access token,和 access token 是會過期的,而預設返回的 access token 很快便會愈期,或者用戶登出都會做成 access token 愈期。你可以使用setExtendedAccessToken() https://developers.facebook.com/docs/reference/php/facebook-setExtendedA... 拿到一個大約兩個月愈期的 token,和用戶的資料一起儲這個長度無上限的 token。

關於 apprequest

Screenshot: https://developers.facebook.com/docs/reference/dialogs/requests/ 是一個有用戶的朋友可以選取的 popup,但有一個容易被人忽略的重點:這是一個 app 的邀請,而非一個 fan page 的邀請。被邀請的用戶會在他的通知欄看到一個邀請,點擊之後會連到 app 的頁面 (app.facebook.com),而非粉絲頁,並不可以修改。這個重要的不同令這裡需要多一個跳轉的機制,由 app 頁跳到粉絲頁面。

實際的操作是如果使用者是透過通知欄跳轉,會有一個沒文檔的 URL parameters fb_source=notification ,檢測存在後使用 window.top.location.href 跳轉到粉絲頁,完全是一片混沌。

Facebook tab + mobile

最後,在移動裝置上的粉絲頁是看不到 Facebook tab 的。Facebook 提供一個選項 “mobile URL” ,但直到現在,我仍然不知道這個選項上的路徑會在什麼時候使用到。但我們仍然做了一個手機版,推廣的同事就可以對應移動裝置使用另一個 URL

Snapshot: 

網頁工程師們的兩難:問中間灰色地帶的責任

情境題:AJAX POST 到 /user/create
究竟是

前端HTML工程師要找出路徑 /user/create 放到 JS
還是後端工程師在完成 user controller 之後負責修改 JS 檔?

這個中間灰色地帶的責任問題一直困擾我們的工作
在某些複雜的 AJAX GET, POST, Facebook API 等多個溝通點的情況之下
中間 integration 需要的溝通量有時差不多和開發的時間相等

前端不想打開 controllers 找出 controller 的 method
後端不想看 JS 的 jquery object, success callback 還可能需要 handle HTML
但在這個兩難式中間
始終有一個人需要完成灰色的工作

我們需要一個有效率而又相對公平的方法
還是這就是工程師們必要的溝通?
那遙距的團隊要如何解決這個問題?

Audi A3 Facebook app

我們Document On Ready為 Audi 發佈了 https://www.facebook.com/AudiHK/app_137123389829201 已經一般時間了
這是一個 facebook tab 內的遊戲
目的在於介紹他們的新車

Document On Ready have launched https://www.facebook.com/AudiHK/app_137123389829201 for a while now
A facebook iframe app, which is not exactly a site building project we usually do
Aiming to promote their new car

我們主要負責技術開發的部份
和其他網頁設計師合作,一邊試驗 iframe 遊戲的限制
一邊將可玩性推到極限
一邊絞盡 facebook 的爛文檔
一邊為順暢的使用者登入體驗修正
當然也有為神聖的 IE 專門調敎一番

We mainly focus on the technical development
Working with other web designers, reaching the limits of iframe games
While pushing the gamify element
Crunching facebook's rotted developer docs
While smoothing user's login experience
And last of course, the holy IE special force comes in

正式進軍「Campaign」,「banners」一類時間性更強的巿場
And we officially joined the "Campaign", "banners" market

Snapshot: 

Doodcard Day 54 - intro to Doodcard

TL;DR
Doodcard 係一個為餐廳而設的會員系統
我的 startup life 轉眼已經開展了二個多月了
準備記錄一下宅男駛入「商業」這個大海的風風浪浪

﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣﹣

話說2012年9月尾我和我上一任僱主分手了(和平地)
我隨即開始展開我一直響往的「自由職業者」的生活
就是其他人付錢給我,我為他們寫程式的生活
在家工作,生活作息,睡眠時間都很隨意
12年十月:宜蘭
13年一月:泰國
三月:名古屋
六月: Drupal camp Taipei
七月: COSCUP
九個月飛五次,算是我人生「吸收高空幅射」的高點了吧
都算神仙般的生活,客戶們也待我不薄,薪水甚至有比打工的時候高一點

轉眼間,六七月的時候開始想做自已的 product
由brainstorm idea, business model,準備 budget,prototype
Doodcard 的計劃就誕生了
入表申請 incub-app,一個科學園的科技育成計劃
也順利在八月中正式進駐
轉眼已經快要兩個月了

我完全是一個科技宅
為了「自由職業者」的生活和客戶聯絡
寫 quotation, proposal
已經覺得自已在「商業」這大海中浮沉了一段時間
好像都可以順風而行
直到真的要找 Doodcard 第一個顧客,惡夢原來才剛剛開始

Pages

Google