| Hello 讀者們好， 不知道你會不會覺得上網愈來愈像在打怪了？一個名為「上網是什麼樣的體驗」的網站復刻了進入網站的歷程：從按下網頁連結的那一刻開始，就要跟各式各樣的彈出視窗對抗：Cookie 使用權、開啟推播通知、訂閱電子報、優惠方案⋯⋯左閃右闖，好不容易進入網站後，還有客服對話機器人、問卷評分的視窗等著被關掉，上下左右遍佈各處的廣告更不用說了。 這個網站在 Hacker News 上引發很多共鳴，有些網友聯想到更多惱人的設計，也有些人討論了原因。當然也有些人提供解套方法（通常是瀏覽器外掛、或直接禁用 JavaScript。當然，如果想重新體會被折磨的感覺，也要記得先暫停這些外掛哦 🥲）。 liz |
| [Podcast] 星箭廣播 EP121 | Oda：你買的不是音響，而是 Live House 的座位 Oda 是一家位於紐約的新創公司，唯一銷售的硬體商品是一對木製平面喇叭，除了以 line-in、藍牙播放你收藏的音樂，最特別的功能是收聽「現場表演」——Oda 販售訂閱制現場演出節目，由他們策展、安排藝術家表演，演出內容主要是音樂，也可能會有朗讀和訪談等聲音內容，唯一收聽管道就是透過 Oda 的喇叭。 為何 Oda 如此追求「僅此一刻，錯過不再有的聲音」？（提示：跟疫情無關）我們會聊聊 Oda 背後的故事、獨特的理念和商業模式，以及「聲音現場」這件事有何迷人之處？為何原本興趣缺缺的 Liz，最後卻很想買一對 Oda？你可能也會好奇：假如不可能時時刻刻都有藝術家做現場表演，那麼在每個節目中間 Oda 要播什麼？按下播放鍵你就知道囉。 |
| [英] 漫步與寫作：一名科技愛好者的做法 Craig Mod 過去曾在 Flipboard 等科技公司擔任設計師，但現在他以「寫作者」定義自己。他長期住在日本，癡迷於在森林古道中步行。Craig Mod 形容「步行」對自己而言是生產力系統，當他處在長途跋涉的模式中，創造力會自然地舒張開來，途中偶遇的各種人事物、觀察與交談，也都成為自己的養分。在 Superorganizers（超級組織者）電子報的專訪中，他描繪了自己如何靠著 Google Spreadsheet、Things、Ulysses、Figma 等科技工具縝密計畫步行與寫作，最大化這場心靈洗禮的收穫。 在這篇專訪中，Craig Mod 也談到自己經營「會員通訊」的哲學，他的步行以及許多作為都是為了寫成書籍，途中他也藉由低干擾性的方式如簡訊、快閃型電子報紀錄，分享自己的漫步歷程。他累積了一批衷心喜愛他的所見所聞的會員，也給予了實質報酬，支持他繼續進行自己喜愛的事。Craig Mod 提到，在這種時刻，有些人會掉入「鍍金牢籠」的陷阱：因為經營了一批忠實的粉絲而走上岔路，轉而教起寫作技能、經營會員的心法，而非持續以初衷為核心創作，這是他極力避免的事情。 |
| [英] 別讓開發者不開心：Slack API 六大設計原則 Slack App 商店 App Directory 吸引了接近 90 萬活躍開發者，打造別出心裁的功能，幫助 Slack 變成更強大的平台。串接簡單、說明清楚的 API 是提升開發者體驗的不二法門，最近 Slack 分享了他們的 API 設計原則，以及規範、審核跟測試 API 的流程。 他們提到，設計 API 時有時候容易落入渴望想一次解決問題的陷阱，但結果只會變得複雜臃腫。API 的設計應該根據特定的使用案例，專注解決單一問題，不但效能更好、更安全，未來也更容易擴展。另外，入門指南、教學、範例程式片段都需要撰寫清楚，如果能提供互動式測試工具更好。此外，錯誤訊息寫得愈明確愈好，像是 name_too_long（命名過長）就比 invalid_name ，減少開發者通靈的時間。如果 API 更新可能破壞既有程式或需要開發者配合調整，也要記得擬定日程跟溝通策略。 |
| [中] Aaron／《A Philosophy of Software Design》心得 I — 寫出複雜度低的軟體 不少開發者可能都有這樣的經驗：寫出來的程式雖然「可以動」，卻在往後的日子裡造成大麻煩，難以理解、修改跟維護，這有可能是程式碼一開始就寫得太複雜了 。本文作者 Aaron 閱讀史丹佛大學教授 John Ousterhout 著作《A Philosophy of Software Design》，整理出三個辨識程式碼複雜度過高的病徵。 如果程式碼常常牽一髮動全身，例如雖然分屬不同元件但色彩元素一致，卻因程式碼散落在不同頁面，導致每次都得手動修改，就是可以藉由將元件集中起來以讓修改連動的時機。另外，如果其他開發者需要多餘的知識或準備才能順利動用或閱讀你的程式碼，也是程式太複雜的警示燈 ⚠️。Aaron 也提到了降低複雜度的方法，code review 時老是有收不完的註解的話，可以參考這篇文章～ |
| [英] TikTok、Youtube、Pinterest、Spotify、Duolingo 怎麼設計 Tab bar 的？ 怎麼為 app 設計一個好看好用的 Tab Bar 呢？作者是一位 UI 設計師，他分析 TikTok、Youtube、Pinterest、Spotify、Instagram、Slack、Duolingo 的 Tab bar，並總結出八個設計重點，包括：tab 數量以 4～5 個為佳，並把同類型功能合併於同一個 tab；必要時可以像 Youtube 一樣，在 Tab bar 的 icon 加上文字說明（但 Pinterest 在這方面又更進階，等你用一段時間後會發現文字說明默默隱藏了）；像 Duolingo 和冥想 app Headspace 的 Tab bar 則以顏色和線條提示使用者在 app 的位置，發揮 Tab bar 的引導作用。 對了，作者也提醒，像計算機、日曆 app 或 Uber 並沒有 Tab bar 的設計，所以記得要先評估你的 app 是否有 Tab bar 存在的必要性。 |
| [中] 最會回答問題的那個男人：Stack Overflow 傳奇人物 Jon Skeet 我們曾經在週報介紹〈如何在 Stack Overflow 上問好問題〉，那篇文章的作者 Jon Skeet 是 Stack Overflow 最活躍使用者之一，reputation 十年內就破百萬，總共回答超過三萬個問題，最高峰的時候每個月平均回答 800 個問題，而且他同時在 Google 工作，資歷將近 14 年。 不過，承載了各種浮誇光環的 Jon Skeet 仍有相對平凡的一面——他曾經受「冒牌者症候群」所苦；接過主管職半年，最後還是選擇退回原位；以為自己會繼續在數學領域深造，後來卻也放棄攻讀博士⋯⋯ |
| [英] 我用兩個 AirTag 找回失竊的電動滑板車 作者 Dan Guido 是一家資安公司的 CEO，這串推文是他分享自己利用 AirTag、蘋果 Find My 網路和 UWB（超寬頻）技術找回失竊滑板車的經歷。比較特別的是 Dan 在車上裝了兩個 AirTag，原因可以參考內文，他對整個過程做了詳細的紀錄。其實整件事並沒有很順利，其中一個因素是當地警方不熟悉 AirTag，在回應上比較謹慎。 一開始 Dan 只能大略找出車輛定位，而且急著趕飛機的他原本已經要放棄（AirTag 具備會發出聲音的反追蹤功能），沒想到過了一週回來後發現 AirTag 還沒被移除，最後透過 UWB 技術和警方的協助，在一家單車店找到失竊的滑板車。Dan 學到幾件事，例如不要立刻開啟「遺失模式」、要在反追蹤功能啟動前行動，最重要的是務必尋求警方協助。（即便有警察陪同，他還是受到店家員工言語和肢體上的威脅。） |
| [中] MH／身為 PM，該怎麼評估一項新需求？身為需求端，又該怎麼跟 PM 提需求？ 「到底要怎樣跟 PM 提需求，他們才聽得懂？」「為什麼那些需求端怎麼講都講不聽？需求不是這樣提的！」 當 PM 在乎的是該怎麼評估一項新需求，而需求端又重視該怎麼提（不會被 PM 打槍的）需求，所以常見雙方在溝通上有落差。 作者剛好是「需求端」（行銷）出身，後來轉職為「接收需求端」的 PM，也觀察到這樣的現象。他從 PM 視角出發，先介紹 PM 接到一項需求後通常會開始思考的五個問題，包括商業價值和副作用等等，這些也是 PM 評估其緊急度、可行性與必要性的參照點；接著個別分享需求端（如業務、行銷、BD、客服等）該如何「正中下懷」，根據 PM 評估標準去描述自己的需求。 |
（文章代表圖：Photo by Kelly Sikkema on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出