| Hi hi 讀者們， 上次的 Logo 測驗有讀者跟我們炫耀只錯了一題，這次直接進階大魔王關卡，考你畫 logo！瞬間體會從選擇題到簡答題的天大差異，這跟美術天分有關係嗎🤣我跟 Liz 到第四題就直接棄賽⋯⋯推薦你找個人一起對戰，畫完還可以嘲笑對方在鬼畫符什麼東西。（怕你畫太認真忘記看本週選文，參賽連結會放在文末👀） Julie |
| [Podcast] 星箭廣播 EP106 | 五星推爆！聊聊生活中的評分系統 ⭐️⭐️⭐️⭐️⭐️（新角色登場！） 你踏進一家咖啡店前，會先在 Google Maps 看評價嗎？幾顆星以上的店可以讓你安心造訪？「看星等」「給評價」已經成為很多人生活的一部分，是我們開始或完成一次消費不可獲缺的儀式。本集《星箭廣播》我們要聊聊生活中的評分系統 ⭐️⭐️⭐️⭐️⭐️ 而且我們還要歡迎一位新角色登場！ 本集節目會分成三個部分，首先三位主持人會分享各種評分系統的使用經驗，例如 Google Maps、Uber Eats、Pinkoi 等各種網站或 app 裡的「評分」功能；第二部分我們會接著聊聊幾個令自己印象深刻的評分系統設計；最後會談到一些對於評分系統的觀察，例如：為什麼串流音樂服務普遍沒有星等評分機制？歡迎跟我們分享你對評分系統的觀察 。 |
| [英] 「字型大小」是個沒用的東西，我們得修好它 當你在編輯器裡設定 “font_size”: 32，指的到底是什麼意思？作者 Nikita Prokopov 從工程師的角度出發，輔以大量圖片探討「字型大小」（font size）這件事，他同時也是開源字體「Fira Code」的作者。他指出「“font_size”: 32」裡的「32」跟真正顯示出來的字體大小本身沒有任何關係，32 指的其實是從字體排印學發展而來的「點」（point）。 Nikita Prokopov 接著討論「em」這個我們在網頁設計上常看到、源自金屬活字的單位。他認為當前在電腦螢幕上量測字型大小的做法有幾個問題： 1. 難以預測，一個「16 pt」字型指的到底是多少像素（pixel）？ 2. 不實用，我們沒辦法說「我要一個 13 px 這麼高的字母 」。 3. 不穩定，你只要一換字體，就算「pt」一樣，不同字體實際顯示的大小就是有差。 4. 在不同作業系統的顯示大小不同。 為了要解決這個問題，他主張應該要以字體的「cap height」（大寫高度）而非 em square 為準；單位要是 pixel 而不是 point。文章後半段即是探討如何將他的主張落實到文字排版的行高。 不過，編輯推測 Nikita Prokopov 對於「相同尺寸的不同字體看起來不一樣大、行距不同，導致排版不同」這件事的看法，可能會遭到字體設計師的反對。文末有本文在 Hacker News 的連結，大家討論得相當熱烈，有近 350 則評論。 |
| [英] 當我們在測試 UI 時，我們到底在測試什麼？ 「為什麼它看起來／用起來就是不對勁？」網站或 App 推出新功能時，使用介面元素肯定都會連帶變更，這時就會產生一連串測試問題。專精於設計系統的開發者 Varun Vachhar 親自訪問了 Twilio、Adobe、Shopify、BBC 等公司的設計工程團隊，統整他們進行使用者介面測試的原則。 使用者介面要測試的東西非常繁瑣，包含：元件的視覺與狀態是否一如預期？多個元件組合起來時（composition）彼此是否運作良好，事件（events）互動是否順暢，accessibility 有沒有符合標準、是不是能讓所有人無痛使用？複雜的使用者步驟（例如填入表單）有沒有出差錯？文章中分別針對這幾大項提供各家公司正在嘗試的解決方法以及——大家最愛的——工具清單。 🧰 |
| [英] Notion 工程師給資料庫麻瓜的第一堂課 這幾年 Notion、Airtable、Coda 之類的軟體讓人輕鬆搭建工作生活資料庫，市面上也有許多課程教人如何利用 Notion 當一名生活駭客。如果你想更深入了解「資料庫」的運作原理跟邏輯，Notion 工程師 Chet Corcos 專為麻瓜寫的這篇入門指南，內容包含了資料庫、資訊架構的解釋，以及使用者生成資料的篩選過濾與排序，也很值得參考。 想像你正在管理一個警員識別卡的檔案櫃好了，你必須確保所有訊息都是最新，而且資訊隨時都可以被提取。剛開始的排序整理很好解決，就按照原始編號即可，一切有序美好⋯⋯但如果有一天某個員警調職或升遷到別的單位，就開始有麻煩了，資料可不是只有被抽掉那麼簡單；此外，如果財務人資想晉升符合某些條件的員警，身為管理檔案櫃的你要怎麼以最快的速度把資料調出來給對方呢？如果你是資料庫苦手，這篇文章寫得簡明易懂，也許能夠幫助到你！ |
| [中] KD Chang／簡明約耳趣談軟體（Joel on Software）導讀書摘 《約耳趣談軟體》是 Fog Creek Software 創辦人 Joel Spolsky 撰寫的軟體專案管理書籍的經典之作，集結軟體開發、人才培訓、創業經營與企業管理等現場實錄，筆法風趣且實用，可惜本書已經絕版，但最近台灣開發者 KD Chang 摘錄了本書部分內容，並且加上自己的心得，還沒讀過的朋友可以參考看看。 本文著重在解釋「約耳測試」，這是專案管理者能夠用來衡量軟體品質的問題清單，例如「你能用一個步驟建出所有結果嗎？」「你有一份最新的時程表嗎？」「你有寫規格嗎？」「你會先把問題都修好再寫新的程式碼嗎？」有志於協同工程師打造好軟體的管理者，都能使用這份清單隨時自我檢視。 此外，這篇文章還討論了一個有趣的問題：軟體的生產能夠像麥當勞炸薯條一樣有一套 SOP 可以依循，從而確保品質完全一致嗎？這是一個合理的期待嗎？🍟 🧵 深入閱讀 Joel Spolsky 的故事👉約耳談軟體：Joel Spolsky，身為軟體工程師，創業就是要為工程師創造更好的環境 |
| [中] 袁浩 / 利用 Apps Script 讓 Google 表單回覆自動產出 Google 文件 你如果常用 Google 表單蒐集回覆，可能得手動把一筆一筆的試算表資料建成不同 Google 文件，等到全部 key 完命也去了一半（？）作者袁浩原本發現 Google Form 擴充套件 FormPublisher 確實可以滿足「一收到表單資料就自動填到指定文件」的需求，但免費版額度只有 20 個。 這篇就是他手把手教你用 Google 開發的程式腳本平台 Apps Script 自製數量無上限的簡易版本（而且免費），只要試算表一收到用戶回應就會複製一份文件模板，並且將此回應自動填入該檔案。這麼實用的教學就算現在用不到也值得先收藏啦✨ |
| [中] Jeff Sia / 關於 UX 研究員作品集，一個研究員菜鳥的見解 作者 Jeff Sia 現任 104 人力銀行的 UX 研究員，這篇是他就職一年後以「菜鳥」角度分享的見解，像是為什麼明明是研究員，還要準備像設計師一樣的作品集？以及他幫忙看作品集過程中觀察到的現象，值得正在迎戰求職季的讀者參考。 例如，業界與學校 Project 在研究方法上有所不同，但 Persona 與 CJM 之外仍有許多成果值得放入。另外，研究員的價值展現在「如何對團隊產生貢獻」而不是「如何做出一個很棒的研究」，而自己如何與團隊合作產出成果卻是許多作品集常忽略的部分。 📌 作者今年初也更新了用戶研究兩年工作心得，有興趣的話也可以順便參考囉～ |
| 送上挑戰憑記憶畫 Logo 參賽連結 😎 啊對了，歡迎回信跟我們分享你的大師級畫作，我可以大聲說我自己前兩題畫的很讚～ |
（文章代表圖：Photo by Hello I’m Nik on Unsplash）