[筆記] 線上作品集的設計方向

一般用途而言，Behance之類的線上作品集網站已經非常好用，有個人作品，也可以有團隊作品，也可以共修，但是這類職業用作品集跟學生作品集的差別在於「主動性」

學生多數是比較被動的，他們的作品也大多來自於非做不可的作業，而較少有個人主動性的作品，因此學生作品集的設計必須有幾個獨特的概念

1. 與課程結合，或是可以發題目並透過email邀請學生上傳作業，學生在交作業的同時也就上傳了作品集的內容

2. 必須能去接其他作品集網站

3. 關連資料庫：作品、主題（課程）、個人

4. 個人亦可發題邀請，且可以確認每個受邀請者的回應狀態，隨著課程結束要能更換受邀者

5. 可做選輯以供不同用途之用


待續

Doubled Face Shader的解法

一般常用的方式都是直接作兩面poly就解決，但是對於布料之類具備物理特性的內容就會有問題（兩面poly的話就會有兩個面在飄來飄去）

解法#1：在Standard.shader中加入Cull Off 設定
這個方式雖然可以讓另一面透出來，但是卻沒辦法有正確的顏色，因為在背面演算時，光線的法線是相反的，所以光線的顏色進不了眼睛

結論：失敗


解法#2：兩面計算
在shader中作兩次pass，一次算正面，一次算背面，算背面的那次要把所有的法線都做反向

DoubledMaterialCloth.shader

在Cull Front的pass中
#define _BACKFACE_RENDERING 1

UnityStandardCore.cginc

在VertexOutputForwardBase vertForwardBase (VertexInput v)中
#ifdef _BACKFACE_RENDERING
float3 normalWorld = UnityObjectToWorldNormal(-v.normal);
#else
float3 normalWorld = UnityObjectToWorldNormal(v.normal);
#endif

結論：解決 ！

Unity中MovieTexture的幾種用法

一、直接將影片檔置入project
丟入的影片檔視為texture，可指定於材質上

1. 在UI上使用
    建立物件RawImage，直接將影片拖入texture中
    加入MovieController.cs，將影片拖入Movie欄位

2. 在空間中使用

    建立實體

    加入MovieController.cs，將影片拖入Movie欄位


MovieController.cs

using UnityEngine;

using System.Collections;

public class MovieController : MonoBehaviour {

public MovieTexture movie;

  void Start () {

if (this.gameObject.GetComponent < Renderer > () != null)

this.gameObject.GetComponent < Renderer > ().material.mainTexture = movie; 

movie.Play(); 

    movie.loop = true; 

  }

}

二、使用外部連結
格式必須為Ogg streaming格式，MP4與MOV都不行

visual programming的實作分類

縱觀visual programming的實作類型，大抵上就是三種分類

一種是connector-based，主要就是透過各種連接線把一塊一塊的運算單元(通常會被取名叫node)連結起來，connector可以做個別描述，也可以做型別判斷。實作的方式其實是偏向物件導向，或者也可以說是函式導向，而實作的方式也影響了使用者的學習曲線，那表示使用者多半也得熟悉物件或是函式的概念。這樣的工具我用過的在電子圈有labview/xilinx，資訊圈有quest3d/virtools/mindstorm nxt/udk、互動圈的max|msp/pd、設計圈有犀牛上的蚱蜢，或者像是Maya的材質球也是透過相同的概念而來，其實是一種偏向各個擊破法(divide & conquer)思考的形態，對於分歧或選擇這兩種邏輯的視覺化有其優勢，呈現資料流也相對清楚，但是在結構化呈現以及迴圈、scope之類的概念就比較難以表示。對於初學者來說，還是需要一點點數學與邏輯的基礎概念才行。

第二種是brick-based，透過類似積木堆疊的方式來寫程式，目前幾個標榜給初學者玩的像是mit的scratch/app inventor、berkeley的snap之類的都是這種。實作的方式是偏向指令式的，作法就是把每一個brick當成一道指令來對應，這種類型的作法對於分歧或選擇是非常難以描述得好的，但是對於迴圈則有很良好的視覺呈現，因為迴圈的起終點及條件是相當清楚的。初學容易，但是因為其對於選擇的弱點，稍微複雜的程式結構反而會變得更難寫。學習曲線短是因為使用者只要知道每個指令在做啥，而不需要理解處理或運算的邏輯，對於使用者而言比較不會有黑盒子的感覺。

第三種是rule-based，主要是透過if-then的條件來作為驅動，但是從系統的觀點，這種機制並不得以建立完整的架構，因為缺乏了組織化的結構，用這樣單純的機制，遇到了多重選擇或是迴圈，程式會比指令式還更難讀懂，通常僅能用作AI的輔助機制，或是在封閉系統裡做特定目的的運作，像同系嫡生的kidsim/viscuit/agentsheets，以及非常特殊的微軟的kodu，單就遊戲創作而言，我認為kodu真的是個傑作，當然以多用途程式來說，這種類型顯然就受限非常大了。而像little bit planet裡面的編輯機制，其實是rule-based的變形，而他所使用的rule，就不是概念上的邏輯，而是物理性質，所以可以做到不需要文字說明就能夠運作，也是我認為最直觀的系統。實作上相對簡單許多，就是大量的if結構，對應到每個圖形去就是了。

今天在寫我自己的系統，是一個visual programming的環境，剛好因為上面每一種都有實作過，突然就想要整理一下從實作觀點來看的心得。

在這三種機制之外，不知道還有沒有別的可能性呢....好希望還能夠繼續探索，可惜，似乎沒有這種機會了....

Processing 2.0 的mode manager有問題（其實這個應該是2b9就有了）

Processing 2.0 + Javascript mode手動安裝
1. 下載
https://github.com/fjenett/javascript-mode-processing/raw/latest/release/JavaScriptMode.zip
2. 解壓縮到modes去

Processing 2.0 + AndoirdMode手動安裝
1. 先到這下載整個repsitory
https://github.com/processing/processing-android
2. 用Mode Manager取得AndroidMode.jar，丟進modes\AndroidMode\mode


原因我想應該是mode manager的運作出了問題，下載不到完整的mode檔案....還自己鎖自己，commit這塊的人該打屁屁....

討論在這
https://github.com/processing/processing/issues/1781
https://forum.processing.org/topic/add-mode-in-processing-2-0b9

獅子的寓言故事

好久沒寫，來講個寓言故事吧～

有頭獅子，毛髮亮麗，叫聲威猛，腳一蹬可以撼動整片原野，爪一揮殲敵無數。有一天，他看上了一頭母獅子，連哄帶騙半強迫之下，他征服了那頭母獅子。母獅子愛他的雄性象徵，也愛他威震八方的吼聲。

過了一段甜蜜的時光，公獅子很愛她，為了給她更好的環境，四處征戰，保護領地。

有時候寒冬沒食物吃，他割下了自己的腿肉，餵飽了又飢又寒的母獅子。
有時候征戰不順，他割去他的毛髮表示臣服，換來勝利者對於他的家人安全的保證。
每次大吼總是嚇到母獅子，母獅子嫌他太粗暴，所以他也學著把聲音變小聲點，展現溫柔的樣貌。
隨著殺傷的敵人越來越多，牠的爪子也變得越來越鈍。

有一天，母獅子嫌棄了他，她聯合了隔壁年輕獅子，一起殺害了他，在最後一擊前，她對著獅子說

「你的毛髮比不上現在的他的帥氣，現在常常喵喵叫一點男子氣概也沒有，腳軟趴趴的連隻螞蟻都踩不死，爪子又不像他那樣可以抱我抱那麼緊，跟他在一起才有安全感，你沒他那麼愛我，我感受不到你雄性的氣息」（螞蟻：靠么躺著也中槍....）

獅子說：「我的毛髮保護了妳的性命，我的腿力換成了妳的體力，我的聲音不想讓妳心驚，我的爪子成全了妳的生命，妳為什麼不用心感受，我的愛情全部融在我們的生活裡，從沒消失，只有更豐富」

母獅子說：「那你下輩子去當人類吧，他們才有心，才會去感受這些，我只是隻獅子，別跟我講心靈」

獅子最後的一句話是....
「我上輩子就是個人類，其實我們也從來不懂得去體會這些的....」

學程式，怕什麼

六年前很想開的一門課，叫邏輯思考，希望能教會沒有程式背景的人，不論是藝術家或是設計師，希望他們能夠透過對程式的學習，將資訊技術應用到自己的領域去，這也是我一直以來追求的目標，雖然到現在還是沒有什麼具體的成果，但是這幾年的實戰下來，其實也累積了不少心得。

總結來說，程式還是令人畏懼的，所以我很想要找出為什麼害怕，也因為這樣我對非常多的同學做了心理輔導，也跟他們當好朋友聊心事，我想知道，他們到底怕什麼。

雖然我很想把這些東西發展成論文，但是目前還是散寫一番就好，嚴謹的研究留著之後拿來申請計劃用好了XD

大抵來說，程式入門的幾個心理跟生理門檻需要跨過的有

1. 怕犯錯而且回饋來得慢
初學者很害怕犯錯，他們很怕寫錯東西，即使我不斷在強調寫錯程式不會害電腦永遠開不了機（雖然這句有點是騙人的，沒寫好真的會永遠開不了機，比方說寫了一個開機自動執行的關機程式，那頭就大了....），不會害死電腦這樣的心理建設雖然有點成效，但是我看得出來，面對一片空白的背景，他們是動彈不得的，因為撰寫程式的過程，大概要經過十分鐘後，程式碼累積到一個程度可以嘗試執行才會知道自己寫的是對還是錯，而這十分鐘，是一片的混沌與黑暗，對於沒有辦法在腦中裡建立程式架構的心智模型的人而言，這是一種漫長的煎熬。
畫畫或寫作也相同，如果不是腦海中有東西，面對一張空白畫布或稿紙也常有無從下手的煩惱，但相對於寫程式而言，畫畫或寫作的心理負擔相對更小，進入到執行面的機會更大，因為畫畫下個幾筆就知道對不對，寫作寫完一句話就能感覺順不順，因為這兩個活動的回饋來得快得多。
解決的方式有兩種，從教育方面，我都先教同學寫出架構，例如先寫出許多的空白函式，然後再寫裡面的細節，而不要一行一行寫下去，因為程式要一直等到架構完整才能執行看看對不對，先大樣再細部。傳統的資訊教科書教完指令就從main()開始，然後一行一行的指令寫下去到hello world秀在螢幕上，教學上雖然看似簡單，實務上會造成回饋太慢。
快速的回饋反應可以讓他們比較敢動手，第一步總是困難的，別讓他們等太久是很重要的。

2. 語法不熟所以不知道自己在寫啥
程式本身就是另一種的語言，當我們對這個語言不熟的時候，恐懼是會伴隨而來的，就像同學如果對自己的英文沒自信，那麼遇到外國人問路，大概就會閃閃躲躲很害怕。而要摒除這樣的恐懼，最簡單的方式，就是「拆」，當他們發現，聽似聽不懂的一句話，拆成一個一個單字後其實每個字都懂，他們只是需要慢慢來，不要一次丟過來，那麼就不會怕了，所以在教學上不能只教程式，而必須搭配每個指令與步驟造成的變化，聽過我上課的同學就知道，我一個重複20次的迴圈，我就真的會重複20次，然後把每一次裡面所有的變化都講清楚，讓大家知道雖然是一個複雜的東西，背後的運作卻是簡單的。另一種方式則可以透過新的介面，讓每一行程式碼都伴隨著視覺上的架構圖同時建立，例如他們每宣告一個變數，視覺方面就讓他知道有多一個東西在等著使用。

3. 除錯除不到錯哪也不知道
任何專業的程式設計師都知道，除錯訊息有多重要；然而所有的初學者都不知道，錯誤的訊息在哪裡，就算他們看到了也看不懂，即便是標榜最平易近人的processing，除錯訊息還是上帝的語言。因為不知道錯在哪，所以一旦嘗試執行了幾次，他們就會放棄，因為錯在哪裡都不知道的無力感，會不斷澆熄學習的熱情。這點也是我認為目前為止最大的關卡，因為寫程式一定會犯錯，即使跨過了第一關不怕犯錯，但是卻沒有人能夠正確指出他們到底錯在哪（就算指了也看不懂啦）。教學時老師會幫忙看錯誤訊息，但是做作業的時候怎麼辦？自己創作的時候怎麼辦？即使回家後滿腔的複習熱情，也會在被一連串的ERROR打槍後決定改玩英雄聯盟去。我們沒辦法在教學時告訴他們所有可能的錯誤狀況，只能教他們在錯誤發生的時候知道怎麼看錯誤訊息，我認為關鍵在於工具，而這點在目前所有的程式工具都做得非常不理想。理想上，除錯的視覺化是一個很重要的環節，將程式的資料流視覺化或許是個可能的方向，至少讓他們看得出來自己設立的資料是怎麼被處理及如何產生變化的，這也會是未來要持續努力的目標吧。

4. 範本人人愛用久離不開
大家都愛範本，拿範本改來改去是最容易的，這點在近期的程式工具發展就看得出來，都會提供各式各樣的範本，有的會把架構架好，有的甚至會寫好一些資料流處理的程式碼讓人去修改了，各種範本的教學也應該重視，讓同學容易獲得成就感，延續熱情。然而要很小心的是，範本實際上是一種速食毒品，上癮了之後難脫離也走不出自己的路，一旦養成習慣，當他們想要自行修改卻發現怎麼寫都錯的時候，挫折感會比從頭開始還要更重，所以範本的教學必須適可而止，讓他們可以簡單完成一些小型程式嚐嚐甜頭，但是課程比重絕對不能太多。

5. 別想太多當佈置而不是建房子
資訊背景的教學，會教會學生如何有效率而且正確地思考，並在腦中建構邏輯模型，撰寫程式不過就是將這些邏輯編碼出來而已，所以我們常常有個錯覺就是邏輯模型建立後就覺得程式已經寫完了，某個程度上來說也不算是種錯誤啦。而習慣以視覺思考的設計師或藝術家，這樣的運作方式其實是會造成困擾的，一來是他們本來就不習慣建立這種有組織的架構，二來是他們習慣看動看，即便腦中先有了印象，動手了之後還是會不斷地依據視覺的回饋做修改，所以過於強調思考的方式，對他們來講是不對盤而且問號滿滿的，而且一旦在思考中卡關，他們就不想這麼做了。因此在教學時，我總是要他們先寫一個小功能，看一下結果後再慢慢擴充，可能這邊加一條，再看看後就那邊又加一行，像是在做裝飾的心態，而不是照計畫行事。在工具上，快速的視覺回饋當然是個重點，而輕鬆的介面是另一個會影響心態的關鍵，這點其實我覺得scratch做得很不錯，但是這樣的設計介面也會讓大家覺得做不出正經作品的感覺。輕鬆易上手跟專業重質感如何並存，也會是設計工具發展的一個很重要的特色。

中間其實很想穿插對於許多程式工具的評論與分析，例如從processing、UDK、Unity、VB到VS等，不過實在太冗長我懶得寫了，留著之後寫計畫用吧～

簡易的架構方式、快速的回饋機制、理想的除錯介面、豐富的範本、輕鬆做裝飾的心態，從教學及工具兩方面的發展，或許能夠盡量達成我設定的目標吧，隨著教學經驗跟白老鼠數量的累積，我相信我能夠更趨近自己的理想，目前的這些想法，我不認為是100%正確的，這些只是一種暫時的心得，同樣隨著時間的增長，其中或多或少也會有所變化吧，這也是自己要不斷修正的部份，一輩子的志業，不是嗎？

Lion的scroll方向小感

Lion的scroll方向引起不小討論，不過我覺得應該多數還是會改掉吧？
除非硬要逼自己相信蘋果絕對不會錯，而是一種更創新更直覺的設計....
（但是想想之前4.2把ipad的鎖定鍵換掉後，4.3又偷偷加回來可以自己設定，就知道蘋果的設計不見得是百分百完美）

在人機介面發展過程中，由於滑鼠是在螢幕外面的，並不是一種direct manipulation而是一種間接操作，所以要藉由mapping的方式，把我們的動作對應到畫面上的變化才知道我們如何在操作，所以游標動作對應著滑鼠的移動方向，選取對應著滑鼠按鍵的下壓動作。

在iOS上，我們是摸著畫面，是一種直接操作，所以畫面跟著動作上下一致是非常合理的。

但在電腦上，我們習慣上是把滾輪mapping到捲軸上的點，所以滾軸的點跟滾輪上下動作一致是合理的，滾輪往上，滾軸的點往上，畫面就會往下，這是一直以來我們習慣的模式。
現在Lion把這個全部一致，當然是希望擁有相同的UX，問題是，多數的PC都是間接操作的，硬體上不同的設計，卻硬要相同的UI設計，我覺得這很詭異。硬要做到這樣，就要教育使用者把手的動作，重新mapping成「想像自己的手指在螢幕上」，這在觸控版上或許會比較合理，但是滑鼠的滾輪方向也這樣搞，我就覺得很詭異了....或許蘋果真的很希望我們趕快脫離滑鼠吧....

雖說magicpad也很好用，但是說真的，滑鼠的效率跟"輕鬆度"好很多
觸控或平板再好用，也比不上有如齒輪效果般的滑鼠，我滑1mm，畫面上可以移動1cm，這是1/10的省力；這讓我想到Wii跟PS3的戰爭，Wii很直覺很創新沒錯，但是到後來很多人都把Wii封印了，多數人的理由應該都是相同的，「天天這樣玩太累了」，在PS3或360用搖桿，手指頭動動，就可以完成非常大量的動作。
把觸控版或是滑鼠的移動速度改成1:1試試，就會覺得太慢好累，平板強制我們用1:1的方式操作，偶而來一下輕鬆愜意又姿態優雅，但是要你天天這樣密集操作？又不是每個人都是畫畫的，不用鍵盤滑鼠，那一堆的選單跟分布各地的按鈕不會讓我們的手像條組裝工廠裡的機械手臂嗎？要說這是因為長久以來的習慣嘛....或許也是吧，只是我不這麼想就是

鍵盤滑鼠是硬屬性的，效率省力
觸控平板是軟屬性的，優雅直覺
從事介面設計，這幾個關鍵字的組合總是令人又愛又恨啊....直覺又有效率？優雅而又要省力？這也讓我想到，在工程管理的觀點，novice跟expert的UX是截然不同的，novice講易學，expert要熟練，以前我曾設計過會自動分析選單項目的介面，菜鳥很喜歡，因為不會選項繁多不知道要按哪個，老鳥在抱怨，因為沒辦法記得每個項目的位置好機械式的快速操作....在當時看到這樣截然不同的回應真是令我大吃一驚呢
而任何軟體總是會有從novice用到expert的階段，就像大家玩臉書的遊戲，按到後來就已經變成機械式的快速點取一樣，如果這些按鈕會時有時沒有，每次都要判斷後才按，就沒辦法養成使用習慣了，介面的設計真的是一種非常大的挑戰，但各種介面設計，總是想討論「直覺」，可是「直覺」是不是就等於「輕鬆」，我個人覺得這完全是兩碼子事了....直覺的使用者介面真的比較「好」？嗯哼....

就像水往下流，人類的肢體行為也是趨向放鬆的自然體

人，永遠是會偷懶的，科技進步的原因始終來自於惰性，不是什麼人性....
或者該說，人性就等於懶惰吧

所謂的使用者經驗的研究，卻常常只在第一眼打轉，忽略了後續使用者經驗的成長發展與使用習慣的養成後會對介面的觀感產生什麼樣的影響....

啊....好長的小感，我在訂標題的時候也忽略了後續寫下來時的感想發展及這會對文章長度產生什麼樣的影響了吧....~"~

旅立ちの日に

=================================================
歌詞翻譯 by Swingly (沒錯，就是我翻的)
白色的光芒中矗立著一座座的山
朝著遙遠天空的盡頭 你就將要起飛
看著沒有邊界的青空 心裡騷動沸騰
在自由中飛翔的鳥 是不會再回來的

戴著勇氣的翅膀 乘著希望的風
在這個廣大的天空中 託付夢想

懷念的朋友的聲音 突然想起從前
那些常常為了沒有意義的爭吵哭泣的時候
還有和好後開心擁抱的日子
這些雖然都已經過去 卻是很重要很重要的回憶

戴著勇氣的翅膀 乘著希望的風
在這個廣大的天空中 託付夢想

現在是離別的時候 起飛吧 相信未來
相信躍動著年輕的力量

在這個廣大的 廣大的天空之中
================================================

五月了，是一個我不知道該怎麼面對的月份
不想在大家面前哭，但是我很清楚，我根本就忍不住
所以要是意外地看見我在哭泣，請不要理我，我會害羞

這次的離別帶著好多意義，因為其中也包含了我的離去
我捨不得所有人，離開我的人，還有我離開的人

我記得好多好多事情，每一個的臉孔、每一個綽號
每一段害羞戀情、每一個皺眉苦惱、每一句碎念抱怨
每一次的爭吵、每一次的氣你們不成材、每一次的心疼
還有，始終沒停過的，擔心與想念

不管發生了多少事情，不管對我有什麼誤解
喜歡我也好，討厭我也好
我相信，總有一天你們全部的人，都會明瞭我的心意跟想法

有些話，當面我說不出口，所以只能打在這裡
只希望用這首歌，祝福大家
期望，未來在某一天，我們會在另一個地方相遇
聽聽你們跟我說工作上的煩惱、當大人的悲哀、現實與夢想的掙扎
能夠透過你們的眼睛多看看這個世界，是我最大的奢侈

而我更知道，能遇到大家，是我到現在為止，最開心的事....

我愛你們，全部（名單是我一個一個回想臉孔打的，順序跟感情好壞無關）
皮皮、慧真、欽聯、欣潔、Len、昆蟲、點點、長老、馬尾、麻雀、甲棒、烏鴉、鴨子、仙貝、明倫、小孩、冬瓜、布布、海漢、妹妹、可可、阿飄、土豆、小狐狸、小妞、豆子、加豪、柏任、阿關、怡岑、斯巴達、小薰、可樂、小飛、兔子、阿哲、均宜、賴暐、老王、老大、老人、小白、魚、張方、家恩

高速公路的愛情

愛情關係，不是什麼手牽手並肩一起走
每個人有各自喜歡的步調，嚮往的方向，沒有什麼完全一致的

倒覺得比較像在高速公路上，開在同一條車道上，的兩台車


有時候跟到一台開得很慢的車，想往前衝的自己，要不跟著慢慢開，要不就超車到別的車道去

有時候前方的車自顧自地往前衝，被丟下的自己孤單地開著

有時候我們是在前面的那台，要小心別被後面的車追撞，也要注意不要丟下對方


偶爾，後面的車一廂情願地跟著前面那台，那麼一場飛車追逐的戲碼就會上演

偶爾，眼光被旁邊車道的跑車給吸引住了，而忽略了自己車道上的路況

偶爾，會有別的車從另一個車道硬要超車切進來，要讓？不讓？


我們總是專心地跟著車，有時會沒注意到前方的那台車，的前方也還有一台
夾在中間的那台車瞻前顧後不小心，三台車就會撞在一起了

當然不幸的時候，也會有連環大車禍就是了....


如果我們在後面又閃燈又鳴喇叭，前方那台還是走著自己的步調
那麼與其希望對方加速，還不如換條車道走吧


開累了，到路肩休息一下，看看風景，看看車道上的形形色色
養足精神再上路，減少失神發生車禍的機會

旅途總會有終點，愉悅的過程才是真實的體會