最近又重新發現新的問題
就是自己的腦部同時進行訊息輸出跟彙整的過程中，會有闡述完概念，忘記目的的問題。
原因一方面是腦部運轉速度變慢了，另一方面也是其他感官單位時間內能獲取的資訊量比以往更多所致。但不知道哪個變因的影響比較大。
背景：溝通工具與訊息傳遞效率的關係
如果把人腦想像成一個獨立運作的系統，感官是我們的輸入設備，語言、肢體、表情是我們的輸出設備。當我們想要把一個完整的概念，從自己的腦中，傳輸到另一個人腦中的時候，首先要面臨的問題是，透過口述，只有一分鐘 160 個字左右，而在我們說話的過程中，我們必須把腦中的概念壓縮編譯，讓對方解壓縮解譯，由於編譯跟解譯的規則，受到各自具備的知識、關注的重點及接收當下的情緒等變因影響，所以單位時間內可傳遞的概念，並不是可靠的 160/分鐘，甚至是更少。
直撥崛起，除了常見的打賞形式服務以外，在社群內的經營者，也逐漸開始嘗試透過直播跟客戶互動，但是由於資源有限，往往要一人同時處理多件事情。
未來應該會需要一種，協助業者直播的服務，可能包括AI或BOT，以及一些基本的投票，訂購等服務。
一個簡單的App，緊張鬧鐘
打開後註冊相關人員連絡方式。然後設定每天幾點起床。
相關資料會紀錄在伺服器上，鬧鐘響時如果沒有在一定時間內按掉，伺服器就會根據設定的內容發通知給指定人員。
應用方式：
[筆記下心得]
許多人習慣離開會議桌後再來整理會議中討論到的待辦事項。但離開後很容易被其他事情中斷而忘了做安排，之前因為要對付銀行客戶的關係，習慣會議中馬上確認，除了較有效率外，也能避免事後反覆確認的困擾。
--
會議結尾應達成的工作
早年寫網頁時，資深工程師會笑新進工程師連GET跟POST都分不清楚，但這麼多年來，大家都真的清楚嗎？
近年來由於各種RESTful API的發展，跟各種工具的普及，在單一URI下，透過識別Http Request Method來判斷客戶端的目的上，越來越趨於統一。另一方面也另人感嘆，從1999年就更新的HTTP/1.1協定中就考慮到的各種應用情境，直到多年後，才逐漸地了解他在應用面的價值。
這兩天遇到兩個小問題:
1. GET是否容許用 Body 來帶參數呢？是否如我們的印象，GET就是不能有Request Body的呢？
2. 如果用來操作資料的話，應該如何區分PUT跟POST的差異呢？ PUT代表新增，而POST代表更新嗎？還是相反呢？能否讓POST同時具備新增與更新的能力呢？
做產品設計一定要試著去了解產品的定位、目的、對象需求、發展、一些Domain Know How等，然後為了說服客人不要浪費我時間作一些沒用的東西，所以必須把他的產品定位搞清楚，才好跟他說哪些要做，哪些可以不作，到最後就是直接開規格了。
最近工作量好像有點升級，除了介面，API，甚至到韌體還有晶片的能耐都要考慮。
幾年來覺得最有差別的地方是，因為創業的關係，除了體驗考量外，還多了一層「市場價值考量」。好的設計一定是從好的體驗出發，有時候要創造好的體驗所要投入的成本是很可觀的，但是獲得的報酬是否合理，過去很少幫客戶想到。
這次行車紀錄器軟體的介面設計，從顧客的用戶體驗出發的話，的確有可能做到更直覺及方便。但是，他的價值在用戶的生活體驗中，佔的比重卻相當微小。因為使用者只有在出事的時候才會體驗到便利，但這種便利他根本無心享受。
而在銷售階段，對經銷業者而言，易用性只是競價籌碼中的一個小環節，在消費者面前，畫面漂亮有質感跟良好的視覺及操作體驗設計，價值基本上是相同的，反而是硬體本身的外觀設計比較重要。所以這個個案來說，花錢把軟體做好的價值，其實遠不如把包裝跟產品外觀做好。因此這次跟客戶溝通，建議只要畫面有質感就好。
2008年開始，做UI都習慣考慮手指觸控操作，直到IPAD出現前都還沒有人特別覺得這是趨勢。後來App流行時，我已經懶得做UI設計了...
2010年，認為交易平台的建立是數位商務必然的趨勢，當時跟投資人說：「未來GPS普及，出門買東西都是線上交易，到時候需要一個平台，所以我要先做好準備。」
今年雖然還停留在老梗的O2O跟行動交易框架內，不過不出幾年應該會有新名詞來說明這件事情了。我已經懶得搞這飛機了，才一堆人找我做行動POS，但還是沒一個看出該做交易API平台而不是行動商務... = =
我也懶得提案了...
2008年，開始研究3D UI及擴增實境，攝影動態建模等資訊，大概預測到未來的操作體驗就是擴增實境體驗，主要的媒介，室內是眼鏡，適合環控人員，室外是車窗，適合民眾，本來想等POS投資賺錢再去發展適合擴增實境的圖形化界面引擎，可惜沒那個財力跟智力...
剛好聊到系統設計想到，對很多開發人員的經驗而言，防呆是很重要的事情，把使用者當笨蛋，確保系統只接收到控制範圍內的輸入。而我的做法恰恰是反其道而行。
每個界面開發人員都認為自己在開發「好的使用體驗」，但是大部份人在設計使用體驗的時候，都是無差別式的設計，也就是，不管做什麼界面，都是以 0 ~ 100 歲的任何人一開到就會用做標準。或至少是 9 歲 到 40 歲。這種設計理念我實在無法苟同，不止影響開發產出效率，同時也限制系統的發展。
我認為好的「使用體驗」，是要根據系統的目標族群，讓新手有足夠的資訊完成工作，老手有足夠的彈性加速工作，更甚者，使用者還能發明意想不到的用法。
在有限制對象的情況下，有時候最簡單的設計反而最好用
舉例來說，前陣子規劃一個員工考核系統，裏面建立員工資料的時候，要選填頭銜。一般開發者的做法，多半是資料庫有一個頭銜資料表，然後做一個新增，刪除，修改，排序用的界面給使用者使用。不過我這次就大膽的只給一個像留言板的空白框框，然後告訴使用者，一行一個頭銜，你想改排序，簡單，自己剪下貼到前面，然後存檔就好。
之前看到有隊友在問 MP7 三聯腿掛彈匣袋傘繩的綁法，正好我的腿掛也斷了，買了新的順便研究一下。
以下是我目前的綁法，希望能給需要的人參考：
step 01: 將散繩穿過彈袋前方魔鬼粘條，兩邊拉等長。
step 02: 先打一個結
step 03: 再打一個同方向的結，然後調整拉緊。這邊注意調整下方不要留太長。
背景描述
阿勝的老爸職業軍人，經常不在家，原本好勇鬥狠的阿勝在朋友的邀請下，加入了槍隊打起了生存遊戲。沒想到反而被老爸數落不好好讀書，整天光會打電動打生存。
不久候阿勝高中畢業，到軍中服役，正好碰上非洲盟國國內發生災變，我國亦派遣國軍前往支援，阿勝菜鳥當然就被推了出去，碰巧遇上帶團的軍官就是他老爸。救災結束後，由於帶團軍官須留下交接，沒有跟部隊一起離開，而是之後再搭商船，勝爸趁機把阿勝留下，希望父子好好交流。沒想到在商船回程的半途中，遇上了索馬利亞海盜攻擊，並且被挾持到海盜的營地。而劇情的主軸就是描寫這對父子如何逃回台灣。