- 在編輯地點標記的說明內容時，點擊編輯框上方的【照片】功能，可以在設定Google帳戶資訊後（若已經設定過會略過本步驟），顯示在Picasa網路相簿內的各本相簿，點擊相簿圖示可以顯示相簿內所有照片。點擊照片圖示，可以在編輯框內插入該圖示的照片網址。儲存後，該照片網址可自動轉換為Picasa網路相簿的圖片。
- 登入使用者在擁有身份的站台，地圖上方點擊【匯入Picasa】連結，可以在設定Google帳戶資訊後（若已經設定過會略過本步驟），顯示在Picasa網路相簿內的各本項不。點擊相簿資訊內的【匯入具備地理位置標記的照片到這個站台】連結，可以將相簿內所有具備有地理標記（經度和緯度）的照片，自動匯入至站台內。匯入完成的地理標記名稱，是照片的標題，描述內容為該照片的網址（會自動轉換成Picasa網路相簿照片）。
2009年12月5日
新功能：匯入Picasa網路相簿
新增Picasa網路相簿的匯入功能：
2009年12月2日
改版：Google AJAX API
先前TWW採用的 Google Maps API 係較早期的 GMaps 版本，事實上 Google 自從野心愈來愈大，預備將所有服務整合後跨足至作業系統提供者，於是整合出了另外一個 Google AJAX API 的版本，共用同一組API key，但可以在一個網頁內同時載入多種Google提供的開源服務API。
二者唯一的差別是，原先 GMaps API 的 class 名稱均以 "G" 大寫字母開頭，例如 GMap2，改採 Google AJAX API 之後，這個 class 名稱就得寫作 google.maps.Map2。差異不太大，只要將整個專案內有用到 GMaps API 物件和類別的地方，修正首字母即可。
會願意這麼釜底抽薪改採 Google AJAX API 的原因，是看在這個新版的 API 是 Google 未來趨勢，同時也支援了 Picasa Web Album API 的原因。接下來 TWW 的下一個主要改版功能，就是要整合 Picasa 網路相簿，將使用者的圖片，和圖片的地理標記位置設法載入至 TWW 的標記當中。
順道一提，前面兩個 Google Maps API 和 Google AJAX API，都提供有適宜閱讀的正體中文版本，對於開發人員而言更為便利，較之去年我剛開始研究 GMaps API 時好多了。只可惜目前 Picasa Web Album API 還沒有中文化，閱讀起來稍微有些吃力。
二者唯一的差別是，原先 GMaps API 的 class 名稱均以 "G" 大寫字母開頭，例如 GMap2，改採 Google AJAX API 之後，這個 class 名稱就得寫作 google.maps.Map2。差異不太大，只要將整個專案內有用到 GMaps API 物件和類別的地方，修正首字母即可。
會願意這麼釜底抽薪改採 Google AJAX API 的原因，是看在這個新版的 API 是 Google 未來趨勢，同時也支援了 Picasa Web Album API 的原因。接下來 TWW 的下一個主要改版功能，就是要整合 Picasa 網路相簿，將使用者的圖片，和圖片的地理標記位置設法載入至 TWW 的標記當中。
順道一提，前面兩個 Google Maps API 和 Google AJAX API，都提供有適宜閱讀的正體中文版本，對於開發人員而言更為便利，較之去年我剛開始研究 GMaps API 時好多了。只可惜目前 Picasa Web Album API 還沒有中文化，閱讀起來稍微有些吃力。
2009年11月30日
新功能：標記的移動軌跡
經過幾天的研發，我們終於順利完成了地圖上標記移動軌跡的功能。
一般訪客可以在進入站台網頁後，於左手邊的選單中，看到多了一個【移動軌跡】的子頁面。點擊【移動軌跡】子頁面的標籤，可以看到這個站台中具備有移動軌跡紀錄的標記。請注意，並不是所有標記均被設定了移動軌跡，需由站台的協力作者們自行編輯移動軌跡的內容，訪客才能瀏覽觀看。
在移動軌跡頁面的各個標記名稱下方，可以看到「播放」和「停止」兩個按鈕。點擊播放按鈕可以立即將地圖導引至該標記所在處，並自動開始播放移動軌跡。正在播放移動軌跡的當中若再次點擊播放按鈕，將不會有任何反應。你可以點擊「停止按鈕」中斷播放，並將標記推回至原始出發點。
站台用戶登入後，可以在編輯標記的頁面中，看到「編輯軌跡」的連結。點擊「編輯軌跡」後，左手邊的選單將呈現為該標記的「軌跡編輯頁面」。軌跡編輯頁面裡共有十個可設定的時軌，你可以在右邊地圖上將正在編輯軌跡的標記，拖曳至某個地方，然後點擊某個時軌的「←」按鈕，以將地圖上目前標記所在位置，設定該時軌。你也可以點擊「X」按鈕將某個時軌的位置設定移除，或者點擊「→」按鈕，將地圖上標記的位置復原至該時軌的設定。
當你標記的移動軌跡編輯完成後，點擊「編輯軌跡頁面」右上方的儲存按鈕，可以將左手邊選單恢復成正常使用的狀況。此時，你可以在【移動軌跡】子頁面內，看到你剛才儲存的移動軌跡，點擊播放按鈕來立即查看標記移動軌跡。
一般訪客可以在進入站台網頁後，於左手邊的選單中，看到多了一個【移動軌跡】的子頁面。點擊【移動軌跡】子頁面的標籤，可以看到這個站台中具備有移動軌跡紀錄的標記。請注意，並不是所有標記均被設定了移動軌跡，需由站台的協力作者們自行編輯移動軌跡的內容，訪客才能瀏覽觀看。
在移動軌跡頁面的各個標記名稱下方，可以看到「播放」和「停止」兩個按鈕。點擊播放按鈕可以立即將地圖導引至該標記所在處，並自動開始播放移動軌跡。正在播放移動軌跡的當中若再次點擊播放按鈕，將不會有任何反應。你可以點擊「停止按鈕」中斷播放，並將標記推回至原始出發點。
站台用戶登入後，可以在編輯標記的頁面中，看到「編輯軌跡」的連結。點擊「編輯軌跡」後，左手邊的選單將呈現為該標記的「軌跡編輯頁面」。軌跡編輯頁面裡共有十個可設定的時軌，你可以在右邊地圖上將正在編輯軌跡的標記，拖曳至某個地方，然後點擊某個時軌的「←」按鈕，以將地圖上目前標記所在位置，設定該時軌。你也可以點擊「X」按鈕將某個時軌的位置設定移除，或者點擊「→」按鈕，將地圖上標記的位置復原至該時軌的設定。
當你標記的移動軌跡編輯完成後，點擊「編輯軌跡頁面」右上方的儲存按鈕，可以將左手邊選單恢復成正常使用的狀況。此時，你可以在【移動軌跡】子頁面內，看到你剛才儲存的移動軌跡，點擊播放按鈕來立即查看標記移動軌跡。
2009年11月25日
網站副標變更成「曾去過!!」
原先ThereWeWere的網站副標題為「美景當前!!」，這個中文詞彙對於SEO而言不具備特殊意義，也與ThereWeWere的英文辭意差距很大。
今日調整中文副標題為「曾去過!!」，雖然非常白話，當更為貼切ThereWeWere英文原意。
同時，將網頁的title顯示順序調整，若直接開啟某站台或某標記的永久連結，該站台或標記名稱移至網頁標題的最前方，以利搜尋引擎顯示更為顯目。
今日調整中文副標題為「曾去過!!」，雖然非常白話，當更為貼切ThereWeWere英文原意。
同時，將網頁的title顯示順序調整，若直接開啟某站台或某標記的永久連結，該站台或標記名稱移至網頁標題的最前方，以利搜尋引擎顯示更為顯目。
新技術：在地圖上控制標記的移動
日前研究出了一個新的技術，讓地圖上的標記可以移動。這個技術目前僅發展至prototype原型階段，且應用至網站的「關於我們」、「使用說明」、「快速按鍵」等上方公用標記，當點擊網頁右上方這些公用標記的連結時，無論目前地圖中心點在何處，都會載入公用標記後，讓公用標記移動至地圖中心點並開啟。
計畫中這個移動標記的功能，會持續延伸發展成為軌跡的基礎，並可能加上時間軸的概念，讓訪客可以拉動時間軸來瞭解標記移動的歷程。
2009年11月21日
SEO：調整永久連結網址
為改善網頁搜尋效果，將永久連結網址URL後方加註 ".html" 字樣，使成 http://therewewere.takol.tw/s.ICLI4I.html 此種格式。
於永久連結網址開啟頁面，新增SEO區塊，放置該永久連結網頁內容的摘要，以利搜尋引擎辨識網頁內容。
新增功能：多重站台標記顯示
允許使用者在登入狀態下，點擊【站台】頁面，可多重選擇要於地圖上顯示的站台標記。除目前所在站台不可取消顯示外，可另行勾選顯示該使用者有參與的站台。
公用站台或未登入使用者不提供這個多重顯示的功能。
2009年11月11日
網域移轉
由於原先的ThereWeWere.org網域名稱到期，為了避免產生更多成本，暫時將ThereWeWere的網址改為 http://therewewere.takol.tw 。同時將官方部落格網址改回至 http://therewewere-blog.blogspot.com 。
2008年10月25日
暫時取消支援 HTML 語法
原本標記內容的 HTML 語法我並沒有禁止使用，以方便幫助我測試的朋友們貼上一些例如 YouTube 或 BuubleShare 等 widget，來豐富各地點標記的內容。但今日新增的訪客標記功能一旦開放，HTML 語法很可能成為系統安全上的一個漏洞，讓有心人士貼上 JavaScript 或嵌入隱藏式的 iframe 產生 cross-site-scripting (XSS) 的攻擊行為。
因此，目前暫時取消了在標記內容支援 HTML 語法，凡是在角括號 < >內的文字都會被自動忽略不顯示。至於 YouTube 和其他常見的 widget，例如 flickr 和 flash 等，未來可能會以其他特定語法格式來替換。譬如：[[YouTube∣nwXUuA8gSRU]] 或 [[BubbleShare∣175572.9c17866b383]]。
因此，目前暫時取消了在標記內容支援 HTML 語法，凡是在角括號 < >內的文字都會被自動忽略不顯示。至於 YouTube 和其他常見的 widget，例如 flickr 和 flash 等，未來可能會以其他特定語法格式來替換。譬如：[[YouTube∣nwXUuA8gSRU]] 或 [[BubbleShare∣175572.9c17866b383]]。
新增功能：免註冊立即建立訪客標記
今日新增了一個功能，允許訪客毋需註冊帳號，就能夠立即在地圖上新增標記。訪客新增的標記如同正常的地點標記一般，可以編輯名稱、位置、說明內容和圖示，但僅在建立標記時的瀏覽器未關閉前有效（以cookie認證)，若訪客關閉了瀏覽器，這個標記的內容就再也無法編輯了。
這個訪客建立的標記，在資料庫結構中與正常的地點標記是分離的，以維繫原用戶資料的隱私問題，且這種標記的永久連結語法也和地點標記不同，以 m. 為開頭。
要建立此類訪客標記，只能在首頁或其他訪客標記的地圖上才行，進入到某個站台後的地圖，僅能允許該站台的登入用戶新增站台內的地點標記。
目前並未考慮到網站用戶新增的訪客標記如何納歸至站台地點標記的問題，按照設計概念，採用訪客標記的目的在於臨時測試、滿足好奇，網站用戶既然已經有了帳號，可以隨意新建站台與增加地點標記，沒有理由回頭使用訪客標記。況且，既然訪客標記是利用短暫cookie來認證，技術上也很難知悉哪個訪客標記是由誰來建立的。
這個訪客標記的功能暫時沒有任何存取限制，不過有記錄訪客標記最後一次的存取時間，未來如果訪客標記資料量過大（會這樣嗎？），也許考慮將一段時間沒有存取的標記從資料庫中刪除。
這個訪客建立的標記，在資料庫結構中與正常的地點標記是分離的，以維繫原用戶資料的隱私問題，且這種標記的永久連結語法也和地點標記不同，以 m. 為開頭。
要建立此類訪客標記，只能在首頁或其他訪客標記的地圖上才行，進入到某個站台後的地圖，僅能允許該站台的登入用戶新增站台內的地點標記。
目前並未考慮到網站用戶新增的訪客標記如何納歸至站台地點標記的問題，按照設計概念，採用訪客標記的目的在於臨時測試、滿足好奇，網站用戶既然已經有了帳號，可以隨意新建站台與增加地點標記，沒有理由回頭使用訪客標記。況且，既然訪客標記是利用短暫cookie來認證，技術上也很難知悉哪個訪客標記是由誰來建立的。
這個訪客標記的功能暫時沒有任何存取限制，不過有記錄訪客標記最後一次的存取時間，未來如果訪客標記資料量過大（會這樣嗎？），也許考慮將一段時間沒有存取的標記從資料庫中刪除。
2008年10月19日
轉不轉型，大有干係
TWW 完工至今已經近一個月了，朋友們幫忙測試的狀況老實說，很不好。畢竟大家都是礙於情面上來幫忙點點標記，貼貼圖片，沒有大量操作和持久應用，就找不到系統的重大問題，和功能上應該改進的關鍵點。這時，原本將 TWW 定位和 DWW 一樣的「半封閉社群網站」這個基本的網站定型，便不時產生信心動搖，而開始重新省思這樣的定型究竟是否妥當。是否讓一般訪客非常容易地註冊帳號，甚至提供不須註冊的免費服務，讓訪客立即快速產生僅含單一地圖標記的連結，供交換資訊使用。這種免註冊的服務僅在當前頁面 cookie 可以修改內容，關閉瀏覽器或超過1 個小時以後就不能再編輯，除非註冊帳號並將此免費的頁面轉換為「站台」，才能繼續延伸使用。
第二點，TWW 推出以後我才發現 Google MyMaps 既有服務的完善度實在難以與之匹敵，若不提供一個市場區隔更多，或更有趣的網路服務，很難要求一般用戶棄捨原先 MyMaps 簡單易用的界面，和幾乎人人都有的 Google/GMail Account，另外註冊帳號使用一個不完全熟悉的操作界面。所以該不該僅僅拘泥於「地圖標記」這樣一個沒有特色的原則上，實在值得好好考慮。要提供些什麼功能呢？Blog？Album？Embedded Widget？
第三點，TWW 與 Google MyMaps 最大的差異在於 TWW 能夠在地點標記上提供大量的參考資訊和「遊記」這個類似於 Blog 文章的功能。且 TWW 既然屬於「地圖類資訊網站」，就不免與「旅遊 Blog」扯上關係。旅遊 Blog 需要些什麼元素？(1) 拜現代數位相機方便之賜，旅途中拍攝的照片量一定不少，如何與既有照片網站結合，例如 flickr 和 picasaweb，卻又不能與其既有的地圖標記功能雷同，這點需要有智慧地好好策劃，以借用既有網站的功能卻又得要儘量避免與之競爭； (2) 既然 Blog 這個通俗的功能免不了，那麼 Blog 該有的元素，例如回應／迴響 (comments)、引用 (track-back)、分類／標籤 (category/tagging)，是不是都必須陸續出現在 TWW 當中呢？
我想，上述的轉型和新功能，都可能無預警地突然出現在接下來這一個月當中。只是在開發程式之前，想清楚究竟該往哪裡發展，或許比花時間做了一堆白工後又修正路線要來得睿智點。
第二點，TWW 推出以後我才發現 Google MyMaps 既有服務的完善度實在難以與之匹敵，若不提供一個市場區隔更多，或更有趣的網路服務，很難要求一般用戶棄捨原先 MyMaps 簡單易用的界面，和幾乎人人都有的 Google/GMail Account，另外註冊帳號使用一個不完全熟悉的操作界面。所以該不該僅僅拘泥於「地圖標記」這樣一個沒有特色的原則上，實在值得好好考慮。要提供些什麼功能呢？Blog？Album？Embedded Widget？
第三點，TWW 與 Google MyMaps 最大的差異在於 TWW 能夠在地點標記上提供大量的參考資訊和「遊記」這個類似於 Blog 文章的功能。且 TWW 既然屬於「地圖類資訊網站」，就不免與「旅遊 Blog」扯上關係。旅遊 Blog 需要些什麼元素？(1) 拜現代數位相機方便之賜，旅途中拍攝的照片量一定不少，如何與既有照片網站結合，例如 flickr 和 picasaweb，卻又不能與其既有的地圖標記功能雷同，這點需要有智慧地好好策劃，以借用既有網站的功能卻又得要儘量避免與之競爭； (2) 既然 Blog 這個通俗的功能免不了，那麼 Blog 該有的元素，例如回應／迴響 (comments)、引用 (track-back)、分類／標籤 (category/tagging)，是不是都必須陸續出現在 TWW 當中呢？
我想，上述的轉型和新功能，都可能無預警地突然出現在接下來這一個月當中。只是在開發程式之前，想清楚究竟該往哪裡發展，或許比花時間做了一堆白工後又修正路線要來得睿智點。
2008年10月13日
Google MyMaps 與 ThereWeWere 的最大差異
今晚花了點時間好好地把玩了 Google Map 提供的 MyMaps 功能，赫然發現，原來在 MyMaps 的地圖標記裡面，是沒辦法設定放大標記的描述框的。這代表，在標準的 Google Map 地點標記描述框大小當中，沒辦法塞入比較大尺寸的照片，和更多的內容。
TWW 這方面的設計就比較有彈性了，不僅允許使用者將描述內容局部擷取當作點選地點標記後立刻顯現的簡述內容，還能夠放大地點標記的描述框至地圖 90% 大小，來觀看更多的內容，和相關的遊記。
揣測 Google MyMap 之所以要如此限制，主要是因為這些由使用者貢獻的內容允許一般用戶在附近地點搜尋，若是無限制地讓使用者在單一地點標記中貼入過多資訊，不僅可能造成搜尋者無法 focus 在地點標記資訊上（會被其他附加資訊吸引注意），還可能被「洗螢幕」讓這原本該是公共使用的地圖遭到有心者濫用。
另外，由 Google Earth 儲存的 .KMZ 檔案也能匯入到 MyMaps 這個功能，應該也可以考慮添加至 TWW 當中，如此就可以讓習慣使用 Google Earth 記錄旅遊行程的朋友，快速將既有的資訊匯入。
最後，因為使用 Google Earth 的地點標記，這才發現原來我花了一個晚上辛苦地取得 Google Maps 當中的圖示網址，其實在 Google Earth 一眼看盡，而且還有更多的選擇可供使用哩。真是囧啊啊～
TWW 這方面的設計就比較有彈性了，不僅允許使用者將描述內容局部擷取當作點選地點標記後立刻顯現的簡述內容，還能夠放大地點標記的描述框至地圖 90% 大小，來觀看更多的內容，和相關的遊記。
揣測 Google MyMap 之所以要如此限制，主要是因為這些由使用者貢獻的內容允許一般用戶在附近地點搜尋，若是無限制地讓使用者在單一地點標記中貼入過多資訊，不僅可能造成搜尋者無法 focus 在地點標記資訊上（會被其他附加資訊吸引注意），還可能被「洗螢幕」讓這原本該是公共使用的地圖遭到有心者濫用。
另外，由 Google Earth 儲存的 .KMZ 檔案也能匯入到 MyMaps 這個功能，應該也可以考慮添加至 TWW 當中，如此就可以讓習慣使用 Google Earth 記錄旅遊行程的朋友，快速將既有的資訊匯入。
最後，因為使用 Google Earth 的地點標記，這才發現原來我花了一個晚上辛苦地取得 Google Maps 當中的圖示網址，其實在 Google Earth 一眼看盡，而且還有更多的選擇可供使用哩。真是囧啊啊～
2008年10月11日
插入連結與圖片的文字語法
在入口標記或地點標記的說明文字欄位內，如果想要插入圖片或連結，不需要懂得 HTML 語法也可以喔！
1. 插入圖片
直接輸入圖片網址即可，但圖片網址必須以 http:// 開頭，且以 .jpg .gif .png 等副檔名結尾。
2. 插入內部連結
放大顯示入口標記或地點標記的描述框，可以在標題下方查詢得知該標記的標記代碼。
輸入 [[標記代碼]] 或 [[標記代碼∣顯示文字]]，系統會幫你自動將這種語法轉換成在地圖上移動至該標記的程式語法。
3. 插入外部連結
輸入 [[連結網址]] 或 [[連結網址∣顯示文字]]，系統會幫你自動將這種語法轉換成外部連結的 HTML 語法。
4. 插入內含連結的圖片
目前發現可以利用連結和圖片自動轉換語法，做出比較有意思的應用，例如：
[[http://therewewere.takol.tw∣ http://therewewere.takol.tw/images/pictures/vacation-travel.jpg]]
不過這種語法目前還有個地方頗奇怪，在"∣"字元後方的圖片網址，必須保留一個空白字元，否則會無法轉換。（此點留作待改善事項）
(上述介紹可參考：編輯內容)
1. 插入圖片
直接輸入圖片網址即可，但圖片網址必須以 http:// 開頭，且以 .jpg .gif .png 等副檔名結尾。
2. 插入內部連結
放大顯示入口標記或地點標記的描述框，可以在標題下方查詢得知該標記的標記代碼。
輸入 [[標記代碼]] 或 [[標記代碼∣顯示文字]]，系統會幫你自動將這種語法轉換成在地圖上移動至該標記的程式語法。
3. 插入外部連結
輸入 [[連結網址]] 或 [[連結網址∣顯示文字]]，系統會幫你自動將這種語法轉換成外部連結的 HTML 語法。
4. 插入內含連結的圖片
目前發現可以利用連結和圖片自動轉換語法，做出比較有意思的應用，例如：
[[http://therewewere.takol.tw∣ http://therewewere.takol.tw/images/pictures/vacation-travel.jpg]]
不過這種語法目前還有個地方頗奇怪，在"∣"字元後方的圖片網址，必須保留一個空白字元，否則會無法轉換。（此點留作待改善事項）
(上述介紹可參考：編輯內容)
2008年10月3日
新增 Google Map 圖示
目前標記可選用的圖示，包括有預設的 PNG 圖示 17 組、Google Earth 內建圖示 176 組，最近又剛新增了 Google Map 內建圖示 91 組，共計 284 個圖示，應該足夠使用了。
未來還會允許使用者上傳圖檔或以外部連結來當作自建圖示。上傳圖檔當然會幫忙縮圖，以防止檔案尺寸過大和駭客藉由圖檔塞入惡意病毒的危險。外部連結可能就不會調整大小，這樣在地圖上看到大大小小的圖片，感覺起來應該也挺有意思的才是。
這次尋找 Google Map 內建圖示，說來有點工人智慧實在很丟臉，竟然是利用反覆設定 MyMaps 圖示來尋找連結位置。花了一番苦心，這組圖示果然比起 Google Earth 的圖示更加美觀且容易辨識。
未來還會允許使用者上傳圖檔或以外部連結來當作自建圖示。上傳圖檔當然會幫忙縮圖，以防止檔案尺寸過大和駭客藉由圖檔塞入惡意病毒的危險。外部連結可能就不會調整大小，這樣在地圖上看到大大小小的圖片，感覺起來應該也挺有意思的才是。
這次尋找 Google Map 內建圖示，說來有點工人智慧實在很丟臉，竟然是利用反覆設定 MyMaps 圖示來尋找連結位置。花了一番苦心，這組圖示果然比起 Google Earth 的圖示更加美觀且容易辨識。
2008年9月30日
Competition
封閉發表後才知道，原來 Google Map 在四月份就已經發表了 MyMaps 的功能。真是一個囧到不行啊，每次都這樣！
在這篇文章裡有介紹，原來類似的服務已經有多家供應商了。先記錄下來，等有空的時候再來好好爬文一番。不過今天稍微試用了一下 Google MyMaps 的服務，幸好他所謂的「意見」只能針對地圖來回應，不能發表在標記上面。呼～這大概是 TWW 和 Google MyMaps 唯一的差異所在了吧。
另外有關照片上傳的部份，PicasaWeb 早就提供了幫照片加上地圖標記的功能，只是我到今天才知道，只要在 Google MyMaps 裡面打開 Picasa網路相簿的 layer，就能夠看到所有在附近標記地點的照片。這個功能也要好好給他來研究一下。
在這篇文章裡有介紹，原來類似的服務已經有多家供應商了。先記錄下來，等有空的時候再來好好爬文一番。不過今天稍微試用了一下 Google MyMaps 的服務，幸好他所謂的「意見」只能針對地圖來回應，不能發表在標記上面。呼～這大概是 TWW 和 Google MyMaps 唯一的差異所在了吧。
另外有關照片上傳的部份，PicasaWeb 早就提供了幫照片加上地圖標記的功能，只是我到今天才知道，只要在 Google MyMaps 裡面打開 Picasa網路相簿的 layer，就能夠看到所有在附近標記地點的照片。這個功能也要好好給他來研究一下。
第一次封閉測試開跑
儘管仍有些功能尚未完竣，但忙碌了三個禮拜，實在不想要繼續漫無目的地等待下去。於是在自己小有人氣的部落格上公開發表文章，徵求「愛旅遊的猴子們」一同來參與封閉測試。
封閉測試的帳號註冊有兩條路徑。第一是經由我設立的〈試驗場〉站台新增成員身分，寄發邀請函後據以註冊。第二是寫信到therewewere@takol.tw 申請註冊帳號，信中註明您慣用的登入帳號即可，我會產生一組隨機密碼給你，請自行登入後修改密碼。
TWW 的帳戶只有登入帳號這一個欄位是不可變動的，其他資訊包括顯示名稱、Email 等都是可以隨時變更設定的，這點究竟好不好，仍有待觀察。不過我覺得 TWW 不是個完全公開社團網站，所以就算個人顯示名稱或站台名稱有重複，應該也沒啥大關係才是。
封閉測試的帳號註冊有兩條路徑。第一是經由我設立的〈試驗場〉站台新增成員身分，寄發邀請函後據以註冊。第二是寫信到therewewere@takol.tw 申請註冊帳號，信中註明您慣用的登入帳號即可，我會產生一組隨機密碼給你，請自行登入後修改密碼。
TWW 的帳戶只有登入帳號這一個欄位是不可變動的，其他資訊包括顯示名稱、Email 等都是可以隨時變更設定的，這點究竟好不好，仍有待觀察。不過我覺得 TWW 不是個完全公開社團網站，所以就算個人顯示名稱或站台名稱有重複，應該也沒啥大關係才是。
2008年9月28日
使用者註冊功能完成
今天處在颱風來襲的平靜當中，一整天除了兒子跑來找我玩耍的交際應酬外，都窩在電腦前面趕工寫 TWW 程式。成果還算不錯，依照原先計畫地將使用者註冊的功能大致上完成了初版。
這次寄發邀請信函的 SMTP server，依舊是借用 Gmail 的服務。與以前幾個網站類似應用的差異點在於，我終於搞清楚了若是利用 Google Application 計畫的 mail account 登入 SMTP，username 須得要填入完整的 email address，而不像利用 Gmail account 來寄信時只填入 username 即可。
在寫註冊認證這段程式時，比較困擾的地方在於一些往返的訊息傳遞，由於得要透過網頁上的 Javascript，所以不能採取我們平常慣用 flash 來顯現。不過繞了個彎，自己想辦法用很醜的方式仍舊解決了需求，只是自己看了就很不酥胡，等以後想要 optimize 系統的時候再說吧。
目前完成的使用者註冊功能包括有：
這次寄發邀請信函的 SMTP server，依舊是借用 Gmail 的服務。與以前幾個網站類似應用的差異點在於，我終於搞清楚了若是利用 Google Application 計畫的 mail account 登入 SMTP，username 須得要填入完整的 email address，而不像利用 Gmail account 來寄信時只填入 username 即可。
在寫註冊認證這段程式時，比較困擾的地方在於一些往返的訊息傳遞，由於得要透過網頁上的 Javascript，所以不能採取我們平常慣用 flash 來顯現。不過繞了個彎，自己想辦法用很醜的方式仍舊解決了需求，只是自己看了就很不酥胡，等以後想要 optimize 系統的時候再說吧。
目前完成的使用者註冊功能包括有：
- 站台內可以新增其他成員身分
- 可以寄出邀請函
- 收到邀請函者，可以點擊郵件內連結開啟註冊頁面
- 註冊時可以選擇 (1) 登入原有帳號 (2) 已經登入者可以直接加入站台 (3) 註冊新帳號
這些功能應該暫時足夠了。接下來要傷腦筋的是測試，可能得要開始找朋友幫忙扮猴子了。
2008年9月25日
模仿 Google Map 網站風格
雖說一開始就決定要以 SPA 的架構來設計 ThereWeWere 這個網站 ，但網站外觀和風格始終沒有個定調。開始建置網站的第一週前幾天，迅速以慣常使用的 Liquid width 3 columns style 設計出網頁模板，自我省視覺得有許多欄位似乎沒有顯示的必要。隨即調整成 Liquid width 2 columns style ，卻也不見得好到哪裡去。然後大幅度地更新至 Liquid width single form，同時將所有要顯示的支援訊息，都嵌入至 Google Map 元件內部，只保留少許必須要固定顯示的資訊，譬如使用者登入訊息等，保留在頁面上。
這個 Signle form 的版面設計，雖然寬度可以隨著視窗大小自動調整，但高度部份受限於底圖和邊框設計不能自動縮放，使得一些使用大尺寸螢幕的朋友反應意見覺得這樣不妥。思索了片刻，開啟 Google Map 網頁察看他是怎麼一種設計概念，隨後醒悟了所謂 SPA 網頁服務的幾個要素：
這當中也曾碰到 IE6 相容性測試的問題，為了 PNG transparent 的這個討厭的 issue，害我浪費了好多時間來找最合適的答案。後來索性不理會 ugly PNG under IE6，遵照先前決議，趕緊把主要功能完成，丟出來讓朋友試玩看看大家反應再說。反正意見先驅者多半使用的是 FF/Safari，即便我大膽宣稱 "IE6 Forbidden Here!!" 大概也不會有什麼人持反對意見吧。
目前剩下的主要功能還有建立通訊錄、邀請朋友參加、認證與註冊這幾個曾經在其他專案做過，只要抄過來用就可以完成的模組，預計至遲到這週日，ThereWeWere 應該就可以正式推出 Beta 1 release 了。
這個 Signle form 的版面設計，雖然寬度可以隨著視窗大小自動調整，但高度部份受限於底圖和邊框設計不能自動縮放，使得一些使用大尺寸螢幕的朋友反應意見覺得這樣不妥。思索了片刻，開啟 Google Map 網頁察看他是怎麼一種設計概念，隨後醒悟了所謂 SPA 網頁服務的幾個要素：
- 將服務的主要元素設計成可以隨著視窗尺寸而縮放
- 把你認為最有廣告效果的元素儘量固定在頁面上
- 輔助性資訊可以縮放，不需要佔用寶貴的版面
- 色系簡明扼要，能夠用來分隔不同分類的資訊最好
這當中也曾碰到 IE6 相容性測試的問題，為了 PNG transparent 的這個討厭的 issue，害我浪費了好多時間來找最合適的答案。後來索性不理會 ugly PNG under IE6，遵照先前決議，趕緊把主要功能完成，丟出來讓朋友試玩看看大家反應再說。反正意見先驅者多半使用的是 FF/Safari，即便我大膽宣稱 "IE6 Forbidden Here!!" 大概也不會有什麼人持反對意見吧。
目前剩下的主要功能還有建立通訊錄、邀請朋友參加、認證與註冊這幾個曾經在其他專案做過，只要抄過來用就可以完成的模組，預計至遲到這週日，ThereWeWere 應該就可以正式推出 Beta 1 release 了。
訂閱：
文章 (Atom)