| Hihi 讀者， 最近《沙丘》在美國上映了，《Vice》把 2014 年編劇 Eric Roth 談創作的影片挖出來，發現原來電影裡無邊無際的景觀，可能是從上古作業系統 MS-DOS 誕生的！這台用來寫作的電腦不能上網，也不能收發 Email，那他要怎麼把劇本交給其他人呢？很有意思的訪談，還能一窺編劇的書房以及培養靈感的方式，推薦給讀者～ 另外，奇幻小說《冰與火之歌》作者 George Martin 也是用 MS-DOS 文書軟體 WordStar 寫出來的！不得不說，一台連不上網路、跑得動古董軟體的電腦才能創造最極致的「想像力模式」，是不是比最新推出的 MacBook Pro 更讓人心動 💖（還是只有我覺得 🥺） lily |
| [Podcast] 星箭廣播 EP130 | 從商店裡的角落生物變身成實聯制門神：聊聊「條碼」 你還記得自己第一次掃 QR code 是什麼時候嗎？經歷疫情洗禮，許多生活在台灣的聽眾應該已經很熟悉進入公共場所前要用手機掃一下實聯制 QR code。上一集《星箭廣播》講了掃地機器人的故事，這次 Titan 跟 Liz 要聊聊另一個充斥在我們生活裡，平常卻不太會特別留意的科技：條碼。 Liz 會先跟大家聊聊已經發明超過半世紀的一維條碼（barcode），回顧當年的靈感來源與時空背景，接著 Titan 談另一個誕生於 90 年代、年輕許多的 QR code，看看它跟一維條碼有何不同，當中有哪些巧妙的設計，其中一個令 Titan 感到非常有趣的是一維條碼與二維條碼都具備的「檢查碼」概念。我們也會跟大家分享一些過去大眾與媒體對條碼的看法，以及創業者跟企業家是怎麼看待條碼這項被稱為「實體超連結」的技術。 |
| [英] 寫給軟體工程師的「搜尋技術」評估指南 如果想在產品裡加入搜尋引擎又該怎麼做？本文作者建議，不要重新發明輪子，善用現成的搜尋引擎服務可以節省很多時間。但如果只是把搜尋框裝到自己的產品裡，但全然無視複雜性，反而可能造成使用體驗災難、浪費開發資源。這也是作者寫這篇文章的目的：解釋搜尋引擎的運作原理，幫助工程師評估最符合需求的作法或服務。 作者分享了影響搜尋引擎的因子，例如文件檔案容量範圍、多媒體、索引速度，還有搜尋時是否需要因應變更搜尋結果，例如地理位置、時間。他還提供了目前較流行的搜尋實作方法與演算法，並且推薦了幾個技術跟工具，例如；最後他也提到，除了搜尋功能之外，預算支不支援、流量扛不扛得住都是需要考慮的因素。 |
| [英] iPod 為了保密做得跟 Mac 一樣大！首度曝光的原型機長這樣（圖多） 扭轉蘋果公司命運的 iPod 推出滿 20 年了，獨立軟體公司 Panic 在部落格上展出元祖 iPod 原型機之一做為慶祝，共同創辦人 Cabel Sasser 從公司的櫥櫃裡撈出一個「神秘的」初代 iPod 原型機，展示許多高解析度、各種角度的照片，還把外殼打開讓大家一探究竟：黃色的塑膠外殼，右上角有一個小小的螢幕，左邊的圓形轉盤應是 iPod 著名的觸控轉盤，右側是為了方便測試的 JTAG，下方則是直式排列的四個方向鍵。 這部原型機約有 MacBook 那麼大，厚度更是好幾倍。Cabel Sasser 打開外殼後發現內部設計在尺寸上已經很接近後來的 iPod，零件標籤上的日期「2001.9.3」距離發表日期甚至不到兩個月。（iPod 開發期是有名的短）「iPod 之父」Tony Fadell 在 Twitter 上證實這是當年趕在產品外觀設計定案前做出來的原型機之一，為了保密原因所以按鍵跟轉盤按鈕才做成那樣。「裡面裝的大部分是空氣。」Cabel Sasser 還在文章裡揭露了一個 iPod 介面裡的彩蛋，表示這是蘋果最令他欣賞的地方——工程師和設計師總是可以在事情還沒有搞得這麼大之前「玩」一下。（媒體注意到之後，蘋果就在新版軟體移除了那個彩蛋。） |
| [英] 如果你討厭電子書，這不是你的錯 你也曾經嘗試使用電子書，但無論如何就是無法像閱讀紙本書一樣進入心流嗎？這篇文章也許可以提供一些解答。本文作者 Ian Bogost 對紙本書有著根深蒂固的偏執，他生動描繪了書的古老特性與細節，如何形成了他們念茲在茲的「書卷氣（bookish）」，以及「閱讀」行為與書本特性無法分割的原因。 他形容了紙本書塑造的沉浸感，一本展開的書，宛如一座山谷，創造了一個讓你可以進入的空間，並且被它包圍；也描寫了印刷書籍裝幀的細節，像是精裝書防止封面跟書頁分離的縫製痕跡。而電子書又是因為哪些設計限制而無法複製這種「書卷氣」？未來電子裝置有可能達成作者的理想嗎？他一點也不抱期望，同時認為，這跟技術也許無關⋯⋯ 作者 Ian Bogost 的背景也很有趣，曾經是一名電子遊戲設計師，現在則是作家，也在大學裡教授電影與媒體學。文中對紙本書的解構佔了大部分篇幅，但電子書廠牌跟設計史的討論也不少，推薦給對「書」的形式有 興趣的讀者 👩🏫 |
| [英] 身為獨立開發者，我提供電話客服半年後的收穫 日本的獨立開發者 Non Umemoto 在 2017 年為他的兩款 app 提供國內電話客服半年多後，寫下這篇心得。主要是下載量並不高所以來電不多，偶爾才會一天接到 2 通，對他的負擔並不大。但他透過與形形色色的使用者通話而收穫不少，特別是情感上的支持力量。 他提到，有人直接感謝自己的那種快樂是看 app 評論的數十倍，有一次他甚至被使用者在電話中的道謝感動哭。當然，他也得應對怒氣沖沖的來電，這讓他發現使用者因操作上的理解困難比起 app 有 bug 來電會更頻繁，通話流露的「情緒」也能讓他識別出問題的急迫和困擾程度，調整開發的優先順序。不過，傾聽使用者描述問題、達成理解共識，再用對方能懂的說法解釋清楚，才是最有挑戰的部分。 （編輯很好奇他是否還持續提供電話客服，結果發現這樣運行四年多後，今年 7 月開始他只保留 email 作為客服管道了🤔） |
| [中] 鄭斐凡／如何建立設計系統，然後失敗。 這是一個執行設計系統的失敗經驗分享（⚠️並沒有扭轉局面最後成功的情節），寫實呈現「船到橋頭才不會自然直」和「接二連三失敗並且集體失憶」的血淚過程。作者擁有更豐富的管理與專案經驗後再回頭看這次失敗，在文末點出究竟踩了哪些坑。 當時剛進公司就被委以重任的作者認為應該重整設計流程，順利徵得主管認可也熱情滿滿的找團隊召開啟動會議——故事的一開始向來都是美好的。結果到交付顏色與字體系統設計的那天卻迎來「大家覺得不說些什麼會大事不妙，但卻不知道怎麼給建議」的沈默氣氛，她才發現事情會自動走上正軌的想法太天真了。甚至早在自己意識到失敗前，專案早就已經死得透心涼⋯⋯ |
| [中] Ian Wu／產品經理（Product Manager）與數據分析的那些事 — 談思維與數據策略 作者擔任產品經理時，累積了產品與商業數據的分析經驗，他在本文分享實務上開始數據分析的流程——數據需求來源、指標的選擇、規劃收集數據的路徑、把資料變乾淨、數據驗證和視覺化，以及最後在數據中找出關鍵並訂出行動方案的步驟。希望這篇會讓你做產品決策和行動推展時更有頭緒～ 數據分析領域包山包海，作者認為產品經理除了 domain know-how，如果具備基礎統計學跟數據思維，有利於與團隊一起定義出標的、場景、限制與預期產出，日後在分析數據的溝通會比較順暢，並幫自己做出正確判斷。他也提到，通常簡易、量級小、即時性的數據會由 PM 自己透過工具處理，能省下跨部門的溝通成本。 |
| [中] Jennifer Lu／身為一個 UX 設計師，我重寫了 FAQ FAQ（常見問答）幾乎是每個服務的標準配備，讀者應該也都有過拉到網頁底部或點選「常見問答」連結找答案的經驗吧？但在公司內部，FAQ 這個區塊應該由誰負責？其實 UX 設計師可以扮演領導角色。 本文作者 Jennifer Lu 分享了自己在 AlfredCamera 統整 FAQ 的經驗，從整理既有的 FAQ 內容發現問題、釐清使用者閱讀 FAQ 的目的，藉由使用者旅程思考分層、接著規劃分明的資訊架構，將原本的長篇文章拆成一個個小而精準的解答，而且各自都有適合的歸屬。那，FAQ 的內容由誰來撰寫呢？ |
（文章代表圖：Photo by Chase Chappell on Unsplash）
本文依 CC 創用姓名標示 - 非商業性 - 相同方式分享 4.0 國際釋出