哈囉讀者: 前陣子我開始在 Twitter 上看到許多含有「🟨🟩」emoji 的貼文,長得像這樣: Wordle 207 5/6 🟨🟨⬜️⬜️⬜️ ⬜️🟨🟨🟨⬜️ 🟨🟩⬜️🟩⬜️ ⬜️🟩⬜️🟩🟩 🟩🟩🟩🟩🟩 後來才知道原來那是拼字遊戲「Wordle」的玩家們在分享自己的成績。這個突然爆紅的遊戲設計看似簡單卻富有巧思,規則是你有六次機會憑空猜出由五個字母拼成的英文單字,灰色代表單字裡沒有這個字母,黃色代表字母對了但位置錯誤,綠色則是完全正確,每天只會有一題。 這個遊戲原本只是開發者 Josh Wardle 開發給喜歡拼字遊戲的伴侶玩的,他發現網友開始在社群網站上以彩色格子 emoji 在不爆雷的情況下分享遊戲分數,於是後來也加上這個設計。遊戲提供色盲模式,喜歡暗色系的網友也可以選暗黑主題,或是你也可以挑戰「困難模式」,快來跟我們分享成績吧!🟨🟩 Titan |
[Podcast] 星箭廣播 EP141 | 神力搜尋框:解決「這個功能在哪裡?」的介面設計(同場加映好用 App 推薦) 我們在138 集聊到 macOS menu bar(功能列表)的設計跟一些相關工具,這集 Titan 跟 Liz 要跟大家聊聊他們很喜歡的一種設計「神力搜尋框」(power bar)。進入正題前,Liz 會先分享她前陣子趁著節慶特價訂閱的 Setapp。兩位主持人也會分享他們對這種「軟體吃到飽」模式的看法。 Power bar 這個被我們稱為「神力搜尋框」的設計,指的是在軟體中以快速鍵叫出搜尋框,輸入你要執行的功能名稱來執行。這個源自「command palette」(指令面板)可能開發者們都很熟悉,但不寫程式的 Titan 跟 Liz 為什麼也喜歡這種設計呢?它有什麼好處?節目後段,Liz 會跟大家分享她愛用的番茄鐘工具,而受不了 Dropbox 越來越「笨重」的 Titan 前陣子改用第三方 Dropbox app「Maestral」,順便聊聊前陣子 Dropbox 惹毛 Mac 使用者的事件。 |
[英] 給前端工程師的命名指南 「電腦科學領域中兩個最令人頭痛的事,其中之一是處理快取失效(cache invalidation),另外一個則是命名(naming)。」90 年代知名軟體公司 Netscape 工程師 Phil Karlton 曾經留下這句經典名言。本文作者 Frank M. Taylor 分享了前端程式命名的簡易指南,分成 CSS class、CSS pre-processor 與 JavaScript 三大部分,羅列命名時應該考慮的問題,例如函式的作用是回傳值還是執行功能,就有不同的命名方法。 作者 Frank M. Taylor 說,「別讓團隊成員因為爛透了的命名詛咒自己,別忘記未來的自己也是團隊成員」如果明明邏輯沒問題,但老是在命名上卡關,或常常因為當初的隨便命名而讓後來的自己後悔莫及,這篇文章應該頗值得參考。 |
[中] 董福興/數位出版中的 Accessibility 作者董福興多年深耕 W3C(全球資訊網協會),其中一項重要業務即是「無障礙」的推廣,同樣一種數位素材,在科技的輔助下,如果能夠規範化,就能以多元的形式呈現,讓使用者可以選用閱讀或聆聽模式吸收。 本文解釋了「無障礙」在網頁與數位出版實際執行層面上的差異,以及歐盟無障礙法的簡史,數位出版(EPUB 格式)的達成要件。文章最後也提到台灣制定無障礙,並且提出了「無障礙」並非做愛心、而是「完善基礎建設」的心態。推薦給對無障礙推廣感興趣的讀者。 |
[英] 跟 Alan Kay 一起吃午餐是什麼樣的體驗? 這是 2019 年的文章,作者 Steve Krouse 經營一個程式社群 Future of Coding,他意外得到一個跟 Alan Kay 共進午餐的機會。這位電腦界傳奇人物在餐桌上發表了許多有意思的觀點,(他們吃了五小時。)我們在此簡述幾句,詳細的內容請大家閱讀內文。 Alan Kay 認為大學教育雖有缺點,但仍比自學更好,前者恰好能強迫你學習自己不喜歡或是沒有意識到其重要性的知識。Alan Kay 覺得作者對維基百科、Scratch、Python 和 Linux 等非營利工具的欽佩是種「錯置的達爾文主義」,把「受歡迎」跟「好」畫上等號。Alan Kay 批評了幾件事:膚淺的程式推廣教育其實有害,各種「code for all」運動就像「吉他英雄」(之於學習彈奏吉他);今日的電腦科學家活在一種流行文化裡,對領域的歷史並不瞭解;他很擔憂創投跟新創公司的「矽谷心態」,覺得人們不必「move fast and break things」,相反地,應該像建築師以百年為尺度建造大教堂那樣,慢慢地打造可以長久存續的美好事物。Alan Kay 還警告,年輕人過早立下目標可能會窄化視野,因為他們甚至不知道自己不知道什麼。 有趣的是,Alan Kay 看起來對作者一無所知,也沒說明為何他願意來吃這頓飯,作者試圖從飯局中的談話推敲出原因,也許這就是為什麼大神們會跟網友們見面吃飯?XD |
[英] Uber 跟麥當勞有什麼共通點?它們都是 API 的集合體 許多熱門但功能大異其趣的 app,從 Google Maps 到 Excel,說穿了其實都是 API 的集合。本文作者 Justin Gage 解釋了 API 的基本原理、API 在前端、後端的「合作」上扮演什麼角色,儘管 API 大致的概念就是提供資料輸入、輸出的介面,但每個人口中的 API,意思可能還是不太相同。 除了僅供內部使用的 API、以及開放外部運用的 API,他們大多用來執行特定功能,但也有一種 API 是程式碼介面,如 JavaScript 中的 `array.sort() method` 也是一種 API。這篇文章進一步釐清 API 的類型與任務,也提供了簡單的手繪圖表,推薦給對 API 概念還有點模糊的讀者 👾 |
[英] 打字速度快是一項高投報率的技能 Brian Lovin 在 GitHub 擔任 Staff Product Designer,他說不管是對設計師、工程師或 PM 來說,打字慢都會干擾思緒,變成進入心流的絆腳石,他認為打字速度是技術領域最高槓桿(high-leverage)的技能之一。 他把打字慢比喻為「背著一個打開的降落傘跑步」,雖然是在跑步沒錯,卻剝奪了跑步本身的樂趣——所以打字速度快會帶來「自己可以控制這台機器」這種神奇的感覺,有讀者可以共感嗎?(我打字超龜速,好想體會一下喔😂)他也說當打字跟得上思維的速度,就會啟動一個強大的正向循環。本文分享幾個加速打字和幫助你練習的訣竅,但在這之前,他建議要先認知到自己打字很慢。(作者有提到他是怎麼辨識的) |
[中] Mark Liang/【職場日常】設計團隊的打造歷程 作者剛加入 KKBOX 時並沒有設計團隊或設計主管,所以他擔任設計主管這一年來花了不少時間做基礎建設,他回顧這個過程中的嘗試與階段性成果,包括文化塑造、品質與效率的確立與設計影響力的發揮。 初期先有週會以及每月一定要和成員 1:1,後期他則新增相對非正式的 Happy Designer’s Friday(不過為什麼他說這個機制也有缺陷呢?)。另外,年初導入 Figma 如何幫助團隊並建立產品的設計系統?怎麼貢獻產品開發的主導能力,進而激起團隊整體士氣?好奇打造一個設計團隊會經歷哪些事的讀者不妨參考這篇分享⚡️ |
[中] 卡米哥/軟體開發者的培養 作者接觸程式的資歷約 20 年,本文從他的學習歷程聊聊,剛入門的軟體開發者到成為資深軟體開發者會經歷什麼、價值觀會有哪些變化,以及互相衝突的價值觀該如何取捨、排出優先程度? 像他一開始認為最短程式碼的解決方案就是最佳解,不過接著就開始重視執行、修改、理解和測試程式碼的成本;他一開始以為只會用套件做東西的人很弱,但現在不這樣想了。過程中也逐漸養成「通靈」、維護任何技術等級的程式碼的能力等等,最後作者分享過往帶人經驗中,自己體會到培養新進軟體開發者的眉角和心態。 |
(文章代表圖:Photo by Melanie Deziel on Unsplash)
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出