5/30 第十次萌典松 moed⑩ct

【主題】固定於單月底舉辦的 g0v 零時政府中型黑客松，五月於 5/30 舉辦。 【同場舉行】 ... 松松相連募集中，歡迎到 Hackpad 頁面填寫。 【共筆】請見 Hackpad 頁面 及 活動

Data Visualization and D3.js Course

Our Data Visualization and D3.js course teaches the fundamentals of creating visuals to communicate data through the use of HTML, CSS and SVG web standards.

mooon.＿

網路速讀｜手機應用程式優先的觀念可能過時了！

這篇是基於WHY ‘MOBILE FIRST’ MAY ALREADY BE OUTDATED這篇文章做的小結（小翻譯）與心得，圖片也都來自於原文 過去許多觀念標榜手機應用程式優先，但以手機裝置優先的許多公司開始開發優秀的網頁型應用程式。像是下列案例 Uber Flipboard Instagram Postmates SCREENS, NOT DEVICES 螢幕介面優先於裝置 手機並不是一個好的消費途徑或是發表資訊管道，不應沈迷於單一的方式，資訊應該是透過螢幕的選擇去傳達而不是裝置。多數人仍然使用大螢幕來操作，所以如果你是要開發一個給大公司又包山包海的應用程式，最好考慮使用大螢幕而非手機應用程式先行，此外，如果你的產品需要發表多餘140字以上或是照片，手機也不會是一個很好的選擇 IS “MOBILE ONLY” A NICHE TYPE OF BUSINESS? 專一開發手機是一個好的商業模式嗎？ 手機越來越普及、使用率越高是個事實，但不會只有手機，我們生活中會充斥著越來越多的螢幕介面，而非只有手機！不管是大螢幕或是手機，專一開發手機的應用程式可能不會是一個好選擇 以下圖表統計了一個人一天的活動： IS “MOBILE” SECONDARY FOR BUSINESS SOFTWARE? 那麼手機為次要開發的商業軟體嗎 許多商業都建議需要開發手機螢幕的應用程式，然而當人們在工作時，多數時間還是盯著公司電腦來收發信件、社交等等，想像一下你開發的是一個公司生產力的軟體，那麼大螢幕的應用程式就會較為重要，手機app則會扮演不同角色 “MOBILE” SERVICE BUSINESSES WILL LIKELY FAIL 單一手機服務可能會失敗 專一開發手機或是手機優先的軟體公司一開始可能有著不錯的表現，但未必長久，為了提供全方位的服務，必須在各種介面吸引使用者 FOCUS ON JOBS, THEN SCREENS, BUT NEVER DEVICES 專注在任務目的，再來是介面，從不會是手機優先 專注在使用者目標為首要，為那個族群、產品經驗服務，也許在手錶的顯示最好，又也許在40寸的螢幕上，思考什麼情境下才能達到產品的最佳化 簡短的帶過這篇文章，有興趣的人可以去看看，在我還來不及一瞧手機應用程式優先的這個概念前就看到這篇，的確是有點時代超越的感覺，另一方面也讓我想到一件事情，當科技快速進步時，很多時候會有大跳躍的情況發生，像是原本都在撥電話，一下子就換成智慧物聯網，搞不好連手機都沒了 在原文的下面有許多討論也很值得一看，有些人提出對於一個人的一天活動這件事的質疑，的確不是每一個人都像是知識工作者天天待在電腦前，那個手機裝置是否更加重要？ 但其實我很認同這篇文章，一個產品開發本來就不該專注於一個介面、裝置上，應該更專注於你的使用者是誰，這個族群、或是這個產品大多數的使用情境，像是這個產品是一個運動產品，那麼就應該在隨身裝置上先行開發，其他的介面則是次要的輔助，像是NIKE的APP，手機app是一個紀錄的裝置而web app是可以檢視、分享等等而未來的生活也會越來越多的介面出現，也許電磁爐就有介面、你的房門也有，所以產品就不會是手機優先了 像上述提到的slack、instagram或是asana、evernote這種app，我自己也覺得因為有了電腦的應用而更加方便，畢竟我工作的時候不會想一直看手機。

Modelo

Modelo, 3D for the web!

Gitbox 介紹

今天看到朋友討論 Git ，發現我用的 GUI - Gitbox 還真是不怎麼有名。所以來寫一點介紹推薦一下。為什麼我要使用以及推薦 Gitbox呢？最重要的原因是在 Gitbox 的界面之下，Git 的概念一點都不困難。 有朋友表示「實際去教人，有的人連add/commit/push 都搞不清楚在幹嘛」。其實我也是覺得 add/commit/push 的概念在CLI下非常抽象，但是在 Gitbox的畫面下就很清楚了： 中間的欄位是一個「歷史記錄」，右邊欄位裡面的檔案則是全部有更動的檔案。因為是全新的資料夾，所以兩個檔案都是新檔案（new file）。在 Git 你要選擇你要「加（add）」哪些更動到這次的「提交（commit）」，而不一定要提交全部的更動。例如這次我就只想要 commit 新增了README而已，我只要簡單打勾，然後寫個訊息： 然後，按下「commit」我們就多了一個 commit 記錄了： 簡單吧，就算你不知道 git add 是什麼鬼，打勾的東西才會存進去是看得懂的吧。 如果你不知道為什麼要 commit 的話，這邊有一個例子。我覺得新增README不是我要的 ，我就在「歷史記錄」的 init commit 上右鍵， 執行 reset branch ，意思就是把歷史倒退到這個 commit 上。結果就變成這樣： 哇！之前的修改通通不見了。這就是做設計用 Git 的好處，你東西寫錯了，可以反悔回到前幾步。 Git 比起單純的 history，最大的差別就是 Git 不只有一條線，Git 有 branch/merge/rebase 的能力。要用這些功能在 Gitbox 也很簡單。 要branch很簡單，就在下拉選單上而已。我們來做一個叫 prototype 的 branch，然後做一些事情： 在prototype上的事情做完以後，我們再到 master branch 上做一點事情，畫面會像這樣： 在上方 master ( merge) prototype 的意思是你在比較兩個 master 和 prototype 這兩個branch 的差異，中間的 merge 是你可以執行的動作。在 history 裡面&amp;hellip; 綠色圓點代表左邊（也就是工作中）的 branch（master）上存在的 但是不存在右邊的branch（prototype） 上的 commit。 藍色圓點代表右邊的 branch上存在的，但是不存在左邊（也就是工作中）的 branch 上的 commit。 我想要把 prototype 上的 commit 「融合（merge）」到 master 上，只要按中間那個按鈕就行了，相信你看到UI畫面也早就知道了。看，藍色圓點消失了，多了一個 commit。 如果你按下 command + shift，merge 會變成rebase，那結果又不一樣了。 在藍綠色點的對比之下，branch/merge/rebase 也不是很難懂的觀念了吧。我個人是覺得比其他 Git GUI裡會看到的「鐵道圖」還好理解。 在 SourceTree，fetch/pull/push/branch/merge 都在 toolbar上，在我看來這是很爛的UI，完全沒有經過設計。 但是在 Gitbox 就不一樣了： 你能做什麼事情，一目瞭然。雖然Gitbox 的UI一個圖示都沒有，但是在UX上可以說是大勝其他 Git GUI。 在 Gitbox 的幫助下，我在使用 Git 上是相當愉快而沒有感覺什麼難度的。雖然老實說我沒有真的很深入了解到 Git 的精華，就像使用 jQuery 而沒有很了解 JavaScript。但是在與 developer 的團隊合作上已經沒有什麼問題了。所以如果你真的搞不懂 Git 的話，我推薦你先用 Gitbox 看看。 <http://gitboxapp.com/>

Tumult Hype

Tumult Hype is the HTML5 creation app for Mac OS X. Animations and interactive content made with Tumult Hype work on desktops, smartphones and iPads. No coding required.

Designer Hangout

UX Community on Slack | Join the UX Slack Community

UX Designers and Researchers make technology better. This UX community is a resource for all of us to learn from each other. Join the UX community today.