搞企劃

"新浪科技":http://tech.sina.com.cn/i/2007-09-02/11511713337.shtml

據國外媒體報導，業界普遍認為馬克·扎克博格(Mark Zuckerberg)是社交網站Facebook的創始人，三位哈佛大學同窗、社交網站ConnectU的創始人卻一直指控扎克博格竊取了他們的創意，並已經就此向波士頓地方法院提起訴訟。不過，最近又有一位新哈佛同學浮出水面，他自稱早在扎克博格和另外三位同學之前就創建了最早的大學社交網絡系統。

這位哈佛同學名叫亞倫·格林斯潘(Aaron Greenspan)，早在2003年，他就創建了一個簡單的網站，並將其命名為「houseSYSTEM」。houseSYSTEM的上線時間比Facebook早6個月，比ConnectU早8個月。

2003年9月19日，格林斯潘在一封群發給哈佛大學學生的電子郵件中介紹了houseSYSTEM的最新功能，並將其稱為「the Face Book」，也就是一個用於尋找其它學生的網絡系統。四個月之後，扎克博格創建了自己的網站，最初名稱為「thefacebook.com」。

格林斯潘和扎克博格的事例再次證明了高科技領域的一個真理：最終的贏家往往不是最早提出創意的人。

抄襲 or 參考？論點歧異之爭是沒完沒了的。不過，就這則新聞來看，我個人覺得 Facebook 不是抄襲，而是「創造性模仿」。

創造性模仿

杜拉克下結論說：『創造性模仿者並沒有發明產品或服務，他只是將原始創新產品或服務變得更完美，並將之適當定位。』...創造性模仿的目標是創造，而不是仿冒。...創造性仿模者透過對他人創意的瞭解，重新組合、改良，產生有不同功能、價值的「新」東西，這就是創意。...創造性模仿是這種「骨子模仿法」，而不是「皮毛模仿法」。

摘錄自《創意人: 創意思考的自我訓練》，作者／詹宏志

青出於藍，勝於藍。

"譯言-技術與創業":http://feeds.feedburner.com/~r/yeeyan_tech_zh/~3/149912344/1769

測試用的胡亂文字（Lorem ipsum dolor）一直是設計者的忠實夥伴。 虛擬文字幫助人們認清設計完成後的觀感。但是這些虛擬文字會很危險。

測試用的胡亂文字改變了拷貝的視像。使得文本內容弱化為一個視覺設計元素 --- 文本形狀 ---而不是其本來面目：有價值的某人錄入/或要讀的信息。

你需要真實的拷貝去認識某個字段要多長才合適； 你需要真實的拷貝去懂得表格是怎樣擴展或收縮的； 你需要真實的拷貝去感知你的應用看起來究竟怎麼樣。

只要有可能，你就要使用真實，準確的用語。...當你用連發開火的方式快速錄入假數據時， 你根本不會體會到填表格時的真實感受。

像你的客戶那樣去做，你才能更好的理解他們。 當你更好的理解他們時，你會感同身受，做出更好的界面。

又一篇深得我心的文章，在離職前曾打算拜讀《Getting Real》這一系列的文章，無奈事與願違 (講白點，我人懶)，剛好訂閱的 blog 中，有人在翻譯分享，索性就開始讀起來。

想當初，我開始規劃服務時，我實在無法接受只用線框來表現版面配置，也無法忍受只用 OOXX 來表現頁面的文字，因為我覺得這樣的頁面很生冷，讓我沒有感覺。

所以，我捨棄了 WORD 而改用 Dreamweaver，我試著去畫出我想要呈現的版面配置，我試著去寫下我想要表達的文案詞句，這樣的做法非常、非常、非常的吃力不討好，而且還曾遭受美編的排斥 (說我限制了他們的發想)。

但，我還是依然故我，用這樣的方式做交友、做知識+ (在此向被我限制的同事致歉)。因為我無法用線框、用OX來堆砌，我需要更具像、更真實、更讓我能想像的一個頁面、一個流程、一個機制、一個服務。如果我能置身其中，知道怎麼使用而不困惑，相信網友也可以。

這讓我聯想到我之前在漫畫出版社當文字編輯時，我會將翻譯人員給的稿子再三潤飾，而且邊看、邊唸、邊演，想像自己是漫畫中的人物，去揣摹應有的對白及口氣。

跟製作網頁一樣，很累，但我樂在其中，時間夠嗎？不夠，我拿回家做。因為我喜歡這個漫畫作品，我希望更多讀者也會喜歡。雖然，很多人認為漫畫好看是因為日本漫畫家畫得好、編得好，而不是台灣翻譯翻得好，但我相信我的付出，是有價值的。

圖像記憶訓練法

你除了要觀察，還要把畫面「背」下來。...為什麼要記憶畫面？因為畫面充滿了細節，而語言式的記憶只有抽粹的要點，沒有細節。...語言思考比較經濟，但是畫面思考容納較多的細節。細節就是創意的材料，它讓你看到和別人不同的事物。看的不同，就想的不同。

摘錄自《創意人: 創意思考的自我訓練》，作者／詹宏志

感同身受，魔鬼都在細節裡。

■ 延伸閱讀：

* Getting Real 學習筆記：跟我一樣，英文不太好嗎？不妨來研讀對岸網友 indigo 所整理的中文版。
* "小論中英文網站的設計差異":https://produsir.synology.me/wordpress/2006/11/23/1228/

"譯言-技術與創業":http://feeds.feedburner.com/~r/yeeyan_tech_zh/~3/149554969/1767

避免寫功能規格定義是一個好的開始,但不要僅只於此；要處處避免過分的寫文檔工作。除非有個文件確實要演變成現實, 否則別寫它。

建造出來,別寫出來。如果你需要解釋什麼,先建造一個原型而不是寫一份冗長的文檔。實際的界面或原型是你正在構建一個真正的產品的很好說明。另一方面,一紙文檔,只能說明它們終將被丟入垃圾桶。

開發Web應用並不會因為有豐富的文檔就會一帆風順。 軟件開發是一個不斷變化的，反覆迭代過程，這其中包含著 相互作用， 快速決策 和一堆在前進路上不斷遇到的無法預測的問題。 這些沒有一個是能夠，也不應該在文檔中捕獲的。

不要浪費時間去堆砌這些冗長成冊的不實文檔；沒人去讀它。

有人說，寫文件並沒有生產力，但我覺得寫好文件將有助於提高溝通效率。

不過，如果開發團隊因為資源不足而無法好好溝通，而必須卯起來拚命寫文件的話，不僅是本末倒置、曠日費時，更會讓人覺得灰心無力。